Re: [Mobopts] RG Last Call for draft-irtf-mobopts-mmcastv6-ps-04.txt

["Thomas C. Schmidt" <[e-mail]>]

Hi Marshall,

many thanks for your detailed review ... and sorry for answering late.

Please see answers/comments inline.

Marshall Eubanks wrote:

> 
> A general comment : By its title, this is explicitly an IPv6 document, 
> but some things that are mentioned
> (DVMRP, SAP, BGMP), which I don't think have IPv6 deployment. I assume 
> that a little bit of that is ok but have pointed out a few cases where 
> it seems unnecessary.
> 
Yup ... the perspective is to keep the multicast 'world' somehow 
comprehensive ...

> Comments on the text :
> 
> NIT : Section 1, paragraph 5,
> In addition, real-time
>    communication such as conversational voice or video places severe
>    temporal requirement on mobility protocols:
> 
> s/requirement/requirements/
> 

O.K. - changed.

> Section 1, paragraph 5,
> 
> Can you provide a reference for the 100 ms / 50 ms requirements ? Those 
> are fairly tight.
> 
> For example, I believe that there is an ITU requirements document with a 
> 300 msec videoconferencing latency requirement, and there is some old 
> Bell Labs telephony work, but I don't recall anything listing 100 msec as
> a requirement.
> 

O.K. - I'll seek a reference. 100 ms is about a spoken syllable and the 
statement is intended to express an aim. We weakened it in the following 
sentence as not to be a strict requirement.

> Section 1.1
> 
> I did not find the discussion of "Multi-hop network mobility" to be at 
> all clear. A reference would help.
> I also did not find the figure 1 to be clear - only the Multi-Hop has a 
> Mobile Network in it, which is not
> clearly defined.
> 
> Is Multi-hop network mobility just the same as NEMO ? Then say so, and 
> reference it.
> 

Mobile multi-hop networks coins the class of scenarios, where routing 
entities are mobile. NEMO is one solution of those, we cited an overview 
article (ref. 8) to hint to a general description of such scenarios and 
related issues.

As said in 1.1., this is not the focus of the document. Actually, adding 
this side remark follows a suggestion of Kevin, who proposed to just 
mark the additional problems inherited by mobile networks.
The graph is supposed to visualize the additional mobile network, which 
you saw - mhmm, what is unclear?

> Section 2.1
> 
> I would remove this sentence, which is not relevant for IPv6 or this I-D :
> 
>    Other
>    multicast routing protocols without significant current deployment
>    include CBT [18], BGMP [19].
> 

O.K. This was just for the sake of completeness.

> Page 5, paragraph 3
> 
>    Multicast routing dynamically adapts to the topology of the sender(s)
>    and receiver(s) participating in a multicast session, which then may
>    change under mobility.
> 
> I would change this to
> 
>    Multicast routing dynamically adapts to the network topology at the 
> locations of the sender(s)
>    and receiver(s) participating in a multicast session, which then may
> 

O.K., done.

> Here
> 
> However, depending on the topology and the
>    protocol in use, current multicast routing protocols may require a
>    time close to seconds, or even minutes, to converge following a
>    change in receiver or sender location.
> 
> What current multicast protocols would take minutes to converge ?
> 

:-) o.k., you got us with the "current": DVMRP does, but you don't 
consider it current. PIM-SM does, when you move/rebuild the RP, but I 
guess this is not the common scenario.

I take the minutes out, o.k.?

> Page 6, partial paragraph at top
> 
> Due to statelessness, the bi-
>    casting of multicast flows does not cause foreseeable degradations at
>    the transport layer.
> 
> What does this mean ? Is this a reference to BiDir (if so, say so).
> 
> By statelessness, do you mean soft-state ?
> 
No, this is a transport statement, not related to routing states or 
BiDir PIM. Bicasting may degrade stateful transport endpoints (in TCP, 
SCTP or DCCP), which is not an issue with multicast.

> What are foreseeable degradations ? Does it cause unforeseeable 
> degradations ?
> 

What is meant: There still could be issues, e.g., with applications 
which don't like bicasting (that sort UDP packets in a careless manner) 
... but this we don't know.

What about adding a clarifying remark?

> Section 2.2.1 :
> 
>    The problem of achieving seamless multicast listener handovers is
>    thus threefold:
>      o Ensure multicast reception, even in visited networks, without
>        appropriate multicast support.
>      o Minimize multicast forwarding delay to provide seamless
>        and fast handovers for real-time services. Dependant on layer 2
>        and 3 handover performance, the time available for multicast
>        mobility operations is typically bound to a fraction of 100 ms.
> 
> Are you saying that this should be a goal ? Where does that number come 
> from ? Be more explicit.
> 

Mobile multicast protocols come into operation after a layer 2 handoff 
and typically after *MIPv6 protocols have completed (a new IPv6 
connectivity is operational). This takes an amount of time (not 
explicitly known), which is not negligible (802.11 handoff is between 
~30 and ~300 ms, 3GPP/UMTS is much faster). So we don't know any general 
value, but the time for multicast to regain stream connectivity is 
actually reduced by these effects.

What about: "... is typically bound to the fraction of the total 
handover time left after IPv6 connectivity is regained. In real-time 
scenarios this may be significantly less than 100 ms."

> Section 2.3.1. [end] :
> 
> In the presence of an
>    embedded rendezvous point address [26], e.g., the primary rendezvous
>    point for inter-domain PIM-SM will be globally appointed and the
>    signaling requirements obsolete.
> 
> Is this saying that for Embedded RP the RP will always be used, even if 
> that leads to triangular routing ?
> Isn't such specifications not part a problem statement ?
> 
> If not, why won't there be a need for signaling ?

This section is about source mobility and wants to say that a newly 
attached source can immediately contact the RP (like a new source) and 
transmit data in the PIM register tunnel.

You are pointing to the PIM-SM source-specific shortcuts, which indeed 
need to be re-established after a source movement. The latter of course 
needs signaling.

We will clarify this.

> 
> Section 2.3.2 :
> 
> NIT : As the
>    principle multicast decoupling of a sender from its receivers holds
> 
> s/principle/principle of/
> 

O.K., fixed.


> Section  4.1 :
> 
>    Several aspects need consideration: First, dissimilar network access
>    radio technologies cause distinct group traffic transmissions. There
>    are:
> 
>     o connection-less link services of a broadcast type, which mostly
>       are bound to limited reliability;
> 
>     o connection-oriented link services of a point-to-multipoint type,
>       which require more complex control and frequently exhibit reduced
>       efficiency;
> 
>     o connection-oriented link services of a broadcast type, which are
>       restricted to unidirectional data transmission.
> 
> Which of these choices is used for normal unicast traffic ? One option 
> at the wireless link layer in, for example, 3GPP MBMS, is to send 
> multicasts are point to point unicast, that also needs to be pointed out 
> and its
> network access RF implications listed.
> 
Normal unicast modes are not explicitly listed here ... but we can add 
this in the memory of MBMS ;)


> Also, a fundamental difference between unicast and multicast in some RF 
> technologies is that the unicast transmit power is adjusted to be as 
> small as possible based on link layer feedback from the receiver. In 
> multicast this is not done, or is done in some cases (e.g., 3GPP MBMS). 
> This is why there is a "multicast tax" which means that multicast is not 
> as efficient as unicast, unless the group size on the local RF link is > 
> some number, typically 2.
> 

Great point: we will add this.


> Section 4.2.1 :
> 
>    To limit or prevent the latter, many vendors have implemented a
>    configurable rate limit for forwarding multicast packets.
>    Additionally, an IGMP/MLD snooping or proxy may be active at the
>    bridging layer between the BSS and the ESS or at switches
>    interconnecting access points.
> 
> Is anyone doing the IGMP/MLD snooping or proxy at the RF Layer, to 
> prevent the unnecessary RF broadcasting of multicasts by an access point ?
> 
IGMP/MLD snooping and separation happens at the MAC layer. 802.11 APs do 
this at the BSS/ESS bridge (between cable and air), but cannot do at the 
wireless PHY. This is different in e.g., 802.16.

> Section 4.2.2 :
> 
> Service flows may provide an optional Automatic
>    Repeat Request (ARQ) to improve reliability and may operate in point-
>    to-point or point-to-multipoint (restricted to downlink and without
>    ARQ) mode.
> 
> What about mesh mode ? Can't that do multicast ?
> 

I believe it cannot, because neighboring nodes initiate connections in a 
3-way handshake. But we'll check back with Rajeev, he should reliably know.

> 
>    To invoke a multipoint data channel, the base station assigns a
>    common CID to all Subscriber Stations in the group. An IPv6 multicast
>    address mapping to these 16 bit IDs is proposed by copying either the
>    4 lowest bits, while sustaining the scope field, or by utilizing the
>    8 lowest bits derived from Multicast on Ethernet CS [44]. For
>    selecting group members, a Base Station may implement IGMP/MLD
>    snooping or proxy as foreseen in 802.16e-2005 [45].
> 
> I did not find that to be at all clear,  but to be frank I find 
> draft-sekim-802-16-multicast-01 fairly confusing
> as well. It might be best not to try and explain it, and just reference 
> draft-sekim-802-16-multicast-01.

O.k., we'll try to move this somehow to a non-confusing but 
comprehensive state.

> 
> Paragraph 4 :
> 
> On reception, a Subscriber Station
>    cannot distinguish multicast from unicast streams.
> 
> Do you mean, at link layer ? Surely this is not true at the IP layer.
> 

Yes, of course on the link-layer: now clearly added.

> Section 4.2.3 3GPP
> 
> In  3GPP2 MBMS is called Broadcast and Multicast Service (BCMCS). They 
> are very similar - I would mention that somewhere.
> 
O.k.

> In both 3GPP and 3GPP2 multicasts can either be sent using PTP (point to 
> point) or PTM (point to multipoint) tunnels, and there is support for, 
> e.g., switching from PTP to PTM.
> 
> P2P uses receiver feedback to adjust power levels.
> 
> MBMS PTM uses a unidirectional common channel, operating in 
> “Unacknowledged” mode, with
> 
> No adjustment of power levels.
> No reporting of lost packets.
> 
> This means that transmission levels must be conservative, “worst-case,” 
> and thus wasteful of power on average.
> 
> To help reduce this performance loss, WCMDA supports Packet Downlink 
> Ack/Nack Mode (PDAN), where MBMS session feedback can be provided by up 
> to 16 terminals in a given cell. I don't know how commonly used this is.
> 
> I would include some discussion of these issues.
>

O.K., thanks: we'll do.

> Section 4.3
> 
>  A mobile multicast node may operate homogeneous (horizontal) or
>    heterogeneous (vertical) layer 2 handovers with or without layer 3
>    network changes. Consequently, a dedicated context transfer of
>    multicast configuration is required at network access. Media
>    Independent Handover (MIH) is addressed in IEEE 802.21 [53], but is
>    relevant also beyond IEEE protocols. Mobility services transport for
>    MIH naturally reside on the network layer and are currently in the
>    process of specification [54].
> 
> 
> I did not find this to be clear. Do you need to distinguish between 
> horizontal and vertical layer 2 handovers ?
> If so, put in a sentence describing this better and / or a reference.
> 

I guess, this is somehow important to bring to mind:

  * If you do a vertical handover, you may need to transfer and 
*transform* multicast service context (address mapping schemes ...).
  * If you do a horizontal handover, you still may need to 
transfer/activate multicast groups.

In many discussions we've experienced people not being aware of that. 
We'll try to add clarifications.

> Section 5.2.1 :
> 
>   An approach based on dynamically negotiated inter-agent handovers is
>    presented in [62]. Aside from IETF work, countless publications
>    present proposals for seamless multicast listener mobility, e.g. [63]
>    provides a comprehensive overview.
> 
> I would change "countless" to "numerous"
> 
O.K., done.

> I would point out that reference 63 is 4 years old, fairly old for this 
> technology.
> 
O.K., done. I haven't seen any newer survey though.

> Section 5.3.1. :
> 
> NIT : Solutions for multicast source mobility can be divided in to three
>    categories:
> 
> s/in to/into/
> 
O.K., is corrected.

>     o Tree Modification Schemes. In the case of DVMRP routing,
>       Chang and Yen [71] propose an algorithm to extend the root of a
>       given delivery tree for incorporating a new source location in
>       ASM. The authors rely on a complex additional signaling protocol
>       to fix DVMRP forwarding states and heal failures in the reverse
>       path forwarding (RPF) checks.
> 
> Is there a DVMRP for IPv6 ? Is this paragraph needed ?
> 
It is not for IPv6, but is one of the 'original' attempts. We find it 
worth mentioning to hint on the ideas, in case other people might want 
to pick up some of it for IPv6.

> Section 5.3.2 :
> 
>    The shared tree approach of [69] has been extended to support SSM
>    mobility by introducing the HoA address record to the Mobility-aware
>    Rendezvous Points. The MRPs operate using extended multicast routing
>    tables that simultaneously hold the HoA and CoA and thus can
>    logically identify the appropriate distribution tree. Mobility thus
>    re-introduces the concept of rendezvous points to SSM routing.
> 
> I do not regard that last sentence as by any means having passed IETF 
> consensus.
> 
> How about
> 
> Mobility thus may
>    re-introduce the concept of rendezvous points to SSM routing.
> 

:-) This is only reporting on the work, not a statement meant to reach a 
general consensus. It is changed now.


Thanks again for the many good pointers!

Thomas

-- 

° Prof. Dr. Thomas C. Schmidt
° HAW Hamburg, Dept. Informatik
° University of Applied Sciences
° Berliner Tor 7, D 20099 Hamburg, Germany
° Fon: [phone], Fax: -8409
° http://www.informatik.haw-hamburg.de/~schmidt
_______________________________________________
Mobopts mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/mobopts