[e2e] Does congestion control belong to The Transport Layer?

[Cannara]

Sounds good to me Marc.  Micah has good points too.  The belief that: "[packet
dropping] has nothing to do with TCP" is odd, since
router/firewall/metro/edge-system-code writers explicitly say they can slow
down traffic by dropping, because of how TCP behaves.  In other words, they
know a TCP flow's weak link, and can get more bang from dropping a TCP packet
than most others. 

If, as you suggest, the network incorprated management of its own congestion,
even if only at ends, but with good information from the interior, that would
be better.  That would indeed be an example of a network "service" -- datagram
carriage with congestion management. 

Protocols are simply communication languages for remote systems to use in
implementing services.  And, for people to argue about.  :]

Alex

Marc Herbert wrote:
> 
> On Thu, 22 Apr 2004, David P. Reed wrote:
> 
> > 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.
> 
> > [...]
> 
> > Note that this [packet dropping] 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.
> 
> This may be "only" a language issue, but considering the
> misunderstandings recently seen here, language is probably important.
> 
> Imagine an Internet where every endpoint protocol that wants to take
> care of network congestion (including imaginary-TCP) does... NOT
> implement it by itself, but instead is linked to some common
> end-to-end congestion control implementation. Something very close to
> what DCCP does. Let's call it here "DCCP" for short.
> 
> So _no_ transport protocol would have to implement network congestion
> control; it comes as a free option, as part as the datagram services
> provided by the (extended) IP implementation in the endhost. Note that
> I make no assumption about how DCCP implements network congestion
> control: packet losses, ECN, or whatever. From a protocol designer
> point of view, I just don't care: DCCP takes care of network
> congestion for me if I want it.
> 
> First, does this work? I see no reason why not. After all, isn't that
> just a different way to implement It? I mean: isn't that just code
> factorization of network congestion control?  It may not be the
> optimal way to implement It in the first place (stacking layers
> usually cause verbosity), but I think it would work.
> 
> Does this prevent some designs? Even "variable quality" applications
> could adjust their rate thanks to some O_NONBLOCK API, sort of
> "dropping" part of the extra packets inside the sender even before
> they congest the network, and still being able to get a good
> estimation of network congestion in the end (pun intended).
> 
> Now the main, language question.
> 
>  Assuming the above is working, where would you classify this
>  DCCP-like block? Is it part of the implementation of
>  The-Transport-Layer or part of The-Network-Layer?
> 
> Thanks in advance.
> 
> PS: another thing that frequently confuses me, is the lack of clear
> distinction between a service and a protocol (see
> start of section 3 in <http://www.cis.udel.edu/~amer/PEL/survey/>).
> But this is another story.