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

["Thomas C. Schmidt" <schmidt at informatik.haw-hamburg.de>]

Dear Craig,

thanks and sorry for this delay: After some processing problems with 
editor tools, version 7 of the draft is now online. The following 
changes were made:

[Mentioning wireless]

Section 1. Introduction:
After
   "Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5,6],"
was added
   "and addresses the scenario of network layer changes while moving
   between wireless domains."

Section 1.1 Document Scope:
After
  "When considering multicast node mobility,"
was added
  "the network layer is complemented by some wireless access technology."


[Use of requirement-like must/should ...]

Section 2.1 General Issues:

  "Any multicast mobility solution must take all of these functional
   blocks into account."
changed to
  "Any multicast mobility solution needs to take all of these functional
   blocks into account."

  "It should preserve the multicast nature of packet distribution and
   approximate optimal routing."
changed to
  "It is desired to preserve the multicast nature of packet 
distribution and
   approximate optimal routing."

  "Where applications are sensitive to packet loss or jitter, 
countermeasures
   must be performed (loss recovery, content recoding, concealment, 
etc) by the
   multicast transport or application."
changed to
  "Where applications are sensitive to packet loss or jitter, 
countermeasures need
   to be performed (loss recovery, content recoding, concealment, etc) 
by the
   multicast transport or application."


Section 2.3.2 Source Specific Multicast Mobility:

  "The above methods add significant complexity to provide a robust SSM
   mobility solution, which needs to converge to optimal routes and, for
   efficiency, should avoid data encapsulation."
changed to
   "The above methods add significant complexity to provide a robust SSM
   mobility solution, which needs to converge to optimal routes and, for
   efficiency, is desired to avoid data encapsulation. "


Section 2.4 Deployment Issues:

   "Facing deployment complexity, it is desirable that any solution for
   mobile multicast should leave routing protocols unchanged."
changed to
   "Facing deployment complexity, it is desirable that any solution for
   mobile multicast leaves routing protocols unchanged."

Section 5.2.1 Agent Assistance:

   "Future optimizations and extensions to shared links should foresee 
native
   multicast distribution towards the edge network, ..."
changed to
   "Future optimizations and extensions to shared links preferably 
adapt native
   multicast distribution towards the edge network, ..."


["Banned" multicast groups]

Section 2.2.1 Node & Application Perspective:

After
   "The requested multicast service may be supported and enabled in
    the visited network, but the multicast groups under subscription
    may not be forwarded to it,"
was added:
    "e.g., groups may be scoped or administratively prohibited."


[Unresolved n-casting]

Section 2.2.2 Network Perspective:

   "Avoid avalanche problems and n-casting, ..."
changed to
   "Avoid avalanche problems and stream multiplication (n-casting), ..."


[wireless is inherently a broadcast medium]

Section 4.1 General Background:

   "Of focal interest to the mobility domain are wireless access 
technologies,
   which always operate on a shared medium with limited frequency and 
bandwidth."
changed to
   "Of focal interest to the mobility domain are wireless access 
technologies, which are
   inherently broadcast-oriented and always operate on a shared medium
   with limited frequency and bandwidth."


Finally, references have been updated and a few typos fixed.

Thanks,

Thomas


Craig Partridge wrote:
> All sounds right from my perspective (sorry for delay -- I was on
> vacation).
>
> In message <49CDE091.7070705 at informatik.haw-hamburg.de>, "Thomas C. Schmidt" wr
> ites:
>
> > Dear Craig,
> >
> > many thanks again for your review.
> >
> > We have now discussed and overlooked things, and are ready to answer: 
> > please see comments inline.
> >
> >
> > > --- On *Tue, 3/24/09, Craig Partridge /<craig at aland.bbn.com>/* wrote:
> > >
> > >
> > >     From: Craig Partridge <craig at aland.bbn.com>
> > >     Subject: [IRSG] review of draft-irtf-mobopts-mmcastv6-ps-06.txt
> > >     To: irsg at ISI.EDU
> > >     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.
> > 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.
> >
> > >     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...)
> > Yes, you are right: one should not forget about the obvious.
> >
> > We added explicit statements in the introduction to link to the wireless 
> > domain.
> >
> > >         * 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.
> > 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".
> >
> > >           I mention it because I often reacted that the document was setting
> > >           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.
> >
> > >         * 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)
> > :-) 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?
> >
> >
> > >         * 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).
> > 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.
> >
> > >         * 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.
> > We added an explanation.
> >
> > By the way: this is not meant to say n-casting is evil - the document 
> > just recalls known issues.
> >
> > >         * 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?
> > 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.
> >
> > >         * 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).
> > 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

--

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 °