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 78 th IETF, July 2010, Maastricht, Netherlands 1

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 2

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 3

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 4

Query Processing – In summary Unicast or multicast General Query – Query can be transmitted to any address (RFC3376, 3810) All hosts addresses ( 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 5

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 6

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

Next Step More study of tuning values and considerations based on simulation result WG document ? 8