[e2e] First rule of networking: don't make end-to-end promises you can't keep.

[David P. Reed]

At 02:32 PM 4/22/2004, Cannara wrote:
>Of course, the fundamental issue is why any Transport protocol should be at
>all concerned with Network-layer loading and congestion points.  That, after
>all, is opposite to the concept of Transports providing reliable end-end
>service, regardless of what the next layers down are troubled with.

This is technically incorrect: that the Transport protocol should (or even 
can) hide network loading and congestion.

Congestion is a problem that is caused and cured only by modulating the 
behavior of the endpoints.   So it does indeed make sense that ALL 
transport protocols need to be involved in congestion control.

Even constant-bit-rate 64-kb/sec voice in the old telco reflects congestion 
to the endpoints because they must deal with it.  (that's what dialtones 
and fastbusy do...)

Now the question has always existed: how should the underlying network 
communicate about congestion and loss to a wide variety of applications, 
given that networks are themselves quite heterogeneous and the packet 
transport ought not to have to track the relationships among end-to-end 
applications.

The answer was quite simple: signal congestion by dropping packets.   Given 
that bit errors can be corrected locally on a best efforts basis and link 
disconnect is handled by re-routing, this is a clean channel, and satisfies 
a principle like "fate sharing" - it contributes to the local solution 
(which is almost certainly that the outgoing link cannot carry the 
presented load) as well as carrying the signal.   It also solves a major 
bug in many end-to-end protocols, which is that the congestion signal needs 
to be dispersed among ALL the contributors to congestion.   The statistical 
nature of dropping achieves this.

Note that this has nothing to do with TCP.   It's part of the definition of 
the IP layer, and is a signal that can be and is useful to implement 
congestion control in other protocols besides TCP.

Sending the congestion signal directly back to the source might seem like a 
possible option for the IP layer to implement (source quench was the name), 
but in fact it is quite incompatible with many high-level protocols.   For 
example, it makes little sense in a multicast tree, unless you have some 
way to tell the source something about the routing algorithm.   And it's 
well known that generating a reverse-path packet can be both difficult and 
places requirements on routers (such as the symmetry of paths) that may be 
difficult to realize in all kinds of networks.

So in fact, the idea was both elegant and defensible.