|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [e2e] Ressource Fairness or Througput Fairness, was Re: Opportunistic Scheduling.
Date: Mon Jul 23 2007 - 13:34:20 EDT
> 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...
> you inevitably have a recovery layer in these systems: ... simply has
> no means to accept "blocks with one percent bit error rate" ... block
> is either corrupt or intact.
> ...
> .. in networks with high error rates, i.e. particularly mobile wireless
> networks, IP is absolutely ill suited for any kind of media streaming.
> ...
> 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.
Similarly, UDP has a distinguished value of the checksum field for "no checksum", for applications for which data perfection is not critical. (Although on checking the IPv6 specification for a point below, I notice that IPv6 doesn't have this capability. More on this below...)
But you do have one (actually several) interesting points below here:
> 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.
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).
However, on high BER networks with a simplistic internetwork<->network adaption layer (important!), there's a good chance (especially with the smaller packets that some media applications produce) that in any packet with error(s), an error will have occurred in the header, and the packet will have to be discarded.
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?
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.
For one, on low-bandwidth networks, this makes sure that the bandwidth isn't wasted. More importantly, TCP responds poorly when a high percentage of packets are dropped; throughput goes to the floor (because modern TCP's interpret this as a signal of congestion), and worse, the connection may close.
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.
(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..)
> .. 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, 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...
But I have seriously tried to think of an inherent advantage that circuit swithed networks *necessarily* have over a well-designed packet switching system, and I can't think of one.
The key, of course, is that "well-designed"; the entire system (especially the internetwork<->network adaption layer) has to be designed with both these applications (data-damage-insensitive) and also these networks (high BER) in mind.
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 :-).
Noel Received on Mon Jul 23 14:01:43 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 |