doc.: ieee 802.11-11/1183r0 submission september 2011 masataka ohta, tokyo institute of...
TRANSCRIPT
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 1
doc.: IEEE 802.11-11/1183r0
Submission
IP over Congested WLANDate: 2011-09-19
Name Affiliations Address Phone email Masataka Ohta Tokyo Instutute
of Technology 2-12-1-W8-54, Ookayama, Meguro, Tokyo 152-8552, JAPAN
+81-3-5734-3299
Authors:
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 2
doc.: IEEE 802.11-11/1183r0
Submission
Abstract
IP layer delays caused by unreliable broadcast/multicast over congested WLAN is discussed
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 3
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 4
doc.: IEEE 802.11-11/1183r0
Submission
Fast Initial Link Setup?
• May not be meaningful, if upper layer setup consumes time by broadcast/multicast packet losses
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 5
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 6
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 7
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 8
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 9
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 10
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 11
doc.: IEEE 802.11-11/1183r0
Submission
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
September 2011
Masataka Ohta, Tokyo Institute of Technology
Slide 12
doc.: IEEE 802.11-11/1183r0
Submission
References
• [RFCs]: available from www.ietf.org/rfc.html by RFC numbers