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

[John Leslie <[e-mail]>]

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