[ih] [e2e] Fwd: Re: Once again buffer bloat and CC. Re: A Cute Story. Or: How to talk completely at cross purposes. Re: When was Go Back N adopted by TCP

[Detlef Bosau]

with cc: to the IH list.

Am 22.08.2014 um 01:01 schrieb dpreed at reed.com:
>
> 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.
>

This obviously the idea behind e.g. VJCC.

>  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.
>

That's the way it is typically done.
>
>  
>
> 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.
>

That's according to RFC 791.

However, what happens in reality?

- in 802.11 networks, we have local retransmissions.
- in mobile wireless networks, we have local retransmissions.

(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.)

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.

I had a look at Cerf's catenet proposal yesterday, I will have another
look at the IP paper by Cerf/Kahn.

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.

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.


Hence, when I think in a "clean slate way", I would like to understand
flow control related to adjacent switches and flow related.

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,.


>  
>
>  
>
> 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.
>
>
>
> On Thursday, August 21, 2014 8:16am, "Detlef Bosau"
> <detlef.bosau at web.de> said:
>
> > 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
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20140822/94de900f/attachment.htm>