Transcript 80th IETF, March 2011, Prague, Czech Republic Tuning the Behavior of IGMP and MLD for Mobile Hosts and Routers draft‐asaeda‐multimob‐igmp‐mld‐optimization05 Hitoshi Asaeda, Yogo Uchida,

80th IETF, March 2011, Prague, Czech Republic
Tuning the Behavior of IGMP and
MLD for Mobile Hosts and Routers
draft‐asaeda‐multimob‐igmp‐mld‐optimization05
Hitoshi Asaeda, Yogo Uchida, Hui Liu, Qin Wu
Changes from -04
• Add Hui Liu and Qin Wu as the co-authors
– Contributed to editorial improvement
• Unicast general query is moved to Appendix
80th IETF, March 2011
2
Outline
• Describes the ways of IGMPv3 and MLDv2
protocol optimization for mobility, and aims to
become a guideline for query and other timers
/values tuning.
• Potential tuning values are clarified
– Query Interval
– Query Response Interval
– Last Member Query Count (LMQC) / Last Listener
Query Count (LLQC)
– Startup Query Interval
– Robustness Variable
80th IETF, March 2011
3
Tracking of Membership State
• “IGMP/MLD-Based Explicit Membership Tracking
Function for Multicast Routers”
– draft-asaeda-mboned-explicit-tracking-02
• Contribution for tuning
– Reduce the number of Group(-and-Source) Specific
query messages and its reply messages
– Shorten the leave latency by shorter LMQT/LLQT
• The explicit tracking function is SHOULD for
multicast routers (or proxies) maintaining mobile
nodes
80th IETF, March 2011
4
Query Interval (125 sec.)
• 150 sec.
– For a wireless link having a number of nodes (e.g.,200
nodes)
– Pro.
• Minimizing traffic of Report messages and battery power
consumption for mobile hosts
• 60 to 90 sec.
– For a wireless link having a higher capacity of the
resource
– Pro.
• Quick synchronization of the membership information
tracked by the router
80th IETF, March 2011
5
Query Response Interval (10 sec.)
• 10 to 20 sec.
– For a wireless link having a lower capacity of network resource
(e.g., a bursty IEEE 802.11b link) or for a lossy link
– Pro.
• Reduce congestion of the Current-State Report messages on a link
– Con.
• Increase join latency and leave latency when the unsolicited messages
(State-Change Record) are lost on the router
• 5 to 10 sec.
– For a wireless link having enough capacity (e.g., an IEEE 802.16e
link) or reliable condition for IGMP/MLD message transmission
– Pro.
• Quick discover of non-tracked member hosts and synchronization the
membership information
80th IETF, March 2011
6
LMQT and LLQT (2 sec.)
• LMQT (=LMQC (Rob. Var.) * LMQI (1))
• 1 sec.
– LMQC=1, LMQI=1
• For a reliable link, LMQI can be smaller, e.g. 0.5, then LMQT=0.5 sec.
– Pro.
• Shortening leave latency
– Con.
• There is a risk that a router misses Report messages from remaining
members if the router adopts small LMQC/LLQC
• However the wrong expectation would be lower happened for the
router enabling the explicit tracking function.
• 2 sec.
– LMQC=2, LMQI=1
– For a wireless link being lossy (e.g., due to a large number of
attached hosts or limited resources)
80th IETF, March 2011
7
Startup Query Interval (1/4 of [Query
Interval] (e.g. 25 sec.))
• 1 sec.
– Pros.
• Quick member discovery
• Shortening handover
80th IETF, March 2011
8
Robustness Variable (2)
• 2
– In the regular case
• 1
– For a wireless link having higher capacity of the
resource or reliable condition
• Note
– SHOULD NOT be bigger than 2
80th IETF, March 2011
9
Appendix. Unicast General Query
• Unicast Query Interval and Unicast Query
Response Interval
– RFC3376 and 3810 do not distinguish multicast
and unicast General Query and do not define
different timer values
– Pros.
• No drain on battery power for non-member nodes
• Shorter Query Interval and smaller Robustness Variable
would be possible
– Protocol extension?
80th IETF, March 2011
10
Next Step
• We appreciate your review
• WG draft ?
80th IETF, March 2011
11