Link layer ARQ paper

[Jean Tourrilhes <[e-mail]>]

	Hi,

	I just came across you IETF draft :
http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-arq-issues-01.txt

	First, I must congratulate you on the very high quality of
your work. Your analysis is very complete and accurate, and echo what
I've been thinking for quite a while. It dispell efficiently of the
old myth present in the TCP/IP community (Wireless link == loss, let's
fix TCP). It's one of the best thing on the subject I've read for
years ;-)

	The second thing, I would like to know if there exist a
permanent URL for this work. I would like to link to it from my web
page where I have article related to a similar topic, and it would be
a welcome addition (I still have to dispell the myth).

	Now, I have a few suggestions of topic to further enhance this
work ;-) Hey, when you are on a roll... Sorry if these topics have
already been beaten to death, but I just thought you might be
interested...
	You'll probably need to pick up the papers on my web page wich
give a few clues about what I'm talking about :
	http://www.hpl.hp.com/personal/Jean_Tourrilhes/Papers/papers.html

	In one of my paper, I discuss limits on ARQ. 802.11 has a
maximum number of retries, whereas I advocate a maximum time to live
for the Tx packet. As I'm not a specialist of TCP/IP, I've no idea of
what would be an ideal MAC TTL, but maybe you could give us clues
based on link characteristics... It would be even better if the MAC
had an way to determine this optimal TTL based on some simple metric
of the current TCP/IP traffic (i.e. : should the MAC calculate the TCP
RTO ?)...
	<Paper : SWAP and TCP/IP>

	Cause of packet losses : you've forgotten the number 1 cause
of packet loss over 802.11, which is MAC contention. From my
similations of 802.11, it's not unusual to have 10% losses or more due
to 2 nodes picking up the same slot in the contention window. Of
course, this applies only to CSMA/CA protocols.
	<Paper : Robust Broadcast>

	Problem for broadcast packets : ARQ applies only to Unicast,
so expect losses for Broadcast. Just provide a small warning that this
discussion applies only to Unicast stream, and the multicast and
broadcast are a different matter (maybe another paper for you there ;-).
	<Paper : Robust Broadcast>

	Not everything is TCP. The classical argument for removing ARQ
from the link layer is that TCP will take care of that. However, not
everything is TCP traffic, and you can have UDP and ICMP traffic. For
example, VoIP won't sustain a 10% frame erasure rate, so the link has
better to ARQ.
	<Aironet mailing list discussion -> ping losses>

	ARQ latency. I believe that for Wireless LAN (very small local
RTO), stop-and-go is better that a sliding window mechanism, because
it keeps the delay jitter minimal and keep packets in order. Keeping
packet in order is especially important because of fast
retransmit. However, I could not seem much difference in practive
(IrDA use a 7 frames window, 802.11 use stop-and-go). Comments ?
	<Aironet mailing list discussion>

	Half duplex links : I thought half duplex would be a
problem. IrDA use a half duplex link and turnaround the link on a
regular basis. With no load, ping RTT is 10ms, but climb up to ~100ms
when link is loaded (due to increased window size). On the other hand,
TCP throughput is around 3.2 Mb/s (over 4 Mb/s link).

	One of my early concern with BlueTooth is the short CRC (16
bits), especially with regards to DM5/DH5 packets (802.11 and SWAP
have 32 bits). BlueTooth has FEC in DM5, but that's worthless against
deep fading and interference. With IrDA that has a 16 bits CRC at the
link layer, I had occurence of garbage going up the stack in very
noisy environments. On the other hand, TCP/IP is checksumed as well,
so we should be safe ?

	Differential latency : there is some case of 802.11FH where
latency of large and small packet are very different (factor 10). If
the latency is small enough, can I assume that it doesn't matter ?
	<Dwell Adaptive Reduction>

	Link adaptation and variation. Most 802.11 products have
automatic bit rate selection, changing the modulation based on the
current SNR. Also, base on the BER, you can vary the amount of
fragmentation, which changes the overhead. For wide area, protocol
like GPRS use the spare slots of a cell, so data capacity vary in
function of voice calls and handovers. So far, it seems that TCP/IP
adapt pretty well to that. Not related to this paper, but...
	<Fragment adaptive reductions>

	Interferer, roaming, fading, ... The impact of those stuff on
Wireless LANs tend to be a long period where nothing go through
(seconds) and packet are dropped despite ARQ (hit max retries). That's
the classical link handover problem. With BlueTooth, a link handover
can take up to 20s (because of inquiry+scan). I guess that Fast
recovery will deal with that...
	<Fragment adaptive reduction>


	Sorry for the length, I hope you will find my random blurb
usefull, and have fun...

	Jean