[e2e] How many transmission attempts should be done on wireless networks?
David P. Reed
dpreed at reed.com
Fri Sep 18 10:49:57 PDT 2009
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest