Internet Engineering Task Force IETF 114, 28 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114 MBONED 20220728 1730

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Someone else has taken off the responsibility of breaking things.

A

Possible deniability.

A

What'd you do.

A

The projector was off so that power. Oh, it was the wrong color light.

B

A

C

Off projectors, when they're cool.

A

They should be fanned all the time.

C

D

A

Since the fan was only.

E

Okay, we're looking for a meeting a note taker, we'll wait for people to trickle in um anybody interested in taking notes. uh You don't have to be in the room you can be in the room who wants to be a notetaker. Notetaking is a excellent opportunity to.

E

To now be part of the process.

E

Anyone on online who wants to be a note taker. It will give you a great sense of uh participation.

E

You can, if you'd like to you'd, be more than welcome.

E

Somebody else can do it when you're, when you're up.

E

Does that sound like eric you're interested.

A

It's a once-in-a-lifetime.

E

Yes, go to meet echo and there is a note-taking tool.

E

um Yes, trying to try the click on the video.

E

All right we'll try and find somebody.

E

C

I will I won't leave you hanging.

F

Let me see here.

A

How about uh if you take notes I'll, take notes, while you're presenting.

E

He said try to find somebody else.

E

And use you as a backup hold up hold on a second. Let me see if there's one person but.

E

A

A lot of people walking around look around run away.

A

E

To take a walk.

E

Jake, um would you have any interest in being the note taker sure and when you're up talking uh eric can take take the all right? I don't. I.

A

Mean I think max is mostly driving. Okay,.

F

All right, cool.

E

E

Okay, we'll wait another minute for people to come back from lunch.

E

Switch to the um go back to the I'm less familiar with that interface. That's the online tool. uh Do the do the remote one, I'm sorry, click click on the um video link.

A

From the agenda.

E

Video and you should get an interface that looks like this and then on that little box with a pencil sticking out. That's the note.

B

E

And it's an online note-taking thing, so you and jake can work in tandem if he gets up okay, we ready to get started.

A

Okay, how's the room. You guys ready all.

E

A

Look at that, the energy is just overwhelming. There we go, we got one yeehaw.

E

All right so we're gonna.

A

Plow right through this food cola,.

E

um All right we're gonna start taking off for this flight. um So uh here's the note well, um it should bear striking resemblance to all the other note wells, you've seen at the beginning of every meeting. um So uh just please read it uh and be aware of: uh what's the the what is noted well in participating.

E

Meeting tips um you know for for those uh who are just arriving today and haven't been in any of these uh previous meetings, even if you're in the room, please do join the meet echo tool because that acts as the blue sheets, and it also enables you to participate in chat and any polls that we have just a reminder. Please wear your masks unless you are actively speaking at the mic and you think that that can help be a little more clear and remote participants keep your audio and video off unless you are presenting.

E

Here's today's agenda.

E

We have a action-packed agenda, um let me know if we missed anything or, if you'd like to bash this agenda. Otherwise this is the plan actually where's warren was supposed to be. Here is warren in here warren with a w.

E

E

Yes, we missed smart warren. All right, um yeah is there any other ops area meetings are going on right now.

E

I guess we'll just cut him in. If he shows up yeah, he must be a dns, dns ops. I guess we know where he we fall in his hierarchy of interests.

E

um Or he's still at.

E

Lunch um all right so uh status of working group, docs um yang models uh document um sandy are you on and sandy. Would you like to speak up uh about um any up? Do you have any updates or anything you'd like to say about the yang models, uh draft.

E

Sandy are you there? I see you in the uh yeah, okay sandy. Let us know if you have, uh if you want to jump up um the telemetry draft, uh how how you will be presenting on this um and.

E

Okay yeah, so that's been a pretty consistent thing, so um please do if you're interested. If you have interested in passions in yang or even if you don't um that's a draft, that's been sitting for a while and needing uh needing comments. So please speak up. uh So please take a look at it, review it and reach out to the authors with any comments you might have the redundant ingress failover draft. This has been adopted since the last since vienna.

E

So that's a new working group document. um Do we have any authors, co-authors want to speak up and say have anything to note about that draft, any updates, or is it just the same as from uh when it was originally submitted?.

E

E

E

Are you a co-author on that one? Okay, do you have any comments about that? One here.

A

I owe them a review. Okay,.

E

Okay, um jake: uh do you want to come up and give us an update on your um multicast to the browser drafts, um the dorms, ambi, cbac and mnet.

E

I should note uh dorms just went working group last call. We've we've heard some comments. I would encourage others. Please speak up on list. If you want to see this document advanced to iesg.

G

Does that work yeah uh thanks lenny! This is jake. um uh So, most of my time since uh since 113, as I mentioned, there was on the uh it was on the quick work.

G

um So I I did like do my own self-review of dorms before uh before poking you about last call, uh and I think I think it's okay, so yeah I'd love to see it go forward.

G

um Probably next on my list is mnet um and uh after a round of reviews- and I I kind of because there's a dependency on dorms- I want ambiency back.

G

uh You know to to make sure that those are gonna be uh unimpacted by any feedback I get on dorms, uh but uh I will wanna get uh reviews on those from security, people and transport people respectively, um at some point, but that'll be coming up soon.

G

uh Well, soonish. I hope maybe especially, and I think, there's been a number of networks that wanted to use that so I'll probably want to want to push that forward and then c back, probably more than ambi, because for for the end point authentication quick will also cover that. So ambi might turn into just a sort of forwarding for the network, uh which is still important, but probably not as important as the endpoint.

G

When I thought it was going to be using that so um uh yeah, so these are still uh still I intend to to get them over the line one day. um Thank you.

E

uh Talk about the clustering are all three.

G

Four being clustered.

E

And you have to cluster them at the same time like how do we.

G

Yeah so I I actually asked the rc editors this uh earlier this week, so they get auto clustered, apparently when they reach the, um if there's normative references between them uh when they reach the rrc editor's key. But I can also just send a note and ask them to to the rsc editors, so I might do that. uh Mnat is not part of the same cluster. I just have a cluster or I just wanted a cluster for dorm's ambience, see back because they're um they're all part of the same uh protocol.

G

Basically all right, yeah thanks.

E

Great thanks um so again we encourage uh everybody, take a look at speak up on dorms and take a look at uh and review ambience back, so we can work on advancing those as well soon.

E

And those are all the active working group uh documents.

E

um So uh we'll move on so um warren was supposed to be here and I believe uh if I might steal his thunder, I think he was saying that his term as a.d is expiring soon and he wanted to encourage uh others to consider becoming an a.d if you're interested in becoming an a.d and being his successor and have questions about that. Please do reach out to him.

E

And if he does come in we'll see, if that's what he says so next up is the telemetry draft, uh how you.

D

D

Yeah, this is how you song from future way. Today, I'm going to give you a brief, update and recap of this on-pass temp tree uh using iom for multicast on behalf on behalf of our co-authors, next slides, please so, first uh updates of this new revision. uh We actually several technologies. uh This document is based on have been uh goes through. The uh some of them have been published as rfc, and some of them is in the last stage for publication.

D

So uh now is a good time to make sure our scheme is actually comply with the existing standards.

D

So, for example, this technology this scheme is based on. One of them is based on the iom trace option which already been specified in rfc 9187, and another option scheme is based on the iom, direct export draft that will be published soon. Okay, next slice.

D

uh First, the problem we want to solve in this draft is uh to apply the unpassed telemetry technologies in for multicast. We think it's a useful uh to monitor the multicast traffic, so the so-called on-pass temperature means we insert the instruction and the telemetry data in user packet itself.

D

So by doing that, we can collect the real-time performance uh on the experience of user traffic and it's also very useful uh in the in terms of multicast. It can help us to reconstruct the multicast tree from the data trees. We collected.

D

But but the issue about that is, if we just use iom trees option, it will introduce a considerable data redundancy, um because uh each destination node will collect the trees of the entire past. You can imagine uh in the in this tree. uh You know many sections actually are overlapped from the root to each node, but if you get all those data and all the uh leaf nodes that will there will be a lot of data redundancy. We want to avoid that.

D

So we can have a two solutions to uh to to solve this problem. The first one is still based on the iom tricks option. The second one is based on the iom direct export option. Next slides. Please.

D

So the for the trees option, uh the trees option means we just keep adding the telemetry data in the user package on the folding path. So you can see this. uh This is why it will introduce a lot of redundancy data in a multicast tree.

D

So the solution is we basically combine the iom trace option and the postcard based telemetry. We don't try to collect the data trees for the entire path. Actually at each branching node. We just configure configure node to export the the data we collected so far. Then we clear the trace twist and on then on each branch. We can do the data collection again.

D

This option there's no need to update the rfc 9197.

D

It only requires the data plane configuration next slides, please.

D

So this is a figure to show the show an example. You can see this multicast tree and to node b there will be two branches and node d. There will be three branches, then we configure the node b and the d to let them know and this point they need to just export the data collected. So far, then we can clear the um the data part. Then we can start over again on each on each branches and but to reconstruct the multicast tree.

D

We do require that the node id data is a mandatory that must be collected and also so each each sections trees also need to include the branching node, for example, the the node d it explore. The data must start from node b. So it's a cover, the section b c and the d in this example.

D

D

The second optional solution is to to use iom dx as a direct export option. um So for this uh each package only carrier instruction header to tell you what data to collect and then uh each node will just send a independent.

D

Postcard package to send the collected data to some collectors, so therefore the the data never goes with the user packet. So there's there will be no redundant data because each each node will only export the its local data.

D

But the issue here is that for in the case of multicast for the postcards mode, we need to correlate the postcard data.

D

This is especially challenging for multicast, because we also need to identify which branch this data is a postcard data comes from so to solve that problem, we need a new data type. We call that branch branch, id or branch identifier solutions that the branch identifier can combine contains two parts. The first part is a node id.

D

This is identical as specified in rfc 9197. It uses three three bytes to hold the node id. Then we use one more byte to hold the branch index, so if this is local assigned index for each output port of the multicast tree, so therefore we can support up to 256 local branches.

D

So, by combining the node id and branch index, we can uniquely identify each branch and to each branching node next slides. Please.

D

So uh left side you can shows a frame format of this uh direct export instruction header. uh We will need to allocate a flag bit.

D

We call that m to indicate uh this is uh for the multicast um use case. uh So if the m bit is set to one, it means there will be a optional data field, the multicast branch id included in the data part.

D

You can see there's a third optional part which includes the branch id we just introduced. So with this such information information, it allows us to easily reconstruct the multicast tree on the right side. You can see an example in the bracket. The item is just means the branch id you can see in the node, a the.

D

Postcard send package includes the a0 as a node id branch id and and followed with a telemetry data collected at the node a and at the node b. It again it sends a branch id a0 than the local data collected, but you can see in the following node.

D

There are two branches: the upper branch will be, the branch identify b0 and the lower branch will have the branch id b1. So with this information it allows us to easily identify where this postcard comes from. Then we can easily reconstruct the multicast tree next slides. Please.

D

Okay, so this is a brief introduction about this and so far we think this document is already pretty mature and therefore we ask the working uh group to consider the working group, let's call for it. Thank you.

D

E

I think you can just you, can just walk up there.

E

It's a small enough room. We can, we can manage.

G

Yeah jay colin: um uh do you have any implementation status to to share on on this work? It looks pretty good. I think.

D

We don't have an implementation for this multicast yet, but uh we do have a uh implementation for the iom uh in general.

G

And is that in in what the open daylight or in.

D

Is a I think in the product um yeah.

G

uh Okay, great thank you and.

G

G

I haven't looked at the latest version of the draft. Do you talk about um uh the index stability when, when interfaces come up and down like when new interfaces are added, and and is it relative to the current fanout tree or to the interfaces that are available or like how are the, how are the local index indices assigned?

G

If you could speak to that a little bit or just tell me to read the draft if it's all spelled out there.

D

um Not sure I understand your question you're talking about the interface uh up and down.

G

Yeah, so the uh the branch id is, I understand.

D

G

Version is a local interface. Identifier of some sort is.

D

That yeah we locally assign uh id for each interface. So we can you just use the one byte value attached to node id to identify the.

G

Unique branch and then as it changes uh while, while flows are in progress, um are you specking out how the how the ideas change or how to re-aggregate those basically.

D

I I I expect that can be static because it doesn't matter the only use of it is to help us to reconstruct the multicast tree so because we also have the node id innate. So as long as we can distinguish the different branches, that's uh okay.

G

So you see this as a as a static assignment on the interface.

A

Essentially, okay, great thank you.

H

It's vancouver dr telecom, um basically uh jq, and uh you asked half of my question as well. um So when I was looking at the data scheme that you provided, I think two or three slides back.

H

My question is: are you actually distinguishing which interface receives or sends the multicast on the node, or is this purely monitoring of of the node id as such? It's.

D

A you know, the the node id data is already available to be included so, but if we think of think about the multicast case, uh if there's no branch id then, for example the next node from the uh from the branching point, uh you will you they both send the postcard package. Then you will, you will note no, you can. You cannot tell if uh if they are belong to the different branches or correct, so with that information you can tell.

H

So so rephrasing my question: I have 2 000 multicast streams in my network and I have um a router, a p router in my network, which has 350 multicast activated interfaces. Okay, how many postcards will I receive.

D

Oh, so it yeah each each tree. Might you might be able to aggregate that explore data, but it's easy to distinguish the different multicast tree, because in addition to this uh branch id, we also have the flow id and I've got the the in the figure. We have some other information to tell you which flow it belongs to. So you can easily attribute the data to different multicast tree. They will not mix together.

H

So the um danny, could you go back one or two slides? Please.

D

H

No lenny yeah this one exactly yeah flow.

D

Id and a sequence number yeah flow id, basically uh tell you it's a unique number and they tell you.

H

D

H

The multicast stream right.

D

H

The the s comma g, okay,.

D

Sequence number tell you the order of this. uh This package and.

H

Where, in this information, do I find the interface to reconstruct the tree, or is this not included in the postcard.

D

Is this is a come from the every packet then then, and uh and each uh each node will um a sign that writes that part? That's the multicast branch id, because I just you need to use that information to tell uh to reconstruct the tree.

H

Okay, so the flow id is is respect is this is corresponding to the multicast group. Oh yeah,.

D

The low id never changes the start from the source and yeah.

H

D

The sequence number never.

H

Change and the multicast branch id reflects, then the interface id.

I

H

You're saying yeah: okay, so back to my original scaling, if you have 350 interfaces, you would receive 350 postcards from one router right.

D

One router, I said, uh based on the current scheme, is support up to 256 um different branches.

H

Oh yeah, okay, so that was exactly where I was pointing at so um 256. I don't know for a large iptv that is already narrow on on our p routers, for example. We have more than that, but on the other hand, um it's it's a good start and a good approach.

H

What what I would like just like to point out is that the um that the interface is really key and needs to be included in in in this postcard, because otherwise you you will have hard time because of the sheer amount of postcards that you will.

D

So you think that uh eight bits is uh to to to view. Are you.

H

um I can only say for us, it wouldn't be enough, but I don't know if, um if this is really representative of uh itf uh or operators, yeah.

D

Yeah yeah, so, okay, thank.

I

E

J

um This is dino thanks for the presentation um I just wanted to say. I support the idea of wanting to solve multicast telemetry at the olympics. They want the the u.s broadcaster wants to look at data on the tree, both downstream and upstream, and what we did in tokyo is. We use the the lisp control plane to to find out um things like rtt times on each branch.

J

One way hop count forward and reverse latency forward and reverse, and uh the advantage we had with doing it with an overlay is that we didn't have to touch the underlay routes at all and we were still able to get that granularity of information, and I was thinking- maybe I'll, present, that next time at the next mmt, if you want yeah. Thank you, but you know like definitely for solving this problem.

E

K

E

So um just quick show of hands uh who has read this draft, thus far yeah uh use if you could use the tool.

E

uh The the poll, the question to the crowd crowd is who is actually who has actually read the draft.

E

The most important thing, if you have please raise your hand uh if you haven't you, can either abstain or not raise your hand. We can do the math all right. So um it sounds like there's a lot of interest uh just needing more folks to read the draft. So please do please do take a look all right.

A

K

E

Okay, jake you're up or no I'm sorry max max you're up.

E

E

I'm gonna bring your slides up.

K

There we go, um the call is set up.

K

All right, hello, everyone, I'm max from the berlin and I'm presenting um the multicast quick extension yeah uh jack, presented already at quick just before lunch, and now I'm going to present it to you. um So, let's start with the basic idea next slide.

K

um But yeah the idea is that we still want to get multicast into the browser basically and we're looking for ways to do that and since browsers have quick implementations, we thought one way to do. That would be to use those quick implementations to find a way to get multicast into that. So what this extension does?

K

It basically uses a quick unicast connection as a sort of anchor or side channel from where a client starts, and it can say the client can say I support multicast, um and these are my limits basically like this is my maximum maximum supported rate, etc, and then the the server could tell the client over the unicast connection, some multicast channels basically and tell the client to join these multicast channels to receive data.

K

So it's server driven the server picks which ssm we only support ssm channels. The client should join. The client can then decide. Okay, I'm gonna try to join these ssm channels and on these ssm channels the client will find quick frames, quick packets, which contain data. Basically, um if the client is unable to join these channels, the server could then decide to also send the data over the regular unicast connection, which means that the client, so so, no matter if multicast is supported or not the client would still get the data.

K

The idea is also that it's transparent to the overlying applications.

K

Of course they would have to set a flag to support multicast because, obviously for some applications they don't want multicast, but um from that point on, it would just see normal quick data arrive basically on connection okay. So what quick also gives us is a way to um encrypt and use integrity, so each packet, no matter if it's sent on the multicast channel or the regular connection is encrypted.

K

Obviously, the issue is that every receiver gets the same packet over the multicast channel. So it's not a high bar to decrypt, because the key is sent to everyone the same key, so that alone isn't enough to to guarantee integrity. So we also send integrity frames which are basically hashes for each packet that guarantee that when the when the receiver sees a packet over the multicast, it knows that it's a valid packet right. So the the client also acts the packet that receives the packets.

K

It receives over the multicast channels over unicast, so the server knows which packets arrive, which packets get lost. So in that way we have reliability and um the flow control and congestion control are obviously different. So the, as I said before, the client sets its own limits and the that's the way congestion control is done. Of course, the server could also do something that sees that a lot of packets get dropped because it doesn't receive the x. Then it could also tell the client to leave some channels um right.

K

It only works from server to client, so obviously the.

G

K

Client can't send multicast and um do you know sure yeah.

J

I just want to ask a clarification question and it only requires a yes or no answer. I think. But could I change the terminology just so we're on the same page, when you say server, we mean source when you say.

G

J

We mean receiver joining the group.

G

Is that right, okay, great.

J

So what if I'm you're a source and I'm a receiver? What if I want to join the group, but you haven't, opened the unicast connection to me. That means I can't join it. Is that true?

J

So you have you have control the source of who joins. Is that kind of the architecture.

K

Well, you don't have control of food joints right. Anybody could join the send an igmp you're still underlying that you system.

J

Will they get the data if they do that.

K

They will get the data, but they can't necessarily decrypt it or um check the integrity.

J

So it's not useful, then.

K

Well but again the the key is shared with everyone right so like a bad actor. Could.

J

It's funny it's fine. I just want to know what the trade-offs were in the architecture and so that that means you're actually putting some access control. This is really a source initiated multicast communication and the source really has control of who joins the group. Okay sounds good. Okay, I'm not I shouldn't have said, sounds good, but okay, okay,.

K

um Right, as I said, the the the packets arriving over multicast are for the application. They they don't differentiate. Yes, jake.

G

Yeah again just to clarify the from a multicast channel perspective, you're right, there's a source in a receiver, but uh since this is like maintained in as part of a quick connection, it's uh this is why we chose the terminology, server and client in it's in the quick context that we have a server and a.

B

G

uh And in that context, it's sort of incidental that they happen to also be source and receiver for multicast.

G

They don't have to be.

J

Somewhere by the server.

E

uh Please repeat the question on the mic: if you you can or jake just repeat his question for him.

J

That was a really interesting comment. So can you have the server do the unicast control plane with the receivers and the source be some other node on the network.

G

Yes, that's uh that's going to be common. We we expect for truly scalable solutions, yeah, because you're going to need to anchor it with a unicast connection.

I

Yeah kyle rose, I mean the. I think, the one of the important things about this about this. uh This proposal is that it's it's not um it's not a general multicast mechanism. It's intended specifically for the case in which you already have you have a relationship with a with a quick server and we're just providing an alternate means for transmitting data that might be shared among many different clients.

J

So you don't have to unicast replicate over the unicast quick channels. Okay, now another thing: that's correct, okay, so another thing I thought about it might be hard for me to join the group because since the control channel tells me yes comment, g is, I may not know it, I could guess it, but I may not know it so it would be hard for me to join receive on encrypted data. That I can't decrypt is that you agree with that. Okay,.

A

Sandy jeffrey.

F

Yeah all right, okay, um yeah stick with us, so this sounds pretty cool. um Just one thought I had is in in the beer working group. They are looking at stuff where a source can send to certain clients without the client having to join first. So it's really. The membership is driven all by the source and they're looking into doing using it for http in some cases. So I think this could fit well within that. Of course, beer is not that used much used yet so you want to solve it for multicast in general.

F

L

Jeffrey from juniper clients x a x each packet over unicast. Let's say you have 10 000 clients and how does that scale.

K

K

um Right it scales better than having 10 000 clients receiving the data over unicast. Altogether right I mean you're gonna have to we we're thinking. We were thinking about not always acting stuff right and you can use but yeah. It would be some of the violation of quick.

I

Yeah so in in some sense it still scales linearly, but the constant is a lot lower.

E

Is it fair to say the control plane is scaling the same, but it's the the actual data packets are where you're getting the benefits of multicast.

I

Right and and because of the way that quick handles acts, it's probably sublinear anyway, um assuming that you're not losing a lot of packets but um yeah. I think this is one of those things where, like we have ideas about how this is going to behave, but we're not really going to know until it's in practice and we're experimenting with it. So, but I mean you know, we're open to to. You know uh helpful analysis from other people as well or thoughts on how this might work out.

L

Yeah, I actually don't know much about quick, so my questions, let me be down, but I guess uh the one difference between this and 10 000 uh separate the unicast sessions or the different differences there is that those 10 000 different sessions. They are separate ones, and here this is one this all these eggs are for the same session.

L

Maybe it's not the problem. Maybe it is. I just don't know.

F

Stick with us, uh maybe a stupid question. I don't know quick really, but but you have to act like send an eck packet for each packet. You act or can you just act a lot of packets in one one message check.

K

G

Yeah, you can act one in many, but uh to come back to the general scaling questions, uh uh I would draw an analogy to norm uh the existing uh knack or unreliable multicast uh spec. So this one talks about a single server scaling only in the tens of thousands uh for for the reasons you were talking about, but we think we can distribute this over multiple servers. In the same way, we do uh other kinds of uh unicast distribution.

G

Things they'll have to be linked in some way because they all have to be able to handle acts for the for the multicast data, but that that's the intent for how to scale it, and it should be compared to quick unicast not compared to like flute, for example, for you know, receiver agnostic, one thing that might be on the table if we get some deployment and sort of operational experience with this would be adding nack frames to quick if it turns out to be actually useful.

G

But uh that's not part of this spec at this time, also like fec frames. If it turns out to be useful- and maybe we can do more aggregation of max of the ax or an ax or something but right now- we're trying to be as vanilla as we can in a quick context.

J

So I have a bunch of detailed questions I want to let you finish your presentation, but actually, I think jake answered half of the things. The broad statement I want to make have you guys looked at norm. The answer is, yes, looks like he looked at next because I was going to say: did you look at the early van jacobson work and the work that the cisco's guys did in the 90s on pgm, pretty good multicast? These are all various forms of reliable multicast transports and the questions about returns.

J

The high-level questions about re-transmissions repair neighborhoods, all that stuff. Are you trying to do that avoid that and- and you kind of said, some of that but I'll? Let you finish your presentation, so I see how it works. All right.

K

um Yeah, so speaking of retransmits, the retransmit could happen both. So you could have quick datagrams, so you don't have retransmits, but if you have stream frames, um the retransmit could happen over both multicast. If enough clients or receivers lose the packet right or you could um individually retransmit them over the unicast channel as well.

J

Is it okay? If I ask questions you.

E

J

To continue the presentation, I don't want to yeah.

E

What do you recommend do you think, um do you think you want to finish the presentation and then take questions, or is this helpful.

J

Because, then, we'll be yeah.

E

J

Be educated more after you do it.

K

um Sure, okay, okay, let's, let's finish quickly, then um yeah next slide.

E

And just uh just a note, uh gory mentioned on the uh chat that quick does not need to hack every packet.

D

B

K

uh Right, that's the the problems we solve, um but yes, as I said already, we want to get it into the browser um we're going to have encrypt like encryption for the packets. We have integrity checks like ambi users, as jack said, so envy isn't yeah.

K

Right, um okay, I think I said most of that already um right. The scalability is in the data and not the control, plane, yeah, okay, um right, the concept of the draft we already on version 3. We had some reviews internally and from lucas and from kyle and the for us at least the current structure seems clear in the architecture and we don't see any reasons that make it like impossible to actually get it deployed and use it and or things that are in violation of the.

G

K

Draft for multicast, um so we got some feedback from the quick working object. Do you wanna.

G

Yeah I mean there weren't many people who commented uh lars had some positive things to say. I think alex uh questioned whether it should happen in quick. um You know I think that can be discussed on the mailing list. uh Martin duke said he was. He found it technically interesting and would be doing a review. So I'm looking forward to that, um you know I I I expect that a lot of people in quick remain skeptical. Some of the offline comments.

G

I've had say that uh that there's some skepticism that we will adequately solve the sort of origin security model for uh for for counting as non-mixed content in browsers.

G

um I would like to dig in more on that claim with with people who believe it, probably not in this form, but this is we're trying to address that with the multicast security considerations, and we think that so my opinion is that I think it can be addressed, but uh there are some some differences.

G

I think that they are minimal enough that they can be addressed, especially if we consider things like uh so apple talked about uh how they they sort of treat a joint of a multicast group as a under the same rubric as sort of local discovery. Things as a potential privacy.

G

Exposure that requires a user input. So this kind of thing, I think, if it becomes more normalized, can contribute to protecting users against inappropriate privacy violations and could- and I think that that's the main difference uh in terms of security, um although I'm not sure that I that I've fully captured everyone's objections to it or that they fully thought it through honestly, because a lot of them, I would say, maybe don't really want to think about it too hard. Yet I think that will change if we can manage to get a decent deployment.

G

That does something, but it's going to not be in a browser. First, it's going to have to be like in a fat client, that's launched from a browser if it's going to address uh web video, for example, but but we would like to do that in our you know, with our demo yeah, that's kind of where we're headed first and then one day, maybe into a browser.

J

All right sure, so this is dino, so I'm getting a really strong gut feeling that this is a really good architecture. I just there's all these positive vibes going through my mind, so I think I'm really happy and I'll explain why you solve the source discovery problem, because it's done at the source. That's really good.

J

The fact that you're, mixing, unicast and multicast means, if you wanted the unicast connections to go on an underlay and you wanted multicast to go on an overlay. This could happen with this architecture. That's really cool, at least for me, because I'm an overlay guy these days now I have a detailed question. um So in pgm there was next that came from the receivers when they saw pack it out of sequence and the router's intermediate would build these lost neighborhoods.

J

So when the packet was retransmitted, it would only go to the lost neighborhoods and not to the receivers that received it. So can you explain I? I realized that if you want to retransmit a multicast packet that has been lost somewhere on some branch somewhere, that you could, you may not be able to, you may or may not be able to identify where it was lost, and you could certainly retransmit on the unicash channels, which could be inefficient if the lost neighborhood was really large right.

J

um So that's my question: what are you guys thinking about how to do this, and I do you just re-transmit on multicast and let the guys who got it drop the duplicates or because there's we did a lot of research with this on pgm and we thought that the knack neighborhood and having router store state about lost messages was worthwhile turned out to be complicated and maybe an over optimization.

K

Yeah I mean yeah, we're not sure exactly how to do it. Yet I think that's like one of the things.

G

Yeah, I would say we're we're not sure, but in terms of the architecture and the document, this would be a server implementation decision. So it's not going to be routers I'll. Tell you that much it's going to be endpoints, so it's going to be a server endpoint and in a deployment model we would expect. Probably to have uh you know, servers co-located in a network and to maybe like I'm, not going to give you this on the first pass.

G

But one day if this takes off yeah we'll have servers that are sort of dedicated to a particular network and when there's loss that's correlated across that network. I would expect the servers to you know as an optimization to prefer to retransmit over multicast for that network. And if there was anybody who got it, they would be able, as a natural part of quick to discard, repeats that shouldn't be a problem yeah. But you know that's that's sort of optimization for later yeah.

J

So what what ended up happening in pgm is that we didn't want to have this router assist neck thing and so pgm turned out to be a reliable transport and what happened was we when there was any knack that came back the reach it retransmitted down the tree and what jake just said is the the receivers who got it just threw it away? It was much simpler and it was more um end to end. So.

J

Having said that, since this is really a reliable transport protocol, it should probably be done in the transport area, but the problem there is, is everybody hates multicast there, so we need good representation to do it. So you know so maybe you teach us transport or we teach them multicast. I don't know.

J

Oh okay got it so the plan is to do it in the quick working group. Okay,.

E

um Why don't you just finish? You got two slides and then.

K

And then we'll.

E

Open up for questions.

K

So um yeah the the the the last two sites are basically about our implementation, um so we implemented started to implement it um in chromium and we got all the uh we got, the frames, the new frames and we got the the transfer permitted and so on um the thing we're missing. There is how to feed the packets we receive over multicast into the event loop of the regular quick connection. Basically- um and that's.

I

K

Tricky in chromium so now we're thinking about for the first um demo to instead use something like a a I o, quick or something in python, where it's much simpler to just feed the packets in and you don't have all the overhead of chromium.

K

Of course, the goal is to get into a browser, so eventually we will do it, hopefully in chromium, but just for the first test like that um yeah also, there are some issues with transporter, but I think we're just gonna skip over those for now, um and rather have the more multicast focus discussion right and that's it.

H

First of all, uh condos for uh doing the work, and I think you've got a really good approach here. um In a matter of transparency, I already provided all some of the points to jake offline.

H

I think what would be interesting is to couple this also not just to native multicast, but also to amt, so that you have the opportunity to say I. I will try first uh to to join a multicast group once once it's already set up, and then you try, uh if there's an amt relay which is still better than unicasting, it all the way.

H

The other option, or the other point that came into my mind, is regarding re-transmission.

H

Maybe you should rethink about this, because if this is uh fundamentally for life, events from my uh so so live tv like super bowl or whatever.

H

Now from our experience, there's only a really tiny time frame where you have the buffering and where it really makes sense to retransmit the data packets um in most of the cases, especially if you're further away from those retransmission servers, I'm talking about 50, 60 milliseconds, typically, um then re-transmission doesn't make sense, and then you don't have to actually think about re-transmission. If you, if you're talking about- and this was another use case- uh downloading files via multicast, so large downloads, etc. Then of course it makes sense.

H

Then you need those packages, but um I think it's more to focus on what is really required, for which you can use case.

K

Right so we support both quick stream and quick data grams so that, if you use datagrams to send the data, you wouldn't get retransmits right, so the application or the sender could choose which, whether to use datagrams or stream frames, but yeah. You want.

H

To reply to that.

G

Sure to also respond to that we've been looking at, like some of the mock work, the media over quick. We think that there's good synergy with the push approaches they're using using there for rush and warp um and possibly for the arkwick stuff or the quick r stuff that they're talking about, um and the idea is as long as you're using server initiated streams.

G

uh The whole stream uh has retransmits sort of built in, but you can still reset the stream and then that stream can be dropped. So you can have unreliable transmission at the sort of level of a frame or a segment if it, if it times out there, some of the work that they're doing there, we think will mesh well with this approach that we have here is basically the point. So I'd encourage.

C

You to read that.

G

To see if, if we need to do more than that, what that's doing.

H

Thanks and the last remark to the acknowledgements, I think from a scaling perspective, especially if you scale up to those volumes that you have in mind or that you're wishing for, I think something like the tcp window size, where you only acknowledge certain packet windows could could actually ease up your life.

K

So so we actually have a mechanic for um bundling x right where you wait for a time where, like like you, don't have to act immediately, but you can wait like a server set timeout before you have to like, say: okay now right, so we have that because yeah in quick, especially the the egging, is worse than tcp. I think just from the overhead yeah. You know.

J

um Regarding the comment you just made about live and re-transmissions, I would just say: don't: have an option never to retransmit and for live events. Use fec, because fec will correct most errors in real time and just as a data point um solan. The solana blockchain uses fec and udp transmission. That blockchain does not use a reliable transport protocol and it's working really well, and this is over, like uh tens of thousands of nodes.

A

Which fpc do they use.

J

I don't know I'll, I.

A

J

Let you know, but I don't know off the top of my head: okay,.

A

Is it open source or is it some variety? It's.

J

Absolutely open source, yeah, yeah and then my other question was, is um you seem to just I don't think you're restricting it to one to many, but you described it as one to many. If you were wanted to have a whiteboard session with uh 100 people drawing on a whiteboard, would this just be multiple instances of one to many or is there any provision to do many to many uh in any specific way.

K

um I mean you need the unicast connection right, so you would have to have like a central anchor point where.

J

Okay, so if you have uh one dimension, you will have n squared unicast connections and that yeah.

L

J

Concern that jeffrey.

L

J

A

There's no way around it by.

J

Just throwing you say, throw resources at it and.

A

You know just going back trying to understand your use case there like a hundred whiteboard sessions. Those would be like each one would be a multicast session.

J

uh I would I meant a hundred participants in one whiteboard session.

A

But they're all writing on it. Yes,.

J

They're all they're all sort of they're, all sourcing they're, all multicast sources, so so.

A

That could be an application solution where they just go to the source, and then it goes down on a single tree. Well,.

J

That's the way zoom works today, and it's not decentralized right, so the this could provide decentralized solutions right. So, okay,.

E

All right, uh one last question: um uh the the this mixing of um uh multicast and unicast. um Does that?

E

uh Does that um imply that if you wanted to do something like uh unicast bespoke advertising with a multicast stream, uh you know this this. This would work well or um you know, being able to mix in unicast, stuff and multicast stuff.

K

Sure the server could certainly decide if it wants to like send something specifically to that client over unicast that isn't supposed to be received by everybody else.

K

All right, thank you.

E

All right, thank you max. This is great.

E

M

E

um I'm going to um maybe yes grant you and I put my hand down.

E

Okay, so next up is lauren she's been working on the um uh we.

A

E

Been speaking for the last few ietfs about um about the work she's been doing, and um it's culminated with off net sourcing and uh some recent enhancements with multicast menu.

M

Yeah, and as soon as my slides come up it would, it is.

E

Slowly, coming up.

M

Yeah, so I want to start by just talking through the stuff, the two and a half components I have and then hopefully we'll try some live demos and see how that goes. um I saw the homework went out on the mailing list, but if anyone wants to download vlc4 that hasn't already and participate in the live demos, if you go to uh trudienne.net, there's a link on the top of the page for vlc4.

E

uh If there's anybody meet echo um we're having a little trouble doing a screen share.

M

Maybe I requested oh, do I really want to share my screen? Yes, I do. I would like to share.

E

Never mind echo.

E

M

There we go awesome: okay, so yeah off net sourcing and the multicast menu like I said I have two and a half components: multicast menu and the off net sourcing bit are the main stuff, and then I just want to talk about tjtv, because I think it's a cool example of lowering the barrier of entry to streaming multicast, so multicast menu started off. Looking like this and the main benefits of it um were it lets you register and or add your multicast streams, yeah yeah uh better.

M

There we go okay, um so let's you register and and or add your multicast stream. So if you've got a multicast enabled network- and you are putting your own stream out there- you can either manually report it so typing in source group, udp port and a description of it or let multicast menu itself, just kind of pick it up every night. It goes through internet2 and giant to look for multicast streams. Essentially it's just hitting looking glasses and running, show multicast or out detail to pick up any streams that are going through there.

M

Alternatively- and this is where the off net sourcing bit comes in, if you're not on a multicast enabled network, you can upload a file, a video file and have it translated um and there's an api to do this all programmatically.

M

Of course, you need a way to manage what you've added so changing like the stream information, title description category and then also it's very easy to view the streams it's much easier than it's much more simple than the command line options that have been there in the past we'd kind of have a direct option to open in vlc we're still working on specifying that the amt relay option when opening directly into vlc and verifying that the manual streams that are reported are actually actually exist.

M

We do basic like did you give an an actual ipv4 address, but not really anything beyond that. At this point, um and then a protocol handler from for opening directly from the browser would be nice um and then a student at tu, berlin, um recently kind of redid the ui made it look a lot better.

M

So we've got a thumbnail for each screen. Now, like I said, ui overhaul and also the ability to sort streams uh by categories like trending editors, choice and various genres.

M

So the second component is off net sourcing, so this is accomplished from a phone and the phone jumps through a transport translator which sends it to the multicast translator so in words.

M

So we're going from the sender and receiver from your phone, an app on your phone to transport, translator, sending it over udp to into the multi gas translator and that's where it actually enters a multicast enabled network for the first time and then that multi-cache translator is obviously translating to multicast still working on various video encodings.

M

And then the hope is eventually that this multicast live or this off net sourcing app can also become an off net receiving app. So you have some sort of amd gateway implementation in the app and then doing it for ios as opposed to just android, and then before we jump into demos. I just wanted to highlight. Tjtv um my old high school is one of the ones running an amt relay, and it's just very easy to.

M

If you have access to a multicast enabled network set up streams, I've just got vlc sending them to the amt relay and actually the first demo is watching one of those streams. So for demo this is the kind of topology that we're working with multicast translator amt relay in the box, sending that tjtv are all on a multicast enabled network and then the rest of the stuff. Isn't we have our three imaginary people in blue and all the stuff in green is infrastructure that actually exists.

M

So I'm going to jump out of presentation mode and split my screen, because I want to also see the terminal over there. That's showing what's happening in the background, um so the first demo is just viewing um the tjtv streams at all so going into multicast menu where that tv is behind okay, so going into multicast menu, finding a stream you're interested in watching and opening it directly from vlc saving placing um it's just opening in dlc.

M

So this is designed to simplify for an end user that might not know how to use a command line. um I've got a stream. I have my laptop muted right now, but the audio comes through as well.

M

So the flow or the flow that happened there was um before any of this. I added go back into full screen.

M

I added the streams to tjtv and I manually added an entry to multicast menu to tell you about the streams, and then we went from our laptop to multicast menu to get the information about the streams and then we reached out to the amt relay because here at iatf, we're sitting on a unicast only network and the amt relay was able to provide that tj tv source for us, okay, here's where things get interesting.

M

So um this is the offnet sourcing bit, and this is the first of the two off net sourcing capabilities where we're streaming from a file. So a pre-recorded video.

M

um If I didn't have access to a multicast enabled network, I could have done tjtv this way, just uploading, the video so going to multicast menu, add stream and uploading a file um specifying some basic stream information to help people know what it is and then selecting our file and as soon as I hit submit here, it's gonna buffer for a second, but when it goes through you'll see that the translator is now receiving a udp source in and it's translating it as multicast.

M

It picked a multicast group address for it and then it pinged multicast menus api to add it, and when we refresh the page here, we see that our video has picked up the source. Our video and multicast menu has picked up the source in the group that was assigned to it. So if we go back over into the main page, we can again go through the process of opening in vlc.

M

Now this one takes a couple seconds to load up, I've noticed um should pop up there we go and we have our source that is streaming for multicast menu that I just uploaded.

M

Okay, so the flow that happened for that one was that we from our computer, we uploaded a file to multicast menu, multicast menu, sent that to the multicast translator to be translated as multicast and then sent an api back to multicast menu to tell us about it and then that same flow that happened before when we tried to view it so the third and final demo and the one that I think is pretty cool is: let's live stream.

M

This meeting, so we're not actually going to open the the app because the video encoding is still messed up, um but on my phone I have an app. It's called high vision live and is there a camera that shows anyway it's on my phone? It's called hi vision live and all I did was type in the url of this transport translator and I'm going to start a stream and I'll prop it up.

M

There you go there, you go. We got a camera man, okay, so.

M

Okay, hopefully that okay, so we see that we have a second uh message here from our translator actually before we do that um see that we accepted an srt source connection. That's what's coming from the phone, that's that first hop into the transport translator and then we're forwarding on to our multicast translator to add to multicast menu.

M

And we see we have this first item here, which is what we just added: there's no description available because we haven't added one yet, but there's the ability to crowdsource such a description.

M

But if we want to open this in vlc, it's a lot of clicking to open in vlc, which is why we'd like to get that protocol handler to do it a little easier, but it does beat the command line for many many users.

M

M

There we go, and so now we're streaming and, like I said, audio comes through just fine. um I just have my computer muted at the moment, but yeah.

M

So most of this, let me get my slides back.

M

Yes um and, like I said, the goal is to get to a separate like multicast live app where it can be both a sender and receiver, but in the interim high vision, live android and ios does the job perfectly fine.

E

Yeah, so just for those you know not following along what um what uh lauren's essentially built here is something that ietf hasn't done in about 15 to 20 years, which is stream a uh an ietf uh over the mbone um and better. Yet it can be received by anybody on uh unicast only network, so so we're getting ietf back over being multicasted. um And uh yes,.

A

E

Is it being multicasted, but it's being received by it's being transported by a multicast but received by anybody on the internet, uh including unicast, only which is something that uh you know even 20 years ago? We couldn't do when multi, when these meetings were multicasted.

M

Yeah with amt, so the I stopped the stream, so you can stop being cameraman, um and the part I didn't address is that the yeah, if you hit stop stream, um that all of the the teardown is very automatic. So when it stops receiving uh translation here, it'll call back to multicast menu and say: hey, I'm not getting a source anymore.

M

Please delete the entry, so people aren't looking up stale sources and for that last the flow for that last was from a phone into our transport translator, which is just an aws box sitting on the unicast regular internet, um then into multicast into the multicast translator back out as an api call yeah. So most of this is still pretty actively being developed, um like I had to do's on each slide, so we're building up little by little trying to pick and pull different uh bits of technology to push them all together.

M

To make this work, that's what I've got.

E

A

E

Followed instructions I.

A

I just had a question about other source options. I mean first of all, fantastic. This is very exciting. uh If, if I had something like an existing uh ip camera, can we pull that uh that stream as well somehow set it as a destination into the translator and get that sourced.

M

Yeah, so that's not built in as like a easy clickable thing in multicast menu, but it's certainly very possible. Yes,.

K

uh Yes, maxwell great presentation thanks um clarifying question, I guess so the app the higher tv app sends it via unicast to the multicast translator.

M

Yeah yeah, so I've still got my slides right, yep, okay, um yeah, so what's actually happening is it's sending the high vision app is using srt, which is uh udp based, uh but still has some server client aspects um and that's going into a transport transport translator which is just taking that srt udp and changing it to regular udp and that's what's going into the multicast translator. Okay,.

K

And then the multicast translator sends it out both via multicast. It translates to multicast and from there okay.

M

Exactly it takes udp unicast and out is multicast thanks.

I

I just wanted to uh to thank you for this presentation and say that I think this is the first time I've ever seen. A live demo at ietf go down without a hitch, so really good job. That was fantastic. I.

M

Was very concerned.

G

Hi, I'm jake uh when you say regular udp, you mean raw ts encoded uh inside the udp right. This is mpeg-ts. That's.

M

It's mpegts yes, great.

A

H

Great job lauren, I just wanted to share some experience that I've seen not working because I used to work for a consulting company and we were doing some consulting work at a large international insurance company and they try to live stream pretty much exactly in the same way that you did their all hands calls for their employees, on-site multicast offside through unicast.

H

um What you've done works, what they've done failed and they had to reshed you the session.

M

Yeah scalability is still a slight issue more just because of like operational constraints, you've got a tiny aws box and iptables firewalls going into the multicast translator, but yeah scalability is a little bit. The next step.

E

uh Who's funding this.

M

uh You mean at the amc level like who's paying for the amt connections.

M

Oh the aws translator is on my credit card right now, um yeah. I I he offered to fix it many months ago and I just haven't gotten around to giving him that info. Yet.

E

I bet you said: you're gonna, you're gonna help. I thought you were gonna, say: you're gonna help pay for it and that will help remind me to pay for it.

M

M

Okay, how do I stop okay, perfect.

E

Great, that's uh pretty amazing work, and this is um just for those. uh Without the background. This has been a multi-year project. uh It started with william zhang at thomas jefferson, high school about five years ago.

E

He deployed the first um amt relay and then uh two and a half years ago, um lauren two and a half three years ago, lauren picked up that work uh and has you know uh she built the multicast menu and has extended um and has enhanced and we're up to off net sourcing, which is something we've been talking about for years and uh she was able to do this so really, really impressive and um and the work continues um max uh uh there. Others have been collaborating and max is gonna at the end.

E

Talk about um some work that his student is doing in collaboration with lauren. um So this is a great project um and it's exciting and, like I said, we're we're getting ietf backing up back on the mbone and uh we're getting content on the m-bone and there's lots of neat stuff. So I encourage folks go visit. uh The multicast menu check this out. It works. It's real um you when you, when you receive that content you're watching multicast streams over the mbone. uh You know something that you know.

E

If we had 20 years ago, the world might be a different place, but um but it's pretty exciting. So um next up is uh eric. You are.

C

Hello, I am eric from viva, we build software for multicasting, zoom and webex and other meetings, and what I want to talk briefly about is the history of some receivers and clients as a way to think about the past and potentially inform quick, multicast and other considerations. So I thought it'd be useful to just give a very very brief. You know overview of some of the things that I experienced and and then some ideas about uh about future implementation.

C

So next slide so so this is uh some legacy receivers that you might have remembered, starlight networks back in 1996 bought by picturetel, and they did mpeg-1 multicast and we built a web-based kiosk for them very close to my heart, because I met my wife at a conference when we built out a little multicast kiosk using starlight networks and then progressive networks, real player again, another multicast receiver, quicktime windows, media vlc.

C

Of course, enterprise companies like vbrik, had other multicast receivers, and so this is thick software deployed by enterprises to receive multicast, typically within a very closed network. Typically one to 12 channels could be an iptv scenario. It could be just a all hands, meeting type scenario: very kind of internal single domain, controlled environment, but yeah a range of multicast receiver, software next slide.

C

So then it evolved a bit more moved into taking the the windows, media player or real player uh as a as a control or an ns api plug into the browser so wanted to get this multicast experience into the browser context. So you could do interesting things about it, then flash with the flash animation movies and eventually video that then provided multicast capabilities from their flash server. They had a concept called fusion where they were blending peer-to-peer and traditional multicast and unicast failover same thing with windows.

C

Media had this concept of an nfc file where you could specify a unicast failover mechanism.

C

So browser context is really important at this point where we want to do a lot of interactivity and other things in that browser and have it be a web experience and not just a you know, a thick client experience, okay next, so then, um what are we doing today? Well, um in the context of trying to get uh multicast video to render inside of a browser, so here's a video.js plugin and a browser joining a live stream.

C

The way we have to do it now and by we I mean there's various companies that do enterprise video like uh high vision, kumu vbrik, uh kaltura others. So these are companies that provide internal, all hands meetings and use cases for one-to-many video where they still want to utilize multicast in some way. So what they do is they have agent software? You could call it a multicast gateway and they push that out to every single desktop and it becomes a a web server.

C

So they're running a local host web server on their their pc mac ends up being this kind of strange java implementation. That's pretty tricky, but here you are listening on. um You know for a local host https request from a browser, and meanwhile you can. These agents can be can be available. So when the browser makes this local https request for a service, it will then open up and join a multicast.

C

So you could do a transport stream multicast and then this agent would receive it, and transfer stream happened to be pretty handy for hls, so you could just take the transport stream and re-packetize package it into http hls tls to the browser. So that's how you get transport stream into hls via a local host browser web server into into a local browser and lots of security problems with that, but at least it solved the problem of of getting multicast into the browser, so we're obviously really eager for quick, multicast and better solutions to do this.

C

One more thing- and we're almost done so uh last slide is- uh is what what is vivo doing. So we are actually building thick clients for all the different platforms. So there's a zoom version, google meet version, it has we're using vp8, it's rtp. We use ford air correction, uh it has chromium built into it, so we could do the interactivity with chromium.

C

It's a g, streamer uh codebase with ulpfec and uses qt for the for the wrapper lots of opportunity to make this much more simple. With uh with uh quick multicast, and since we have chromium, maybe we can get to get to that very quickly. Take out the g streamer make this just be one interactive experience, and that would definitely make our customers a lot happier. So last slide is the is the future and jake eager to talk with you about it?.

G

Great thanks eric. uh I just had a question two slides back in this deployment model where you've got a localhost server yeah. uh What do you do for mobile or do you have uh do you have mobile support because there's like sandboxing issues with this model there right.

C

Yeah, it doesn't doesn't support mobile, I mean. There's one option is to do a gateway in that local network. Have that be on a wi-fi network and have mobile devices just join hd to be unicast over wi-fi.

G

All right thanks.

G

E

I have a so I've heard over the years, a lot of different use cases for multicast. This is the first. This is the first time you've come up with a new use case. I believe it you described it spouse discovery. You, you.

G

Multicast, yes, yes,.

I

E

um You're you, you actually got married as a result of multicast.

C

That's true: that's right. I was definitely shy, but when, uh when my wife was at the conference I was I had the gumption enough to go and say check this demo out and it worked as well. So I got lucky and I've been married ever since so I've been very lucky. That was a that was a multicast join, that's still successful.

C

uh So I have lots of swag if anyone wants t-shirts or mugs with multicast stuff uh come on down any other questions.

C

That's true, yeah, that's yeah, there's, no there's no group sharing or key sharing or.

H

C

Like that uh possible.

J

Let's just stick with spouse discovery.

C

And I guess I guess that is the question. Yeah, it's uh yeah, that's true! Yeah there was no. There was no group activity in that one. Any other questions all right. Thank you! Yeah and again. If anyone was interested in shirts and mugs, I've got stuff for you.

E

Okay, uh max you're up.

K

All right yeah, um so this is just going to be quickly um basically.

E

You can take as much time as you want yeah you take us home yeah. All right. You've got 30 minutes, yeah, okay,.

K

um I hope I don't need 30 minutes uh but yeah, so this is like just some updates on or like reporting on some of the student projects we're doing at turbulent related to multicast.

K

So the first one is adding ipv6 support into the vse implementation.

K

So that's all the different ways. Jake did some testing at last at the last second about the tunneling and so on. So since that worked, we're hoping to it will work here as well, so we will have ipv4 and mp6 and so on. um It should be finished relatively soon. um The project is going to be over in like three weeks, and the last thing to do basically is. We are also looking um where we're gonna upstream it hopefully and um we're also looking for deployments.

K

If anybody has an ipv6 capable amt relay somewhere or could enable aimed ipv6 on a relay somewhere. That would be great in the mbon, um we're still looking to serve our own relay at tu berlin. um So so it would be the deutsche four chunks net, so dfn, which is not really jean but connected to zhong, and it's all a bit uh bureaucratic and we're trying to figure out, and hopefully we get a relay up soon as well. All right thanks.

G

K

The the next student is um implementing graceful failover for mt, so make use of the lflac that's there, but as far as I understand it not really used anywhere so far, and the idea is that the relay sets the outflag when it's about to shut down, or it knows that it's going to shut down soon, for whatever reason and the the gateways can start discovery and in that way, keep the stream running and don't have any interruptions by the the relay suddenly disappearing.

K

um This is part of a bachelor thesis, so the implementation should also be done in the near future. Okay, the last slide good question.

J

Is there an equivalent graceful restart on the client side, so the amt relay can shut down the tunnel quicker when the it goes away. So it doesn't.

A

J

J

I'm worried about I'm worried about the relay um encapsulating to where there's no client anymore. Oh.

K

That's a good problem to solve. Okay, thanks.

J

Do you know what I mean? No, if the client just drops off the air, the the the if the amt gave me drops off the air and then the the amt relay still has the tunnel to it. It'll keep encapsulating to it until some time out. So I just didn't want to send all the data on the network to no place right right. I want it to happen sooner, so I was wondering if there's a sorry, I'm going away sort of thing when.

I

It's a graceful.

J

Restart not when it crashes or goes away right.

J

Then it would do it great. So that's the graceful mechanism so you're saying jake, there's no need for that. Okay,.

K

Yeah but yeah thanks for jake for also coming up with that idea in a way or like um helping the student along as well um right and since the bachelorette has to be some scientific part. So it's gonna include some measurements, hopefully, and how much time you save and so on. Yep.

J

Yeah, actually there is a reason if, if there's a shut, if uh um if something goes away, um maybe the um the relay can send a query sooner, so it can detect that no igmp report is going to come back within 10 seconds. You could shut down the tunnel in 10 seconds instead of three minutes. That's useful right.

K

Yeah, okay, all right and the final one is basically what lauren already talked about and shown um this update to the multicast menu. um I guess the interesting part here is that on one hand, the the pulling of the preview frames is gonna do some measurements on how much resources that's gonna, take and so on. But the other thing is: how do you do like ranking for multicast streams right? Because, unlike twitch or something you don't have the viewer numbers? You don't know who's actually watching the stream?

K

um If you have something like multicast, quick, of course, you would know that, but for the multicast menu, especially there's no good way of doing that. So he implemented something like um cache. The the the same algorithm that's used for cache management, where you use the likes on the website to to figure out which stream is relatively popular um but yeah there might be future work on seeing like if this also could be related to telemetry and so on.

K

But if there's a good way to figure out, like which multicultural stream is actually popular and is actually getting watched by a lot of people. Okay next slide.

K

uh Yeah, so there's also the the idea um for a future problem, but it's like a big idea, so we would need a bigger group for that. uh Maybe in the over the winter term is to try to get apt-get distribution with multicast implemented right. So you would popular properly uh popular packets would get distributed over multicast if a lot of people are requesting at the same time, next slide.

K

Yeah and that's basically it so if any of you have ideas for similar scope, topics related to multicast or just any other collaborations, you would want to do. We have a lot of students applying for theses. We can't we don't. We can't come up with enough ideas for interesting thesis, um so yeah we would be very happy if any of you have ideas or something like that, all right, thanks, lauren.

M

uh Yeah with the trending streams, is he what is he tracking for trending streams, just the like button? So would there be any value in tracking like how many people are actually clicking to open the stream as well?

M

Because I mean that is a button. That's clicked.

K

Right, I I I guess. Yes, the the ideas then or the issue, I guess is, um do you like weigh them differently? But yes, it's. It's probably a good idea to like for future. um I can tell yeah thanks, yes, and you don't know like if somebody launched from the con so um from the command line. You also don't, I guess, wouldn't know.

F

Stick with us, um could you track how long people actually are watching? If people you know just watch it for a few seconds, then they probably didn't care about it. If they watched a long time, they might really like it or no.

K

You can't okay, that's fun,.

E

I would imagine that you should be able to track uh one, how many people click on the entry and two, how many people could clicked on the launch in vlc.

E

So at the very least, you know how many people.

K

E

Did click to to try to get it right.

I

E

How long they were on right.

K

If, if they didn't use the command line right right for the for the second one, and that's like that's, why so far? Here's the like button, because that's like more a strong indication, that's actually like something they want to watch and are interested in watching um but yeah. It's definitely like an, I think, a bigger area where you can probably come up some clever mechanism somewhere else that that you could use yeah.

E

I think the only ones who are using the command line are like the people in this room, so sure yeah.

K

Is anybody else using the multicast menu right now right other than the people in this room? So after.

E

This meeting it'll be a lot.

K

All right uh thanks a lot.

E

All right, thank you. um So we do have a little bit of time, uh but that doesn't mean you can leave um so uh everybody please uh feet proud on floor eyes, eyes forward, hands, folded till the end, um uh but um we have some time uh anybody wanna uh anybody, have anything else. They'd like to bring up uh and discuss.

E

Jake, are you trying to leave? Are you uh okay? uh Yes, t-shirts are here, um I should say, uh like I mentioned, there's there's a there's, a slack group uh that um a lot of this activity is happening on um uh reach out to me. I can get you added to the slack group or you know any of the the others in this group, uh and we can add you and get be part of the revolution.

E

Okay, everyone. Thank you. One of the big issues.

B

That's happening.

E

Actually, that would be really valuable because that could prevent. In the past there was like the issues with dead streams and like these things, they go there and they never. You know, remember: sdr, had hundreds.

B

E

Streams that were dead.

A

A

A

B

This is like one of the best.

E

uh So for the folks still on uh we've, actually the meeting's over. So thanks for coming and we'll see you in london.

E

And foreign telemetry.

B

By default, they do this satellite telemetry, but.

E

They push out in real.

B

B

A

B

A

Was the intent.