Re: [tsvwg] draft-stewart-tsvwg-sctpecn

["Scheffenegger, Richard" <[e-mail]>]

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...

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), then the counter can increase continuously. Understanding the concept (counter with reset, pure counter) would answer what the receiver is to do when the counter hits 2^32-1...

I am bringing this up because for TCP, a single bit counter is insufficient for the requirements of Conex; and I want to understand if the signaling scheme was given thorough thought that I could leverage for a redesign in the TCP space...


I do agree, that when one excludes misbehaving implementations, this question is more of academic interest rather than a true issue of a deployment following the draft, owed to the large counter.

Richard Scheffenegger

> -----Original Message-----
> From: Randy Stewart [mailto:[e-mail]]
> Sent: Freitag, 03. August 2012 08:53
> To: Scheffenegger, Richard
> Cc: [e-mail]; [e-mail]; [e-mail];
> Matthew Mathis ([e-mail]); [e-mail]
> Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn
> 
> Richard:
> 
> Hmm
> 
> Re-reading the document a bit, I don't see that it does not tell you to
> retransmit the chunk in the receiver side (5.3) we state:
> 
> "
> After transmission of the ECN Echo chunk, usually bundled with the
>    SACK, the receiver does NOT discard the ECN Echo chunk.  Instead it
>    keeps the chunk in its queue and continues to send this chunk bundled
>    with at least a SACK chunk on each outgoing packet, updating it as
>    described above if other CE codepoint data packets arrive.  The ECN
>    Echo chunk should only be discarded when a CWR Chunk arrives holding
>    a TSN value that is greater than or equal to the value inside the ECN
>    Echo Chunk.
> "
> 
> If this is not clear enough please let me know a wording that would make
> it clearer.
> 
> Note that the ECN echo continues to be received until a CWR shows up with
> a TSN number at least as big as the TSN sent in the ECN Echo.
> 
> R
> 
> On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote:
> 
> > 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?
> >
> > Does it allow for special use cases, which cannot be addressed by either
> handshake or simple counter alone?
> >
> > I'm very interested in the answers to the last two questions, as I am
> one of the authors of an Accurate ECN feedback draft for TCP, and TCPM has
> a milestone to define an appropriate (accurate) feedback mechanism that
> allows more than 1 bit per RTT...
> >
> > Best regards,
> >
> > Richard Scheffenegger
> >
> >> draft-stewart-tsvwg-sctpecn-02
> >> Partially replaces (draft-stewart-tsvwg-sctp-nonce)
> >> IETF-78 suggested there was interest in this topic.
> >> Discussed at IETF-83, Paris.
> >> DUE: ECN is within the TSVWG Charter, will call for adoption on the
> >> list.
> >> Please comment on list.
> >
> >
> 
> -----
> Randall Stewart
> [e-mail]
> 
> 
>