[e2e] Is the end to end paradigm appropriate for congestion control?

[Detlef Bosau]

I know this question is as heterodox as could be.

Nevertheless. A TCP packet on its way from source to sink will typically
travel quite some packet switching nodes, each of which
introduces a potential flow control problem. A switching node typically
does "store and forward" - and whenever a queue on the node cannot be
drained sufficiently fast - be it due to a throughput shortage on the
outgoing link, be it due to a large amount of incoming traffic - the
switching node has to throttle down incoming traffic or it must discard
packets.

Both scenarios are possible with TCP: An unexpected throughput shortage
may occur on wireless networks, unexpected traffic may be caused
by any competing sender.

I'm - after years - still not comfortable with the concept of "storage
on the line", which is basically the motivation for our sliding window
model.
A line (fibre, copper, air interface) may or may not offer a certain
amount of transient storage capacity, depending on quite some factors,
one of which is the MAC scheme. E.g. in CSMA/CD nets, there is no more
then ONE packet on the line. Hence, the concept of a
"Latency-Throughput-Product" must be used with extreme caution.

I'm sometimes not quite sure whether particularly VJCC actually works
around a "concatenated flow control problem", which in the late 80s
really WAS a concatenated flow control problem because the vast majority
of a paths "capacity" was located on the switches - and not on the lines.
(At least to my understanding.) And because we did not want to touch the
switches, in other words we wanted to keep thins small and simple, we
worked around this flow control problem using an end to end congestion
control.

Detlef

(expecting flames...)

-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de