|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [e2e] Ressource Fairness or Througput Fairness, was Re: Opportunistic Scheduling.
Date: Mon Jul 23 2007 - 17:22:28 EDT
Noel Chiappa wrote:
> > From: Detlef Bosau <detlef.bosau@web.de>
>
> > - 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.
>
> "sensitive to data corruption" would probably be a better way to phrase that
> first one...
>
>
Thanks. (And now you all know: I´m not a native speaker. Prepositions and the like are always a problem. And we Germans often strike back with articles :-))
> > IP or any other packet switched protocol must not be used for media
> > streaming in mobile networks.
>
> Well, at an architectural level, the internetworking model is supposed to
> work for media applications (i.e. error-tolerant applications) on networks
> with some errors.
>
> That's the whole reason IP and TCP were split apart to begin with, because
> the media applications (packet voice was the one they were actually doing)
> didn't need the high robustness of TCP, and the data stream delays caused by
> retranmissions were a bad case of "cure is worse than the disease". That
> allowed applications which didn't need the data robustness of TCP to be built
> directly on an unreliable datagram service.
>
That points into the direction of having header data "better protected" than payload.
However: Is this implemented particularly in mobile wireless networks,
particularly on "data channels"?
And to the best of my knowlege, IP packets typically _are_ conveyed via
"data channels".
In the mentioned project, I was advised to ignore the checksum in UDP
packets. If we ignore possible problems with the header information,
this is exactly what you write: Respect the (IP) header checksum and
ignore the rest.
However: What happens on the link layer? In the link layer specifications for data channels I read so far (and I never happened to read a standard where header data is given better protection than payload, although I often heard about it) there is frequently a data recovery mechanism which simply tries to recover the data packets and which check the correctnes of a packet by _one_ CRC sum for the whole packet. Or for the individual "radio blocks" respectively, which in turn means nothing else than that the whole packet is either error free or will be dropped.
> Similarly, UDP has a distinguished value of the checksum field for "no
> checksum", for applications for which data perfection is not critical.
>
Surely it has! But how do I tell the link layer not to care for correctness? Where is the switch where I can tell the link layer: "Dear Link Layer! I never will have a look at the UDP checksum, I always leave it alone!" and where I don´t get the answer: "So, when you don´t care for the checksum, you surely won´t mind me to care for a correct checksum, won´t you?"
Some months ago, Dave Reed wrote that mobile network´s link layers often are simply "too smart"! ;-)
I´m not quite sure, whether we have header checksums particularly for UDP and RTP, or perhaps for UDP and RTP combined, than we could define for the link layer that it shall care for the IP/UDP/RTP headers to be correct - and _must_ _not_ care for the rest. I´m curious whether this is implemented in any wireless mobile network?
> IPv4 has a separate header checksum which has to be correct; the thinking
> being that if the internetwork header is damaged, you might as well toss the
> packet, since it's quite possibly damaged past the point of being useful
> (e.g. source or destination address is damaged).
>
>
Yes. And when the checksum is correct the network shall be well behaved
and damn stupid and convey the packet.
However, some of these networks like GPRS, UMTS and I´m not yet sure
with HSDPA are "know it all" networks and even toss the packet when it´s
perfectly acceptable for (to? Prepositions are rerrible ;-) ) the
application.
That´s a typical end-to-end argument: Only the application knows whether
the packet is o.k. or not. (However, "smart" networks think, they knew
better ;-))
>
> The obvious engineering response (especially on low bandwidth networks!),
> knowing that if the header suffers a bit error, the bandwidth used to send
> the packet will have been wasted, is to use an internetwork<->network
> adaption layer that takes special measures to protect the header. E.g. an FEC
> or CRC - something that can *correct*, not just *detect*, errors - over that
> part of the packet, or something like that.
>
> Does any high-error, low-datarate network used for media applications
> actually do this?
>
>
That´s exactly my concern! I heard some rumour that this were intended.
But I never saw it practically.
(And it´s only a concern in _packet_ switching as in "_line_ switching" / TDM networks the "header information" is put into the schedule and therefore the problem does not exist any more.)
> The next obvious response is one that requires a little bit of cooperation
> from the internetwork level, which is to realize that for data applications,
> which are sensitive to data error (such as TCP), it's worth turning on
> network-level reliability mechanisms (such as a CRC over the entire packet).
> Obviously, the internetwork layer ought to have a bit to say that; the
> adaption layer shouldn't have to look at the protocol type.
>
>
That´s the "switch", I missed above.
> Interestingly, again, IPv4 originally did include such a mechanism: the ToS
> bits did include a "high reliability" bit, but I'm not sure we fully
> understood the potential application I am speaking of here.
>
Tempora mutantur, nos et mutamur in illis, or how the use of the ToS
bits changed over the years ;-)
> (Also, interestingly, speaking of IPv4, IPv6 doen't have a separate header
> checksum; IIRC the thinking was it was duplicative of the end-end checksum.
> That's why UDPv6 mandates the checksum. However, it seems to me that this,
> plus the UDP checksum point, means that in a very critical area, IPv6 is
> actually less suitable for media applications than IPv4. But I digress..)
>
>
Is this really digressive?
Interestingly, some people within the COMCAR project talked about IPv6 in newspaper interviews and emphasized its suitability for media applications in mobile networks =8-)
> > .. what would be a litte flaw for a propper implemented line switching
> > is reliably turned into a disaster, when you use packet switching.
>
> Now this raises another interesting point (although not the one you were
> making, which I think I have answered above); which is that circuit switching
> is potentially inherently better for transmission systems which have high
> BER.
>
> One possible way this could be true is that the application will perform
> poorly, and that damaged packets potentially waste bandwidth. However, I
> think this can be mostly avoided through use of CRC's, etc, as discussed
> above.
Yes. However, the actual IPv6 discussion points into a different direction. And I well think of projects which recommend IPv6 even for mobile networks. And when I consider your points above, this requires some considerations. The one thing is whether we _can_ use IPv6 even vor media tranportation in packet switched networks when your points are considered. The other thing is whether the implementations are actually _done_ that way.
> Yes, that makes for a slightly more complex design, but in this day
> and age (we're not back in the age of 74-series TTL anymore) the extra
> computing power to do a CRC is 'no big deal'.
>
> Another point might be the per-packet header overhead, but this is obviously
> an old debate, one where the other advantages of the datagram model (such as
> the lack of a setup delay) have carried the day - to the point that even
> notionally circuit-based systems such as ATM have had datagram features,
> along with per-packet headers...
>
>
>
And we both know about the long term success of ATM :-)
> I think the original IPv4 design did a reasonable (not perfect, of course -
> we had nothing like the experience we have now) job on these things. Perhaps
> the understanding of those points was not spread as widely as it should have
> been, though (through not being prominently discussed, as the other points of
> the datagram design philosophy were).
>
> The system you worked on (which apparently used an all-or-nothing approach to
> data integrity - could they even repair damage, or just detect it?) didn't do
> that, but I don't think it proved it can't be done (any more than the Titanic
> proved you can't make ships which don't kill passengers by the thousand :-).
>
>
The system I worked on is spilled milk. And it was not my job to change the IP implementation. I had to work above IP. In addition, I did not see all these details. I started the whole work with little, not to say no, knowledge about mobile networks.
It´s spilled milk. And perhaps, I will learn and accept this one day.
Detlef
> Noel
>
-- Detlef Bosau Mail: detlef.bosau@web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937Received on Mon Jul 23 17:55:07 2007
This archive was generated by hypermail 2.1.8 : Mon Oct 29 2007 - 14:15:35 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |