Re: [multrans] Some comments on draft-jaclee-behave-v4v6-mcast-ps-01

[Tina Tsou <[e-mail]>]

Hi Stig et al,

I agree that it might be useful to emphasize the particularity of multicast
features. Here lists the aspects I could think about.

1. Multicast communication is asymmetric. The source does not necessarily
need to be the receiver and vice versa. For TV class application, multicast
data delivery is unidirectional. 

2. Multicast network is segmented. The source does not necessarily perceive
the receiver and vice versa.  Thus multiple protocols (i.e. IGMP and PIM)
are required among source/network/receiver.

3. As its key application, video service has different performance
requirements as unicast service.

4. The above mentioned unique feature of multicast network structure and
service requirements determines its own transitioning characteristics, which
is not the same as unicast one.

5. Multicast has its own address management architecture and its counterpart
during transition period should be considered particularly.

6. Even several drafts have been proposed in different groups, their
standpoint is from different technique aspects, and should be evaluated
under the common infrastructure of multicast transition, whether they are
the proper technique meeting the networking/service requirement of specific
multicast transition scenario. This should be the task of Multrans.

More specific comments on draft-jaclee-behave-v4v6-mcast-ps-01.

1.1.  Goals
...
   o  Check if both encapsulation and translation schemes are concerned .
[Tina: It might be better to add "considering the requirement of multicast
network performance".]

2.  Discussion
...
Access to IPv4 multicast contents raises several
      issues: (1) The completion of the IGMP-based multicast group
      subscription procedure, (2) The computation of the IPv4 multicast
      distribution tree, and (3) The IPv4-inferred addressing scheme to
      be used in a networking environment which will progressively
      become IPv6-enabled, but not necessarily IPv6 multicast enabled.
[Tina: It may need clearer illustration for this paragraph.]

3.2.  Context
...
Since there is mis-match of
   IP address family of sources, receiver, and delivery network, the
   operator should plan carefully and choose the right transition
   technique that could efficiently utilize the network resources to
   deliver the services.
[Tina: Suggest to change "is" to "may be", as mismatch does not necessarily
happen.]

...
   (**) Hybrid is used to denote a network where customers may be
   IPv4-only DS and/or DS-Lite serviced.
[Tina: Revise "IPv4-only DS" to " IPv4-only, DS".]

...
So based on the capabilities of the underlying multicast delivery
   Infrastructure.
[Tina: It seems an incomplete sentence.]

3.3.  Dual-Stack Multicast Delivery Infrastructure
   Dual-stack model is supposed to be the most straight forward
   deployment model where the network is dual-stack and the same content
   is sourced into both IPv4 and IPv6 multicast stream.
[Tina: "straight forward" to "straightforward".]

3.4.1.  Translation Cases
...
* Receivers have to know the translated   |
   |                       |  source address in the context SSM        |
   |                       | * Receivers would have to know the        |
   |                       | translated multicast group address        |
   |                       | * The information loss during the         |
   |                       | translation operations  
[Tina: For TV-class application, if e.g. an IPv6 user is authorized to
access an IPv4 content, he should has the way to get address(pair) for this
content, just as in the pure IPv4 case. Perhaps this might not necessarily
be a limitation.]

3.4.2.  Traversal Cases
...
This solution may require two                     |
   |               | translation levels, can impact the overall        |
   |               | performance of the CPE, may alter the perceived   |
   |               | quality of experience, etc.  This solution may be |
   |               | the source of service disruption (especially for  |
   |               | live TV broadcasting).  This is not desirable
[Tina: Whether this be verified by experimental data? I.e. Can it be
declared that two-layer translation cannot meet the multicast delivery
performance requirements.]
...
Doing so, would lead to a |
   |               | single core multicast tree and flow replication   |
   |               | to DS-Lite serviced devices will occur upon       |
   |               | request.  Multicast flows are not replicated in   |
   |               | the core and aggregation network
[Tina: "a single core multicast tree" seems contradicting with "Multicast
flows are not replicated in the core".]

4.2.  Group and Source Discovery Considerations
...
The ALG may be located downstream the receiver.  
[Tina: In general a receiver is on the lowest level, not clear the use of
"downstream".]

4.3.  Subscription
...
the information conveyed in IGMP messages should be relayed into
corresponding MLD messages.
[Tina: Is it possible that translation is made directly between IGMP and
PIMv6 without intervening of MLD?]

4.4.  Multicast Tree Computation
[Tina: It seems the title does not fit the content very well.]

   Grafting to an IPv4 multicast distribution tree through an IPv6
   multicast domain suggests that IPv4 multicast traffic will have to be
   conveyed along an "IPv6-equivalent" multicast distribution tree.
[Tina: Not clear how can a <S4,G4> multicast data stream forwarded according
to PIM <S6,G6> forwarding state.]

4.9.1.1.  IGMP-MLD Interworking
[Tina: Might be better to add illustration when and where this interworking
is needed.]


We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Stig Venaas
Sent: Thursday, May 05, 2011 2:49 PM
To: [e-mail]
Subject: [multrans] Some comments on draft-jaclee-behave-v4v6-mcast-ps-01

Hi

I've read through this draft again and I have some comments.

First is the scope of the draft. Based on the title it seems
generic, but it seems to focus on a single provider, providing
multicast streams to its users? What if there are multiple
sources, or the users can also send. One example would be
RTCP, another multi-party conferencing. There may be more.

I think you either should make it clearer that this is the
scope, or try to make it more generic. I agree that what you
cover is probably the most common case though.

When you list the issue of AMT, I think you should note that
you lose the benefit of multicast between gateways and relays.
It's just unicast then.

In 3.4.1 it says:

    The content will be delivered once which is better utilized the
    network bandwidth.  However if the application relies on the IP
    information stored in the payload (e.g., SDP), then translation will
    break the application.

This is not obvious. E.g. the source of the SDP may be able to
include both IPv4 and IPv6 and groups, in the case it knows the
translation mappings. You are saying something like this in 4.2 too.

You generally seem to focus a lot on DS-Lite, but there may be other
alternatives. E.g. in 3.4.2. Maybe talk about tunneling in more general
terms, but note that DS-Lite is an example.

In 4.2, you first say that an ALG is needed. But as you explain
yourself, it can also be avoided.

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