Re: [MBONED] draft-zhou-mboned-multrans-path-optimization

[Stig Venaas <[e-mail]>]

On 3/23/2012 11:24 AM, Lee, Yiu wrote:
> Hi Stig,
>
> On 3/23/12 1:17 PM, "Stig Venaas"<[e-mail]>  wrote:
>
>> On 3/22/2012 8:16 PM, Zhouqian (Cathy) wrote:
>>> Sorry, I mean the v4 and v6 interface, rather than the source in my
>>> last email.
>>> Yes, there will be two streams coming from the source. When the two
>>> streams coming from v4 and v6 interface separately, MTR will determine
>>> whether the two addresses (v4 and v6) have the address format based on
>>> draft-ietf-mboned-64-multicast-address-format. If the v6 address is
>>> v4-embedded v6 address according to the draft, it means the two streams
>>> are the same. If it is not, the two steams are different.
>>> Then the two streams will come to different receivers.
>>
>> The scenario I find the most interesting is a bit similar to what you
>> describe I think.
>>
>> Imagine you have a router supporting IPv4 PIM and IPv6 PIM that is
>> translation capable. Imagine that it receives IPv4 join (PIM or
>> IGMP) on one interface, and an IPv6 join (PIM or MLD) on another
>> interface. It could even be the same interface...
>>
>> Assume these joins are for (S4,G4) and (S6,G6), and that there
>> are active sources for both, sending basically the same content.
>> Either because there is a real source for both, or some upstream
>> router is translating.
>>
>> The router could then simply send upstream joins for both of these,
>> and forward the traffic as needed without translation.
>>
>> But if the router is aware that these two are really the same content,
>> it could in theory join just one of the streams, and translate as
>> needed for the one downstream that wants a different protocol. We
>> basically will have a tradeoff between bandwidth on the upstream
>> links, and the cost of translation (both on this device, and perhaps
>> the quality of the stream).
>
> [YL] Agree about the trade-off. In the Taipei demo, it seems the header
> translation is relatively cheap.
>
>>
>> One concern I have though, is that if say the stream is originally
>> (S4,G4) but this router decides to join only (S6,G6), then we may
>> end up translating twice. If possible, the router should know how
>> to choose the non-translated source.
>>
>> Also note that if this router chooses to join both (S4,G4) and (S6,G6),
>> then somewhere upstream there may be translation from IPv4 to IPv6 to
>> provide this content. And we're sort of wasting bandwidth by having two
>> identical streams coming down to this router.
>>
>> If this router only joined (S4,G4), and did translation itself, then
>> translation would still occur only in one place, and you would not
>> waste bandwidth. Basically it is good to translate as close to the
>> receiver as possible (I think).
>>
>> Note that when I say translation in one place, I mean only once on the
>> path from the source to a particular receiver. There is also a
>> trade-off with bandwidth and translation cost whether you do it close
>> to the source so that perhaps only one device does the translation for
>> all the content, or whether you do it close to the receivers so that
>> there may be multiple devices, each on a different receiver branch,
>> translating the same data.
>>
>> One final thought. Somehow having two identical streams (S4,G4) and
>> (S6,G6) can actually help provide redundancy, as long as they can
>> be translated as needed.
>
>
> [YL] I try to understand the network topology. When we develop the problem
> statement and framework, we focus on 4-6-4, 6-4 and 6-4-6-4. We didn't
> discuss the deployment scenario where we have mixed receivers and mixed
> sources in a dual-stack network. This is an interesting deployment

I think mixed receivers in a dual-stack network will be common though.
We're talking about transition, and the reason we're doing translation
is that there are mixed receivers, right? And most IPv6 networks are
dual-stack.

We've been discussing simple scenarios where translators are placed
on borders between IPv4-only and IPv6-only networks, but I don't think
it is that simple. When parts of the network are dual-stack, you have
some choice where to deploy the translators.

I think the main question to ask is perhaps where translators would be
located. Some interesting things (as I tried to illustrate) might happen
with translators in multiple locations and trying to be clever...

> scenario but we will need to define a set of requirements and use cases
> before tackling the solution. For example: you asked whether the router
> should join (S4,G4) or join (S6,G6) and translate twice? I don't know. In
> general, single translation is better than double.

Please don't get me wrong. I want to avoid translation as much as
possible. Hence I also want to avoid double translation, although it
might in some cases be better than tunneling.

Some general things to consider are IMO

1. Is it bad if multiple independent devices are performing the same
    translation of the same data?

    Translation at the source may guarantee it happens at most once.
    Translation further down the tree may result in multiple devices
    doing the same translation. Bandwidth is the main reason not to do
    it at the source in a dual-stack network.

2. With multiple translators, can we ensure that packets don't get
    double translated unnecessary?

    Basically if the network is dual-stack, can one make sure that
    there never will be more than one translator on the path between
    any source-receiver pair?

Stig

>
>
>>
>> Stig
>>
>>> Best Regards,
>>> Cathy ZHOU
>>>
>>>
>>> -----Original Message-----
>>> From: Lee, Yiu [mailto:[e-mail]]
>>> Sent: Friday, March 23, 2012 10:42 AM
>>> To: Zhouqian (Cathy); Stig Venaas
>>> Cc: [e-mail]; Ronald Bonica
>>> Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>>
>>> You can't do that right? If I have a v4 receiver connected to the
>>> v6-only
>>> network, the v4 receiver has to receive stream from the S4 source. Or
>>> you
>>> suggest the access network will statefully convert the v6 group address
>>> to
>>> v4 group address?
>>>
>>>
>>> On 3/22/12 10:31 PM, "Zhouqian (Cathy)"<[e-mail]>   wrote:
>>>
>>>> Hi Yiu,
>>>> This solution is not only for transition, it also covers the pure v6
>>>> case.
>>>> About the content stream, there will be only one stream received by MTR
>>>> because MTR makes comparison.
>>>> If the path metric of v4 source>   path metric of v6 source, the MTR
>>>> will
>>>> choose the path of v6 source. Otherwise, it will choose v4 source.
>>>> If the v4 metric=v6 metric, it will choose one of them.
>>>>
>>>> Best Regards,
>>>> Cathy ZHOU
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lee, Yiu [mailto:[e-mail]]
>>>> Sent: Friday, March 23, 2012 10:07 AM
>>>> To: Zhouqian (Cathy); Stig Venaas
>>>> Cc: [e-mail]; Ronald Bonica
>>>> Subject: Re: [MBONED] draft-zhou-mboned-multrans-path-optimization
>>>>
>>>> Hi Cathy,
>>>>
>>>> I am a little confused. Since MTR is for transitioning, why will it
>>>> connect to the S6 in the first place? Besides, say you have two types
>>>> of
>>>> receivers (v4 and v6) connected to the v6-only network. At any given
>>>> time,
>>>> there are v4 and v6 receivers watching TV. In this setup, you will
>>>> have to
>>>> stream the content twice anyway because the group address will be
>>>> different for native-v6 (v6 source) and v4-embedded v6 (v4 source).
>>>> Did I
>>>> get this wrong?
>>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>>
>>>> On 3/22/12 9:50 PM, "Zhouqian (Cathy)"<[e-mail]>   wrote:
>>>>
>>>>> There are two cases in Figure 1. One is v6 network connecting to both
>>>>> v4
>>>>> and v6 sources via MTR, which is in higher priority and is the main
>>>>> case
>>>>> of this document.
>>