[e2e] Congestion control as a hot topic in IETF
detlef.bosau at web.de
Sat Mar 9 16:22:58 PST 2013
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
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
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
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
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
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.
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest