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

[Randy Stewart <[e-mail]>]

Richard:

Well maybe am mis-understanding your comments. Are you concerned
that the counter really should not roll over?

This would require 2Billion attempts at sending an update CWR. This is a bit
far-fetched so I never thought about it ever happening.

Now the counter does not have a defined use, sort of like the duplicate receipts of TSN's
in the SACK. I was playing with it actually in a different CC algorithm and thought it 
was a good idea to have for future work since its easily obtainable.

As far as what to do when you don't get a CWR… hmm let me re-read the document. You are
supposed to (like TCP) continue to retransmit ECN Echo chunks until a CWR is received

Maybe I missed that statement in the document.

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]