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

[Cannara]

Precisely right Venkata, as I said all along, TCP is not the only flow that
needs to know of reasons why it should control itself.  David's remark...

-> 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.
-> 
supports exactly this point, because making TCP slow down does nothing for
UDP, except perhaps give it unfair advantage, especially when TCP's slowdown
is open-loop in relation to actual network-layer load.  Dropping packets is
always how router programmers must manage queues under excessive load, so
those packets should fairly come from all flows.  No flows should sacrifice
more than appropriate.  Unfortunately, TCP without ECN sacrifices too much at
the wrong times.

TCP 'congestion control' fails to address anything but avoidance of
embarrassing network collapse, as long as it's the dominant traffic.  That's
why ECN use by newer protocols is a more intelligent, long-term solution.  The
telco example supports exactly that and doesn't support relying on a
decades-old, incomplete stopgap.

Alex

"Naidu, Venkata" wrote:
> 
> David,
> 
> -> 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.
> 
>   I got exactly the opposite supportive argument when I read
>   RFC 2884 (http://www.ietf.org/rfc/rfc2884.txt). This RFC
>   clearly states that the explicit congestion signal is efficient
>   is most of the situations.
> 
>   Coming back to compatibility and portability of network layer
>   congestion notification to higher level protocols, ECN for example,
>   is in fact implemented for TCP, UDP applications. Recent
>   transport protocols, like DCCP and SCTP also adapted the ECN
>   usage.
> 
> Venkata.