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

[Marshall Eubanks <[e-mail]>]

Hello;

I have read this document and I support the progress of this document.  
The author's have clearly spent a good deal of time going through the  
many various options for and realizations of multicast mobility and I  
think have done a good job in describing the problem and possible  
approaches.

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.

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/

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.

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.

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].

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

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 ?

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 ?

What are foreseeable degradations ? Does it cause unforeseeable  
degradations ?

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.

      o Minimize packet loss and reordering that result from multicast
        handover management.

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 ?

Section 2.3.2 :

NIT : As the
    principle multicast decoupling of a sender from its receivers holds

s/principle/principle of/

    for SSM, the client updates needed for switching trees become a
    severe burden.

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.

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.

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 ?

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 ?


    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.

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.

Section 4.2.3 3GPP

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

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.

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.

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"

I would point out that reference 63 is 4 years old, fairly old for  
this technology.

Section 5.3.1. :

NIT : Solutions for multicast source mobility can be divided in to three
    categories:

s/in to/into/

     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 ?

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.


Regards
Marshall


On Sep 8, 2008, at 2:41 PM, Koodli, Rajeev wrote:

>
> Hello folks,
>
> This is to initiate a LC for the Multicast Mobility document.
>
> This document has already gone through some good reviews resulting  
> in the current version.
>
> However, we need broader review from the RG folks, in order to  
> progress this (and other RG) documents.
>
> Please provide your comments by September 26.
>
> ID URL: http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps-04
>
> Thanks,
>
> -Rajeev
>
>
> _______________________________________________
> Mobopts mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mobopts

_______________________________________________
Mobopts mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mobopts