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

[Eric A. Hall]

Neil Spring wrote:

> > it never goes to zero benefit unless the alert itself is lost
> > (which, btw, is equally possible with SQ and ACKs if you've
> > really got that much congestion on the return path). IE, there
> > is always >0 benefit, except in those cases where it is 0 for
> > everybody.
> 
> If an ACK carrying the ECN-echo bit is lost, this matters
> very little, since subsequent ACKs will also contain
> the ECN-echo bit until the sender acknowledges it with
> the Congestion Window Reduced (CWR) bit.  So, while the
> probability of loss on the return path is the same for
> SQ and an ACK, the consequences of loss are significant
> for SQ and insignificant for ECN-ACKs.  In this sense,
> ECN provides reliable contestion signalling, while source
> quench does not.

Although it would seem so on the surface, that's not necessarily the case.
I think what you mean is that ECN *can* provide reliable congestion
signalling if the TCP segments get through.

I cited a number earlier of 30% loss, so let's use it, with equal loss on
both ends of an asynchronous route, cross-country link. Some lucky packets
get through from the sender, and ECN echoing happens. If the congestion on
the backpath is bad enough for SQ to get dropped then its bad enough for
one/some of the ECN to get dropped on both the inbound and outbound
congestion points. Assuming that at least one of the ACKs gets through,
then it appears to be a win for SQ.

Don't forget that we've still got to keep the congested inbound path in
mind when we do this math. We are not looking at a stream of ACKs that
have greater chances of surviving simply because of their greater numbers.
Instead we are only looking at ACKs for the packets that made it into the
congested link in the first place.

Let's say there is an eight segment dump coming in (I'm generous, this is
more than the default 8k rwin used by the majority of bulk-receivers).
Depending on what comes in and when, some dupacks will go out (this also
works in your favor since the receiver won't wait for 2+ segments before
responding, so more ACKs go out). So at most three of the eight inbound
segments will have survived, triggering a maximum of three outbound
dupacks. The scenario says that the backpath is also at 30% loss so at
most only of them will get through to the sender. Still a win for ECN.

Now then, drop the number of packets down to six and the odds are a lot
lower that all of this will occur. Drop the number of packets down to four
and the odds are practically nil that more than one of the inbound
segments made it in alive and that the lone ACK made it through the
backpath alive. At this point we are back to a time-out scenario on the
bulk-sender, for SQ and ECN both.

In short, ECN provides reliable alerting if: an rwin of eight or more
segments is actively in use, *and* if both ends of the link fall down
simultaneosly. These are unlikely preconditions, especially when they are
looked at together.

 o It's unlikely that the receiver has an rwin of more than eight
   segments. It's certainly not impossible, but the current
   demographic profile of the typical bulk-receiver (this is a
   receiver-side congestion scenario, after all) is 8192 bytes
   in my work. It is probably smaller on average, we should find
   a survey and use that number rather than argue this.

 o It's extremely unlikely that both ends would fall down at the
   same time. But if they fell down at staggered intervales then 
   the sender would have dropped cwin, so we are back to a small
   number of segments that ECN can act upon. Small numbers don't
   survive backpath loss, as you pointed out for SQ.

The factors that are required in order for ECN to come out succesful in
this scenario has a cumulative probability somewhere below 1% in my
opinion. You can play with the numbers and make it a win, but in the end a
double-whammy loss scenario of any significance is still going to be
fatal, and will still be very rare. I'm not sure I consider it to be a
scenario that ought to be designed for.

> -neil
> an SQ infidel

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