120 likes | 237 Vues
IP over Congested WLAN. Authors:. Date: 2011-09-19. Abstract. IP layer delays caused by unreliable broadcast/multicast over congested WLAN is discussed. 802.3 and 802.11 are Different. Unicast over 802.3 and 802.11 are reliable thanks to retransmissions with CSMA/CD and CSMA/CA
E N D
IP over Congested WLAN Authors: Date: 2011-09-19 Masataka Ohta, Tokyo Institute of Technology
Abstract IP layer delays caused by unreliable broadcast/multicast over congested WLAN is discussed Masataka Ohta, Tokyo Institute of Technology
802.3 and 802.11 are Different • Unicast over 802.3 and 802.11 are reliable • thanks to retransmissions with CSMA/CD and CSMA/CA • Broadcast/Multicast over 802.3 is reliable • thanks to retransmissions with CSMA/CD • Broadcast/Multicast over 802.11 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 Masataka Ohta, Tokyo Institute of Technology
Fast Initial Link Setup? • May not be meaningful, if upper layer setup consumes time by broadcast/multicast packet losses Masataka Ohta, Tokyo Institute of Technology
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 Masataka Ohta, Tokyo Institute of Technology
For Fast Initial and Subsequent IPv4 Setup • 802.11ai 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 Masataka Ohta, Tokyo Institute of Technology
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 Masataka Ohta, Tokyo Institute of Technology
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 802.11 beacon, though • RA MI of 3 seconds is still applicable to non-mobile routers • too bad even if packets are not lost Masataka Ohta, Tokyo Institute of Technology
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 Masataka Ohta, Tokyo Institute of Technology
What are These?RFC4068: Fast Handovers for Mobile IPv6 (FMIPv6)RFC4260: Mobile IPv6 Fast Handovers for 802.11 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 Masataka Ohta, Tokyo Institute of Technology
For Fast Initial and Subsequent IPv6 Setup • 802.11ai 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 Masataka Ohta, Tokyo Institute of Technology
References • [RFCs]: available from www.ietf.org/rfc.html by RFC numbers Masataka Ohta, Tokyo Institute of Technology