[e2e] How many transmission attempts should be done on wireless networks?

[David P. Reed]

Queues and retransmissions are inseparable.  You have to maintain a 
queue while retransmitting.   Ideally (in coding theory) you never would 
retransmit the same thing twice.   You would instead transmit a smaller 
and different piece of information the second time, so that the 
combination at the receiver would regenerate the lost information.

For an erasure channel, you could use low rate Reed-Solomon codes or 
other kinds of things over the link.   For other kinds of channels, you 
could do other kinds of things.  But the key thing here regarding 
latency and throughput is: don't create a queue behind your 
retransmission by focusing on moving the current packet (becoming older 
and older) at "heroic cost".   This is an "end-to-end argument" about 
placing function (reliable delivery) in the wrong place (at the link 
layer in wireless).

Larry Roberts fumes (and I support him) about 802.11 systems that won't 
stop retransmitting one Ethernet packet until 255 tries have been made.  
That means that congestion is not signaled and routing is not changed 
for 255 times too long.  What the link should do is fragment packets to 
tinier deliverable units, reassemble them, and stop creating a backup in 
the path.

On 09/18/2009 12:06 PM, Detlef Bosau wrote:
>
> O.k., so that's the case for small queues: small queuing latencies and 
> endpoints, which back off intelligently.
>
> But what's the reason for doing only a small number of retransmissions 
> locally on a lossy channel?
>
> One point, you mentioned, is that an application may want to pause and 
> wait for better channel conditions (you talked about load conditions, 
> but this is comparable).
>
> Basically, my question is to which extent recovery on lossy links 
> should be done locally and to which extent recovery should be left to 
> the end points.
>
> Detlef
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090918/5d72a9e6/attachment.html