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

[Kaleelazhicathu R R Kumar]

The RFC 2481 talks about sending a pure ack with ECT bit set to 0. Can we
not set the ECT bit for a pure ack as well?? This could help in avoiding
ack loss in the reverse direction to a greater extent. The receiver of
the pure ack can be modified  to behave appropriately  when a CE bit is
found or don't react at all.
  
Renjish



> 
> ---------- Forwarded message ----------
> Date: Thu, 15 Feb 2001 21:50:49 -0800
> From: Eric A. Hall <ehall at ehsco.com>
> To: Neil Spring <nspring at cs.washington.edu>
> Cc: Tianbo Kuang <kuang at sask.trlabs.ca>,
>      Zhang Miao <zm at csnet1.cs.tsinghua.edu.cn>, David P. Reed
> <dpreed at reed.com>,
>      end2end-interest at postel.org
> Subject: Re: [e2e] Can feedback be generated more fast in ECN?
> 
> 
> 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/
>