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

[Naidu, Venkata]

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.