Re: A "Railway Model." Re: Codel and Wireless

This is hop-by-hop flow control, as implemented with 802.1 pause frames.
 It works, kind of.  But there's a phenomenon called an 'incast pause
cone', in which a single heavily loaded interface can pause an entire data
center fabric.  So it's not a panacea, in fact it has a whole menagerie of
its own congestion issues.  Infiniband also has hop-by-hop control, and has
to be very carefully admission controlled to avoid these issues.  The net
effect is that you cannot use about 30% of the ostensible performance of
any interface in the network, to avoid fabric deadlocks.  Internet-style
congestion control gets better utilisation, which is good if the links are
expensive.


On 7 December 2013 11:03, Detlef Bosau <[email protected]> wrote:

> Am 06.12.2013 13:49, schrieb Jon Crowcroft:
> > i think the variations in wireless properties
> > over the length of their traes for their experiment
> > probably covers most tof hte cases of variation you might
> > see in future scenarios....there just isn't that much
> > design space for the channel to vary over - they aren't trying to
> > evolve/deisgn a channel condition predictor - just a reactive system
> > that does betterer than others....
> >
> > i think the Reverend Bayes has some things to observe in this space
> > about a priori and a posteriori, although i might be talking out of my
> > posterior when I say that
>
>
>
> And perhaps for simulations, this is perfectly fine.
>
> Nevertheless, although I'm writing much about wireless networks, I don't
> want to be a pure wireless guy.
>
> Actually, wireless networks cause some difficulties for TCP - when you
> run TCP along a single mobile link, some things are different from
> wirebound  ones, e.g. the loss differentiation.
>
> However, this is not the core question of TCP congestion control.
>
> Perhaps, I'm a bit influenced by my residence, the famous city with
> water canons and without a train station (the water canons are used
> against those who want to keep the train station as written e.g. in the
> Washington Post,...), where it is quite common when you travel from one
> station to another ("Feuersee" to "Stadtmitte", a walk of about five
> minutes) that your train will pause several times: "Dear passengers,
> unfortunately the section in front of us is still occupied by another
> train, we will continue our trip in a few minutes." So, the railway is
> split up into sections. A train must not enter an occupied section. It
> has to wait for the section becoming available instead.
>
> Compared to TCP, this is EXACTLY, what we want. A TCP packet must not
> enter an occupied link, it has to wait for the link becoming available.
>
> And actually, it is not the link what becomes available - but the next
> hop, So a packet travels from hop to hop, in each case waiting for the
> next hop becoming available. There is no loss differentiation problem,
> there is no assessment of resources, there is no probing. Just a travel
> from section to section, and waiting for the next hop becoming available
> in each case.
>
> Just as if a packet were travelling from "Feuersee" to "Stadtmitte".
>
> This is just a thought. However, wouldn't this thought be at least
> interesting as a strategy for resource sharing and congestion avoidance?
>
> Yes, it would work on wireless networks.
> Yes, it would work on "long fat networks".
> And it would work on wire bound networks.
> And perhaps it could spare us some problems.
>
>
> Actually, that's what I had in mind, when I started this whole discussion.
>
> Is this thought completely weird? If not, where are the pitfalls?
>
> Pehaps, it makes sense to ask  this question right to you, because it is
> not that unusual to read even unusual ideas in your posts ;-)
>
>
>
>


-- 
Andrew McGregor | SRE | [email protected] | +61 4 8143 7128