1 / 12

IP over Congested WLAN

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

orinda
Télécharger la présentation

IP over Congested WLAN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IP over Congested WLAN Authors: Date: 2011-09-19 Masataka Ohta, Tokyo Institute of Technology

  2. Abstract IP layer delays caused by unreliable broadcast/multicast over congested WLAN is discussed Masataka Ohta, Tokyo Institute of Technology

  3. 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

  4. 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

  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 Masataka Ohta, Tokyo Institute of Technology

  6. 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

  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 Masataka Ohta, Tokyo Institute of Technology

  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 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

  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 Masataka Ohta, Tokyo Institute of Technology

  10. 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

  11. 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

  12. References • [RFCs]: available from www.ietf.org/rfc.html by RFC numbers Masataka Ohta, Tokyo Institute of Technology

More Related