doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: Authors:

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 2 Abstract IP layer delays caused by unreliable broadcast/multicast over congested WLAN is discussed

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide and are Different Unicast over and are reliable –thanks to retransmissions with CSMA/CD and CSMA/CA Broadcast/Multicast over is reliable –thanks to retransmissions with CSMA/CD Broadcast/Multicast over is not reliable –no retransmission with CSMA/CA ACK can not be sent because there may be no or more than one recipients –packets may be lost with considerable probability by simultaneous transmissions in a slot or by hidden terminals –packet losses over congested WLAN are not negligible

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 4 senderreceiver unicast lost retransmission retransmission lost lost ACK ACK senderreceiver broadcast/ multicast lost Unicast with ACK and Broadcast/Multicast without ACK upper layer retransmission after upper layer timeout?

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 5 Fast Initial Link Setup? May not be meaningful, if upper layer setup consumes time by broadcast/multicast packet losses with considerable probability –if aCWmin=7 and probability of someone sending in a slot is 50%, the probability of a slot collision of a broadcast/muticast packet (delayed randomly between 0 and 7 slots) is 1/8*50% (probability of collision at the first slot) + 1/8*50%^2 (probability of colltion at the second sclot) +... ~ 12.5%

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 6 IPv4 over Congested WLAN ARP (Address Resolution Protocol) [RFC826] may be delayed due to packet losses –ARP request is broadcast –ARP reply is unicast and safe DHCP (Dynamic Host Configuration Protocol) [RFC2131] may also be delayed –DHCP discover and DHCP request are broadcast not a problem if a DHCP server is AP or within wired LAN

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 7 Broadcast/Multicast of ARP and DHCP ARPDHCP ARP request ARP reply DHCP discover DHCP offer DHCP request DHCP reply

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 8 For Fast Initial and Subsequent IPv4 Setup ai needs address allocation mechanisms other than broadcast-based DHCP –may be as a integrated part of the fast initial link setup ARP delay can be prevented if proxy ARP is replied from an AP, if the AP has all the ARP information or AP communicate with an address allocation server

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 9 Proxy ARP by AP unicast ARP request ARP reply STA1 APSTA2 broadcast ARP request unicast ARP request proxy ARP reply STA1 AP with ARP tableSTA2

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 10 IPv6 over Congested WLAN ND (Neighbor Discovery) [RFC2461] may be delayed due to packet losses –RS (router solicitation), RA (router advertisement), NS (neighbor solicitation) are multicast –NA (neighbor advertisement) is usually unicast –Address allocation with ND optional RS to request RA RA tells a node to use SAA (stateless address autoconfiguration) [RFC2462] or DHCPv6 [RFC3315] –SAA needs DAD (duplicate address detection), which use NS and NA –DHCPv6 is like DHCP –Address resolution is with NS and unicast NA

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 11 Broadcast/Multicast of IPv6 Address Allocation Stateless Address Autoconfiguration Stateful DHCP optional RS RA DHCP solicit DHCP advertise DHCP request DHCP reply Node Router MLD report NS optional RS RA 0~1 second delay may be omitted DAD Node Router

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 12 Broadcast/Multicast of IPv6 Address Resolution NS NA Node Router

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 13 IPv6 is Multicast Intensive with Minimum Intervals Counted in Seconds (1) RA and optional RS use multicast –minimum interval (MI) of RA and RS are 3 and 4 seconds RS needs 0~1 second initial delay –mobility supporting router SHOULD use RA MI of 0.03 second [RFC3775] no RS is necessary and delay caused by waiting lossy RA is solved frequent RA should better be carried over beacon, though –RA MI of 3 seconds is still applicable to non-mobile routers too bad even if packets are not lost

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 14 IPv6 is Multicast Intensive with Minimum Intervals Counted in Seconds (2) SAA use multicast NS, which requires joining solicited- node multicast address corresponding to the target address, using MLD (multicast listener discovery) [RFC2710], which use multicast –if MLD packet is lost, default retransmission interval is 0~10 seconds, against which RFC3775 specifies no exception switches may snoop MLD DHCPv6 solicit message have 0~1 second initial delay

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 15 What are These? RFC4068: Fast Handovers for Mobile IPv6 (FMIPv6) RFC4260: Mobile IPv6 Fast Handovers for Networks Do reduce RS delay and, *IF* lucky, other delays DAD remains, unless, e.g., “the NAR can have a list of all nodes on its subnet, perhaps for access control” –have overhead of access control based on (random) SAC address!? –should better have a rational address allocation mechanism Complex inter-router protocol to reduce AAA latency –routers should better share cache of AAA relays Experimental (4068) and informational (4260) RFCs modifying basic ND for mobile IPv6 only –should better have a rational address allocation mechanism

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 16 For Fast Initial and Subsequent IPv6 Setup ai needs address allocation mechanisms other than the current ND, SAA or DHCPv6 –may be as a integrated part of the initial link setup –a problem is that IPv6 people loves ND and SAA modifications on retransmission timeout and initial delay could be a compromise Address resolution delay by lost NS may be prevented *IF* proxy NA from an AP could be tolerated

doc.: IEEE /1183r1 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 17 References [RFCs]: available from by RFC numbers