[e2e] Congestion control as a hot topic in IETF

[Detlef Bosau]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130308/5ea73def/attachment.html