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

Detlef Bosau detlef.bosau at web.de
Fri Dec 6 16:03:46 PST 2013

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 ;-)

More information about the end2end-interest mailing list