80 likes | 212 Views
78 th IETF, July 2010, Maastricht, Netherlands. Tuning the Behavior of IGMP and MLD for Mobile Hosts and Routers. draft‐asaeda‐multimob‐igmp‐mld‐optimization‐03 Hitoshi Asaeda, Yogo Uchida Keio University. Changes from -02.
E N D
78th IETF, July 2010, Maastricht, Netherlands Tuning the Behavior of IGMP and MLD for Mobile Hosts and Routers draft‐asaeda‐multimob‐igmp‐mld‐optimization‐03 Hitoshi Asaeda, Yogo Uchida Keio University
Changes from -02 • Remove the specification description of the explicit membership tracking function • “IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers” • draft-asaeda-mboned-explicit-tracking-00 • Describe potential tuning values thanks to our simulation results • Query interval, Query response interval, Startup query interval • Robustness variable
Tracking of Membership State • The explicit tracking function on routers (described in a separate draft) works for: • Per-host accounting • Reducing the number of transmitted Query and Report messages • Shortening leave latencies • Maintaining multicast channel characteristics (or statistics) • For tuning IGMP/MLD timers/values for mobile multicast, this draft assumes routers enable the explicit tracking function • The explicit tracking function is MUST
Simulation Scenario • IEEE802.11b link • IPv6 only (MLDv2) • 40 MNs individually join/leave the same channel (as seen in the next slide) • MNs moves with random waypoint algorithm (the above white solid lines show trajectories for MNs) • Multicast stream bandwidth is 120kbps
Query Processing – In summary • Unicast or multicast General Query • Query can be transmitted to any address (RFC3376, 3810) • All hosts addresses (224.0.0.1 and ff02::1) are used as the destination of general query in general • Unicasting General Query would be advantageous when the small number of MNs join a same channel • The Query Interval timer can be adjusted according to the number of MNs • The Query Response Interval timer would be shortened from its default value • Multicasting General Query would be advantageous when a large number of MNs join a same channel
Timers, Counters, Default Values • [Query Interval] • Default: 125 sec. • Larger values cause IGMP Queries to be sent less often • Proposal • 125 sec. for unicast General Query with the small number of MNs (e.g. le 100 MNs) • 150 sec. for unicast General Query with the large number of MNs (e.g. gt 100 MNs) • 180 sec. for multicast General Query • Useful with a large number of MNs such as more than 500 MNs • [Query Response Interval] • Default: 10 sec. • Larger values make the traffic less bursty • Proposal • 5 sec. for unicast General Query • 10 sec. for multicast General Query
Timers, Counters, Default Values • [Startup Query Interval] • Default: 1/4 of [Query Interval] (= 25 sec.) • Shorter value such as 1 sec. contributes to slightly smooth handover (e.g. for PMIPv6) • Proposal • 1 second • [Robustness Variable] • Default: 2 • Should not be bigger than 2, especially when [Query Response Interval] is set smaller than its default value • Proposal • 2 (and SHOULD NOT be bigger than 2)
Next Step • More study of tuning values and considerations based on simulation result • WG document ?