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

[Eric A. Hall]

> Looking into the fast notification argument, it acutally consists of two
> parts: (1) Is it really faster? (2) Is congestion control the faster the
> better?
>
> To question (1), it depends on the congestion pattern of the Internet.
> My conjecture is that most congestion occurs at the access point of
> network, where bandwidth is scarce.

My field experience seconds this. There are exceptions where congestion is
caused by internal applications and there is no transitional point in the
infrastructure that can be blamed, but 99% of the congestion is caused by
transitions between big->small pipes (IME). The other 1% is constrained to
a local network.

> This is especially true in the case of mulicast (See M. Yanjnik, J.
> Kurose, and D. Towsley, "Packet loss correlation in the MBone Multicast
> Network," IEEE Global Internet'96, London, UK, Nov. 96.). In this case,
> the congestion point may be near the receiver most of the time,

There are enough applications and scenarios to say that it mostly splits
50-50 between sender- and receiver-side congestion. The popular web server
behind a thin pipe (the slash-dot effect) is sender-side congestion, while
the handheld browser that stumbles into a set of content-rich pages is
receiver-side, and both cases happen often enough to balance it out fairly
equally.

There are exceptions. I've been seeing a lot of big->small<-big problems
lately with certain exchange points, where congestion occurs in the middle
of the link. There are some limited examples of full-duplex congestion,
such as multi-party videoconferencing over a small->big<-small mesh with
reflectors in the middle, although they are rare.

> which reduces the benefit of early notification.

"Reduces" is probably an accurate term since a greater distance between
the sender and the congestion point means higher latencies for the alert
itself. But 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.

Sender side alerts between a LAN-WAN router and the slash-dotted server
are almost immediate, with very little congestion on the fast short link
between the two devices. Even if the congestion point is at the reciever's
boundary, then the maximum time for detection and alert is LESS than one
RTT (SQ bounces off the congestion boundary, it doesn't have to go through
the last [consgested] link). Obviously an SQ sent from the deep end of the
range won't stop a sender from dumping a complete window of data into the
network, but then again neither would an ACK which required >1 RTT.

Therefore, in sender-side congestion scenarios SQ will always deliver a
faster notification. In receiver-side congestion scenarios it will still
be faster on average (less beneficial but still very beneficial). Even in
the big->small<-big congested exchange point scenario, SQ always wins. The
only scenario where SQ and ECN tie would tie is small->big<-small
full-duplex congestion, which is extremely rare in my experience.

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