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

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

Thanks John,

I think I understand now what you are saying - at least to my understanding, you weren't as explicit over in the TCPM WG list :)

Let me discuss these considerations with my co-author, perhaps we can come up with a proper way to encode all these signals appropriately.

Any thoughts as to the exact sequence of CE marks being seen on the receiver side? (I think that this will be too much information, better served by some kind of explicit byte-congestion counter, that has similar properties to a packet-congestion counter).

Best regards,


Richard Scheffenegger


> -----Original Message-----
> From: John Leslie [mailto:[e-mail]]
> Sent: Freitag, 03. August 2012 18:03
> To: Scheffenegger, Richard
> Cc: Randy Stewart; [e-mail]
> Subject: Re: [tsvwg] draft-stewart-tsvwg-sctpecn
> 
> Scheffenegger, Richard <[e-mail]> wrote:
> >
> > Suppose you are restricted on bits available to signal the congestion
> > back to the sender, would you implement a continuously increasing
> > counter (that eventually wraps), or a gauge that only increases up to
> > a certain point before requiring an explicit reset.
> 
>    [tcpm] is facing this issue for TCP: I haven't posted an opinion
> there yet; but frankly my opinion is that a counter that wraps is a
> better mechanism. It end-runs a lot of race conditions.
> 
>    I don't know the exact details for SCTP -- but it seems avoiding
> race conditions would be best here, too.
> 
> > Independently from this, do you see value in letting the receiver
> > (and implicitly, the network) explicitly know that the sender
> > (supposedly) did perform a congestion control reaction?
> 
>    There is arguably some value in that; but it tends to strike me as
> a MAY rather than a MUST.
> 
> > Think of this scenario as when the send window (# packets) is larger
> > than the largest value that the counter could hold; With TCP, that
> > happens with windows > 1 packet; with this draft, when the window
> > grows beyond 2^32 packets (purely hypothetical).
> 
>    TCP, here, serves only as a bad example IMHO. The one-bit counter
> was barely adequate when first specified, and can never pass more than
> one event per RTT. This is already considered inadequate for things we
> want TCP to do today.
> 
>    IMHO, if there is a CWR indication at all, it deserves to be the
> value of the ECE counter when the window was reduced -- thus as many
> bits as the ECE counter. Again, this end-runs race conditions.
> 
>    (The mechanism is analogous to the circular-buffer algorithms from
> the 1960s when we dealt with shared-memory communication between
> processes that could interrupt each other.)
> 
> --
> John Leslie <[e-mail]>