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

doc.: IEEE /1183r0 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 /1183r0 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 4 Fast Initial Link Setup? May not be meaningful, if upper layer setup consumes time by broadcast/multicast packet losses

doc.: IEEE /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 5 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 6 For Fast Initial and Subsequent IPv4 Setup ai needs address allocation mechanisms other than DHCP –may be as a integrated part of the 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 7 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 8 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 9 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 DHCPv6 solicit message have 0~1 second initial delay

doc.: IEEE /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 10 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 AAA cache Experimental (4068) and informational (4260) RFCs modifying basic ND only for mobile IPv6 only –should better have a rational address allocation mechanism

doc.: IEEE /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 11 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 /1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 12 References [RFCs]: available from by RFC numbers