Subject: Re: Link layer ARQ ID : Part 1 of reply

From: Jean Tourrilhes <[email-masked]>
Date: Wed, 14 Mar 2001 10:55:02 -0800

On Wed, Mar 14, 2001 at 09:55:30AM +0000, Gorry Fairhurst wrote:
> Part 1 of reply : List of ARQ Persistencies
> 
> 
> Having looked at the table you sent, I think it would
> be worth sending this to the PILC list, I'll do
> this (if you like) and say it is a contribution from
> you.

	I've cc'ed the list...

> >         802.11 :
> >                 Spec. default Short retry limit (RTS/CTS) : 7 retries
> >                 Spec. default Long retry limit (no RTS/CTS) : 4 retries
> >                 Cisco/Aironet default setting : 16 for both
> >                 From my simulations : 7 is a bit too low as a long retry
> >         OpenAir :
> >                 ??? 
> >         SWAP :
> >                 Tx packet TTL
> >                 (max time the MAC try to send each packet)
> >                 Spec default : 100ms
> >         HiperLan 1 :  
> >                 MSDU lifetime per packet
> >                 (end to end lifetime, including queuing and forwarding)
> >                 Settable 0ms -> 32s, 500ms by default
> >         HiperLanII :
> >                 Wireless ATM (small cells)
> >                 ???
> >         IrDA :
> >                 Fully persistent up to link timeout (as far as I can
> see)
> >                 Link timeout : 3s to 40s, default 12s
> >                 (Infrared link tend to be all or nothing)
> >         BlueTooth :
> >                 By default, fully persistent (like USB)
> >                 If flow ISOC, can limit retries (no value given), and
> >                 will flush other cells of the same PDU
> >                 Link timeout : LinkSupervisionTimeout (no value given)
> 
> 
> Can I just check a few facts?
> 
> (i) What is MSDU?

	Mac Service Data Unit. Basically, this is a packet or a frame
as manipulated by the MAC and exported to the higher layer. It may be
fragmented in the MAC.
		Ethernet (802.3) : 1500 B
		SWAP		 : 2000 B
		802.11		 : 2048 B
		HiperLan 1	 : 2420 B
	Wireless MAC try to push higher values to get better benchmark
results (we have a higher packet overhead than 802.3), unfortunately,
most TCP/IP stacks refuse to go beyond 1500.

	Note : the difference between HiperLan TTL and SWAP TTL is
that HiperLan include the queueing, access, retransmit and forwarding
delays in the value, whereas SWAP start the timer only when the packet
reach the first place in the queue (so include only the access and
retransmit delays).

> (ii) These links are all high speed wireless links. Is
> it worth adding the data rates involved? Are they
> all shared channel schemes (multiple senders) too?

	802.11 :
		CSMA/CA, 1, 2, 5.5 and 11 Mb/s
		Note : the base protocol (timing, headers, broadcasts)
is the same and designed for 1 Mb/s, that's why there is so much
overhead when you operate at 11 Mb/s (only ~5 Mb/s on top of TCP).
	OpenAir : CSMA/CA, 08 and 1.6 Mb/s
	SWAP : CSMA/CA, 1 and 2 Mb/s
		(I'm talking about the original SWAP 1.0, not SWAP 1.2)
	HiperLan 1 : CSMA/CA (with priorities), 23 Mb/s
	HiperLan II : TDMA, 9 to 54 Mb/s
	IrDA : Token passing (max 7 frames per token)
		SIR : 9.6 Kb/s to 115kb/s, FIR : up to 4 Mb/s (16 Mb/s soon)
	BT : TDMA, 1 Mb/s

> (iii) What sort of round trip link delay do people quote for
> these links?

	<standard ping round trip on Linux>
	802.11 : ~2 ms @ 11 Mb/s, ~10 ms @ 2 Mb/s
	IrDA : 20 to 40 ms on idle link, 10 to 2000 ms on loaded link

> (iv)  Have you any feel for the anticipated loss rate which
> the link is being designed for?
> 
> I'd guess up to about 10% given the persistencies?

	That's a bit hard to gauge, but my belief is that people try
to be at least as good as Ethernet (10-9 BER) above the MAC. 1% packet
drop is definitely crap. Unfortunately, when I try to do UDP test, the
AP loose my packets so I can't get any numbers.
	For the underlying wireless link, 10% seems to be in the
ballpark if you include contention, interference and channel errors
(with contention beeing usually the largest contributor).
	But, you have to take into account other mechanisms that
usually kicks in when the SNR goes to low, such as bit-rate adaptation
(shift from 11 Mb/s to 5.5 or lower), auto fragmentation and roaming
(looking for another Access Point). So, my answer is that the wireless
link is not designed in term of packet loss but in term of SNR.
	One of the problem when you go over 10% loss purely on
interference and channel error is that you will start to loose network
sync (AP beacons and co), so you will quickly assume that the network
is gone and go back to scanning for another network (i.e. roaming).

> I'll follow this with an email addressing the other 
> points.

	No problem...

	Jean