[e2e] Can feedback be generated more fast in ECN?

[Eric A. Hall]

I will ignore the question of whether this 5% scenario requires both ends
to stutter within a single RTT.

> In 5% of SQ'd cases, the sender won't slow down.

This requires a lot of assumptions.

  It requires all of the original data from the sufficiently-large
  cwin to get through the receiver-side congestion.

  It requires SQ to be discarded (granted).

  It requires the trailing ACK to survive so that rwin on the
  sender can be shifted without affecting cwin.

  It requires that the trailing ACK arrive within a reasonable
  amount of time.

Even after all of that, it also assumes that the next burst won't trigger
another SQ or inbound loss, and that the subsequent SQ will also be eaten
while the trailing ACK won't, ad infinitum. We are moving from marginal
probability into fractional.

I can assure you that a sender will almost certainly slow down in the face
of 5% bi-directional loss, even without the use of SQ or ECN.

> Even in the miniscule fraction of times the sender doesn't 'reliably'
> get the explicit congestion signal, the sender still gets an implicit
> congestion signal and slows down.

The "implicit" TCP mechanisms work for SQ just like they do for ECN.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/