[e2e] Ressource Fairness or Througput Fairness, was Re: Opportunistic Scheduling.
detlef.bosau at web.de
Sun Jul 22 14:02:35 PDT 2007
there is another very basic objection, I have to your Inforcom Paper.
This is a _very_ common misconception, and I suffer from this for years.
In once was involved in a project called COMCAR and had to do a quite
strange task within this project.
There were no results - and I was accused for that. And honestly, I
think one did me wrong there.
My task was to produce an "adaptive middleware" for "adaptive
components" in wireless networking. This whole thing started in 2000 and
I never talked about this in the public. I´m extremely bitter about this
project and that I was made responsible for things I´m not responsible for.
One difficulty was, and during the last years I learned that this is
perhaps the most basic reason why adaptation of multimedia documents in
mobile networks is condemned to fail before it´s even started, that
there is no serious possibility to have a long-term or even medium-term
prediction of a wireless channel´s properties.
If you want to adapt a document or a multimedia system´s appearance to
changing channel properties and if you want to do this in an acceptable
manner, i.e. don´t want to change your appearance any 10 ms, you
inevitably need a certain idea of what properties your channel will
expect to have for, say, the next 10 or 20 seconds. And from all what I
know about mobile networks, this is simply ridiculous. Of course, there
are the usual Nearly Infallible Sources of knowledge: Laplace´s demon,
clairvoyance and divine inspiration ;-)
What I learned in addition, and know I switch to your paper, is that
media streaming and TCP are two different cups of tea.
I was condemned to work with IP and I was strictly forbidden to have a
look at the lower layers and that time, I did not have the standing to
resist such a request. I felt, I had to look at the lower layers and
that time I did not really know why.
The reasons are so simple.
- Data flows are typically asynchronous and sensitive against data
- Media flows are typcially synchronous / isochronous and at least to a
certain degree robust against data corruption.
With respect to mobile networks that means: Because you inevitably have
a recovery layer in these systems:
Any recovery layer based upon ARQ or HARQ as it is offered today simply
has no means to accept "blocks with one percent bit error rate" or
"blocks with only a small number of bits being corrupted". An ARQ block
or HARQ block is either corrupt or intact.
So, I´m absolutely convinced that in networks with high error rates,
i.e. particularly mobile wireless networks, IP is absolutely ill suited
for any kind of media streaming.
I know, that there is some religious faith which claims the contrary,
but after having thought about this problem many years know, I´m
convinced that IP or any other packet switched protocol must not be used
for media streaming in mobile networks.
You can even have anouther approach to the same problem.
Media flows are typically conveyed using RTP/UDP/IP.
When media flows are played out, you need three kinds of information.
- What is played out
- where and
"When" is determined by the RTP header, partitially "where", when
several flows are multiplexed.
"Where" is determined by the RTP header (see above), the UDP header
(port) and the IP header (user equipment´s address.)
"What" is dtermined by the RTP SDU.
Have anything corrupted but the RTP SDU, than you can throw away your
So, your media flow may well tolerate 1 percent BER, if the one
corrupted bit is in the time stamp in the RTP header, you can throw away
your whole RTP packet which may consist of say 1 kBypte, roughly spoken:
So, what would be a litte flaw for a propper implemented line switching
is reliably turned into a disaster, when you use packet switching.
If I knew this eight years ago, I would have simply not joined the
project or cancelled my employment within the first three months of this
nonsense. And I´m sure that my personal situation would be a different
one from that what it is now. So, please forgive me when I´m bitter on
But when I read your paper, I saw two TCP flows and one Audio flow and
one Video flow.
And then I saw something on throughput, which is necessarily comparing
peaches and oranges in that case, because no one is interested in TCP
throughput. One is typically interested in TCP _goodput_. And that has
to take into account of couse TCP retransmissions and can be "slightly"
differ from any kind of L2 throughput in faulty networks.
In consequence, I´m not quite sure whether it makes sense to handle TCP
and media flows by the same kind of scheduler anyway. More drastically
spoken: I´m strongly convinced that this is simply nonsense.
I was not allowed to deal with lower layers that time. Otherwise, I
would have learned what I learned duing my unemployed time because no
one was to tell me then I shouldn´t, that in _any_ kind of mobile
- forwared error correction
- care for error robustness
- data compression
for media streams (e.g. speech) is done simply completely different from
the ARQ/FEC schemes used for data, particularly there is _no_ ARQ and
there is no packet switching but line switching (...with the usual
metric ton of salt if someone thinks of line switching being done with
copper lines) and therefore the
- When and
for a media flow is determined by the system´s schedule and anything is
This is one of the rare rules which is even not confirmed by any
Therefore, we can make phone calls with mobile phones.
But from my experiences from the last years, I´m strictly opposed to IP
based media streaming in mobile wireless networks. I think that media
flows should be delivered using line switching techniques and if someone
wants to combine packet switching and line switching here, I often
remembered the "Beyound IP" project, I think it was pusrued by Paul
Krueger in Kaiserslautern some years ago, which targeted at a similar
goal with ATM and IP IIRC.
However, I strongly beleive that IP based packet switching in mobile
wireless networks is not the correct way to go and that there are better
alternatives, e.g. a hybrid approach like Beyond IP.
It may well be that the situation is different in WLAN. In fact, I´ve
seen successful media flow distribution via IP Multicast in WLAN.
However, in WLAN, you have well placed antennas and no mobility (i.e.
pedestrian, i.e. no mobility) and strong distance restrictions. I often
say: WLAN is a wirebound network with invisible copper.
I well know that there are approaches to add additional protection to
UDP / RTP headers in media flows to accommodate them to mobile networks,
but I´m not yet convinced that the results are really better than media
tranport using line switching techniques in that case.
O.k. My position is somewhat extreme and perhaps not common sense. But
at least, I confessed it :-)
In addition: The situation becomes much more complex when it comes to
HSDPA networks. I think, there are some remarks necessary particularly
in this context concening the term "rate" and some scheduling issues,
but I´m still working on it.
Detlef Bosau Mail: detlef.bosau at web.de
Galileistrasse 30 Web: http://www.detlef-bosau.de
70565 Stuttgart Skype: detlef.bosau
Mobile: +49 172 681 9937
More information about the end2end-interest