[e2e] Congestion control as a hot topic in IETF

[Detlef Bosau]

Am 09.03.2013 11:21, schrieb Jon Crowcroft:
> 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

The term "serialization delay" is inherited from wired networks like 
Ethernet and may, within certain limits, have some minimal justification 
in 802.11 networks.

It is nothing else than the reciprocal value of the holy "bandwidth" 
which is an idealized model for some kind of data rate, data may be 
conveyed with with negligible error rate.

In mobile networks this model simply does not apply.

Think of opportunistic scheduling in HSDPA, which means, figuratively, 
that your network interface is simply plugged off now and then.
Or your 10 GE interface is replaced by a 10 MBit/s Ethernet interface, 
than by a 19k2 modem line, then the interface is plugged of for, say, 20 
seconds.

The term "serialization delay" does not make any sense in this context. 
Contrary to Ethernet, you cannot even tell in advance how long the 
"serialized packet" will be, because, again e.g. HSDPA, the net data 
rate may change several times from the beginning of the packet to the 
end of the packet and the channel may even be suspended and getting no 
service in between.

And when you refer to 802.11 and the base station switches from DCF to 
PCF from time to time, you may well tell me that the base station will 
issue flow control messages to stop a sender from sending if necessary, 
does this waiting time affect the time it takes to send the packet to 
the channel? Of course it does!

So, what's the justification of a "serialization delay" or a known 
throughput (as perceived by the application) in mobile networks? Or, in 
other words, what should be the meaning of such a term? Which is 
typically coined in wire line networks.

I would agree with you when we talk about point to point technologies. 
But I completely disagree in case of 802.11 and particularly in mobile 
networks.

And this is neither rocket science nor a brand new insight, this is 
standard knowledge from any lecture in communication engineering.

When I started my research in the COMCAR project 13 years ago and I 
discussed QoS parameters with CE and EE guys, they simply ridiculed 
about me and asked me: "You're a wire line guy, aren't you?"

And Jon, although this is beyond the scope of this mailing list, this 
experience hurts me up to this moment. I was berated for not having 
provided QoS in mobile networks from my CS colleagues and I was not 
taken seriously by my CE and EE colleagues and I spent literally 
hundreds of hours to understand what's happening here during the last 13 
years.

Ahd the result of this investigation is quite simple: We CS guys do not 
listen to what the CE and EE colleages say - and vice versa.

We don't listen to each other - and quite often, we intentionally 
misinterpret the other discipline.

E.g. the term "bandwidth" which is even discussed in some RFCs. Fine. 
The term was coined in by the CE colleagues with a well defined meaning 
decades ago.
And when we CS guys redefine a well defined term of engineering which 
was successfully used over 80 years or so and redefine the meaning, the 
only consequence is some kind of babylonian confusion. (Perhaps, I 
suffer from my experience with some civil engineers here, because for 
civil engineers the first thing is the standard. Second comes the 
standard, which is the only thing. The word of good or the law are 
helpful - but they are not part of the standard.
I worked with an institute of steel construction and the relevant 
standard was the DIN 18.800. That was the word of god. And if god would 
have spoken differently, he would be berated because he would have 
violated DIN 18.800. This may sound extremely narrow minded. But as a 
consequence, e.g. civil engineers from the US, from GB, from Germany, 
from Japan and much other places in the world could cooperate in 
building things like the
Akashi-Kaikyo-Bridge
http://en.wikipedia.org/wiki/Akashi_Kaiky%C5%8D_Bridge
because they understood each other.

And I've seen many engineers, particularly civil engineers, shaking 
their heads about us CS guys and complaining: When are the CS guys to 
develop a professional engineering attitude towards their own work?

In other words: Most of us know the well known Unix cookie: "When 
builders built buildings like programmers write programs, any woodpecker 
that came along would destroy human civilization."

So we can apply the term "serialization delay" to a wire line interface. 
For mobile networs and 802.11 this term simply does not apply.

And I was held responsible for not providing something which is, to the 
best of our knowledge, physically impossible. E.g. providing QoS in HSDPA
would require some kind of throughput forecast. Not only for my own 
channel but for competing ones as well because of opportunistic scheduling.

Now, it's credited not only to Niels Bohr but to many scientists:
"Prediction is hard. Especially of the future."

As I said. This experience hurts until this day - and not only as a 
personal experience, in that case I should not talk about this here, but 
as a central misconception in how we deal with mobile networks! And as 
long as algorithms like VJCC do not make a difference between wired and 
wireless networks but are applied thoughtlessly on "internetworks" 
consisting of wired and wireless lines as well, we cannot really expect 
them to provide the results we want to see!

So this is not only a personal experience but I'm convinced I've learned 
something during the last 13 years.

Detlef

Detlef

Detlef



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