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

[Jon Crowcroft]

In message <3A8B9481.F64EB1B9 at ehsco.com>, "Eric A. Hall" typed:


a rule of thumb for dimensioning buffers at a router is to have a
bandwidth*delays worth - thhis means that under peak correlated input
load from a set of TCPs in linear increase mode, we wont lose anything, 
but under a burst (e.g. from a UDP or a set of correlated TCPs starting in expo
mode) we see loss...

now normally, patterns dont have too many of bottlenecks (unless 
you traverse several continents) so i'd say that it would be weird in
a modern net to see the RTT variance be more than the RTT on a long
path.

oh, and 30% Loss means you either have under bufered routers, or
severe overload where there's either lotsa unresponsive
 streaming traffic , or you are in a severe underprovisioned case
(yes, i know this happens in developing regions more (e.g. like
england to us links in the recent past:-))

but even then, the delay contribution from queueing ought to be on the
same order as the actual RTT (surely) - in fact, shouldnt it even be
bounded (well, no, i spose in practice you might get unlucky and have
multiple bottlenecks due to the old car park type traffic pattern in
which case it will be maxed out at (bottleneck_hops+1) * RTT
so i spose pathologically, we might see (hop+1)*RTT as the variance on
RTT...hmmm....of course, the probability of a traffic pattern
sustaining for long like this is incredibly low (there's a calculation
based on indepenence assumptions at the end of the old EF diff serve
doc...i seem to recall)



 >>
 >>Alhussein Abouzeid wrote:
 >>
 >>> Is a saving of a fraction of one RTT worth using an additional signaling
 >>> protocol instead of setting a bit in a packet that is anyway going to be
 >>> generated in the network ?
 >>> 
 >>> Looking at a lot of analytic and simulative work for
 >>> TCP, I have never seen any drastic effect of not accounting for the time
 >>> between the transmission of a congestion notification (be it ECN or
 >>> SQ) and the throttling response by the source, as long as this time is
 >>> within the order of one round-trip time.
 >>
 >>I have a hard time believing that the average delivery time for a
 >>bulk-flow ACK is one RTT when faced with serious congestion. Assuming the
 >>best case scenario of no packet loss and trivial delay, it will be
 >>slightly greater than one RTT if the recipient is capable of sending an
 >>ACK immediately. Worst case (collapse or link failure) is infinity/never.
 >>
 >>One form of the question then is whether fast response via SQ of a lossy
 >>link is better than waiting for timeout. Or rather, does this occur often
 >>enough for it to be useful. I see highly congested links every day (>30%
 >>loss, which might as well be down for all practical uses) so I think so.
 >>
 >>Another aspect to this is the ability to shutup the sender quickly. That's
 >>the idea right? It's not to tell the sender "stop wasting your breath,
 >>nothing's coming back" it's to tell the sender "please stop filling me up
 >>with your packets." Faster notification is absolutely better if that's the
 >>principle objective.
 >>
 >>Is there enough of a performance difference between SQ and ECN for links
 >>which are not yet crippled? Probably not, and riding on ACKs is cheaper if
 >>you know they will arrive. It may very well be that ECN is better for
 >>operational links which are becoming congested, while SQ is better for
 >>crippled links which are approaching teetering mass.
 >>
 >>-- 
 >>Eric A. Hall                                        http://www.ehsco.com/
 >>Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

 cheers

   jon