[e2e] Does congestion control belong to The Transport Layer?
marc.herbert at free.fr
Sun Apr 25 03:09:37 PDT 2004
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.
More information about the end2end-interest