Re: [Msr6] MSR6 - Is there a BoF proposal?

[Dirk Trossen <[e-mail]>]

Hi Xuesong,

Please see inline.

Best,

Dirk

From: Msr6 [mailto:[e-mail]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: 21 June 2022 10:28
To: Dirk Trossen <dirk.trossen=[e-mail]>; Gengxuesong (Geng Xuesong) <gengxuesong=[e-mail]>; Yisong Liu <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Msr6] MSR6 - Is there a BoF proposal?


Hi Drik,



Thanks for your detailed explanation. Please find some further comments inline.



Best

Xuesong



> -----Original Message-----

> From: Msr6 [mailto:[e-mail]] On Behalf Of Dirk Trossen

> Sent: Friday, June 17, 2022 10:38 PM

> To: Gengxuesong (Geng Xuesong)

> <gengxuesong=[e-mail]<mailto:gengxuesong=[e-mail]>>; Dirk Trossen

> <dirk.trossen=[e-mail]<mailto:dirk.trossen=[e-mail]>>; Yisong Liu

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: Re: [Msr6] MSR6 - Is there a BoF proposal?

>

> Hi Xuesong,

>

> Thanks for the reply. Please see inline.

>

> Best,

>

> Dirk

>

> -----Original Message-----

> From: Msr6 [mailto:[e-mail]] On Behalf Of Gengxuesong (Geng

> Xuesong)

> Sent: 15 June 2022 23:16

> To: Dirk Trossen <dirk.trossen=[e-mail]<mailto:dirk.trossen=[e-mail]>>; Yisong Liu

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: Re: [Msr6] MSR6 - Is there a BoF proposal?

>

> Hi Dirk,

>

> Thanks a lot for bringing this document to MSR6 ML.

> I've gone through the document and in my understanding, it introduces a

> method to "translate" the P2MP request from application layer, for example

> HTTP, to multicast service provided by the network.

>

> [DOT] Indeed, it introduces an ephemeral identifier that allows for grouping

> forward requests to the server into a single multicast response. Hence,

> different forward requests typically include different ephemeral identifiers -

> e.g., interpret a hash over a chunk URL as one such identifier. All forward

> requests for the same chunk can be grouped together while requests for

> another chunk lead to a different response (and different receiver set).



[Xuesong] Here may involve 2 further questions: 1. The service handler(SH) is supposed to process different kinds of service request. Just as you have mentioned, there will be " different ephemeral identifiers ". It seems that SH is supposed to support different application layer capability. So I'm wondering who will maintain this device? Service provider or content provider?

[DOT] Good question, thank you! The issues lies with how to determine the ephemeral identifier. In previous realizations of this idea, this was done through some operation over HTTP-based requests, which in turn required access to the content. So the SH was usually operated by the content provider. But I could also imagine a standardized interface for exposing such ephemeral identifier so that the return path multicast creation could be done at the service provider level, particularly for cases in which the path creation itself is not exposed to the content provider.



2. If different chunks belong to the same live streaming, the multicast service should be the same. Why it will lead to a different response (and different service set)?

[DOT] In this case, the content may be the same (and therefore also the ephemeral identifier) but you may still have distinct responses (with the same content being transmitted in each). Take OTT streaming, where requests to a specific content chunk can all be delivered in a single (multicast) response but synchronicity of the incoming requests determines how many distinct responses (of the same content) you will have. In experiments, we used bucket sizes of about 50% of the segment length to group a number of requests into one response. Any request coming later will be part of a separate response. This, of course, poses questions on how to convey the grouping (from the content provider to the service provider, if the response formation was done at the service provider) etc. So there is a range of interesting interface interactions that need considerations.



[DOT] But why doing all of this ¨C something the draft could outline more clearly, I must admit: it is clear that any request model of many to single content access leads to a linear increase of costs in relation to the requesting users (no matter what the timing of the requests are), while FRRM has the potential to flatten that (linear) curve, possibly significantly even, if requests are very much aligned time-wise! This is the main reason to position this as a more general communication semantic instead of an applicability for a technology, such as BIER or MSR6.



>

>  Service Handler is supposed to convey the multiple requirements of the same

> content and terminate the transport level protocols; PCE is supposed to

> allocate the multicast path and the corresponding header to the ingress node

> based on the request.

> [DOT] In the BIER realization, the PCE is only responsible for the forward path

> creation since the return path is created through a binary OR over all forward

> path for the same ephemeral identifier, hence allowing for creating that

> multicast path locally at the source (which is the receiver for the forward

> requests). This is what makes this fast in realization.



[Xuesong] To clarify a little, MSR6 tries to introduce different usage and meanings of bitstring, but the method introduced by BIER, which use bit position to represent egress nodes, is not excluded. But of course, if MSR6 TE is used, encoding of the return path will be more complicated. But still, there is no explicit multicast tree maintained in the intermediate nodes. The speed of response is only limited by the path source routing encoding.

[DOT] Thanks for the clarification. Indeed, no operations at the intermediary nodes are required, sorry if anything else may have come out as an understanding from my comment. It is indeed the speed with which the source can encode the ephemeral source routing information. My example of BIER (as well as a path-based technique over SDN that we used in the past) was to illustrate that it could be as simple as binary ORing the forward path information of each incoming request, which is really simple operation although assumes path symmetry (which is not always a given).





>

> I think this is a very interesting scenario, which may benefit from multicast

> source routing because of the fact that: ephemeral multicast request demands

> non-explicit multicast trees inside the multicast domain to circumvent

> incessant state synchronization and protocol convergence.

> [DOT] See above, the path may also be constructed entirely at the source only.

> There are differences when realizing in MSR6, as far as I can tell, not being

> quite as simple as a binary OR.

>

> Do you think it is also requested by this case to provide TE path in order to, for

> example, specify replication nodes or provide SLA guarantee?

> [DOT] It all depends on what one can execute at the source. If you contemplate

> to run this through a PCE for every return multicast, the supported frequency

> for doing so may become an issue.



[Xuesong] This may involve implementation. One possible method is that PCE calculate the unicast TE path to all the possible egress nodes. When there is new request for multicast, the only thing PCE is supposed to do is stick the unicast path together, delete the redundant path and generate a multicast path, rather than re-calculate the multicast path when there is new request. This may help increase the efficiency.

[DOT] Yes, there are a number of way one can think of making the ephemeral path creation actually fast, all of which rely on the fact that doing this decision at the source only inherently puts you in the ¡°rather fast¡± category already :)



>

> And the structure proposed by this document seems very similar to DVB A176,

> which is referred in the draft. It will be appreciated if you could give some

> further explanation about the relationship with DVB work.

> [DOT] The A176 reference seems a leftover from the original BIER draft, which

> included IP multicast text. I don't think it is relevant here anymore.

>



[Xuesong] In DVB A176, there is a reference architecture as the following:

[cid:image001.jpg@01D88572.E08247B0]

The multicast server and multicast client seems play similar role as ¡°service handler¡± in this document. So I¡¯m wondering whether the problem domain is also similar.

[DOT] Ah, right, we did indeed re-use the arch component in the form of the SH, but its function is different. Thanks for teasing this out!



>

> Thanks!

> Xuesong

>

> -----Original Message-----

> From: Msr6 [mailto:[e-mail]] On Behalf Of Dirk Trossen

> Sent: Wednesday, June 15, 2022 3:05 PM

> To: Yisong Liu <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>

> Subject: Re: [Msr6] MSR6 - Is there a BoF proposal?

>

> Hi Yisong, all,

>

> many thanks for sharing the proposal! Very interesting to read and looking

> forward to working with the community on this.

>

> Possibly of relevance to MSR6 is work I presented in the BIER WG on a

> communication semantic called 'forward request return multicast', which aims

> at scenarios in which multicast relations are ephemeral, possibly (as the name

> suggests) to a set of forward requests relating the same service response.

> Examples here are chunk-based services, such as video retrieval, SW updates,

> file storage but we are also looking into distributed AI services. BIER is here

> used as an example multicast technology, also since the predecessor draft had

> its roots in BIER.

>

> You can find the draft at

> https://datatracker.ietf.org/doc/html/draft-trossen-bier-frrm-00.html. I can

> see this applying to MSR6 due to the similarities in source-based routing.

> Relevant content, like Section 6 and 7, could be described for MSR6, too, I

> think.

>

> If you feel this may be interesting, e.g., as an applicability for MSR6, I am happy

> to bring this into this community for further discussion and consideration.

>

> Best,

>

> Dirk

>

> -----Original Message-----

> From: Msr6 [mailto:[e-mail]] On Behalf Of Yisong Liu

> Sent: 15 June 2022 04:35

> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: Re: [Msr6] MSR6 - Is there a BoF proposal?

>

> Hi Adrian,

>

> Thanks a lot for your attention to MSR6. We have submitted the BOF request

> and updated it recently, and please review the proposal at the link

> https://datatracker.ietf.org/doc/bofreq-liu-multicast-source-routing-over-ip

> v6msr6/. We're very appreciated if you can give us some comments.

>

> Best Regards

> Yisong

>

> -----ÓʼþÔ­¼þ-----

> ·¢¼þÈË: Msr6 <[e-mail]<mailto:[e-mail]>> ´ú±í Adrian Farrel

> ·¢ËÍʱ¼ä: 2022Äê6ÔÂ15ÈÕ 05:00

> ÊÕ¼þÈË: [e-mail]<mailto:[e-mail]>

> Ö÷Ìâ: [Msr6] MSR6 - Is there a BoF proposal?

>

> Hi,

>

> I caught up with the video of the side meeting, and I see from the Datatracker

> that there are some five drafts related to the work

> (https://datatracker.ietf.org/doc/search?name=msr6&activedrafts=on)

>

> What are the plans to take this forward? Do we just review and discuss the

> drafts, or is there a proposal to have a BoF? If there is a BoF being considered,

> can someone point us at the proposal so we can discuss it here (if that is

> appropriate)?

>

> Thanks,

> Adrian

>

> -----Original Message-----

> From: IETF-Announce <[e-mail]<mailto:[e-mail]>> On Behalf Of IETF

> Secretariat

> Sent: 10 June 2022 16:24

> To: IETF Announcement List <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: New Non-WG Mailing List: msr6

>

> A new IETF non-working group email list has been created.

>

> List address: [e-mail]<mailto:[e-mail]>

> Archive: https://mailarchive.ietf.org/arch/browse/msr6/

> To subscribe: https://www.ietf.org/mailman/listinfo/msr6

>

> Purpose:

> Multicast Source Routing IPv6 (MSR6) is a new architecture focused on evolving

> the L3 multicast architecture to carry real-time applications statelessly,

> programmatically and with high reliability across a SRv6 data plane. How can

> we best to reuse the ongoing work with IPv6 extensions for multicast services.

>

> The video of the side meeting could be found: https://youtu.be/1SBrvsvMLZk

>

> This list belong IETF area: RTG

>

> --

> Msr6 mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/msr6

>

>

>

> --

> Msr6 mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/msr6

> --

> Msr6 mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/msr6

> --

> Msr6 mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/msr6

> --

> Msr6 mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/msr6