[e2e] Congestion control as a hot topic in IETF
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Fri Mar 8 06:00:25 PST 2013
congestion/contention
involve multiple senders competing for a resource,
and partitioning the use of that resource
when you have multiple packets in flight (sure, intercontinental fiber a bit, and ong haul radio links more) then
sure but the origins of the scheme are shared resource in the sense of the output link at the
the bottleneck as measured by a queue building in the buffer just behind that
the media type of the link up to that point is irrelevant. the capacity is
btw, path loss is very real (and not at the antennae) - in freespace, with omnidorectional antennae its
a feature of inverse square law of spreading the signal over a speherical surface ...plus
there's atenuuation from signal energy being absorped (e.g. by water vapour or concrete) - etc etc
your mixing it up with interference with concurrent senders o nthe receive antennae (which is fixable using mimo and
smart processing - viz
http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p235.pdf
>>Am 08.03.2013 00:22, schrieb Jon Crowcroft:
>>> hunh?
>>
>>Likewise :-)
>>
>>>
>>> a wire is just a channel no different from free space
>>> except for interference and possibly slower than speed of light RF
>>> propagation, and, depending on technology, lower interference and
>>> lower path loss
>>
>>from a very abstract level you're right. However: From that abstract
>>level we don't talk about interference and path loss.
>>Because from that abstract level, we apply Shannon-Hartley and are
>>simply fine.
>>
>>Particularly, no channel suffers from "path loss". It's not the channel,
>>where packets/blocks are lost. It's the receiver who discards nonsense
>>with defective CRC, if he is told to do so. NB: This is definitely not
>>the case for wireless speech connections. Because there is no CRC check
>>at all.
>>
>>
>>the channel is irrelevant to this discusson, except that a wireless
>>
>>
>>I strongly disagree. The whole VJCC is based upon Little's law. So, for
>>VJCC, a channel is characterized by exactly four proberties.
>>
>>P1: A path capacity.
>>P2: A path RTT.
>>P3: Capacity and RTT are not necessarily constant but: at least
>>(quasi-)stationary.
>>P4: A loss rate, which is necessarily negligible.
>>
>>That's all - and these are the four inevitably required necessary
>>conditions for VJCC to work.
>>
>>(If these conditions do not hold, VJCC does something. And TCP behaves
>>somehow. However, this behaviour has hardly anything to do with the
>>congavoid paper and what we expect as "Congestion Control".)
>>
>>> channel may be shared so you can see contention for the receive
>>> antennae (some people talk about contention for the media too, but
>>> that's a figment of the technology of choice for MAC)...
>>>
>>> so i have no idea where you think packets are stored except in
>>> senders' and receivers' NICs' buffers....
>>
>>This is an academic question. However: If no data were stored along the
>>channels, there would be no need for flow control and congestion
>>control, we could employ a wired handshake as in V.24 with RTS/CTS, DSR/DTR.
>>
>>
>>VJCC does not make a difference whether data is stored in buffers or
>>along the channel.
>>
>>>
>>>
>>> you need to haev a REALLY long haul link to get a lot of packets
>>> in transit (propagation) - these are unusual cases (satellites)
>>and intercontinental fibres - and it's that "irrelevant" that BIC and
>>CuBIC have been proposed.
>>
>>
>>> basically (comms #101) - you have the
>>> packet serialisation time (s=clock speed*packet length)
>>
>>That's another point where I strongly disagree. The term "serialization
>>delay" is, frankly spoken, complete nonsense in the context of wireless
>>networks.
>>
>>We can talk about service times for a block/packet to be successfully
>>delivered along a wireless channel.
>>
>>Hence, we can talk about capacity/service time/loss rate for a wireless
>>channel. It does, however, make ABSOLUTELY NO SENSE to talk about
>>serialization delays in thes context.
>>
>>(I did not yet have a look at the NS3, so I don't know whether this was
>>changed. What's used in the NS2 in this context is simply complete
>>nonsense. The model used there is simply completely wrong. Although I
>>will ask for additional memory for my mailbox for the next two hours to
>>have capacity for the rants, I'm "looking forward to".)
>>
>>(From what I'm told, CS guys are polite and well behaved. They do not
>>rant, but on some occasions they throw chairs ;-))
>>
>>> and you have the packet propagation time (p=link geodistance / c)
>>
>>Which is of no interest for VJCC because it's encapsulated in the
>>service time.
>>
>>> so the case of packets in transit is plural, is when p/s > 1
>>> which is not too many cases...
>>>
>>> anyhow that's not what congestion or contention are about
>>
>>If the path's capacity is sufficiently low (which is almost certainly
>>the case in terrestrial wireless networks) I agree.
>>
>>So, I said we can use stop'n wait.
>>
>>
>>--
>>------------------------------------------------------------------
>>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
>>
>>
>>--------------080605040504040009030400
>>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 00:22, schrieb Jon
>> Crowcroft:<br>
>> </div>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">hunh?</pre>
>> </blockquote>
>> <br>
>> Likewise :-)<br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>
>>a wire is just a channel no different from free space
>>except for interference and possibly slower than speed of light RF
>>propagation, and, depending on technology, lower interference and
>>lower path loss</pre>
>> </blockquote>
>> <br>
>> from a very abstract level you're right. However: From that abstract
>> level we don't talk about interference and path loss. <br>
>> Because from that abstract level, we apply Shannon-Hartley and are
>> simply fine.<br>
>> <br>
>> Particularly, no channel suffers from "path loss". It's not the
>> channel, where packets/blocks are lost. It's the receiver who
>> discards nonsense with defective CRC, if he is told to do so. NB:
>> This is definitely not the case for wireless speech connections.
>> Because there is no CRC check at all.<br>
>> <pre wrap="">
>>
>>the channel is irrelevant to this discusson, except that a wireless</pre>
>> <br>
>> I strongly disagree. The whole VJCC is based upon Little's law. So,
>> for VJCC, a channel is characterized by exactly four proberties.<br>
>> <br>
>> P1: A path capacity.<br>
>> P2: A path RTT.<br>
>> P3: Capacity and RTT are not necessarily constant but: at least <small><small>(quasi-)</small></small>stationary.<br>
>> P4: A loss rate, which is necessarily negligible.<br>
>> <br>
>> That's all - and these are the four inevitably required necessary
>> conditions for VJCC to work.<br>
>> <br>
>> (If these conditions do not hold, VJCC does something. And TCP
>> behaves somehow. However, this behaviour has hardly anything to do
>> with the congavoid paper and what we expect as "Congestion
>> Control".)<br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>channel may be shared so you can see contention for the receive
>>antennae (some people talk about contention for the media too, but
>>that's a figment of the technology of choice for MAC)...
>>
>>so i have no idea where you think packets are stored except in
>>senders' and receivers' NICs' buffers....</pre>
>> </blockquote>
>> <br>
>> This is an academic question. However: If no data were stored along
>> the channels, there would be no need for flow control and congestion
>> control, we could employ a wired handshake as in V.24 with RTS/CTS,
>> DSR/DTR.<br>
>> <br>
>> <br>
>> VJCC does not make a difference whether data is stored in buffers or
>> along the channel.<br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>
>>
>>you need to haev a REALLY long haul link to get a lot of packets
>>in transit (propagation) - these are unusual cases (satellites)
>></pre>
>> </blockquote>
>> and intercontinental fibres - and it's that "irrelevant" that BIC
>> and CuBIC have been proposed.<br>
>> <br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>basically (comms #101) - you have the
>>packet serialisation time (s=clock speed*packet length)</pre>
>> </blockquote>
>> <br>
>> That's another point where I strongly disagree. The term
>> "serialization delay" is, frankly spoken, complete nonsense in the
>> context of wireless networks.<br>
>> <br>
>> We can talk about service times for a block/packet to be
>> successfully delivered along a wireless channel. <br>
>> <br>
>> Hence, we can talk about capacity/service time/loss rate for a
>> wireless channel. It does, however, make ABSOLUTELY NO SENSE to talk
>> about serialization delays in thes context. <br>
>> <br>
>> (I did not yet have a look at the NS3, so I don't know whether this
>> was changed. What's used in the NS2 in this context is simply
>> complete nonsense. The model used there is simply completely wrong.
>> Although I will ask for additional memory for my mailbox for the
>> next two hours to have capacity for the rants, I'm "looking forward
>> to".)<br>
>> <br>
>> (From what I'm told, CS guys are polite and well behaved. They do
>> not rant, but on some occasions they throw chairs ;-))<br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>and you have the packet propagation time (p=link geodistance / c)
>></pre>
>> </blockquote>
>> <br>
>> Which is of no interest for VJCC because it's encapsulated in the
>> service time.<br>
>> <br>
>> <blockquote cite="mid:E1UDk8m-0004Lk-KQ at mta1.cl.cam.ac.uk"
>> type="cite">
>> <pre wrap="">
>>so the case of packets in transit is plural, is when p/s > 1
>>which is not too many cases...
>>
>>anyhow that's not what congestion or contention are about
>></pre>
>> </blockquote>
>> <br>
>> If the path's capacity is sufficiently low (which is almost
>> certainly the case in terrestrial wireless networks) I agree.<br>
>> <br>
>> So, I said we can use stop'n wait.<br>
>> <br>
>> <br>
>> <pre class="moz-signature" cols="72">--
>>------------------------------------------------------------------
>>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>
>>
>>--------------080605040504040009030400--
cheers
jon
More information about the end2end-interest
mailing list