Subject: [multimob] The MLD tuning milestone

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2010 11:00:22 -0700

At our meeting the general opinion seemed to be that none of the current
individual MLD tuning drafts were ready to be adopted.

It probably makes sense for us as a working group to figure out in more
detail what we actually want from such a document. This can help authors
of MLD tuning drafts to write a draft that we want to adopt.

Below are some of my thoughts on this. I hope this can initiate some
useful discussion. We did have some good discussion along these lines
in the wg meeting, and I'm hoping we can continue it now.

The parts of the charter I believe are relevant are:

|Specific goals for the group are:
|  - Document how multicast can be supported in a Proxy Mobile IPv6
|  environment
|  - Document the configuration of IGMPv3/MLDv2 in mobile environments

Next we have:

|  IGMPv3/MLDv2 has been specified for wired networks with shared links.
|  Mobile nodes have needs that are specific to wireless networks and
|  mobility (e.g. entering a dormant mode to conserve battery power,
|  minimizing the latency for joining and leaving a group in support of
|  movement).
|
|  The second task of the WG is to assess existing solutions for group
|  management, and determine to what extent these methods are sufficient
|  in a mobile environment. This will include recommending appropriate
|  selection of timer values and protocol parameters.

And finally the milestone:

|Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for mobility,
|for publication as either Informational or Best Current Practice

1. What is tuning?

    I believe when we say tuning, there are definitely no protocol
    changes. The way IGMPv3/MLDv2 are designed, there are parameters
    like Robustness Variable, Query Interval, Maximum Response Delay
    that certainly can be tuned. RFC 3810 already has section 9.14
    that discusses these to some extent.

    The most restrictive way to think of tuning would be to just look
    at parameters like this that are designed to be tunable.

    There is also a lot of flexibility and options regarding how to
    implement these protocols. Some of the things that have been
    brought up are explicit tracking and unicast of messages. Do you
    think such things should be considered tuning? If not tuning,
    should it still be considered in this document?

    What else should be considered tuning or appropriate for the
    document?

2. Recommendations for specific link types, scenarios or in general?

    It may be possible to talk about tuning some of these parameters
    in general. Some of that is already in RFC 3810 section 9.14. E.g.
    if high loss, consider this, if many clients consider this. If
    you do this you may also do that etc. Is something like this what
    we want?

    Should we try to find some real life scenarios, specific link types
    and test or simulate things? Or is it sufficient to say that if a
    link has certain characteristics (without it necessarily being
    related to a concrete existing technology), then based on simulation
    or reasoning, this is the tuning that works best?

3. What should the style of the document be?

    Do we want a BCP? One example of a BCP might be RFC 3819. Is that
    kind of document structure something like what we want? Other
    suggestions? Would analysis in the same style as say section 8.5.3
    be reasonable?

    I'm not sure whether I should have picked a particular RFC here. If
    people can illustrate what they want by referring to existing
    documents or describing it in other ways, that would be great.

4. What else?

    These are roughly the things I can think of. Any thoughts on
    structure of documents, what it should contain etc. would be very
    welcome. My personal opinion is that we should be a bit restrictive
    regarding what we want from this document, in order to make forward
    progress. On the other hand, the document should have some useful
    information and go beyond the recommendations that already are there
    in the IGMPv3/MLDv2 RFCs.

Stig

---

From: Liu Hui <[email-masked]>
Date: Tue, 24 Aug 2010 22:19:49 +0800

Hi Stig,

Please see my considerations on the issues in line: 
> 
> At our meeting the general opinion seemed to be that none of 
> the current individual MLD tuning drafts were ready to be adopted.
> 
> It probably makes sense for us as a working group to figure 
> out in more detail what we actually want from such a 
> document. This can help authors of MLD tuning drafts to write 
> a draft that we want to adopt.

> Below are some of my thoughts on this. I hope this can 
> initiate some useful discussion. We did have some good 
> discussion along these lines in the wg meeting, and I'm 
> hoping we can continue it now.

I think this effort of clarification is beneficial.

> |for publication as either Informational or Best Current Practice

If I'm not wrong, it is recognized that the changing of IGMP and MLD should
be cautious to avoid interoperability problems.  This is why the charter on
it has been revised several times.  

> 1. What is tuning?

I'd like to divide the "changes" we talked into four groups:
G1. of parameter values, 
G2. of protocol behavior without defining new messages on the media (line or
wireless link) and without introducing interoperability problems
G3. of protocol behavior by defining new messages but within the scope of
group management protocol 
G4. of protocol behavior by supporting new functions which are outside the
scope of group management,

 I believe G1 and G2 could be thought of as tuning.

>     at parameters like this that are designed to be tunable.

This belong to G1. Because they are already be covered 3810, I don't think
it's necessary to redecribe it as a new work.

>     should it still be considered in this document?

This belongs to G2. I think they are the true tuning of IGMP/MLD protocols,
if they require" the minor changes on the implementations", but "without
changes of the message types" and "without the interoperability problems" (I
might miss some others) . Some options proposed in the current tuning drafts
might belong to this catagory. I think they should be covered within the
current charter. 

>     What else should be considered tuning or appropriate for the

Any optimizations (which might be proposed in the future), if they meet the
three requirements above for G2

>     you do this you may also do that etc. Is something like this what

Every parameter in IGMP/MLD is configurable. They have been covered by 3810.

>     or reasoning, this is the tuning that works best?

If we have simulation that would be better.  But in some cases, soming tuing
might be thought work best with simple reasoning.  For example, for point to
point link, Group-Specific Queries designed for multiple users can be cut
without any need of simulation.  The choices could be made according to the
situations. 

>     documents or describing it in other ways, that would be great.

I think we should prepare a document first decribing scenarios and problems,
giving the reasons why IGMP and MLD need to be tuned.  Then list the
possible tunning options we think reasonable to solve the problems.  This
doc could be BCP or be informational.

Then if some of the options need to be analyzed detailedly, separate docs
could be prepared. Their type could be determined according to their
contents.

8.5.3 style might be useful for some of scenarios such as calculation of
channel zapping speed, etc.  But still there are other tuning options that
do not require this calculation.  I think this style could be incooperated
into concrete options if needed

> 4. What else?

Besides, G3 should also be considered if the change deserve it.  But for G4,
I think they should be resolved by other control protocols rather than  MLD
protocols themselves.

>     in the IGMPv3/MLDv2 RFCs.

Agreed.  I think the document should provide some useful informations that
current RFCs don't have

Best Regards,
Liu Hui

---

From: Bill Atwood <[email-masked]>
Date: Tue, 24 Aug 2010 10:48:27 -0400

One comment, which results from my discussions in Mboned about extending 
IGMP to carry authentication/authorization information:

Given that IGMP v3 has not seen wide adoption (in spite of the fact that 
it has been standardized since 2002) and given the fact that IGMP v3 was 
seen as sufficiently "heavy" that a "lightweight" version of it was 
defined (RFC 5790), it is _not_ likely that an "IGMP v4" would ever gain 
traction.

Therefore, since G3 and G4 would definitely constitute a proposal for 
"IGMP v4", the group should stick with what can be done in the areas of 
G1 and G2.

   Bill

Liu Hui wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Aug 2010 09:49:13 -0700 (PDT)

Folks, 
  A few corrections on Hui's mail and my views:

- Multimob had a single charter, no revisions/ rechartering yet.
- The charter is clear on the MLD tuning milestone, we need a single document 
not many.
G1, i.e. parameter tuning and G2, i.e. "behaviour tuning" are needed. Regarding 
simulations, 

we had a presentation about simulation results in Maastricht, they were good but 
applied to
a single link type. WG wondered about other link types?

Stig mentioned: One example of a BCP might be RFC 3819. In this RFC, several 
link types are covered and recommendations are given.
Can we have extensive simulations for all link types? 
Maybe not. In the meeting it was mentioned that simple measurements could be OK.

Regards,

Behcet

----- Original Message ----
> From: Liu Hui <[email-masked]>
> To: Stig Venaas <[email-masked]>; [email-masked]
> Sent: Tue, August 24, 2010 9:19:49 AM
> Subject: Re: [multimob] The MLD tuning milestone
> 
> Hi Stig,
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 31 Aug 2010 17:02:22 +0900 (JST)

Hi Behcet,

> G1, i.e. parameter tuning and G2, i.e. "behaviour tuning" are
> needed.

IMO, the word, "tuning", can be used only for changing "values" or
"parameters".
I may say saying "changing behavior" is reasonable but "tuning
behavior" is a bit strange, because it means "protocol modification",
doesn't it?

> Regarding simulations, 
> we had a presentation about simulation results in Maastricht, they
> were good but applied to

Yes, we can modify and run our simulation with different link types
and different scenarios.
Please wait a while.

Regards,
--
Hitoshi Asaeda