[e2e] Congestion control as a hot topic in IETF
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Sat Mar 9 02:21:54 PST 2013
not sure why you are annoyed....
serialisation delays are the time taken to clock a packet on to a
channel - this isn't some figment - there's a coding method and a
modulation technique - there's a signal which is modulated and a
nyquist limit for the symbol rate you can get out of the signal
so the physics impose a delay to get all the bits of a packet on to
the channel. then the speed of light (or lower - your milegage may
vary in different media) imposes a propagation delay
you may dice and slice the channel in some time vaying manner
(indeed you often do) but it is a resource which is going to have a
limit for you - and if it is shared with other people (whether on a
per packet basis, or slot/cell (e.g. atm multiplexed dsl line, or
packet interleaving on some wireless links) there's a limit imposed
by other people on what you can send (or by you on others) - that's
contention for the channel - it isn't magic
then there's contention for the buffer in a bottleneck switch
just before any contended link - persistent contention leads to
queues building, and eventual buffer overrun or, as some call it,
congestion....
I'm not modeling bandwidth as serialisation delay, by the way - i
am not sure where you think i said that - what I am saying is that
there are a number of contributions to the delay across a hop and
yes, it is quite complex to get a good model - but a relatively
simple feedback based controller (esp. if you use some decent
control theory and decent filters to manage the noise in the
feedback, and especially if you have explicit feedback from the
switch with a building queue, and perhaps from the switch
if it has detailed knowledge of the channel contention (e.g. from
looking at number of sources, which you can't see as a lone sender
(for lots of reasons like hidden terminal, transmit signal drowning
receive signal in today's antennae etc etc) then you can manage
congestion....
by the way, a lot of techniques on wireless nets are making their
way into wired (and photonic) nets these days to get better
resilience to noise and pack more bits in....
anyhow, i'll stop annoying you at this point, as I have other fish
to fry
In missive <513A7732.5010406 at web.de>, Detlef Bosau typed:
>>Content-Transfer-Encoding: 8bit
>>
>>Am 08.03.2013 15:28, schrieb Jon Crowcroft:
>>> actually packets stored in the channel may not have contended for the
>>> channel, whereas packets arriving at a queue are contending for the
>>> output to that queue....
>>>
>>
>>Even that is simply wrong.
>>
>>In Wifi, packets are sent in the whole: One IP packet is encapsulated in
>>one 802.11 packet. This simply holds not true in mobile networks.
>>
>>E.g. in HSDPA you have 2 ms timeslots and you may change the line coding
>>scheme, the puncturing and the wrapping about channels each and every 2 ms.
>>You have transport blocks the payload of which may vary from about 150
>>bit to 12000 bit, very roughly I need to look it up.
>>
>>Than you have opportunistic scheduling where channels may be suspended
>>for some time.
>>
>>What I read so far in CS books is simply orthogonal to reality in many
>>cases. And the model to assign a packet a "serialization delay" is
>>hopelessly naive and, physically, simply as wrong as could be.
>>
>>That's completely different from wired networks.
>>
>>And I really cannot imagine that I'm the only one here to see this.
>>
>>One immediate consequence is that the annoying discussion about
>>"spurious time outs" is nonsense.
>>
>>The RTO in TCP is a confidence interval derived, by Cantelli's
>>inequality, from expectation and variance of the/, so assuemed,
>>//stationary /RTT. (See Edge's paper, the congavoid paper etc.)
>>
>>(Cantelli's inequality is a special case of Chebysheff's inequality.)
>>
>>Of course, you can put RTT "measurements" into an EWMA filter (garbage
>>in garbage out principle), put this into Cantelli's inequality and get
>>(again garbage in garbage out) an RTO statistics.
>>
>>You can easier take 15. (No matter if seconds or hours.)
>>
>>This is as wrong as the other RTO formulae but easier to implement.
>>
>>However, if we use an RTO determined by pure hand waving, how can we
>>really claim this to be a confidence interval and say that ACKs are "late"?
>>
>>
>>And what's particular annoying: I'm neither the first one to claim so
>>neither the only one. E.g. Raj Jain and Lixia Zhang published on the
>>deficiencies of timers nearly 25 years ago! This is really old and
>>accepted basic knowledge! Why is this ignored?
>>
>>You referred to Dave Reed some posts ago, from quite some PM exchange I
>>very well know Dave's anger about formulae, which are mistaken for
>>reality, and the ignorance of the community against physical reality
>>which is around everywhere!
>>
>>And for decades we modelled "bandwidths" in our simulators as
>>"serialization delay" in wired networks and mobile networks as well.
>>except some very few extensions, e.g. the EURANE extensions to the NS2,
>>and wonder why simulators yield exactly the wrong results we previously
>>encoded in them!
>>
>>As you may notice, I'm extremely upset about this!
>>
>>It may sound cynical, however I'm not employed with any university at
>>the moment, so there is no professor to fire me tomorrow morning because
>>I wrote this post. And believe me, this attitude is anything than
>>unfamiliar to me. If someone points to physical reality and violates
>>some dogmatic "laws", he is most likely to be at least severely berated
>>he must not damage the reputation of his employer.
>>
>>However, wrong statements are not corrected by berating students, PhD
>>students or research assistants!
>>
>>Wrong statements are only corrected by correct ones!
>>
>>--
>>------------------------------------------------------------------
>>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
>>
>>
>>--------------020404080109060908000106
>>Content-Type: text/html; charset=ISO-8859-1
>>Content-Transfer-Encoding: 7bit
>>
>><html>
>> <head>
>> <meta content="text/html; charset=ISO-8859-1"
>> http-equiv="Content-Type">
>> </head>
>> <body bgcolor="#FFFFFF" text="#000000">
>> <div class="moz-cite-prefix">Am 08.03.2013 15:28, schrieb Jon
>> Crowcroft:<br>
>> </div>
>> <blockquote
>>cite="mid:CAEeTejL03mjAxPTk87b24RNf4ECQhjphSYmocd77ct4T+oAoYw at mail.gmail.com"
>> type="cite">
>> <meta http-equiv="Context-Type" content="text/html;
>> charset=ISO-8859-1">
>> actually packets stored in the channel may not have contended for
>> the channel, whereas packets arriving at a queue are contending
>> for the output to that queue....
>> <div><br>
>> </div>
>> </blockquote>
>> <br>
>> Even that is simply wrong.<br>
>> <br>
>> In Wifi, packets are sent in the whole: One IP packet is
>> encapsulated in one 802.11 packet. This simply holds not true in
>> mobile networks.<br>
>> <br>
>> E.g. in HSDPA you have 2 ms timeslots and you may change the line
>> coding scheme, the puncturing and the wrapping about channels each
>> and every 2 ms. <br>
>> You have transport blocks the payload of which may vary from about
>> 150 bit to 12000 bit, very roughly I need to look it up.<br>
>> <br>
>> Than you have opportunistic scheduling where channels may be
>> suspended for some time.<br>
>> <br>
>> What I read so far in CS books is simply orthogonal to reality in
>> many cases. And the model to assign a packet a "serialization delay"
>> is hopelessly naive and, physically, simply as wrong as could be. <br>
>> <br>
>> That's completely different from wired networks.<br>
>> <br>
>> And I really cannot imagine that I'm the only one here to see this.<br>
>> <br>
>> One immediate consequence is that the annoying discussion about
>> "spurious time outs" is nonsense.<br>
>> <br>
>> The RTO in TCP is a confidence interval derived, by Cantelli's
>> inequality, from expectation and variance of the<i>, so assuemed, </i><i>stationary
>> </i>RTT. (See Edge's paper, the congavoid paper etc.) <br>
>> <br>
>> (Cantelli's inequality is a special case of Chebysheff's
>> inequality.)<br>
>> <br>
>> Of course, you can put RTT "measurements" into an EWMA filter
>> (garbage in garbage out principle), put this into Cantelli's
>> inequality and get (again garbage in garbage out) an RTO statistics.<br>
>> <br>
>> You can easier take 15. (No matter if seconds or hours.) <br>
>> <br>
>> This is as wrong as the other RTO formulae but easier to implement.<br>
>> <br>
>> However, if we use an RTO determined by pure hand waving, how can we
>> really claim this to be a confidence interval and say that ACKs are
>> "late"?<br>
>> <br>
>> <br>
>> And what's particular annoying: I'm neither the first one to claim
>> so neither the only one. E.g. Raj Jain and Lixia Zhang published on
>> the deficiencies of timers nearly 25 years ago! This is really old
>> and accepted basic knowledge! Why is this ignored?<br>
>> <br>
>> You referred to Dave Reed some posts ago, from quite some PM
>> exchange I very well know Dave's anger about formulae, which are
>> mistaken for reality, and the ignorance of the community against
>> physical reality which is around everywhere!<br>
>> <br>
>> And for decades we modelled "bandwidths" in our simulators as
>> "serialization delay" in wired networks and mobile networks as well.
>> except some very few extensions, e.g. the EURANE extensions to the
>> NS2, and wonder why simulators yield exactly the wrong results we
>> previously encoded in them!<br>
>> <br>
>> As you may notice, I'm extremely upset about this!<br>
>> <br>
>> It may sound cynical, however I'm not employed with any university
>> at the moment, so there is no professor to fire me tomorrow morning
>> because I wrote this post. And believe me, this attitude is anything
>> than unfamiliar to me. If someone points to physical reality and
>> violates some dogmatic "laws", he is most likely to be at least
>> severely berated he must not damage the reputation of his employer.
>> <br>
>> <br>
>> However, wrong statements are not corrected by berating students,
PhD students or research assistants!<br>
>> <br>
>> Wrong statements are only corrected by correct ones!<br>
>> <pre>--
>>------------------------------------------------------------------
>>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 at web.de">detlef.bosau at web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
>>
>></pre>
>> </body>
>></html>
>>
>>--------------020404080109060908000106--
cheers
jon
More information about the end2end-interest
mailing list