3 Aug 2012 01:58
draft-stewart-tsvwg-sctpecn
Scheffenegger, Richard <rs <at> netapp.com>
2012-08-02 23:58:26 GMT
2012-08-02 23:58:26 GMT
Hi, While looking as to how other protocol do ECN feedback signaling, I found that this draft is missing (at least not mentioning) an interesting detail. The existence of a CWR Chunk indicates, that the feedback signal is supposed to be reliable. However, the ECN Echo chunk defines the Number of CE marked Packets as 32-bit unsigned int, and does not specify how a receiver should behave it never received a CWR chunk... The sheer size of the ECN Echo chunk would lend itself to be a simple feedback signal, without any explicit signal from the sender. Historically, in RFC4960, it appears that this chunk effectively contained only a single bit (no counter; only the presence of the chunk). In order to establish a reliable feedback for at most one ECN signal per RTT, a handshake mechanism (CWR chunk) is required. That mechanism was very much alike what TCP does with ECE / CWR. IMHO, this draft should be more clear around the mechanism: If a handshake is required, the 32-bit counter MUST NOT roll over at 2^32-1, but remain at that value until CWR is received. The sheer size of the counter however makes it highly unlikely that the sender will not receive a signal (before the session collapses for lack of feedback from the receiver). So a handshake-less (CWR chunk optional on the sender?) is also feasible, but then the ECN counter MUST roll over... As it stands now, the counter rolls over, and is reset via CWR... Are there any specific reasons for this chimera mechanism?(Continue reading)
On Aug 3, 2012, at 12:17 PM, Scheffenegger, Richard wrote:
> Hi Randy,
>
> My point being, that it is not clear, architecturally, if the mechanism implements a reliable feedback,
or not.
>
> The way TCP (3168) signals ECN is, that you have a counter that counts up to a specific maximum value, and
remains at that value until reset. In TCP, that counter is only 1 bit (ECE), and CWR is the reset signal.
>
> Now, when the counter is large enough (5+ bits), the resiliency no longer requires a reset signal
(statistically), as the counter is increasingly unlikely to wrap over unnoticed. So with a 32 bit
counter, you can do away with the CWR signal entirely. Or is there any use to the receiver to know when the
sender has reacted to congestion (by an unknown extent)? (Historically, SCTP implemented the same
one-bit counter/reset scheme that TCP did, IIRC; so CWR is really only relevant for legacy
compatibility, correct?).
>
> Since the receiver resets the ECN counter only if it receives a CWR with the appropriate TSN, that means
that you implicitly require at least one RTT without a CE mark, for that to happen…
Correct.
>
> Assume a pretty congested network, where you'll get one CE mark per RTT (and the source doesn't react
traditionally with halving the sending rate),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RSS Feed