W3C Multicast Community Group, 6 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-07-06 Monthly Multicast W3C Community Group Meeting

Description

2022-07-06 Monthly Multicast W3C Community Group Meeting
notes here: https://docs.google.com/document/d/1aGyLFiaIuwlcvRGueVKsPmpF1EYVAKSJHf8usxfQvoE
meeting series here: : https://github.com/w3c/multicast-cg/tree/main/meetings

A

All right, they are very interested in that food. Okay, um hi guys welcome thanks for coming uh multicast community group. uh This is the w3c meeting using those rules. um Let me paste the notes in.

A

The notes link in the chat- yes anyway, uh let's look, follow along, add edits, um I'm kind of thinking this will be pretty short, uh but obviously discussion is welcome and anyone uh should make comments if they want uh okay, I'll I'll. Just take some notes in the document so perfect. Thank you today. No worries.

A

uh Oh and actually uh enrique said he would be about 15 minutes late. So, given we're already seven minutes late, we'll see him soon. I guess um okay, so mostly, I just wanted to give a brief update on our status.

B

Sorry to interrupt.

A

The the documents read only at the moment- I think uh sorry, but it's not sure yeah. That is not intentional. Certainly I want you to have edit access. Thank you for raising. That meant to do that. That's it all right uh that should work. You can uh yeah. That's good! Yeah thanks awesome! Thank you, chris uh okay. So, uh as I said in the in the update, oh hey, dom.

A

uh Let's see, as I said in the update, uh we've continued to work on the quick, multicast, spec and implementation uh in our I don't know, I guess you'd call it task force, that's been meeting weekly to do the implementation experiments.

A

um I think that's going well, I'm not as usual, I'm not as as far along as I wish. We were, but um or we're not as far quite as far along as I wish we were, but I think we've continued to make good progress and uh with the looming deadline of iedf coming up, then I'm sure we'll start things will start moving faster, at least on my side. That's quite likely.

A

um I think I've cleared off most of my conflicts uh for the upcoming couple of weeks, so I'm hoping I'll be able to make some decent progress better than I have been um lately. It's been a lot about spec work and I've not managed to do as much coding. That's checked in or anything but but I think we've gotten some good work out of uh kyle and leo and max.

A

uh So that's that's! Really good uh and enriquez has started looking at it as well. He's uh he's trying to get a build up, I believe, and has done some work toward making it a little more approachable for more people to uh to start with it he's working on a docker container uh sort of set up for it.

A

I think, um but mostly uh the overall goal is to try and get you know a demo running, um but I I mean the overall goal is not that the overall goal is to end up with something deployable really, but an intermediate step that we'd like to have to generate extra interest at this upcoming ietf is to get a demo running. That can actually do some.

A

Some transport using multicast.

A

So uh and I think, there's a good chance we'll get there. um There was a problem brought up last time on the technical side for how to integrate with web transport that we realized uh with the comment from dave shanazi that there's a workaround for at least four four streams, uh though not for datagrams um and so we'll. Probably the first pass will focus on that, um but it's my intent to get traffic actually running to a web transport session if possible, inside a browser.

A

So that's that's what I'm aiming to achieve for this pass, we'll see if it gets there.

A

We might have something short of that we'll see, um but I think it's uh that's sort of the goal we're trying to achieve there.

A

uh Let's see in terms of so the other thing we were talking about uh a use cases document um and uh I got one positive response, but not actually uh any paragraphs filled out for that document.

A

Yet um uh from uh eric hurts he's been here before, uh didn't show up this time it looks like, but um he said, it'll be giving me a paragraph that I can use as a starting point for uh describing what it would mean to them to have multicast to the browser, and I was going to try and use that to reach out to some more people and get uh collect.

A

You know evidence of interest um so that I still want to do uh to help with it. I'm happy.

B

To help with that joke, if you want.

A

That would be fantastic dom if you want to write one also um yeah yeah.

B

A

Yeah, uh so we I had a list of about eight companies that I was going to reach out to, and I eric was here last time and I asked him if that would be okay. He said yes, uh but I haven't really followed up and yeah dom you're on the list too. So absolutely if you wanna.

B

I was yeah- I was talking to a telco today here in the uk that was uh really heads down on multicast for network efficiency at the moment. So I think it'd be quite good to maybe engage them as well.

B

A

Yeah um yeah, you know it's a recurring theme: everybody who does the math figures out that this is actually one of the best bets for getting scalability, but it's hard to get people to really believe that it's possible.

A

But people keep trying so let's see anything any questions, I guess or anything we should cover that goes deeper or beyond that.

C

I had a question about uh after reading the the draft you have for multicast over quick about the transport setup, um I can actually get on the mailing list, but I figured it might be a little bit easier on the phone first and it has to with the setup of the tunnel where, if I understood correctly, it uses an s, comma g, to create the tunnel, and then I think, for that reason it.

C

You can only have one multicast flow per quick tunnel rather than having one tunnel with multiple s, commodities that could potentially go through it and I wasn't sure- and I'm not a quick expert.

C

I wasn't sure if um that's it just some technical constraint or if it's just um you know the kind of most cases, there will only be one multicast session that you really want to set up anyway, and I wasn't sure if there would be any scale issues if but let's say for like some iptv kind of head-in device inside home, they wanted to join a hundred multicast streams if having a quick tunnel per multicast stream would would impact anything negatively and yeah.

C

I don't know how far this goes back to like just the structure of how it was done, originally unicast, but just curious if there is a reason for it or if there is available availability for flexibility with that, maybe in a later version or something like that after we get this working.

A

Yeah, um so there's not any such restriction, I think uh by tunnel. I think you mean the uh the unicast connection, um if I'm, if I'm remembering right or I'm not sure, I'm not sure which one you mean by tunnel, I think I put in tunnel a mention of tunneling uh udp datagrams over, like quick datagrams uh in like the app in the operations section, but for the most part the quick spec doesn't talk about tunnels, although it does have a connection anchoring all the channels that are associated with it.

C

Thinking of the connection anchoring like that, you know in the network, so I think of tunnel. You know so I may be saying uh it was in section two. I believe kind of the the general setup. um I'm trying there's a link handy in your email or I can just pull it up and double check real, quick.

A

Yeah yeah I'll put a link in.

A

If I can drive my browser.

A

Okay, so um let's uh so I I don't know if you're on the uh the latest editors version, but let's take a look at the text, real quick, so there's the. uh Can you get the chat.

C

Yeah, I just pulled it up.

A

Okay, so the multicast channel- um okay- so maybe maybe the spec- should make this more clear. There can be multi. Multiple multicast channels that are used by a single connection um is that is that the first question you're asking like there seems to be only one.

C

Yeah I'm trying to find the exact text, I'm pretty sure it's in section two: okay.

C

Yeah each, I think it was this paragraph. Each quick, multicast channel has exactly one associated. That's common g.

C

um The baby is just that's the channel, but you know for like a quick connection or something like that.

A

Yeah, so it so there's a so you um in a single quick connection, you can describe multiple different channels and each channel represents one sg, okay, okay, so yeah uh sure we should. If that was a confusing point, then we should make sure to clarify that I don't want people taking away the wrong idea. There thanks.

C

Yeah I started like going to section three and see if I could get a better understanding about. You know like what set up and then what can go over it. So um you know again I'm, but people are more familiar with quick, probably wouldn't have tripped up on that one, but uh I just wanted clarity on and it makes sense the way you're explaining it now um so yeah. I think I think I get it so that makes sense to me.

C

You have you know the the one, uh the transport and then you can have multiple channels. Okay, thanks.

A

uh Yeah sure, I'm glad that I'm glad to clear that up.

A

Yeah, so uh I guess another point that confused somebody that, maybe we should add some text for was- was that channeled packets are always interpreted in the context of a connection.

A

So that's a you know the when they carry a stream data, then that stream data is a stream. That's in the connection.

A

Another subtle point there is that the data in streams is not necessarily the same for all.

A

For all connections between any you know any given clients and servers, even if they use it's only this the stream data at specific offsets of the stream. uh That would be identical and that would be carried on the on the multicast connection. But you can you know, I feel, like that's a point that confuses people too, um that uh streams themselves don't have to necessarily be entirely identical in their contents, but stream data that's carried over between different clients, but stream data, that's carried over channels has to be identical.

A

So it just means that some of the stream data has to be carried over the over a unicast connection or over a different connection, a different transport. I should say um anyway, um yeah I'm sure we'll have ongoing clarifications as this spec matures assuming it gets a chance to mature, rather than being, uh you know, killed by by quick people if they can come up with a kind of a security problem, but I don't think we have any security problems that I know of that.

A

Weren't addressed in the security consideration stock, so we'll see uh we'll see how that holds up once they really dig into it.

A

All right, thanks for the question chris uh anything else, we should go over or any other questions. People had.

A

In the uh initial implementation, I'm just going to go ahead and make it transparent. There won't be a web api component. I think that we'll be adding, uh even though later on, we may add a web api component that would like allow the page to disable it or enable it or something but we'll we'll get to that later, and I'm hopeful that it will be. You know relatively trivial, uh like a very small extension that doesn't do very much.

A

Let's see, there's like the potential that we would want to still make that server-side chosen session id uh at some point, but that also can be deferred. I think for quite a while, because we can just do all this all the data transport over streams instead.

A

All right, so, uh I think we're probably gonna wrap up early then today, if nobody has anything else to add.

A

Oh uh dom, I I realized, I regretted this in eric's case. uh Can I ask you for like how long should I give you before? I ask you for it again like, should I just set an alarm for next week.

B

Oh, no, um that's fine! uh I! I was actually just looking at the beer one I did and a while ago, and I think it's probably overkill it's very long. I think you probably just need a couple of paragraphs really um unless you're thinking something deeper.

A

uh No, I mean you know, content and emphasis first, uh however long it needs to be, but I was looking for something you know digestible, I'm thinking like uh yeah a paragraph or two probably on the order of uh somewhere between 200 and 500 words.

A

I'll get that done.

B

A

Tomorrow, fantastic, thank you. I will look for it. um Let's see.

A

I guess chris, do you know, do you have any updates about so dumb? You mentioned, you talked to an isp and, and chris uh I don't know, I guess, yeah on the isp front. Anybody have any comments about interest in multicast uh developments, um things that have been going on so.

C

I didn't one content provider actually amazon and amazon, prime, but more of the european contact, and he said something kind of interesting where in europe, they're focused on multicast, more than united states in the united states, at least for now, they're still looking at leveraging, cdn and in europe they're, actually very high in multicast and at least around north america. You know it's like thursday night football nfl, that's kind of the popular thing, but then you know they mentioned well in europe.

C

They have that multiple times every night with you know, premier league and other sports, and things like that. So um it seems like there's more of the interest there and a lot of isps apparently are using multicast for tv delivery. So it's uh it aligns a little bit better. um You know that being said in at least the united states for verizon. You know we're at least I'm definitely interested in multicast and exploring multicast technologies.

C

Hence this call- um and I know that there is interest to do multicast as well, but I think, given just kind of the unicast centric nature, a lot of tv delivery right now, especially streaming. um It's more of a second step beyond just getting something deployed, so I definitely see there's interest to kind of answer your questions. Simply.

C

I I think it's just a matter of continuing to socialize and getting more people involved to give their perspective and their priorities.

A

Okay, yeah thanks that matches what I've.

B

Seen some this telco this operator, it's an operator network that is a full stack operator, so they they've done everything from you know. Rights acquisition through to um you know set-top boxes uh various times in the last 10 15 years, uh and I was talking to one of their sort of architecture guys and he was he just commented today in an email.

B

You know we were actually talking about greening and streaming so sort of sustainability strategies and energy reduction in the delivery cycle, and he mentioned multicast as the third sort of priority after codex and better collaboration with content providers, but used to multicast to multicast abr to reduce unicast consumption of linear.

B

I was specifically what he said so yeah. There is a definitely a a real interest out there in the operators. They are getting to a point where I think there is more on the old broadcast networks and the scale you mentioned. You know being more active over here in europe. I think that is truly the legacy. Ptts are very defined, quite large footprints and they've. You know gone through cycles of doing their iptv networks and it's a bit all a bit much for them. They'd, rather just make the ott stuff efficient.

B

Let someone else worry about the content. I think that's my gut feeling.

C

I agree with that in north america as well, where um so I I've deployed multicast and large networks. So I mean I, I know it can be done and I know that it's it's it's not like cbn, where it just works, but you know I, I think, there's a bit of a hurdle, um I'm sure when cdns were first deployed, people were kind of curious about. You know: how are we going to deploy these servers and get the traffic to talk to each other, and you know jake.

C

You probably have a better perspective on that, but you know it may just be one of those learning curves where once more people see it doable, then you know it'll move a little bit quicker um and then one thing you mentioned: do you say uh energy savings as one of the points of increasing efficiency, like you know, fewer servers or something like that with the smaller cdns yeah.

B

It's a it's a complete sidetrack for for for today's um chat but yeah. I know that I started up a project about a year ago called greeningofstreaming.org as a fun conversation and it's just exploded around me. Everybody wants to innovate around energy efficiency, which is quite interesting in the streaming sector, because everyone was splitting hairs on latency and it was becoming a very boring cell.

B

Everyone's suddenly trying to do the same, latency same quality picture, but with half the energy which is kind of a noble thing to be doing. But uh it's it's sucking my time at the moment.

C

Because if you look at building cdn deployments for just a spike in traffic, I mean you know, that's servers that may even be sitting idle, but they're still using energy and stuff and there's, even though of having to build out the power for those servers, even if they're idle so yeah.

B

Yeah, absolutely we've been I'm getting uh a we've, been getting measurements right out across cdn's and looking at energy profiles alongside traffic profiles around live events and things, and it's it's all very interesting. Looking at how little the traffic actually affects the power, which is something that we you know in the world of nfv and orchestration and sdn, we should be dab hands at winding our systems down when we're not using them, but we're not so anyway.

A

I think that's the the greening uh conversation is one of the key drivers for multicast. I think.

B

Yeah, it was something I was going to bring into the use cases. It's uh it's it's it's a really important one at the moment.

A

Yes, there are others as well, but um yeah, but yeah the green credentials actually could do with some better highlighting and better numbers around them. I think um I think some of that's in the charter, even um for this group.

A

What was the question I just thought of? Well, you guys are attacking.

A

That'll probably come to me tomorrow.

A

Must not be important.

A

Okay, uh great, then um anything else we should cover. Then.

A

Oh uh you'll be publishing some numbers. That's on streaming of greening dom. Is that uh sort of an ongoing? Is there like a.

B

Yes, I guess sticking in the chat room.

A

That's what it was. um How much did you said? The codex is the top priority.

B

For the operators, the codecs are but they're a bit naive to the whole data to really so so. um One of the the evolution of thinking over the last five or ten years that's come out of academia.

B

Is that if you say you reduce your bandwidth, you can say you're, greener and actually I put the sort of null hypothesis to the people who understood the infrastructure that I didn't think that energy would fluctuate very much as you went from naught to 30 million viewers on a big champions league football game and then back to zero again.

B

um So we put some instrumentation out and indeed the energy profile um really doesn't look like the traffic profile, it's pretty flat, and uh so, when you, when you're provisioning, all that infrastructure even before you're streaming, something it doesn't matter what your bandwidth is. If you're not streaming anything at that point, and we have to account for that and understand that energy, the infrastructure growth and the infrastructure scaling around the availability of service data attribution is good for claiming a little bit of it and taking away your responsibility.

B

But if you say you only use 10 of the router and half your bandwidth and call it five percent of your router's capacity, it doesn't change the 100 watts, that's powering the router at all, uh and we need to take that systemic look at scaling the infrastructure so that you know as much as possible. Well, the first thing we're looking at is trying to reduce wastage and just working on availability and slas. The second there's all sorts of other discussions going on around codex and compression, because that plays into the scaling.

B

But the big, big sort of obvious white elephant in the room is just making stuff available for three months when it's only used for 90 minutes, so make sure you meet an sla and that's that's a big problem.

A

Okay, okay, uh I think that makes some sense. Yeah I mean the the codex will apply also to on-demand content. That's why I assume it's.

B

uh Huge energy burn with transcoding and storage and caching and and and.

A

Sure, but if you do it once and then you've got the right, codec that's more efficient, then then that could save a bunch of downstream stuff. So yeah absolutely.

B

Transcoding into 34 formats and 58 devices all the time, it's just extremely inefficient.

A

Okay, it would be interesting to get a handle on uh what numbers um you know like if we could put into the same kind of format what we can get out of multicast, then that that would be.

B

I'll connect you internally as well with mike matera, okay yeah, um I'm talking to him. Do you know mike yeah talk tonight, he's really active with brilliant streaming, he's being a champion.

A

All so cool, thank you, um uh okay, anything anything else. Then I think we're.

A

In decent shape, um they're as decent as we're getting today,.

A

All right, um if there's nothing else, then thanks everyone for coming uh good to see. You all uh see you again next week, um thanks very much chris for taking some notes uh and uh yeah I'll stop the feed.