[e2e] A "Railway Model." Re: Codel and Wireless

[Neil Davies]

Actually, with worm-hole routed fabrics you can achieve better than 67% [1] for random paths with the right switching architecture.

You are right, there are contention trees that form (spanning out from the bottleneck) in ALL such fabrics. 
You need about 1.41 (root 2) the edge capacity in the switching core to sustain all non-pathalogical traffic destination patterns at load[2]

Its a system with two degrees of freedom - either you get delay or loss - your choice.

We've found that the best approach is a polyservice one, not a monoservice one - push the trading space up the value chain, work with both loss and delay characteristics in a consistent framework.[3]

Neil
[1] Jones, Davies, Firth and Wright, The Network Designers Handbook, IOS press, 1997 ISBN 9051993905
[2] A Jomah, Instability in Switching Systems, PhD, Bristol 2000
[3] D Reeve, A New Blueprint for Network QoS, PhD, Kent , 2003 (Jon Crowcroft eternal examiner…)

On 7 Dec 2013, at 11:11, Andrew Mcgregor <andrewmcgr at google.com> wrote:

> 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 <detlef.bosau at web.de> 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 | andrewmcgr at google.com | +61 4 8143 7128