doc.: ieee 802.11-11/1183r0 submission september 2011 masataka ohta, tokyo institute of...

12
September 2011 Masat aka O hta, Slide 1 doc.: IEEE 802.11-11/1183r0 Submission IP over Congested WLAN Date: 2011-09-19 N am e A ffiliations A ddress Phone em ail M asataka Ohta Tokyo Instutute ofTechnology 2-12-1-W8-54, O okayam a, M eguro, Tokyo 152-8552, JAPAN +81-3-5734- 3299 mohta@ necom830.hpcl.tit ech.ac.jp Authors:

Upload: lee-fitzgerald

Post on 18-Dec-2015

218 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

[email protected]

Authors:

Page 2: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 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

Page 3: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 4: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 5: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 6: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 7: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 8: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 9: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 10: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 11: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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

Page 12: Doc.: IEEE 802.11-11/1183r0 Submission September 2011 Masataka Ohta, Tokyo Institute of TechnologySlide 1 IP over Congested WLAN Date: 2011-09-19 Authors:

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