[e2e] Ressource Fairness or Througput Fairness, was Re: Opportunistic Scheduling.

[Detlef Bosau]

Dave,

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

"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 
whole packet.
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: 
10.000 bits.

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 
this one.

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 
networks the
- coding
- forwared error correction
- adaptation
- care for error robustness
- data compression
- switching
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
- Where
for a media flow is determined by the system´s schedule and anything is 
fine.

This is one of the rare rules which is even not confirmed by any 
exception ;-)

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