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

[Marc Herbert]

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.