[e2e] Congestion control as a hot topic in IETF

[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....


this leads to an interesting model of shadow pricing - its a bit like
changing he solid angle subtended by the source

On Fri, Mar 8, 2013 at 1:51 PM, Detlef Bosau <detlef.bosau at web.de> wrote:

>  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:          566129673detlef.bosau at web.de                     http://www.detlef-bosau.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130308/e424f58e/attachment.html