Hi Phil,
In general I like your proposal to provide more information to the link layer.
>
>>I (as a link layer designer) would like to use a flow's DSCP
>*not only* to
>>control scheduling and/or queue management algorithms at the
>network layer,
>>but *also* to control link layer error control algorithms.
>
>Exactly. Information theory says there are fundamental tradeoffs
>between delay and throughput, and it would be nice for the link layer
>to have some guidance in making these tradeoffs.
>
>The main parameter is the FEC interleaver blocksize. Larger blocksizes
>yield better performance, especially over fading channels, but they
>increase delay. So something that can tell the physical layer what
>size FEC block to use would be very helpful.
>
There are some more parameters like e.g. FEC code rate and transmission power.
>[The idea that larger blocks perform better over noisy channels may
>seem strange to those unfamiliar with coding theory. If you think that
>larger blocks would have a larger probability of at least one error,
>you're right. That's why, on *uncoded* channels, high error rates
>dictate smaller blocks. But with interleaved FEC, it's not whether
>there are *any* errors in the block, but whether their number exceeds
>some correction limit. With uncorrelated channel errors, the number of
>errors in any given block follows a binomial distribution; as
>blocksize is increased, this becomes a gaussian distribution. Thanks
>to the law of large numbers, the standard deviation of this
>distribution increases only as the square root of the blocksize. So
>the probability that the code will fail, i.e., be overwhelmed by
>errors, goes to zero as the blocksize approaches infinity *provided*
>that the expected number of errors in a block is within the code's
>error correction capability.]
I think that your explanation regarding the coding theory might lead some into the wrong direction. What you describe in your "tutorial" is an ideal scenario. The mobile radio channel is different and therefore infinite blocks lenghts are far from ideal.
The mobile radio channel can be described by a so-called coherence time, which is a measure for the duration during which the channel is correlated. Interleaving is trying to move coded bits describing the same info bit further apart than the coherence time. If that is achieved there is no further gain by increasing the interleaving.
Interleaving does help to reduce the bit error rate for a channel, but for a given bit error rate, the block error rate is increasing with increasing block length. Thus, there exists an optimal block size. It has to be large enough for efficient interleaving, but small enough for a low block error rate.
>
>This has gotten me thinking about how TOS should really work in a
>wireless link. When you think about it, the old-style qualitative TOS
>bits that meant "low delay" "high throughput" or "high reliability"
>are really not that orthogonal. Ultimately the *only* link/subnet
>characteristic that ever really matters is LATENCY. "High throughput"
>is important only insofar as it reduces latency due to queuing delay,
>and "high reliability" is important only as it decreases (or avoids)
>the latency of an end-to-end retransmission scheme. In every
>situation, the goal is the same: to complete a "transaction" as
>quickly as possible.
>
>This suggests that all the link layer ever *really* wants to know is
>the application transaction size. Two examples:
>
>A bulk file transfer is a single "large" transaction, i.e., one that
>will take many packets to complete. We assume that just having part
>of the file is useless, so we want to finish the whole thing as
>quickly as possible. And we assume the file to be much larger than the
>bandwidth*delay product of the available network path, so propagation
>delays have a small effect on the transaction latency.
>
>Here the link can be allowed to operate on the data in large chunks,
>e.g, by using large FEC code blocks that could possibly span many IP
>packets. This will increase throughput on a noisy channel and allow
>the transaction to complete more quickly -- thus reducing "latency" by
>this particular application's definition.
Besides the negative impacts of increased delays for TCP slow start, increasing the interleaving delay might be harmful, because TCP has this bias for connections with a large RTT. This is for me another reason for not having large interleaving blocks.
I don't see big advantages of having many IP packets in one FEC code block for the reasons I explained above. But I do completely agree that the link layer needs more information to perform its job in the best possible way.
/Michael
******************
Michael Meyer
Ericsson Research
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:24 EST