<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">with cc: to the IH list. <br>
<br>
Am 22.08.2014 um 01:01 schrieb <a class="moz-txt-link-abbreviated" href="mailto:dpreed@reed.com">dpreed@reed.com</a>:<br>
</div>
<blockquote cite="mid:1408662060.059513826@apps.rackspace.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<p>Detlef - since my posts are by default blocked on e2e, I rarely
respond. But in the Internet, the general idea was that since
an "overlay connection" can be treated as a link from one
Internet switch to another. </p>
</blockquote>
<br>
This obviously the idea behind e.g. VJCC.<br>
<br>
<blockquote cite="mid:1408662060.059513826@apps.rackspace.com"
type="cite">
<p> Generally, there is localized flow control between two
successive Internet layer switches, either using the underlying
technology, or using the "envelope" that wraps an IP datagram.
This is not specified in the Internet standards, because the
Internet does not define standards about how IP datagrams are
transported, but it is always there.</p>
</blockquote>
<br>
That's the way it is typically done. <br>
<blockquote cite="mid:1408662060.059513826@apps.rackspace.com"
type="cite">
<p> </p>
<p>There are rules about how those Internet hop protocols that
carry IP datagrams must work. They must not buffer excessively,
they must not try to be reliable. They must drop IP datagrams
when congested. They may drop IP datagrams if they encounter
problems. That all is what "best efforts" actually means.</p>
</blockquote>
<br>
That's according to RFC 791.<br>
<br>
However, what happens in reality?<br>
<br>
- in 802.11 networks, we have local retransmissions.<br>
- in mobile wireless networks, we have local retransmissions.<br>
<br>
(particularly in 802.11 networks, local retransmissions can be
necessary due to packet collisions, hence we should not restrict the
number of retransmissions to the same degree as it makes sense in
mobile networks.)<br>
<br>
In networks with excessive bridging (ADSL in huge ATM clouds, huge
enterprise networks built with Ethernet) we may have congestion
"under the hood", i.e. packet loss which is taken as an indication
of congestion, we may have flow control as well.<br>
<br>
I had a look at Cerf's catenet proposal yesterday, I will have
another look at the IP paper by Cerf/Kahn.<br>
<br>
However, at the moment, I'm about to make a certain "bookmark"
(which may become a "question mark") at the point where we separated
the transport layer from the network layer, with particular respect
to flow control.<br>
<br>
As far as flow control is offered by subnets (e.g. Ethernet) it is
typically a "link" flow control. This may lead to head of line
blocking. It would be nice to have a flow based flow control.
However, this is not available in all networks.<br>
<br>
<br>
Hence, when I think in a "clean slate way", I would like to
understand flow control related to adjacent switches and flow
related.<br>
<br>
Where this is not available or cannot be reasonably achieved,
"congestion control" in the sense "where nothing is dropped,
everything will eventually pass" is a work around. But this is
apparently not the road taken by the community,.<br>
<br>
<br>
<blockquote cite="mid:1408662060.059513826@apps.rackspace.com"
type="cite">
<p> </p>
<p> </p>
<p>It's very confused thinking to treat the properties of
underlying networks as the provenance of the Internet design.
Instead, this definition of "best efforts" creates a modular
definition of what all possible underlying technologies must do,
and what they MUST NOT do.</p>
<p><br>
<br>
On Thursday, August 21, 2014 8:16am, "Detlef Bosau"
<a class="moz-txt-link-rfc2396E" href="mailto:detlef.bosau@web.de"><detlef.bosau@web.de></a> said:<br>
<br>
</p>
<div id="SafeStyles1408661424">
<p>> As far as I see, DPR's idea is to gather congestion
information along<br>
> the path using Bloome Filters.<br>
> <br>
> There is one possible problem, which also arises with
hopwise credit<br>
> based flow control: The Internet is basically an overlay
network.<br>
> So an important issue, sometimes gets a bit lost, is that
"adjacent" IP<br>
> nodes are - though being adjacent - not always connected
by a point to<br>
> point link but there may be a more or less complex
infrastructure in<br>
> between.<br>
> <br>
> Now, congestion may well occur on nodes BETWEEN the IP
nodes. (E.g.<br>
> Ethernet bridges, think of remote bridging as used in
ADSL.)<br>
> <br>
> The IP packet's payload is not accessible for those "L2
nodes", hence<br>
> these nodes cannot stamp packets with any actual
congestion information.<br>
> <br>
> As a consequence, imminent congestion may not be visible
for the IP<br>
> based overlay network.<br>
> <br>
> Detlef<br>
> </p>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>