[e2e] A Cute Story. Or: How to talk completely at cross purposes.

[Detlef Bosau]

I presume that I'm allowed to forward some mail by DPR here to the list
(if not, DPR may kill me...), however the original mail was sent to the
Internet History list and therefore actually intended to reach the public.

A quick summary at the beginning: Yes, TCP doesn't manage for sent
packets a retransmission queue with copies of the sent packets but
maintains an unacknowledged data queue and does GBN basically. This
seems to be in contrast to RFC 793, but that's life.

A much more important insight into the history of TCP is the "workload
discussion" as conducted by Raj Jain and Van Jacobson.
Unfortunately, both talk completely at cross purposes and have
completely different goals......

Having read the congavoid paper, I noticed that VJ refers to Jains CUTE
algorithm in the context of how a flow shall reach equilibrium.

Unfortunately, this doesn't really make sense, because slow start and
CUTE pursue different goals.

- Van Jacobson asks how a flow should reach equlibrium,
- Raj Jain assumes a flow to be in equilibrium and asks which workload
makes the flow work with an optimum performance.

We often mix up "stationary" and "stable". To my understanding, for a
queueing system "being stable" means "being stationary", i.e.
the queueing system is positively recurrent, i.e., roughly, in human
speech: None of the queue lengths will stay beyond all limits for all
times but there is a probability > 0 for a queue to reach a finite
length at any time.

A queueing system is stationary when its arrival rate doesn't
permanently exceed its service rate, this is actually nothing else than
the "self clocking mechanism" and the equilibrium VJ is talking about.

[Andrew Mcgregor]

Bufferbloat definitely does impair performance, by slowing down feedback it
increases the variance of the system workload, which inevitably causes
either packet drops because there is a finite buffer limit in reach, or by
causing such large delays that retransmission timers fire for packets that
are still in flight. In either case, the system is doing excess work.

Post by Detlef Bosau
I presume that I'm allowed to forward some mail by DPR here to the list
(if not, DPR may kill me...), however the original mail was sent to the
Internet History list and therefore actually intended to reach the public.
A quick summary at the beginning: Yes, TCP doesn't manage for sent
packets a retransmission queue with copies of the sent packets but
maintains an unacknowledged data queue and does GBN basically. This
seems to be in contrast to RFC 793, but that's life.
A much more important insight into the history of TCP is the "workload
discussion" as conducted by Raj Jain and Van Jacobson.
Unfortunately, both talk completely at cross purposes and have
completely different goals......
Having read the congavoid paper, I noticed that VJ refers to Jains CUTE
algorithm in the context of how a flow shall reach equilibrium.
Unfortunately, this doesn't really make sense, because slow start and
CUTE pursue different goals.
- Van Jacobson asks how a flow should reach equlibrium,
- Raj Jain assumes a flow to be in equilibrium and asks which workload
makes the flow work with an optimum performance.
We often mix up "stationary" and "stable". To my understanding, for a
queueing system "being stable" means "being stationary", i.e.
the queueing system is positively recurrent, i.e., roughly, in human
speech: None of the queue lengths will stay beyond all limits for all
times but there is a probability > 0 for a queue to reach a finite
length at any time.
A queueing system is stationary when its arrival rate doesn't
permanently exceed its service rate, this is actually nothing else than
the "self clocking mechanism" and the equilibrium VJ is talking about.

[Detlef Bosau]

Post by Andrew Mcgregor
Bufferbloat definitely does impair performance, by slowing down
feedback it increases the variance of the system workload, which
inevitably causes either packet drops because there is a finite buffer
limit in reach, or by causing such large delays that retransmission
timers fire for packets that are still in flight. In either case, the
system is doing excess work.

I absolutely agree with that. And I did not say anything else.

It is, however, interesting, that probing schemes as, e.g., VJCC simply
don't consider buffer bloat. On the contrary, they produce it because a
path is "pumped up" with workload as long as no packets are discarded.

We try to alleviate the problem e.g. by ECN, where switches indicate
that their buffers grow extremely large, or intentionally discarding
packets, e.g. CODDLE, in order to have the senders slow down.

However, the basic algorithm in VJCC is chasing congestion - and lead
the flow in a nearly congested state again and again.

While Jains approaches attempt to achieve am optimum performance.

NB: I mentioned a performance metrics throughput / sojourn time, AFAIK
this is neither mentioned in the Bible nor in the Quran or the Talmud
and the Nobel Price is still pending.


I can well imagine that users only assess one of these two parameters,
e.g. in a FTP transfer, I'm only interested in a high throughput.
In an interactive ssh session, I'm primarily interested in a little
sojourn time.

[Detlef Bosau]

Reading the congavoid paper and the footnote regarding CUTE, one _could_
think, VJCC and CUTE would pursue the same purpose and the "equilibrium
window" CWND and the optimum workload "path capacity" or "path space" in
CUTE are the same.

No way.

And NB: As queues (in queueing theory) are often considered unlimited, a
self clocking TCP flow is necessarily in equilibrium state from its very
beginning. The challenge is to maximize its performance, hence to find
the right trade off between avoiding both, idle times and abundant queue
lengths.

[Detlef Bosau]

Post by Andrew Mcgregor
Bufferbloat definitely does impair performance, by slowing down feedback it
increases the variance of the system workload, which inevitably causes
either packet drops because there is a finite buffer limit in reach, or by
causing such large delays that retransmission timers fire for packets that
are still in flight. In either case, the system is doing excess work.

I thought quite a bit about that during the last weeks and sometimes I
think, we're mixing up cause and effect.

And we basically rely upon assumptions which may be put in question.

IIRC, David Reed pointed out some weeks ago what he defines as
"bufferbloat". Simply put: A packet conveyed in a network spends most of
its sojourn time in queues.

Now the problem is that we cannot determine a packet's "queuing time" a
posteriori. So, sometimes we have criteria for buffer bloat, e.g.
Coddle, where buffer bloat means "a packet resides in the local router
queue for more than 100 ms". (Whether 100 ms is defined by experience or
by divine inspiration is still opaque to me, it will certainly become
clear when this contstant is assigned a name and the Turing Award is
awarded.)

According to Dave's definition it is no way clear, whether a flow
experiences buffer bloat from this single queueing time. When a packet
experiences 5 seconds of sojourn time - and the 100 ms in the local
router queue are its only queueing delay, anything is fine. If the
0,1000000000000000000000000000000000000000001 seconds soujourn time
consists of 100 ms queueing delay "and a little rest", this would be
unsatisfactory.

In other words: Buffer bloat is not a phenomenon for a single flow - but
a symptom of wrong system design.

Now, there are quite some rules of thumb how buffers should be designed
that buffer bloat is avoided - and all of these miss the problem.

The problem is: Queues are utilized. And when congestion and resource
control are handled by feedback in a way that a system which does not
drop packets is not fully utilized, queues WILL BE FULLY UTILIZED,
because we offer that much load to a system that it eventually drops
packets.

That's basically the same af if you don't know the size of your fridge -
and you fill in butter and milk and cheese - until the whole mess
becomes lively and walks out. And then you throw away the whole mess,
clean your fridge - and restart the same procedure from the beginning.
(We call this "probing". In the context of a fridge: Mould cheese probing.)

My basic question is: Can we avoid probing? Wouldn't it be preferable to
probing to assign known resources by proper scheduling instead?

Isn't probing the very problem? Hence, CUTE and VJCC basically introduce
the problem which they pretend to solve?

WRT buffer bloat: When we don't offer inappropriate load to a network
and all packets could be served in reasonable time, there wouldn't be
any buffer bloat at all.

[Detlef Bosau]

The precise analogy for buffer bloat in operating systems is
"thrashing". Hence, a process' sojourn time in a system is spend mostly
by swapping in or swapping out its pages. So the question is the same:
How to we avoid thrashing in operating systems? In case of memory leaks,
I have a look at the output of "top" and I feel free to issue a "kill
-9" to the "one weird process" - as long as I'm able to do so. However,
better ideas exist ;-)

[Kathleen Nichols]

If by "Coddle" you mean "codel", then you need to read about it more
carefully.
Excessive delay is NOT defined as "a packet resides in the local router
queue for more than 100 ms". As for the value of the constant, you may
wish to read the
most recent I-D or watch the video of Van's talk on this at the IETF.

Perhaps improving CC will obviate the need for AQM. In the meantime, it
is useful
to have solutions available for those who need them.

Post by Detlef Bosau

Post by Andrew Mcgregor
Bufferbloat definitely does impair performance, by slowing down feedback it
increases the variance of the system workload, which inevitably causes
either packet drops because there is a finite buffer limit in reach, or by
causing such large delays that retransmission timers fire for packets that
are still in flight. In either case, the system is doing excess work.

I thought quite a bit about that during the last weeks and sometimes I
think, we're mixing up cause and effect.
And we basically rely upon assumptions which may be put in question.
IIRC, David Reed pointed out some weeks ago what he defines as
"bufferbloat". Simply put: A packet conveyed in a network spends most of
its sojourn time in queues.
Now the problem is that we cannot determine a packet's "queuing time" a
posteriori. So, sometimes we have criteria for buffer bloat, e.g.
Coddle, where buffer bloat means "a packet resides in the local router
queue for more than 100 ms". (Whether 100 ms is defined by experience or
by divine inspiration is still opaque to me, it will certainly become
clear when this contstant is assigned a name and the Turing Award is
awarded.)
According to Dave's definition it is no way clear, whether a flow
experiences buffer bloat from this single queueing time. When a packet
experiences 5 seconds of sojourn time - and the 100 ms in the local
router queue are its only queueing delay, anything is fine. If the
0,1000000000000000000000000000000000000000001 seconds soujourn time
consists of 100 ms queueing delay "and a little rest", this would be
unsatisfactory.
In other words: Buffer bloat is not a phenomenon for a single flow - but
a symptom of wrong system design.
Now, there are quite some rules of thumb how buffers should be designed
that buffer bloat is avoided - and all of these miss the problem.
The problem is: Queues are utilized. And when congestion and resource
control are handled by feedback in a way that a system which does not
drop packets is not fully utilized, queues WILL BE FULLY UTILIZED,
because we offer that much load to a system that it eventually drops
packets.
That's basically the same af if you don't know the size of your fridge -
and you fill in butter and milk and cheese - until the whole mess
becomes lively and walks out. And then you throw away the whole mess,
clean your fridge - and restart the same procedure from the beginning.
(We call this "probing". In the context of a fridge: Mould cheese probing.)
My basic question is: Can we avoid probing? Wouldn't it be preferable to
probing to assign known resources by proper scheduling instead?
Isn't probing the very problem? Hence, CUTE and VJCC basically introduce
the problem which they pretend to solve?
WRT buffer bloat: When we don't offer inappropriate load to a network
and all packets could be served in reasonable time, there wouldn't be
any buffer bloat at all.

[Detlef Bosau]

Post by Kathleen Nichols
If by "Coddle" you mean "codel", then you need to read about it more
carefully.

Sorry, I refer to codel.

Post by Kathleen Nichols
Excessive delay is NOT defined as "a packet resides in the local router
queue for more than 100 ms".

At least that's what you wrote in your own paper.

Post by Kathleen Nichols
As for the value of the constant, you may
wish to read the
most recent I-D or watch the video of Van's talk on this at the IETF.

Could you help me with a link?


The problem however is a bit deeper. The main cause of buffer bloat (and
I expect contradiction here) the basic misconception of CC.

The purpose of sliding window in TCP is to fully utilize the links.
(This is by itself a misconception and mixes up master and slave in a
network.

[Detlef Bosau]

And in addition, what queue length is concerned, I take the position
(which is similar to DPR's, IIRC) that a router should keep no more than
one packet per flow at a given time, in the general case.

I explicitly state that in wireless scenarios, there might be reasons to
accept longer router queues, particularly in the context of
opportunistic scheduling. But in the general case, the very first step
to be taken is to keep packets out of router queues. I sometimes
observed RTTs by 20 ms or more between Stuttart and Karlsruhe, i,e.
about 60 kilometers.

Perhaps, we have a special "opaque fibre" with reduced speed of light
there. However, I'm not convinced that this RTT is caused by the links
and processcing delays. I would have a look at the memory graveyards
called "router" along the path.

[Detlef Bosau]

[Joe Touch - please pass this on to the e2e list if it is OK with you]
I'd like to amplify Detlef's reference to my position and approach to
end-to-end congestion management, which may or may not be the same

What I have in mind is different in some respect - however the goals are
quite compatible,

To avoid/minimize end-to-end queueing delay in a shared internetwork,
we need to change the idea that we need to create substantial queues
in order to measure the queue length we want to reduce.

That's what I talked about, when I argued, we would measure the wrong
parameters.

Particularly, when you refer to Raj Jain, Jain measures (in his
mathematical model) a queueing system's power in order to achieve a
workload which would allow the system to work with optimum performance.
What we actually measure is: Was the workload too large for the system
or not?

This is possible, because of a simple observation: you can detect and
measure the probability that two flows sharing a link will delay each
other before they actually do... call this "pre-congestion avoidance".

In a "hop by hop flow control scenario" this could be achieved by a
window based flow control which follows the very simple rule that a
packet must not be sent to a hop until it can be processed there without
having to wait.

Rather than leave that as an exercise for the reader (it's only a
Knuth [20] problem at most, but past suggestions have not been
followed up, and I am working 16 hours per day in a startup), I will
explain how: packets need to wait for each other if the time interval
each spends passing through a particular switch's outbound NIC
"overlaps". If you remember recent flow histories (as fq_codel does,
for example), you can record when each flow recently occupied the
switch's outbound link, and with some robust assumptions of timing
variability, one can estimate the likelihood that a queue might have
built up. This information can be reflected to the destination of all
flows, just as ECN marks are used in Jain's approach. Since
congestion control is necessarily done by having the receiving end
control the sending end (because you want to move end-to-end queues
back to the source entrypoint, where they must exist for
retransmission in any case), the receiver can use that "near
collision" detection notification to slow the sender to a
non-congesting rate that shares all links on the path such that queues
will develop with arbitrarily low probability.

Where we might differ, however I have to think about it, is that I tend
to emphasize the asynchronous character of the Internet (where a
definition of a term "rate" is not used) while I think you have in mind
the model of "optimum rates" which have to be reasonably estimated.
(IIRC you mentioned something in that direction some weeks ago.)

Call this the "ballistic collision avoidance" model (and cite me if
you don't want to take all the credit).

[Jon Crowcroft]

I dont think there's anything wrong here, but maybe a note on buffer bloat
is in order:-

alongside the feedback/AIMD and ack clocking mechanisms for tcp, there was
a long discussion on right sizing buffers in the net - since AIMD naively
applied led to the sawtooth rate behaviour in TCP, a back of envelope
calculation led to the notion that the bottleneck had to have a buffer to
cope with the peak, which at worst case would be bandwidth*delay product
worth of packets (basically 3/2 times the mean rate) so that when 1 more
packet was sent at that rate, one loss would be incurred triggering the MD
part of AIMD once every ln(W) worth of RTTs...[al this is academic in
reality for lots of reasons, including the various other triggers like
dupacks and the fact that this case is a corner one - since usually there
are lots of flows multiplexed at the bottleneck(s) and multiple
bottlenecks, so the appropriate buffer siz could be way smaller - and of
course, any one running a virtual queue and rate estimater (i.e. AQM a la
codel etc) and especially ding ECN rather than loss baed feedback can avoid
all this rediculsous provisioning of packet memory all ov er the net

but alas, the rule of thumb for a corner case became dogma for a lot of
router vendors for way too long to get it disestablished....

and many of the bottlenecks today are near the edge, and more common than
not, probably in the interface between cellular data and backhaul, where,
as you say, thee radio link may not exhibit any kind of stationary capacity
at all etc etc

Post by Detlef Bosau
I presume that I'm allowed to forward some mail by DPR here to the list
(if not, DPR may kill me...), however the original mail was sent to the
Internet History list and therefore actually intended to reach the public.
A quick summary at the beginning: Yes, TCP doesn't manage for sent packets
a retransmission queue with copies of the sent packets but maintains an
unacknowledged data queue and does GBN basically. This seems to be in
contrast to RFC 793, but that's life.
A much more important insight into the history of TCP is the "workload
discussion" as conducted by Raj Jain and Van Jacobson.
Unfortunately, both talk completely at cross purposes and have completely
different goals......
Having read the congavoid paper, I noticed that VJ refers to Jains CUTE
algorithm in the context of how a flow shall reach equilibrium.
Unfortunately, this doesn't really make sense, because slow start and CUTE
pursue different goals.
- Van Jacobson asks how a flow should reach equlibrium,
- Raj Jain assumes a flow to be in equilibrium and asks which workload
makes the flow work with an optimum performance.
We often mix up "stationary" and "stable". To my understanding, for a
queueing system "being stable" means "being stationary", i.e.
the queueing system is positively recurrent, i.e., roughly, in human
speech: None of the queue lengths will stay beyond all limits for all times
but there is a probability > 0 for a queue to reach a finite length at any
time.
A queueing system is stationary when its arrival rate doesn't permanently
exceed its service rate, this is actually nothing else than the "self
clocking mechanism" and the equilibrium VJ is talking about.

[Detlef Bosau]

Post by Jon Crowcroft
I dont think there's anything wrong here,

"wrong" wouldn't be an adequate word. I think, we have different goals
here.

Post by Jon Crowcroft
but maybe a note on buffer bloat is in order:-
alongside the feedback/AIMD and ack clocking mechanisms for tcp, there
was a long discussion on right sizing buffers in the net - since AIMD
naively applied led to the sawtooth rate behaviour in TCP, a back of
envelope calculation

^^^^^^^^^^^^^^^^^^^^^very appropriate for a physicist :-)
Even Einstein did so :-)

Post by Jon Crowcroft
led to the notion that the bottleneck had to have a buffer to cope
with the peak, which at worst case would be bandwidth*delay product

and exactly this might be a problem. What is the "delay" then? The more
buffer space you introduce in the path, the greater the delay, and hence
the product, will be....

Post by Jon Crowcroft
worth of packets (basically 3/2 times the mean rate) so that when 1
more packet was sent at that rate, one loss would be incurred
triggering the MD part of AIMD once every ln(W) worth of RTTs...[al
this is academic in reality for lots of reasons, including the various
other triggers like dupacks and the fact that this case is a corner
one - since usually there are lots of flows multiplexed at the
bottleneck(s) and multiple bottlenecks, so the appropriate buffer siz
could be way smaller - and of course, any one running a virtual queue
and rate estimater (i.e. AQM a la codel etc) and especially ding ECN
rather than loss baed feedback can avoid all this rediculsous
provisioning of packet memory all ov er the net

My concern is that I doubt, that this calculation should be done for the
"whole path end to end". And of course, you will perhaps provide
sufficient buffer that the links will work at full load. Hence, the
delay will vary from propagation and serialization delays only (empty
queues) and ./. + queueing delays. Extremely rough-

Post by Jon Crowcroft
but alas, the rule of thumb for a corner case became dogma for a lot
of router vendors for way too long to get it disestablished....

what doesn't forbid to ask questions ;-)

Post by Jon Crowcroft
and many of the bottlenecks today are near the edge, and more common
than not, probably in the interface between cellular data and
backhaul, where, as you say, thee radio link may not exhibit any kind
of stationary capacity at all etc etc

When I got the insight of non stationary radio links fourteen years ago,
I certainly would have less grey hairs than today ;-)

[Detlef Bosau]

Jon,


basically, the term Bufferbloat seems to me more like an agreement than
a hard fact.

In any queueing system we observe the sojourn time = service time +
waiting time.
And when I correctly remember DPR's clarification some months ago, the
term Bufferbloat means nothing else than that a jobs queueing time
exceeds the jobs service time.

Unfortunately, from an end to end point perspective, neither of these
can be assessed. We can assess the sojourn time, we can assess the
throughput. We cannot (at least not in the general case) assess a jobs
service time or a jobs waiting time.

Hence, RJ's perfomance metric is a derived term which maps assessable
metrics (sojourn time, throughput) to some number suitable as input for
some control mechanism. (This is a generic problem in control theory, VJ
refers to Luenberger in his congavoid paper, refer to the textbooks of
Luenberger or Kalman here. Keywords: Luenberger Observer, Kalman Filter.
The problem is how we assess variables which cannot be directly observed.)

When we coin a term for the situation "waiting time exceeds service
time", this is an agreement. Nothing like an "universal constant".

However, any approach to avoid buffer bloat from an end to end
perspective is restricted to one control variable (the congestion
window) and to derived assessment variables (see above) as well.

This is a direct consequence of building a feed back control loop here.

Could it be worthwhile to discuss an open loop, feed forward approach as
an alternative?

[Joe Touch]

Forwarded for David Reed.

Joe (as list admin)

-------- Original Message --------
Subject: Re: [e2e] Once again buffer bloat and CC. Re: A Cute Story.
Or: How to talk completely at cross purposes. Re: [ih] When was Go Back
N adopted by TCP
Date: Wed, 20 Aug 2014 16:03:28 -0400 (EDT)
From: ***@reed.com
To: Detlef Bosau <***@web.de>, Kathleen Nichols
<***@pollere.com>
CC: end2end-***@postel.org, "Joe Touch" <***@isi.edu>

[Joe Touch - please pass this on to the e2e list if it is OK with you]

I'd like to amplify Detlef's reference to my position and approach to
end-to-end congestion management, which may or may not be the same
approach he would argue for:

To avoid/minimize end-to-end queueing delay in a shared internetwork, we
need to change the idea that we need to create substantial queues in
order to measure the queue length we want to reduce. This is possible,
because of a simple observation: you can detect and measure the
probability that two flows sharing a link will delay each other before
they actually do... call this "pre-congestion avoidance".

Rather than leave that as an exercise for the reader (it's only a Knuth
[20] problem at most, but past suggestions have not been followed up,
and I am working 16 hours per day in a startup), I will explain how:
packets need to wait for each other if the time interval each spends
passing through a particular switch's outbound NIC "overlaps". If you
remember recent flow histories (as fq_codel does, for example), you can
record when each flow recently occupied the switch's outbound link, and
with some robust assumptions of timing variability, one can estimate the
likelihood that a queue might have built up. This information can be
reflected to the destination of all flows, just as ECN marks are used in
Jain's approach. Since congestion control is necessarily done by
having the receiving end control the sending end (because you want to
move end-to-end queues back to the source entrypoint, where they must
exist for retransmission in any case), the receiver can use that "near
collision" detection notification to slow the sender to a non-congesting
rate that shares all links on the path such that queues will develop
with arbitrarily low probability.

Call this the "ballistic collision avoidance" model (and cite me if you
don't want to take all the credit).

It's one way to achieve what Detlef has described as "my position" while
retaining a simple model.

And if you need a mechanism for tracking packets that have passed
through a node in recent times, I suggest studying this paper very
carefully: Deng and Rafei, "Approximately detecting duplicaes for
streaming data using Stable Bloom Filters". Stable Bloom Filters can
use the switch memory not used by excess buffer space to prevent
unnecessary queueing, rather than to create queues in order to have
something to measure. They can detect the current density of packets on
the same flow (they are a version of Counting Bloom Filters that don't
need the delete() operation to reduce the "count", only requiring
insert() operations).

As they say in the patentability literature, that is a description of
the concept sufficient for someone skilled in the relevant (protocol
engineering) art to fully realize the invention. I view this note as a
publication - thus no one can patent this idea from now on. This is
"prior art" and a "constructive realization" of the invention. Thus I
grant it to the internetworking community to be used freely without a
license, which I hope is what will happen, as has happened with all
other internetworking concepts. If it is turned into specific source
code or silicon design, you may want to copyright it, however, to
capture value from your labor in completing the implementation. I'm sure
there is also a great paper or two waiting to be written based on
exploring the idea's impact on real networking and comparing it with
other approaches.


On Wednesday, August 20, 2014 3:01pm, "Detlef Bosau"

Post by Detlef Bosau
And in addition, what queue length is concerned, I take the position
(which is similar to DPR's, IIRC) that a router should keep no more than
one packet per flow at a given time, in the general case.
I explicitly state that in wireless scenarios, there might be reasons to
accept longer router queues, particularly in the context of
opportunistic scheduling. But in the general case, the very first step
to be taken is to keep packets out of router queues. I sometimes
observed RTTs by 20 ms or more between Stuttart and Karlsruhe, i,e.
about 60 kilometers.
Perhaps, we have a special "opaque fibre" with reduced speed of light
there. However, I'm not convinced that this RTT is caused by the links
and processcing delays. I would have a look at the memory graveyards
called "router" along the path.
--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: [phone]
mobile: [phone]
skype: detlef.bosau
ICQ: 566129673

[Detlef Bosau]

As far as I see, DPR's idea is to gather congestion information along
the path using Bloome Filters.

There is one possible problem, which also arises with hopwise credit
based flow control: The Internet is basically an overlay network.
So an important issue, sometimes gets a bit lost, is that "adjacent" IP
nodes are - though being adjacent - not always connected by a point to
point link but there may be a more or less complex infrastructure in
between.

Now, congestion may well occur on nodes BETWEEN the IP nodes. (E.g.
Ethernet bridges, think of remote bridging as used in ADSL.)

The IP packet's payload is not accessible for those "L2 nodes", hence
these nodes cannot stamp packets with any actual congestion information.

As a consequence, imminent congestion may not be visible for the IP
based overlay network.

Detlef

[Detlef Bosau]

In this context, my question is: When were the terms congestion control
and flow control coined?

I intentionally don't ask for the typical definitions in lectures "flow
control is between TCP sender and receiver" and "congestion control is
somewhat in between".

(A definition like this is vague, and in my opinion, exactly this
vagueness is the very problem.)

Detlef