Subject: Re: [Mobopts] [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Mar 2009 11:15:15 -0700 (PDT)

Hi Craig,

many thanks for your thoughtful review. I am sure the authors and the RG find this useful.

Regards,

-Rajeev

--- On Tue, 3/24/09, Craig Partridge <[email-masked]> wrote:

From: Craig Partridge <[email-masked]>
Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
To: [email-masked]
Date: Tuesday, March 24, 2009, 9:22 AM

I had two almost contradictory views after reviewing the document.

The first view is that it is very well-informed and presents a lot of
complex information well.  The second view is that it seems lost -- that
it doesn't know what it is trying to do and where it is going.

So, I'm comfortable seeing it published -- I think some folks will find
it useful, but have some suggestions for how it could be improved to work
as a roadmap for research/thinking about the problem of multicast
mobility in wireless (which I think is what it aspires to be).

Comments:

    * First, the draft should be more explicit that its focus is
      on multicast IPv6 mobility in WIRELESS environments.  You can read
      the early part of the draft and think you might be involved
      in worrying about someone unplugging from one wired network and plugging
      into wired network.  Particular odd is that Figure 1 clearly
      envisions wireless edge networks (single and multihop) yet never
      says wireless anywhere in the text around it.

      (Example -- "wireless" appears in the abstract but then not
      again until page 8...)

    * The document appears to be seeking to define a set of constraints
      within which a solution must appear.  I took the step of capitalizing
      every MUST/MUST NOT and SHOULD/SHOULD NOT in the document and when you
      do that the document is clearly a half-thought-out requirements
      document.  I suspect the authors would be surprised at themselves if
      they undertook the experiment.

      I mention it because I often reacted that the document was setting
      requirements in one spot but not another and I wondered why.

    * in section 2.1, "jointly support unicast and multicast" -- why
      not broadcast and anycast as well? (esp. as broadcast is
      near universal in wireless and anycast apparently matters)

    * in section 2.2.1, 2nd bullet, why would we enable multicast in
      a network but ban a particular multicast group from circulation?
      (Needs some more explanation here about why this happens -- it is
      a surprising restriction not mentioned earlier).

    * 2.2.2 uses the word "n-casting" in a context where it is clear
      the draft things n-casting is evil, but n-casting is never defined
      anywhere in the document.

    * 2.4 "Facing deployment complexity, it is desirable that any solution for
      mobile multicast SHOULD leave routing protocosl unchanged". [Note
      I capitalized SHOULD to point out the restriction here].  Why is this
      desired?  If we found a routing approach that worked better for all
      environments and supported multicast, wouldn't we prefer that?

    * 4.1 -- never mentions that wireless is inherently a broadcast medium
      and that there may be opportunities to exploit this feature.
      Especially for receivers, an inherently multicast medium makes it
      easier to rejoin groups (if the group is already live, you can
      immediately listen in).

Craig
_______________________________________________
IRSG mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/irsg

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 27 Mar 2009 12:11:57 -0700

Hi Craig,

many thanks for your fast and highly reflective review: this will 
certainly trigger many reflections on our side, as well.

So we will take a bit of time to think things over again ... and then 
respond in detail.

Thanks again!

Kind regards,

Thomas

Rajeev Koodli wrote:
> --- On *Tue, 3/24/09, Craig Partridge /<[email-masked]>/* wrote:
> 
> 
>           says wireless anywhere in the text around it..
> 
>     [email-masked] </mc/compose?to=[email-masked]>
> ------------------------------------------------------------------------
> 
> Mobopts mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/mobopts

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 28 Mar 2009 01:32:17 -0700

Dear Craig,

many thanks again for your review.

We have now discussed and overlooked things, and are ready to answer: 
please see comments inline.

>     it doesn't know what it is trying to do and where it is going.

This is in a sense quite right: We are trying to comprehensively explore 
the problem space and to present all relevant aspects of the somewhat 
intricate issues. The idea was to write a general reference document 
that summarizes 'all there is to think about' in its corresponding contexts.

In this sense, the document is not going into a particular direction, 
that's right.

>           (Example -- "wireless" appears in the abstract but then not

Yes, you are right: one should not forget about the obvious.

We added explicit statements in the introduction to link to the wireless 
domain.

>           they undertook the experiment.

We repeated your experiment and questioned all these occurrences. In 
quite a number of cases we reworded, in particular the "must/must not" 
terms.

In general the document does not make use of normative terms in the 
sense of RFC 2119, so there are repeated occurrences where "should" is 
just used as an English word, in particular like "should preferably do ...".

There are a couple of instances, where requirements drop out of other 
sources. Some originate for instance from normative aspects of existing 
standards (e.g., "must respect scoping restrictions"), some are just 
logical consequences of technical arguments given beforehand (e.g., 
"source must provide address transparency"). The latter are not meant as 
requirements for specific protocols, but as conclusions "if we want to 
achieve this, we have to do the other".

>           requirements in one spot but not another and I wondered why.
Actually, we tried to keep the solution space as open as possible by 
avoiding any evitable constraint in argumentation.

>           near universal in wireless and anycast apparently matters)
:-) The issue we discuss is multicast and thereby assume, a unicast 
routing is present. Broadcast, I suspect, is not exactly an issue, as it 
may be viewed as a special case of multicast (can at least be emulated 
by multicast).
Anycast matters, yes, but it is not required to implement multicast. So 
adding anycast mobility aspects to the document would probably just 
confuse the reader, or am I wrong?

>           a surprising restriction not mentioned earlier).
We added a clarifying remark.
A limited group allowance is not rare these days for administrative 
reasons. A typical example are IPTV deployments, where providers offer 
(allow for) a certain collection of groups (TV channels) they 
(contractually) support. Other IPTV multicast groups they do not support 
(allow) in their networks. So by changing a provider on handover, one 
may enter a domain without the group previously under subscription.

>           anywhere in the document.
We added an explanation.

By the way: this is not meant to say n-casting is evil - the document 
just recalls known issues.

>           environments and supported multicast, wouldn't we prefer that?

 From a technical and research perspective we completely agree: We would 
much rather design an elegant routing protocol than fiddle with proxy 
functions. However, this is a pure deployment argument. Given the 
experiences with slow, limited multicast deployment today, it appears 
much more promising to propose solutions that only require adding some 
'boxes' at the wireless edges and leave the routing core untouched. 
Otherwise, we assume, a timely deployment is hardly to expect.

>           easier to rejoin groups (if the group is already live, you can
Yes, again this is one of the obvious to be mentioned in the beginning 
of section 4. We added this.

I hope we got all your comments and hints right.

Best regards,

Thomas

--