Internet Engineering Task Force Interim Meetings, 23 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-AVTCORE-20230523-1600

Description

AVTCORE meeting session at IETF
2023/05/23 1600

https://datatracker.ietf.org/meeting//proceedings/

A

B

Yeah yeah, for some reason, the uh the carp, the pdf version is showing an old slide deck. So.

A

You might not do I seem to recall that sometimes you need to like reload your own session so that it knows.

B

C

Confirm that, because I approved that almost every ITF and.

D

A

C

Because we always get things at the last minute.

A

A

For now, you still have no media by the way, if you wanted to say anything.

B

This is the ABT car working group, Central interim, presumably it's being recorded so be aware of that and I guess Jonathan. You can walk us through the usual toilet plate. Yes,.

A

um Yeah- let's see so yes, virtual interim meaning tips I think most people here have used mediko before, but it's I remember that uh you need to enable your own audio. Also, that can be quite slow, sometimes so uh Becca can you mute, I think I'm, hearing Echo from you, where I can mute. You.

A

um Yeah so yeah you'll need to please see a pleasure as please stay muted, when you're, not talking and so forth. um No well um ietf has various policies, including IPR and uh participation policies and uh code of conduct and privacy policies by participating. You agree to them see your lawyer for more details, not really well, please. uh As mentioned, we are under the code of conduct and the anti-harassment policy.

A

um Please behave professionally respectfully to all participants and if you feel that- uh and you know that you're thinking they're not being handled properly, please talk to the chairs or the ombuds team.

A

A

Okay, uh this is the meeting. Here's the link notes. uh You should also there's also a link to the note-taking tool in mediko, the one that looks like a pencil on a piece of paper or perhaps a square.

A

um If anybody says anything so far, no one has and we do need a note taker. So at this point we will install to ask somebody to please take notes.

A

E

E

B

My God yeah, we really do need someone to take notes pointless.

F

A

Yeah, um if you need somebody who's, not presenting I'm, not sure who's presenting for all the sessions. But let's see.

B

That fun are you willing to take notes.

G

Kicked out of the session already twice in the LA in the first five minutes, I'm willing to take notes on the best effort basis, and uh it's not going to be a particularly good effort. I feel.

B

Okay, well maybe we'll need two people, then yeah.

A

um Let's see foreign.

C

It is also fair to ask people to uh check the notes for uh what what they said and what they've heard as the answer um this, this really is kind of a working group uh responsibility as much as.

A

C

Is one or two people.

A

A

um So yeah, so everybody please keep. You know open up the note taking tool and keep an eye on it, but we need somebody to be the primary Note Taker still.

C

um And and I.

G

Will be happy to.

C

Do with someone else.

A

Anybody want to be an.

H

A

Taker dispenser assembly, obviously principally when he's not talking, but also just to as backup.

G

Something we'll see how good it is all right. Thank you sounds good. Thank.

B

A

Okay, here's our agenda um I'm not going to go over it in detail, but if anybody has any comments or requests to change it, let us know shouldn't take uh too long.

A

Okay, we've got various things published, I, don't remember which of these are before the.

D

A

The previous IDF, but we are getting stuff done so that's good. um Let's see in the RC editor queue. We've got bp9 and 7983. This, which is the quick multiplexing vp9, is still waiting on print marking directly as I recall.

A

um uh Any follow-up on skip, which we have some proposed changes we discussed today and if you follow up on frameworking with simple changes to discuss today,.

D

A

Adopted r2p over quick, EVC, green metadata and v3c foreign I think we're all discussing most of this today next time, and next up is Skip service demanding for that damn.

I

Great I'm presenting for that okay, um let's go ahead here, I guess we published draft version 05 back on March 29th um again, we'll read the whole list of things that we did change because we talked about this at the meeting. Again we focus things on more from a network perspective rather than from a pillow perspective, because again trying to empathize and Skip is an opaque payload and trying to Define it at any particular point in time in the rpt. Stream is really difficult um and again asking that network devices.

I

Don't attempt to try to do packet filters on it just because again, it's hard to quantify specifically what skip looks like um not only because of different messages, but because of the it being encrypted that it again makes it a very difficult uh payload to try to modify at any point in time and try to produce a reliable package as well. So basically we just change it say: don't do it.

I

So I guess other than that I guess final slide is I, guess yeah trying to figure out how to how to move forward um again. We've contacted I've contacted several of the reviewers from the is icsg and ask for their reviews, but I've heard absolutely everything back from any of them. For the last two months. I guess I'm.

B

Yeah I've also.

I

B

Mail and I asked the area director our area director.

H

B

To send mail, he sent mail, he didn't get a response.

I

B

So I guess we're.

I

Sort of stuck at this point trying to figure out what you know: how do we move things forward? You know I, guess you said in a slide. You have a couple of things that you may want to change and the sort of be willing to listen to that and see what see. What.

B

Those values are yeah, I mean I, don't want to try to interpret somebody who's silent uh as to what they want, but we couldn't I but I. Didn't you know in the deck I did include the comments. The discuss comments that uh just trying to address um so I mean here. Here's you know it's Roman and darker. So.

I

Right and like I said, we've addressed those as much as we can I mean we still deserve been there for five months now so I mean we've tried to address those as much as we can to put that in there. So.

B

Yeah I think in particular. So let's talk about Roman's comment. The section four comment, I think the new draft does say the details are entirely opaque right. Yes, so we have been explicit in saying that uh I guess maybe ah well, there's the there's the pre-pre-uh encryption messages which are in opaque. But after that it is um I, don't know what you could say more other than copying text out of the skip document or something.

I

Well, maybe try to illustrate that in the figure that we added I'm.

B

Saying that there are there.

I

Are some some clear messages and some encrypted messages so.

B

Yeah I mean what I'm wondering I mean it's. It's kind of the these reviews were conducted without access to the skip documents right so they're saying they want something from the skip documents, but they haven't looked at the skip documents to actually be able to express what they're asking for right. So that's kind of a difficult it's difficult position to even talk about right because you know I've read the skip documents, I think they're, useful I. Don't think they're required to implement this document, but I'm.

B

My knowledge of that is based on reading the skip documents, as opposed to not reading them right. So it's kind of a weird situation where, if I hadn't read the skip documents, I might not know that I don't need to skip documents. If that makes any sense.

I

Right and I mean we're more than willing to provide them to them if they want to. They want to look.

B

At it yeah the thing is they haven't, they haven't asked for them, I mean we'd, happily, I'm sure you'd provide them if they asked. But it's I'm just trying to understand how we get out of this situation. We if they would ask and look at them. They then understand they don't need them.

B

It's like I think I need something. Okay, we'll give it to you, I, don't I, don't want it. I, don't know I, don't.

I

Know what to say.

B

I

Right right, yeah I mean it's the fact that again that we've had radio silence the last two months is kind of disturbing. Even why? Why is no one even bothered to to respond to you know, ask them.

H

I

Re-Review and post another discuss or something, but we haven't heard anything so right.

B

I don't know what's going on there, all mail goes into the big bucket.

G

B

I don't know uh well I understand why that happened with Francesca. She was legitimately on leave, but you addressed her comment so that one I understand these these other ones. I do not understand, because those people I I, see email from them just not to us.

I

um Right and there were others that were listed on that list, but they didn't have any contact information, at least what was on the. If you go.

B

I

Other members of the review board, but right they didn't have.

B

Any contacts there's section six uh about RC 7202.

B

It just says that the 7202 basically says there's different Security Solutions in the RGB ecosystem. He's saying he's not clear how this applies to skip.

I

Yeah I mean I was taking it trying to understand that because I guess he was his point was basically saying well, because it's an encrypted stream, then you don't have to worry about any security.

I

I mean that was sort of my impression of what he was referring to in that section.

I

um You know, because that's basically that boiler that 7202 is kind of boilerplate text saying well, if this is how you address security concerns- and you know in certain for certain.

F

I

Or whatever, which go.

B

Ahead, yeah, so this uh so he seems to be asking for the security properties which I think you have some are in the document. Right. Basically, it's I mean I'm, not sure what he means by security properties, but the services are indicated, or certainly they could be basically authentication and encryption um yeah. It's it's section two says: end-to-end Security application, layer, authentication of user identity ability, probably different security levels.

B

So right I guess you could put that text into the security consideration section uh it's already there, but you can put it somewhere else.

I

Right, yeah, I.

B

Mean we could do.

I

That, if you want, you know whatever you know, I guess, whatever you know makes makes them happy again because he said I mean there's some clear and there's some encrypted traffic. So I guess you could sort of right.

B

I'm trying to make.

I

It make the argument that, while the whatever generic security concerns there are for any RTP stream still apply for that case, I guess right. Yeah.

B

I

Same time in parallel, it's also encrypt and then as I say it's also encrypted. So maybe it doesn't apply for that I mean you make the argument both ways.

B

I mean, but that's true of all Key Management traffic right. It's set in the clear until you push down the keys, so that's not news, uh but I I mean the way you can clarify. That is with a state machine, but uh it'll, look like I mean it. The state machine will look exactly like it's pretty much what it does in ipsec or other encryption protocols right. It's the stuff is in the clear but I, don't know what the point of that is because it's in it's inside of skip okay.

B

So this is soccer's, discuss and he's asking about the RTP profile.

B

But the answer to that is: it could be any profile right, depending on what the.

I

B

I

What's the stated right, the State of the State to skip, you know a state machine, it's basically, it could be like I said anything, that's why we've avoided.

J

I

To to to do that because it's you know, depending on what messages are being sent through different sizes and some are clear.

B

Yeah I mean as an example you could you could negotiate srtp or not right. That's just you. Don't I.

I

Mean well I still I, guess that's, but that's really out of Band of skip I mean I, suppose right exactly run run both or whatever. So it's kind of you.

B

Could I guess you could say you could say that that's a point of confusion. That's like! Yes, you could do sodb or you could not do sotp, but that's not related to the payload per se. I mean we don't say that in every Pro RTP profile spec, you could do srtp or you could not, but I guess we could say it if that helps them. I I, oh, so he does have confusion about the term variable because he's wondering if it means variable bit rate which it doesn't foreign.

I

This output stream is variable size, packets, it's not like a 700.

B

It thinks it means variable bit rate, so that's something we could fix. I guess.

I

Right and we changed that we changed that wording in the in 2017 the last revision. So that's that has been addressed already so so.

B

What bit rate is specified in the sdp I guess you could put the B parameter in if you wanted to right, Max bit rate or whatever.

I

Yeah well, I think he's. That was that's relating to the previous comment. I think that's what he was right relating the confusion about you know, variable rate and so I didn't see that it being applying the need to put a b parameter. If you wanted to put it, you can, um but that was not I think that was. That was not the meaning of of what that was right.

B

Jitterbuffer, a Jitter buffer may be implemented in endpoint devices, only uh all right, so he doesn't like the May yeah. Well I you're, not saying that that it's optional to have a Jitter buffer.

I

Well, I'm saying it's not required to have you know, that's implementation specific. If a device wants to do it, do it or not? Do it I mean it's not it's not required in 35.50.

I

B

I

I, don't think it is, but.

B

Well, and that's also because skip has a Jitter buffer right.

K

A

Yeah, let's hear him.

C

Thank you. um My my working group is uh working through a discuss about a May that should have probably should have been. Might uh right. It's not it's, not a it's, not a bcp-14 may, but uh you know, but basically, basically, the conversation we're having on our discuss is uh that this is not a bcpe 14 use of the word May and uh saying that it could be or might be right.

C

It takes that off the table.

B

Yeah I think this use of may may be gratuitous.

C

It it often is I mean this is what we do right.

B

Yeah, so that's a suggestion. Dan is maybe it could be or something like that, because they're freaking out because you're saying it's just above instruction.

I

S: okay, right yeah: we could change it to could be.

B

I

B

About this as a, why don't we try to focus on soccer's disgust, because if that one seems eminently addressable.

B

um So, can we make that the goal and we'll all send emails to him.

B

um Just trying to I'm just trying to bite eat this elephant one bite at a time.

I

I

Yeah I have to go back. I can make some I guess. We didn't change some Jitter buffer wording on that, but um I can go back and look at that to see so.

B

So, let's do this: let's, let's try to have some a proposed set of changes for the soccer discuss and then send it to him and see if we can see if he thinks they're, okay or comes back and says, I want this other thing. In addition, okay.

I

Yeah we can do that.

B

Okay, well, thank you um and then we'll we'll see. If we can, we can Whittle this down right.

I

B

Yes, yes, well uh he's asking for a link to the spec and he said he had a hard time finding documentation. Well, is it were we not clear that you had to ask for it? I, don't know right right anyway,.

I

B

I

Can you can find an older version of the spec online or you can Google it and you can find it.

B

I

Like it's like 10 years old, so right so.

B

Okay, thank you all right, so this is this. Next one is about discussion of the discusses on frameworking.

B

C

B

A

C

A

Sorry, yes, okay, yeah, let's go ahead! Spencer on the previous.

C

uh I was just gonna say that um my encouragement to uh the authors, chair and working group would be that uh as long as we're making changes that do improve the document um that making changes that improve the document is a fine thing to do.

C

But uh if, if we get to the point where other additional changes are not going to improve the document and um we're just you know we're just negotiating with ourselves uh right right. That's.

D

C

Well, but that's that's a conversation that the chairs can have with the ad about um doing things like and uh just for an example uh putting you know putting this document on a uh on a telechannel agenda as a returning as a returning item. uh Okay, as a you know, kind of there's a it. You know it's it's easy for area directors to forget about one discuss among many yeah.

C

You know it was for me.

B

Okay, so that's another good, that's a good uh Point Spencer! We can try to get it put on as a returning document and that might that will almost certainly generate new feedback. Foreign.

B

So I guess this segment here is uh to understand what we need to do to address. uh Paul wooters, discuss on prey marking and uh just reading this discuss. It says the document has no privacy considerations section but as far as I know, I mean I wrote the Aya B. We wrote the IAB uh statement on privacy, there's no requirement to have one, but basically what he's asking about is I guess, uh encryption of header extensions.

B

So uh what do you? What do you think? How can we resolve this? Do we just put in a reference to cryptex or something in section four.

A

Seeing as how we've not published cryptex I have no objection to that. No you're not to raise your hand while you're the person speaker here.

H

Yeah, um the the um the security considerations can just be augmented to add uh some points about the diplomacy considerations, um I'm, not sure. If, uh if it really changes anything I mean I, don't think it really changes the security posture of how this is used.

H

um The the whole point of this was that it would be uh uh understandable by the by the middle boxes. uh You know frameworking doesn't make sense for end to end. It only makes sense uh for for deployments with metal boxes right.

B

H

So the the you know we.

D

Can spell that out.

H

In in a privacy considerations that yeah that this is not, uh this is intentionally being revealed to a middle box.

D

And you'd have to be okay with that to.

H

A

Yeah I think. The point is that you know standard SRD, header extension, Exposed on the wire and I think you know if you could use cryptex or you know, potentially the um whatever the older I received number was, but probably cryptex is better.

A

um Then it's only exposed to the middle box itself, not on the wire which Fair.

A

B

A

Maybe a recommendation to use you know, you know you know you might want to consider using cryptex if you feel like six or five percent sensitive.

B

A

B

Same the other part is saying: don't send these bits all the time that that seems, I don't know that that makes any sense yeah.

A

No I think saying you know, keep them secure, rather than not sending them all. The time is probably a better got a better solution to that.

H

Well, that's what I was kind of alluding to is that in an.

A

H

Case where you don't have middle boxes, I I, there's not that much value in in frameworking there's a little bit of value because it adds a little bit more determinism and and when you have losses. But it's.

B

H

I, don't think someone would would implement it just for that extra determinism- it's really only for conferencing, topologies with middle boxes, and so it really wouldn't be negotiated. We can add some text to say you know this is intended to be negotiated for topologies with middle boxes and, if you, if you're not using that topology, then for.

D

Privacy considerations.

H

It may be better to not negotiate this.

B

Here: okay, that all sounds reasonable and hopefully we'll we'll address to discuss. Thank you, Mom yeah,.

H

So do you want next uh in a version 15 that says that and then and then present, that for the discussor you want to just have a a proposal. First to Paul.

B

Well, if you can actually get him to respond to you, a proposal first might be physical. If that doesn't happen, I wouldn't wait. Hold your breath.

H

B

H

Round of email, if it doesn't work we'll just do the draft update and and follow the process.

B

A

C

To get something to say: yeah yeah, my apologies uh I'm still trying to catch up with the uh minutes on the skip document. So I had to not take any notes at all on uh on this document um and if somebody could uh take notes why you know for like two or three more three minutes and I'll say that I'm back in the chat uh that would really.

B

Be helpful, maybe we could could help you out by a mock and you summarize.

C

B

You think the next.

C

Step that would be a that would be a fine thing to do and I'm not finished yet so I'm trying to get I was I was trying to raise the raise uh awareness of this, so I wouldn't be just sitting there trying to flag down the meeting for the whole time and not taking notes. Okay,.

H

um Yeah so Spencer that my summary would be that uh um we will uh add privacy considerations in the security consideration section and um mentioned that this is intended for topologies with middle boxes, and it's not recommended to negotiate it in other topologies to preserve privacy.

B

Yeah, we could also mention cryptex, as you.

A

Know yeah basically yeah, which might be you might want to use if you feel there's issues of exposure. Oh yes,.

B

A

Got that expensive to get that or do you want Mo to actually just type it himself into the.

B

Note you can yeah, you can type it in.

C

That would be, that would be superior, usually I have two screens uh and I'm in a hotel. So.

G

I I wrote this down.

C

Perfect. Thank you if you, if you could stick that in the in the notes, that would be awesome.

B

Okay, excellent all right so now we're at the b3c payload format, uh Lori.

L

All right, I hope everyone. Everyone can hear me all right.

L

Yes, so thanks for accommodating this to your agenda today, um I wanted to just make it make you aware that the uh version with the changes presented in the last online meeting or like in-person meeting is now available, and you can have a look at that and after that, or shortly after making this available, a couple of new issues were created for the draft uh one proposing to change the previously hex coded Fields fields to a base64 coded Fields like in BBC RTP, payload format, um I I, suppose this makes sense, but I also looked at hebc, RTV payload format, specification and there it's there.

L

It seems that there's a mix of uh base, 16 and base64 coded builds uh personal I think it's. It might be better to just keep with one coding rather than mix them together in the same specification. So I was thinking that we should just move to this base64 code. It builds.

L

um Another thing another issue that was added was to remove comments from the example STP fields and add them as text instead to kind of maintain the syntax correctness for the sdp examples and uh yeah. Those are the two two new things uh that I'm trying to are planning to address for the next meeting and as always, new, more more ideas and suggestions are always welcome.

L

uh You can file these issues under the under the link here and yeah. That's it. I've, no requests just an update of what's Happening.

B

Okay, if there are.

A

D

A

Think how far do you think you are from being done and ready for a working with last call.

L

uh I I mean these are minor changes right, so I think it's. It should be fairly fairly straightforward from this point on.

A

If you think, if you think you're, um you know your your future complete and have no open issues, then, presumably just moved to working with classical.

D

That's a good idea.

A

All right, uh Bernard.

D

And I will figure out who's gonna run that one okay.

A

Green metadata, let's be ready for this one.

B

I guess there's not much more new content here, yeah.

F

Okay, can you hear me no yeah, yeah? Okay, thank you yeah. uh So uh young he's not present today in today's meeting so I'm presenting on before her film. uh This is srinivas, uh so uh we updated the title up that draft us, because uh this uh are the artistic messages for temporal special resolution. uh This basically uh is not presenting all the messages that are part of the green metadata, so it's only presenting the temporal and special resolution requests.

F

So, as per the request, we change the title to particip messages for temporal and special reservations, and also we received a comment saying that the constraint should be added in this class for for that 1.2.

F

So the temporal and spatial resolutions in the TSS TSR message shall not be more than the resolutions that were negotiated in the SD via the sdp, so the constraint has been added in the ITF draft, uh so these are the changes that we made it uh in uh and we uploaded the revision in April and we haven't received any other feedback. uh So, as usual, we are open to receive the feedback here. Avt core reflector.

B

uh Just out of curiosity, what happens if the uh temporal and spatial resolutions in the TSR are are are greater than what was in sdp.

F

uh I I think we should receive a error message, so it's not accepted, so it should be basically a maximum of what is uh uh it's negotiated during the STP yeah. The the responder should not uh uh accept for anything more than that, but anyhow in the rtcp, the UE actually requesting you, each uh shall request only less than uh their resolutions that are negotiated during the STP negotiation.

B

Yeah, it's just useful to say what the receiver ought to do if it gets something that doesn't make sense.

F

Yeah, okay, sure I can update like uh that. You, uh the receiver Behavior as well sure okay.

G

Stefan I would I, would you know I I, wouldn't I? Would I wouldn't put sender-based constraints there um and expect them to be uh to be uh obeyed? I would I would just say what the receiver is doing. Yeah um I would write a rather something like um it doesn't make sense to send TSS our messages with with resolutions uh higher than what what uh rtcpe and what STP has negotiated and uh if anything like that is received, the the the receiver shot ignore it uh or.

A

At least never.

G

Respond with anything.

A

Higher than basically it's a double constraint, you'll never send anything higher than the STP constraints, as well as the.

F

A

G

F

If we can add that yeah yeah.

G

The uh the um you know the the it it the the burden should be on on the receiver to react on. In the spirit of that that we don't want to. You know, uh we want to be tolerant uh against stupid senders right. We don't want to have an application Crush, because some idiot doesn't read this line all right or doesn't read this shell statement and we don't want to get into non-compliance arguments either, so so just uh make it receiver Centric then it's!

G

No, then it's clear who is who is at fault if something goes wrong. Thank you.

F

Sure, thank you yeah. We can update that the receiver of the rtcp message shall ignore. If it is more than the negotiated resolution, special or temporal resolutions, definitely yeah. We can include that.

A

I mean I would actually I mean ignore, is sort of a little tricky, because I think you still want to send the tsrm um with uh you know, basically just never send anything higher that never send the tsrn higher than the or the media higher than the sdp. But if you just ignore that might imply don't respond to the tsrn, which means somebody would keep her interested in the TSR forever, which is a bad outcome too. So um I.

F

Would say basically yeah, so the request will be ignored, but there will be a tsar and message with the actual with with what has been actually been used uh by the sender. So the uh that special and temporal resolution will be included in the tsrn message. So yeah a message will still be flowing, but the request will not be accepted or uh acted upon. Yeah.

B

Okay uh Spencer did you get that for the notes.

C

I think so again um it would be. It would be great if somebody is looking at what I'm doing what I'm typing. There are six people in the in the meet Echo document and uh I'm not seeing things coming along, but anyone coming on behind me and changing anything I, don't know what that means. Of course,.

B

Yeah, so Serena boss have a look at what uh is in the minutes and if you clear enough.

F

Sure I can check the notes. Yeah I can check the notes and I can update it yeah. Thank you.

B

Soon Spencer will be I, guess talking so or is it Mathis.

C

J

C

I I really need to be paying attention to what I. My co-author is saying and not try to try to type the words down. Can somebody take notes for this.

A

James says he can cover briefly.

G

I am I'm taking best effort basis and.

A

Do you do your awful you're taking notes offline, not in the in the Head Start.

G

Yeah, please, uh okay, multiple screens here and and multiple sessions ongoing, not only activity.

A

C

All right, thank you, yeah. Thank you all.

J

Right so we have a couple of updates, since we last met in Oklahoma, um I I want to start with a couple of things we merged into the document since then, and then later, I have a couple of slides on issues we're currently working on or we're planning to work on next um next slide. Please ask first rdcp analysis.

J

We already mentioned this one in Yokohama we basically added a large table of um a lot of different rtcp packet types and subtypes, and for each of them we explained um if there is equivalent information that we can use from quick and for a lot of them. That means that we only have a entry in our table, which says there's nothing to be done about this, but we still include that because we wanted to make sure that we document what we considered in this document um done in the same PRS. Here we also.

J

D

Not even going to say something or.

J

Okay, so in the same PRC we also swapped the sections we had on rtcp before with the one we have now, but this is so it's all.

J

Rtcp analysis is still work in progress, because we still have a couple of open issues related to this uh one is that was mentioned, I think in the last meeting we had that we don't really consider that there are differences for um how we can replace certain rtcp fields in different topologies because for peer one-to-one connections that may be different than or from from topologies, where we have multiple Hops and quick connections between different notes in the topology and then the information we get from Quick is, of course, not the same as you would get it from rtcp.

J

So we will add some considerations for that, then the analysis just not yet include green metadata, I guess, depending on how fast that progress is, we can add a note for that. I'm not sure how much we can say about this, but it will probably make sense to at least I, don't know, as we did for many other rtcp fields that we considered this um then there's at the moment um there are a few sections which are duplicated because we have fields in our new tables, and we also had some text about that before.

J

So we added- or we should add references to that and remove some of the duplicated text and yeah I, don't know what the last point was on the slide, but anyway, topologies is similar. As for our TCP analysis, we added a large table for the topologies from RFC 767.

J

and for all of them we explained how well it works with RTP over quick. If there's anything to consider about that, and then there's again the related issue, which I already mentioned for rtcp, that we don't have good considerations. We want to talk much apologies with rtcp, so we may need to do some changes to the topology section here too.

J

All right next slide. Please.

J

Then we merged pull request about congestion, control terms and definitions. We added terms and definitions for these Fields here, like for delay based and low latency condition, control, algorithms for loss-based congestion control algorithm, and then we have explanations for what we mean when recycle a congestion, controller or RTP congestion controller, because we thought that makes it much easier to understand what we say about congestion control in the sections later, when we have clear definitions of these terms and- and we have a few more about congestion control on the next slides.

J

um Yeah, we explain why we don't make any BCP recommendations for congestion, control algorithm and the reason is basically that the choices often dependent on application or coding specific things. And we have a couple of references to different algorithms. But they are all informative and the references are mostly to the RM cut algorithms, which are all experimental.

J

And then we have a reference to the GCC draft, which is currently an expired draft from a couple of years back. And so we think that it makes more sense to have these as informal, informative references rather than as PCP recommendations.

J

Next slide, please.

J

I think this was the biggest change. We have the world congestion control uh in the recent updates. We rearranged the section A little bit and added edit some parts from the introduction to that section to more specific subsections, and we added a new subject section, which talks more clearly about resolving interactions between quick and application layer, congestion control and um explains issues that can appear when we have congestion control at different layers.

J

This talks about um what happens if we are application limited or what happens if we have um different kinds of contention, control in the quick layer that react differently and may have an impact on what happens on the RTP layer. There are still a couple of open issues for congestion control. The first two are about how to handle congestion. Control for um shared connections runs for shared connections on a single five to pull I'm, not sure how much we can say about that.

J

But probably there should be some consideration that um we or that that there could be impacts on the different connections depending on what congression control they use and the second one is um what condition control impacts there are. If we have media and non-real-time streams sharing one single connection, and then we still have an issue about where there are, where the real-time congestion control algorithms are suitable for quick specs themselves like if we would Implement any of these directly in the quick stack I think there may be some need to do some research on that.

J

um So we have this as an open issue and we'll work on that in the future.

J

Next slide, please, okay, stop sending! We already talked about stop sending in the last two meetings, I think and in Yokohama.

J

I already explained that the problem with status we need to somehow Define how to handle stop sending on sender site with um what what happens if the sender receives stop sending from the RTP receiver, because the receiver might send that at any time, because it's in quick, so the sender which receives stop sending doesn't really know um which stream does which Media frame on that stream?

J

Does the receiver actually want to cancel and the receiver might not know what is actually following on that same quick stream, so that could lead to a situation where the receiver accidentally cancels more media frames than intended um next slide? Please.

J

So now we added in pull request ADH, that um a review paraphrase RFC 9000 here from Quick, which says basically that a quick sender that receives stop sending must send a reset stream afterwards and it should not re-transmit any data that was declared lost.

J

And now we add to that that in RTP sender, which sends some media stream on uh quick streams should or must continue sending the media stream. But it must do that on a new, quick screen or generally will open more new quick streams anyway, and um that the RTP sender must not retransmit media frames that have already been transmitted on the previous quick stream that received the stop sending frame on new quick streams. That was something we discussed in Yokohama I.

J

Think, because if the receivers has a stop sending me that frame because it's too late, then the sender should of course not start resetting the same frames on new quick streams.

B

I just have a question about the I think there's an issue here about, like you said it, it's not clear what the receiver is trying to do when it sends stop sending so I'm wondering if you think the semantics are clear for everything.

B

uh I think we we basically said we didn't want to interpret application layer semantics based on the quick message, um but uh I I guess. uh The question is why the question is why you would send the stop sending. What is the? What do you think the purpose of it is and is is: does that make sense did just to try to cancel a frame.

J

Yeah, so I I think what we said in Yokohama is that we actually would like to drop this as a feature which we advertise in our document, because, okay, exactly for that reason, but the feedback we got in Oklahoma was, as I said, is that we still need to say something about substanding, because it is in quick and any quick implementation may send that. So we need to add some text that says how our sender should handle the situation.

C

A couple things as we're talking: this is actually a PRI road. So that's why I'm, asking or or uh or a lot of feedback on it anyway, um this one uh so basically uh I think.

C

We we for some value of we. We have been a little bit confused about um how you know about uh what stop sending would mean uh because in so let's say uh in HTTP 3, um if you say, stop sending I really have lost interest right right, but in in RTP.

C

That's not necessarily true, because you know what I've what I've lost interest in is not. This is not the RTP stream I've.

H

B

C

In getting frames that are up too old for me to do anything with right right, so the so uh so and I'm not telling I'm not trying to say that um stop. Sending is the right way to clear the queue basically.

B

C

So that so that gives the RTP Center a opportunity to start with the newest information. They've got so basically you get one big blip. Instead of you know, instead of a bunch of small blips, every time you get another uh uh RTP frame, that's just a little bit too old.

C

So, like I said I'm, not I'm, not it may be that we're we're conflating two different things in this conversation and I. Believe uh uh Mattis has a uh fascinating third slide on this uh immediately following, but uh I think that's one of the things that's going on.

B

um Yeah, because in in conventional RTP right you have uh you have the negotiation of RTX time where, basically, the sender knows, if it takes more than this, don't bother yeah um you allow through basically reset for the sender to be a little bit more sophisticated, maybe vary the reset times, depending on what kind of packet it's sending or or frame it sending. So you have that on the sender side and then I I guess yeah I mean you guys can think it over.

B

But the question is: what is: is there a role for stop sending and if so, what it, what it is um as well I mean.

C

I think that I'm agreeing with what you're saying, Bernard and uh I I think I I would not maybe even just add that um there's there's a there's, a role for an RTP receiver.

C

Explaining to the RTP sender uh that they need to change the uh Leading Edge of what's being transmitted uh and uh if or if stop sending turns out to be a way to do that. Fine, if it doesn't turn out to be a way to do that, uh we still have to explain what stop sending means.

B

B

Yeah I think I think the first line here, which is essentially saying that stop sending, is a way of suggesting to the sender to send reset streams.

B

So it's kind of a receiver initiated reset stream. I guess.

C

Yeah and I mean that is a I mean that and that's RFC 9000 kind of language paraphrase so I. That may not be perfect, but it's you know. It seemed kind of blunt about that.

C

You know it basically uh uses uses words like uh the uh reset. The stop sending uh triggers a reset string.

B

Right: yeah, okay, thank you.

J

um York is still in the queue. Do you want to add something or.

E

Yeah, so can you hear me yep um I I just wanted to offer two more uh additions to what Spencer said. um I see, Bernard Bernard I see your point about the RTP level operations, but um we shouldn't forget that um we have. If we are talking about streams, we have an undetermined amount of data buffered inside quick that the RTP sender doesn't really have control over.

E

um So you will not know when you're no longer in control of re-transmissions, and um this is a legitimate way to cancel any outstanding efforts, and we could of course do see this similar semantics of signaling a layer above. But one of the things that we try to do also is to reduce the amount of extra RTP, RTP and RTP CP signaling, um also in other places, so that we can make of the future use of the good use of the features that are available.

E

It stands to be validated that this is truly the complete and comprehensive semantics exactly of what we want, um but I believe there is a very legitimate reason for having this or this kind of mechanism, at least in mind, hope that helps.

C

Spencer just saying that Spencer agrees uh that what uh York's and was was helpful. Thank you.

B

A

um Yeah I think the um I agree. Obviously you know quick says: stop sending means reset stream, but the question is, if you're, sending a multiple frames per stream semantic.

A

What goes on your next stream, if you're doing a single frame for stream somatic I, think it's pretty straightforward, stop that frame send another frame, but if you're doing multiple frames per stream semantic. Where do you resume and that's the thing that's unclear.

J

D

Can we go back one.

J

J

So what we have in the draft now is that the sender that receives stop sending and knows what frames media frames that send on that stream should restart sending New Media frames on new streams, only starting with that Media frame that was not transmitted on the stop sending screen before because stop sending does not have an offset, and so we can't really have any mechanism that tells the sender I got until here and please start from that frame with new quick streams.

J

So we currently in the document just say the the I think best thing that I can do is to start with New Media frames that have not been transmitted on the screen before. Does that make sense.

A

um Yeah I mean I think it's obviously you don't know what the receiver had received at the time it sent stop sending. But- and it's not clear- it's not clear that a receiver can usefully do this for a multiple RTP frames per stream.

M

J

It is I think it is possible that the receiver accidentally canceled more frames yeah.

A

So maybe there needs to be language saying you know if the sender is doing, multiple frames for stream may not want to do this because you don't know where you're going to get.

J

Yeah we have that in the draft and okay good good good um yeah. We have a note that says it is possible that there's data on that stream following that the receiver doesn't know about, and it may accidentally be canceled by sending stop sending. So you might want to use other mechanisms. Okay,.

C

Yeah and and on on the on the next slide, uh one of the things we are kind of getting at there is how much the is basically. So, how does the RTP receiver tell the RTP sender what to do and uh if the only tool is stop sending, we may not be very happy with that for multiple frames per per stream um that, if that really turns into a requirement, it might be good to advance the to the next slide, because that's actually what I'm talking about, um but the.

C

The you know the base. Basically, this is why we have the line down there about uh using streams diagrams and pro RTP frame streams with you know, and even the uh multiple RTP frame streams, but not but being willing to uh close the stream and reopen a stream in a new stream uh in order to uh fast forward to something useful.

C

But all this all this is about. uh You know we, we know what the quick tool is and we tools we have available are, and we need to think about whether those tools can whether we can use those tools to do the thing we need to do or whether we need some other tool.

C

I'm not necessarily happy about that, but we are talking about the issue. You know, I think what I think the conversation we're having about the issues is correct and helpful. So if that's true, then you know, if that's true, we really need to to look more carefully at things.

C

E

I wanted to come back to what uh Jonathan said and maybe also add a bit on to what Spencer just said effectively saying that we shouldn't be trying to over specify at a very low layer, these semantics and applications you might try to implement.

E

We do have a need for a receiver to signal that whatever is coming on a given stream is so late that it won't be of use anymore.

E

um That is a very straightforward interpretation and the reaction to this, whether you're using multiple frames per stream in the first place, or whether you're, using just one frame per stream or, if you're, using multiple frames per stream. What your packing strategy then would might be heavily dependent on the application context. It would appear to be to me premature to try and embrace all these potential faults that the application might have um at that level when we are effectively trying to tell this stream is too late.

E

um If a Spencer alluded to us the tools we will require for some specific application users, additional signaling bits that tell us further details on how a sender should react. um That may be very well specify. Those um later on, but um it it appears too hypothetical to me to try and um cover all potential use cases, including their semantics at this point and that ain't gonna get us anywhere and because we will surely miss something.

E

So therefore, I'd like to stay a bit closer to the actual semantics of what this means to a particular stream and the remedy action may be obvious for some senders. It may least be less obvious for other senders. It may be a part of negotiation um that applications have performed before or of the implicit understanding, and so maybe I just want to try to prevent us from from from interpreting too much semantics into this more transport related mechanism. Here.

C

J

J

Part, we have one more open issue before discussing exactly this. How is how our streams being used, and what can we assume about that? And then we have one open, pull request which still fixes some of the wording we have from what we changed before and yeah. Then, let's continue with Max streams.

J

We also talked about that in Yokohama, and the problem from extremes is that receiver needs to give a sender in US, quick stream credits to open enough streams that can send all the media and the receiver needs to do that fast enough, and we don't really have a very concrete way to tell in the draft how that should be done because it's depending on a lot of factors. So we now added an example.

J

Calculation for one scenario might be like it was suggested in Yokohama, and then we also added a note that some signaling may be required here, because if the receiver doesn't know what the sender is going to send, then it's going to be hard to set my streams correctly. So, depending on what what the scenario is, there may be some signaling that helps the test.

J

Receiver, they're going to be so many new streams for so many media streams, so you have to open so many clicks or allow so many quick streams um yeah that that was merged in this pull request too um next slide. Please yeah.

E

This one is easy. We.

J

Added an acronym work for into the draft. We decided to use roq here because it matches what also DNS and media work with do so. That's consistent with what what's in their use.

A

um Is that pronounced Rock.

J

Yeah you're welcome to pronounce that rock.

D

Next slide, please.

J

Okay, so then, then we have a couple of One open, pull request, currently I think in addition to the one for substanding, which I already mentioned uh about error codes. This is the kind of work in progress um and, if there's an issue 76 which asks about error codes, which makes sense because we need to Define error codes for different um things, that can happen at quick um and then there's Issue 13, which has been open for quite a while, which also could be solved by adding error codes or using the error. Codes appropriately.

J

um I have two slides of error codes, which we came up with so far, but we, of course welcome comments on whether this makes sense and whether we missed something.

J

um I took some of these from other documents like HTTP, 3 and DNS over quick um I'll just quickly go through them, so no error could be used, for example, to close a connection or a screen. If there's just no other reason just fill in the connection, then I think General protocol error could be used for when there's no more specific one. uh That seems to be something that makes sense, because it's also in the other documents, internal errors, I, think also clear, um screen creation error.

J

We specify, uh in intersection about quick streams that we only use unidirectional streams. So if a sender tries to open a bidirectional screen to send RTP, for example, that could be used as an error code next slide. Please.

J

Then we have packet error for um inverted packet. Pedal formats with the payroll format is not compliant with what we specify in the draft for our RTP packets are encapsulated, or also for um non-rtp things that are sent um and, for example, the floor idea as a whole thing is not um format. Formatted correctly, then we have frame canceled, which would be what we just talked about. Stop sending an unowned flow ID in theory, I think we could allow receivers to accept any flow ID if they know what to do with it.

J

uh But if a receiver does not accept the flow ID or it was not negotiated for an RTP stream, then we could use this as an error code here and then signaling error is um for a situation which was described in this issues, 13., where, for example, if we do signaling outside of quick, which says that we want to use Quick RTP over quick datagrams, but then we open a quick connection which does not support datagrams. Then we need something to tell there's an error.

J

uh All right, yeah thanks.

J

um Then we have a couple of more open issues which we have not started working on yet but plan to do after we finish the stop sending PR and the error codes PR, we have number 50 with just ice interaction. We haven't done anything about that so far, but I think there will be later slot in this meeting, which may help I don't know but we'll see.

J

um Then we have issue 77, which is about extending motivation for adoption of prtp over quick, which adds a few more nodes to I. Think protocol overview or to the introduction for y11 would want to use either quick.

J

um Then we have an issue about reduced and Tu sizes versus extra packet considerations, because if we want to add quick X in the same packets as quick, datagram frames, then that would reduce the MTU in person and we might want to add a note for that.

J

Then, if we have small RTP packets that could be batched in single grid, packets may be helpful to have a note about that too um yeah, then we have a.

J

A

The batching would also potentially have latency issues right yeah, so you mentioned that therapy yeah.

J

Yeah um then, we have a couple of quick extensions which we already mentioned in the draft. We always said that none of them is required, but it would be helpful to have a list of extensions that um are mentioned somewhere else in the draft and that are helpful for different things um and then the using streams, datagrams and pro XP frame streams with work is what we also just talked about and stop sending um then the last two issues down here are things that we are not sure.

J

Yet, if there's something we can do about this in this stocks. In this document uh we have issue labels on these currently in a stock enhancement and not just rtps. So um we are not sure if we are going to do something about these.

J

um For example, multiple multicasts are still in development, and maybe that's something that should be soft enough in a future document, but we still have them open it on our radar, but currently no plan to do anything on this and I think that was all for from my side today.

J

Any further questions.

B

Okay, thank you.

B

So the next topic is an hevc profile for webrtc.

B

uh Basically, this the need for this came about because browsers are actually adding support for hebc, so in web codex. Api decode is supported today for Hardware. Only um and typically the support is for main profile level. 3.1 I haven't gotten a look at all the chipsets, so I don't know what other things are supported, but at least through cell level 3.1 seems very common.

B

uh Encode is a work in progress that will also be Hardware only and there's a Tracker bug where you can see what progress they're, making there's a registration page in web codex. That tells you what, in code options there are for hevc, because the support is Hardware. Only we've only looked at adding stuff that will be very commonly supported on different Hardware chipsets.

B

Some of the more advanced things like screen coding, at least so far, don't seem to be supported, so we haven't added it yet. But if you have suggestions, uh you can file an issue about the registration so now that uh the encode decode code apis are getting hevc support. The next question has been what about webrtc.

B

So there's a Tracker bug that tracks the progress on, supporting that it will also be Hardware. Only uh work is proceeding on implementing RFC, 7798, packetization and depacketization, but one question that came up is: what is the sdp that's going to be supported as part of that, so that's. uh They would need that in order to finally ship this and and get HB supported in webrt, you see, um there's no Guidance. The webrtc video document is RFC.

B

7742 doesn't talk about hvc only about ABC, so there's a little bit of a hole there that we're trying to fill in with this document.

B

So it's uh basically and what we're trying to do. We generally use the approach taken by RC 7742, um there's not a lot of guidance here, but basically it says you got to support the RFC 7798 format um and it requires support for level 3.1 and suggests uh support for main profile level. Four um and it requires support for receiving and I guess mini support ability to send so the decoder is required, but um the encoder is I.

B

Guess you could say optional, although presumably it would you get those once the encode support is in there um and then the question is what has to be. Parameters need to be supported in webrtc and obvious. One is the level ID and.

B

um Also, some of the same parameters that are in the AVC uh section under 7742 such as Max FPS, Max, BR, Etc, it's kind of the kind of stuff uh and then uh for the VPS, SPS and PPS. The same approach is taken as 7742, which basically says uh that webrtc implementations will signal the information inbound and won't put it in the sdp, um and that seems to be working okay so far for for ABC, so we figured hey, let's try it for hebc um and then uh there's uh the issue of video orientation.

B

Typically, this is done in Weber to see use using the CVO extension um and I guess it could be done in hebc as well. So that's the extent of the guidance that we have in there. Not it's not uh terribly much, but it's trying to get a minimal profile that would allow use of hebc in in webrtc.

B

Any any thoughts.

A

um I think this is useful to do I'm. You know trying to figure out if this is within our Charter and I think the answer is probably yes because RTC web is closed, but we definitely would want to raise it on the RTC web list, also just to make sure that the I think the list is so open. Even though the group is closed, so I.

B

Think that makes sense. I just uh thought the hebc expertise would might be more here. Yeah.

A

Yes, yeah I agree. The expertise is here about the you know that we need the browser side too. I mean the one quibble I'd have is on the previous thing. You must support receiving it. This. You know it's possible to build a you know a non-browser web urgency endpoint that doesn't support sending it doesn't receiving video at all. So video at all. So.

B

Yeah we could, we could change.

A

That that just switches words but I think yeah.

B

Yeah, so any other comments on things that you think have to have to be there.

A

I I haven't it's been too long, since I did in the atbc work, so I'm I'm worried if there's any other parameters that might be needed, but um I agree basically following the general model of ABC of don't use, S props and send everything inbound, especially things that can change anything that certainly anything that changes when a resolution changes needs to be invent.

A

A

People implementing it.

B

Yeah, well, they haven't gotten to the sdp stuff yet because they're still working on a packetization depacketization, but um I'm I'm, hoping that once they get to that point, they'll take a look at it and see what they think. Yeah.

A

Does anything need to be said about um if you actually support hvc SVC.

B

Well, at least right now, uh because it's Hardware only the the hardware. Support for SVC is really bad. Okay, um but uh yeah I mean part of it is just getting a handle on what the chipsets actually do. I mean.

H

If there was something that.

B

Did it we should probably put it in to allow them to do it. You know, uh but right now uh we're still um still sorting through uh all of the chipsets and what they can do there. You know the the problem Jonathan has been SVC. Support has never been high on their list for really any code. Yes,.

A

B

Sad but true right so yeah, I.

A

Know, let's see but.

A

Yeah I guess the other thing you know maybe you'd need to say is if there are actually like you know, common bugs and Hardware codecs that you need to work around with me. I don't know if.

B

A

Guidance for that.

B

There are a lot yeah, that's another topic that has come up very frequently and we have had to.

M

B

A lot more attention to that um and one of them one of the really bad ones that we encountered uh recently with ab1, was that um uh lack of support for spatial referencing in the hardware decoder. So we thought ah great, we've got this codec, we can do spatial ABC in the spatial SVC and the answer is Matt. You can't do that now so well anyway, it's it. What we did is we surfaced it as a parameter in the capabilities where you'd know hey. My receiver is busted. You can't.

C

M

B

So there may be a lot more of that: I'm sure that more of that will come along yeah.

A

And I'm not positive uh ITF document is the best place to track such things, but right right. Oh.

B

Yeah, it's yeah. Basically, with those things they're not negotiated, necessarily they're they're kind of transmitted out of band. Hey I've got a busted uh decoder in the following project: s yeah.

A

Yeah and in cases where you couldn't have a fallback of software decoders it's easier, but the cases here were like yeah.

B

That's something it's going to be, it's gonna, be uh you know, Less Pleasant,.

B

Okay, so I think the next steps is to uh uh notify the RTC web list and see if they have any opinions. Yeah.

E

B

I already, if there's any suggestions on changing the text, uh we welcome them yeah and.

A

Personally I feel like this: is you know you know good enough, for you know close enough to our in our Charter, so it should be fun, okay, yep and maybe mentioned that on the RDC website. Let's say we're planning to do this in Davis Decor, but if anybody objects to that, let us know.

B

Okay, all right, thank you, so we're gonna turn it over to Peter Thatcher.

K

Test test: can anyone hear me.

B

K

Okay, if, for some reason, my network connection fails which there's a possibility of that, then Bernard will be my backup all right. Next slide.

K

So a review from last time, I presented on how we can packetize s frame, not s packet. At the end, I was told to write a draft, so I wrote that draft yesterday obviously waited to the last minute and just to review.

K

It contains the ideas that I presented last time, which are to packet ties first, with the codec specific packetizer into one big RTP packet, then encrypt the payload of that using S frame then packetize that using the S frame, specific packetization defined uh in this draft, which takes the ssrc, timestamp and other RTP header values from the first packetization when making the packets in the second factorization.

K

um But it takes the payload type for S frame and puts it in uh the RTP header as indicating that it's s frame and then takes the RTP load from the first packetization and puts it in the payload for the S frame, specific uh packetization. And in order to do this, you need to negotiate One S frame.

K

K

Right now, I just put myself I didn't know if Linux for you and wanted to be on there, but they can be if they want to be um I, wasn't sure if there should be an introduction like what you and wrote previously with nysaski are describing the whole process of how westframe works. I didn't put it that in the draft, but we can cut and paste some ASCII art and descriptions.

K

If we want um it wasn't it decided how the package the depacketizer would know which packets go with the which s frame so I went ahead and put a Media frame ID in the draft, which indicates you know the RTP packets for the same Media frame, ID go together when depacketizing.

K

um There are different options for how the Deep packet, as you would know, the order of the packets within Nest frame and which one's the last I went ahead and put a frame or a fragment index in the draft. uh But there are other options and uh the question of whether or not we should put all the RTP header extensions in all of the S frame, RTP packets.

K

You know, for example, if there's a mid or a video rotation, should we put that in all the packets, for the benefit of sfus for now I just put all I just said all the RTP header extensions go, but we could refine that and then also the payload type, that's embedded in the S frame, specific RGB packet that is copied from the package, the Codex specific packetization um that I putting on all of the packets right now.

K

But if we wanted to, we could try and save a byte I guess, but maybe an S if he wants to know that buy it every time. So there's some possible discussion there, but next slide.

K

The big question is: do we want to adopt this draft and obviously people are going to want to go? Look at it. First I just put it on GitHub uh yesterday. So um that's the status questions comments.

A

uh One thing I didn't see: one question I know we had is: how is the sequence numbers being handled? How does the the packet has to figure out how to describe sequence numbers? Did you handle that or.

K

uh I didn't say anything in the draft about sequence: numbers I was just kind of assuming that it would increment as it went along just like any important.

A

Yeah no I mean I, think it's it's I mean incrementing, it went along, yes, but I mean I. Think there was something.

K

Oh right, right, sorry, yeah um on the depacketization side, when you feed in to the depacketizer the the assembled s frames, what sequence number do you use? Yes, I've.

M

K

Forgot to put that on the slide here, but yes, that is, that is another question you're right um anything in the draft at the moment.

D

B

uh Given all the discussion that we have had about, if I would be in favor of having an introduction and Peter, uh if you can look at all the best comments, they had on skip basically being unclear about the whole notion of Indian encryption, and you know.

A

Well, I think the fact that we'll have S frame that we can reference will make things a lot easier, but.

B

That that's true, but but I think the whole process may be. It may be worth having that in the intro to try to clear that up, because they also, of course, had lots of questions about how you packetize the encrypted blob. So it's probably good to have an intro that clears a lot up from the beginning.

K

Sure, I'll uh I'll pull over an intro from the one you and made.

A

C

Mean I think this is.

K

A

Know I feel, like you know, I drafted today old is a little early to adopt, but.

B

Yeah I mean I, mean.

K

So what should the next steps be like.

A

um I don't know I'll try to answer some of these questions that are still like. You know, fickly the you know, the ones that you don't have.

A

K

Ahead, I I put answers in the draft, except for the one.

L

K

L

K

Yeah and on the pre on the previous presentation, I provided like some options, he said: okay, there's a there's, B yeah.

A

K

I just kind of picked one for the draft at the moment.

B

um But I think you know the first step would be to get it submitted to the archive and ask for a review from the working group.

K

Okay, I could do that yep.

A

Yeah I think that's certainly.

K

A

K

My my next steps are add an introduction and submit to the archive and ask for review from the working group. The main linguist station.

D

A

Next presentation is also YouTube.

L

A

This presentation is also yours, I think it says your name on it, perhaps with us Peter.

B

uh Peter, are you here you're back.

B

We can't hear you Peter. Are you muted.

B

Well, maybe I'll I'll read this slide and hopefully Peter can get his audio back. So uh there was peer-to-peer quick, shipped in chromium as An Origin trial in 2019.

B

That was to be clear that wasn't ITF standard quick. It was G quick at the time which didn't have the ability to Multiplex srtp uh RGB TCP like like we've done 7983 this, but it was a prototype that that went out in 2019.

B

It was later evolved into web transport, which became a client server only, but it turns out that a bunch of the applications that uh were envisions for web transfer turned out to be peer-to-peer apps.

B

As an example, uh people thought that game streaming would be done, client server, but in fact the a lot of the implementations out there also are used not just for cloud gaming, but also remoting your game from your console to your at your mobile device, for example. uh Similarly, remote desktop isn't just from the cloud to your machine.

B

It could also be trying to get access to your computer at work, so it turned out that the web transfer doesn't actually handle a bunch of the use cases that were envisioned and they need the peer-to-peer stuff too, um and so, as a result of that, the original discussion about web I apis for peer-to-peer, quick is restarting um and uh and so the question there have been a few open questions about the implementation of the peer-to-peer, quick um in RTP over quick and so there's a few things that need to be discussed in the igf.

B

How quick combines with ice, um registering of an alpn value, uh defining how the STP works or really I'd, say also the authentication model for peer-to-peer, quick um and then some of the same real-time congestion control issues that have been discussed for Rock, um and there is uh some overlap here. I think the difference. May one difference is that peer-to-peer quick was the General thing it could be used for data or RTP.

B

It didn't uh really specify which what it could be used for um and uh the API by the way is very, very similar to What's Done in web transfer with a few additions um that are in the list of documents, basically to establish the peer-to-peer operation, it basically works a lot like dtls works, it's self-signed search and then uh in the signaling you verify the fingerprints, um so Peter says here uh it's important to distinguish between what's in peer-to-peer quick and what rock does um there may be some similarities?

B

There may be some differences um and I think the next slide talks about some of those can.

K

D

K

Hope so yeah what I meant to say at the bottom was basically like. Instead of defining certain things twice, I think we should find things that are uh the same and Define them once and if it's not something specific to RTP over quick, but rather more generic P2P quick, we should do the generic way that can be used by both RTP over quick and future other uses of P2P, quick.

K

Yeah, so if I, if I'm still working I'll, go to the next slide, so, for example, when you're combining quick and Ice, uh what we would need to describe are things like demuxing, using like the ice magic, cookie I, like Bernard just mentioned, using the self-signed certs with signal uh fingerprints, turning off quick migration, and then, if we have ideas for how to save a round trip when using ice and quick together, um I put some there. But these are things that are an overlap between uh RTP over quick in.

A

Which is in the RFC, editor queue, so good news there, um but okay, all right, yeah I.

K

L

D

Is you have to turn off.

A

Yeah, the main thing is you: you can't use the um you can't Grease the quick bit. You have to actually set the quick bit because that's the debug's point, but that's easy enough.

B

um Peter, are you back.

K

A

Here are, you, are you? Are you here, I have been hearing Peter? Are you hearing Peter Bernard.

B

Not right this second, but I was hearing him before. Okay.

K

Yeah I guess I should just keep talking until.

B

I

K

Yeah, sorry, uh okay, let's move on to the next slide, so the aopn will probably be something like q2q or peer-to-peer quick or something like that. uh It would not make sense to have any more anything more descriptive than that, um so the question would be if potentially, someone wanted to implement RTP over quick on top of a peer-to-peer quick web API. Would it make sense to have a different aopn for RGB, real quick, or should we just have one LPN when doing peer-to-peer quick.

A

B

First, yes yeah, so my question is: uh are we? Are you thinking Peter that peer-to-peer quick? Would it be only be a browser thing? Because um and and what is what is the meaning of saying what would be the difference between that and rock? For example, I guess Rock assumes that the quick is kind of compiled with the r2b stack into one application.

B

Would using the alpn q2q mean that that would not be the case I'm just trying to understand that there's this there's some kind of difference between the two APNs in terms of how how they could function.

K

Well, the way I the way I was thinking it could work. Is we just Define one alpn to mean we're doing ice and quick together and okay.

B

K

Peer-To-Peer quick and then RTP over quicker, just build on top of that, but still use the same aop and not have a separate one so that you could Implement rtb over quick on top of this and not have to worry about AP aop and incompatibility I.

B

Q to Q is this: it would be used for both native and browser.

K

Yeah, if you wanted a mobile app to talk to a web app, you would use qdq or just keep it the same for native to Native mobile to mobile, whatever I, don't see any reason why you wouldn't just use this aopn all the time.

A

Yeah I mean the main reason to have an LPN is to be a debugs play for something and I don't see what this would be just for the DMX flight 4, because this is also been by definition. This is all something that has to be fully negotiated before you actually even start the quick connection so.

B

Question would be uh like if you register q2q you could you could do RTP over quick, but you could do something completely different and I guess.

D

I guess that's to.

B

Be qualified by the signaling right, not by the.

K

Aom, yeah right we're never going to have a situation where a web app is going to choose the aopn. So we just need to pick something. But if we want a web app to be able to implement something like RTP over quick, then we can't rely on using the aopn.

K

But if we don't, if we don't care about RTP over quick ever being implemented on top of a potential um peer peer-to-peer, quick in a web browser, then I guess it doesn't matter. It was just something: I wanted to bring up as an overlap between the conversation being started now and RTP over quick.

B

J

Yeah I think it's good that you bring it up, because if you want to do, for example, RTP or click on top of uh peer-to-peer, um we should uh yeah. It should be possible I guess, but we should- or we might want to add- that to RTP over quick. Then too, so um not only just Define something somewhere else, but maybe important to have that in our document too. So because currently we say that I.

D

Think we have RTP.

J

Max quick, which says this is for multiplexing RTP and whatever other protocol using the slow ID and if you use RTP, Max, quick IOP, and then we expect this wire format and we Define something else for peer-to-peer. Then that may be important in our document too.

K

Okay, well I think I'll just uh keep going here. uh Next slide.

A

James, did you have your hand up.

B

M

I did um I'm I I. Don't think that the aopm is the right place to be putting the signaling of this is a peer-to-peer thing and and not a usual server, client interaction. This really needs to belong elsewhere, but I also recognize that trying to extend uh quick itself to support that would be kind of difficult because you're conflating both the peer-to-peer aspect and the RTP in something that really should only be handling one of those.

A

Yeah I feel like there's a way in which the alpn semantic is designed for the HTTP use case and I'm, not sure it semantically matches what we're trying to do here very well. So you kind of just have to put something there and then do the things we actually need at some other level.

K

I mean it's either that or make a make it a part of the web API to choose the aopm, but um that seems fro I, don't know that that seems right, yeah.

K

Well, anyway, uh in the interest time, I think I'll skip to the next slide. Yeah, um so I just wanted to this would not be part of the web API because we do not want to move, have more sdp in web API. But uh if you wanted to use sdp to Signal, um peer-to-peer quick I think that it would look something like this, where it looks almost exactly like when doing ice and dtos together, except that the the string for what it is I forgot. What that string is called is different.

K

So it's UDP, slash, quick, it's all the same attributes for ice and the um the roll on the fingerprint next slide and then I even thought. Okay, if you wanted to do it together, then uh with with RTP, you could just stick in uh RTP parameters there and so I I don't actually know what sdp have come up with for r2b over quick. If you have any sorry, but um it did, it didn't seem to me that it would overlap.

K

Much I mean sorry, it wouldn't conflict much, but we could, if we wanted separate the definition of the pieces that are for uh peer-to-peer, quick and those that are not if we care to for the web API, like I, said we don't need to define the sdp at all. It's just one of those things. People always like to have they like to have some STP.

C

um This this is this.

K

C

So uh a draft on uh sdp for what is now Rock uh I stopped doing that, because the functionality that uh we had defined for rock so far was not. It was. You know we had not defined enough of the functionality and we did not have consensus for enough of the functionality to uh justify trying to do to maintain that in parallel.

C

So uh this is but this is definitely something I'll be interested in talking about uh fairly soon, because I honestly I've been uh helping with uh RTP over quick and uh waiting for us to uh do the uh you know the ice interaction thing before I move forward on that.

K

C

K

Think when you worry about it conflicting.

C

Now but let's let's worry about making sure it doesn't conflict of the future.

K

C

A

Can take that one.

K

Of them is that good.

A

uh I was gonna, say you can take a look at Spencer's expired draft. Even you know just for this. You can see what his ideas were when I'm like the UDP quickest idea. So just more or less matters. What you have here so.

K

Well, it's all it's almost exactly the same as what webrtc does with ice dtls and RTP together yeah.

K

um It just just happens that you can also send uh data by itself without having sctp in the mix kind of um so the only thought I would have. There is if we get to the point where we're going to Define these, it might make sense to Define in two separate drafts, uh one for the peer-to-peer, quick things just ice and quick by itself and then a separate one for RTP being added on top of that, so that people that are doing just peer-to-peer, quick, wouldn't need the RTP parts.

K

um But I guess it could be two sections in one draft. I, don't know.

K

Correct I just wanted to make it make everyone aware that it might be useful to separate out the non-rtp parts of quick plus ice right.

B

uh I would point out that this similar kind of question has now come up in the re-chartering of the wish working group where people have raised you know, there's the whole RTC data chat, the webrtc data, Channel signaling and people have wondered how do I signal something being sent over the data Channel, for example, if media is being sent over the data Channel, because today the webrtc data channel is just generic like what Peter had for the you to be quick right, it doesn't say, what's being sent over it, uh but in which the need has come up for maybe trying to specify that more like extending it like what he's describing here so I think this this problem has come up.

B

uh Rtp might not be the only media that gets sent over this. This uh Channel, like, for example, in webrtc data channel cmap, gets sent over the data Channel very commonly anyway, so I think. There's there's something in common with some of the issues discussed in which year.

A

Peter, will you not hear you at this point.

K

uh The other piece of overlap is the real-time congestion, control thing and uh I think we should try and solve this for everybody, not just RTP, and so um basically.

K

Adopting or requiring an extension like uh the one I linked here and then somebody needs to Port something like CC to an implementation of quick and see how well it works. uh It's on my to-do list to keep trying that, but I haven't done it yet so, but I think that effort should be done in a way that is not just for RTP.

K

Or I should call it Rock now right, not just for Rock.

K

That's it. That's my last slide.

A

Pornography, or are you wondering.

B

C

Yeah, uh so um I, so um Methodist and York and I have not uh cut a new version of the uh Rock draft. uh Since you know, since 116, we expect to do that before 117.

C

uh and if we weren't busy closing PR's uh the last couple weeks, we would have probably done it before this meeting, uh but uh just too bad, possibly to encourage people to think about what they need to be reviewing. uh One of the big things that we had in the Rock draft was ideas about what uh what should be going on.

C

You know, basically, what quick should be doing for uh uh for uh real-time media and um uh we so I've been trying to uh be clear, be clear about that and to make sure that we were not over specifying that um because there's, you know from my perspective, uh there's still a lot of unknowns about uh world-time uh congestion control, and uh you know for media and interaction with that uh of that with other uh kinds of traffic that are sharing the same network paths or quick connections or whatever I.

C

I was not following uh our cat as much after Maria took that became she joined the isg, and uh you know she got that working group because she knew more about it than I. Did I've been the I've been the ad for it, but she'd been the chair, so uh I don't know everything that I would like to know about.

C

The armcat algorithms, but my impression was that they had done a lot more work on making sure you were not self-congest uh congesting uh than looking at how you were interacting with other congestion controllers, especially uh for congestion controllers that were not. You know for that congestion controllers that were not being used for uh real-time traffic, so I, I, really I'm. Sorry, I'm, not clear on this um I think.

H

I'm more clear than what's.

C

Coming out of my mouth, but I think that what you're what to do is a really good idea, um I think it's I think it could be consistent with the uh Rock draft, uh and if it's not consistent with the rock draft, uh we should probably have a conversation about why that would be different, so I I would encourage you. You know I would encourage you to continue thinking about that. I would continue to encourage myself and the uh other Rock folks who've been uh typing in the draft uh I would encourage.

C

I would encourage uh us to have a conversation uh more. You know have conversations about this, uh but I. Think I, think that specifying this once for real-time, that is not uh restricted to RTP is a good plan.

C

Thank you for thank you for raising that.

A

um So yeah I guess my main question is I mean I. Think where do you see this work actually being done because I think this is you know it's important for Abt core to be aware of this, for the rock but I. Don't think this itself is in scope for Abt core. So you see this in quick, proper or some new group or w3c or what.

A

Yeah Peter I'm hearing background noise, but not you.

K

Oh sorry, uh that maybe did you were you, did you mean peer-to-peer quick in general.

A

Yeah, quick in general, yeah.

K

I, don't know where the right place it should happen is um if it should, if we should make a new working group or what kind of like we did with web transport.

K

um I don't know, that's a good question.

C

So uh I and I apologize for jumping in and I I I was I was aiming to click uh the race hand, thing and managed to close my window for um meet Echo, so I missed about the last 15 seconds of what Peter was saying or I missed about 15 seconds of what Peter was saying.

K

uh It was a good question that where we should do work for peer-to-peer quick, um if it's not RTP specific, does that no longer fit in avt cord. If not, then where should it go and I don't know the answer to that? It's a good question for web transport. We made a new web trans working group and maybe we need one for peer-to-peer, quick, I, don't know.

C

So um I am not current in the past week about uh how about what the charter for uh the uh congestion control working group that's uh in the process of chartering I'm, not quite sure what their Charter says right now, I, don't know if that would that might be a place to have this conversation I.

A

Mean the conversation about the congestion control, probably the conversation about peer-to-peer, quick in general. You know I, don't think so.

C

A

um Yeah and I mean maybe it should be, I mean my. My first thought you know would be take it to the quick group itself and see what they think if it's small enough, that it can be done in quick itself or whether it would need a new working group.

C

Somewhat amusingly uh I think quick would have I I the 80s, the the transport IDs would be the people who would know this, but my.

H

C

Was is that the quick working group would probably have to re-charter to take that on, but but but Peter has raised a good question and all we have to do now is figure out how to answer it.

A

Yeah, obviously, the web with the web API parts of it are in the scope of w3c right.

K

Right or would be, we still need to find the right home for that too.

K

But you were saying the congestion control part of this might be done somewhere else.

A

There's a new congestion control working group.

B

A

Which yeah I'm not sure how much this is what they're initially looking at versus.

C

Not for real time.

A

Specifically, but um for but not the real time is out of their scope.

C

Right right, so uh what I was trying to say was I, don't know, they've been they've, been uh in the process of chartering since, before uh 116.

C

and uh and the last time I looked, which has been within the last week, they were still in the process of chartering, so I don't actually know what's in scope for them, because that's and you know until the charter is approved, you know I'm, not sure I'm, not sure who knows, but um so I'm not saying I'm, not saying that that's a good place to do that. I'm saying that it's a good place to consider whether it's a charter for them uh well, whether they think it should be in Charter for them.

C

K

The name of the working group.

C

Conveniently it's the congestion control working group, it's one of the ones, that's not being renamed after that. Yeah.

C

I'm not sure what else you could call it, but that's what that's that's what it says in the data tracker yeah.

A

I think all the clever names were turned out to be defense. You know mean something offensive in some language they gave up and called it CCW team.

A

All right, yeah, so I think this is um important work. um You know the rock people should keep an eye on it, but I don't think the core of the work is in scope. Here, obviously, pieces are and it should you know, influence Rock, but I. Don't think we would need a draft Beyond Rock just that this draft needs to keep in scope, and you know to be authors of rock. You need to keep an eye on this and hopefully stay in sync with it and contribute to its requirements. Wherever that happens,.

A

D

A

A

All right, in that case, we are done. Thank you. Everybody thank.

B

You everybody yeah.

A

C

So Bernard and uh Jonathan uh I I, captured as much as I could in the votes and I'm still uh making updates. So uh don't don't cut and paste them into the data tracker. Yet all right, but.

B

C

You I'll be finished in probably 30 minutes or something okay,.

B

A

B

Stefan also had some notes: I don't know if you forwarded them to you Spencer, but I.

C

Will follow them? Yeah, I, I, haven't I, haven't been able to uh confirm or deny that yet because uh he was uh I.

A

Think he said, oh no, he did send to you. Okay yeah. He sent to you boo, hi.

L

A

To you, Spencer yeah cool is a global 10 cent. I think that's your email.

C

Oh God, no uh uh Spencer Dawkins at uh it's Mr Dawkins at uh uh Spencer doc, has got ietf gmail.com, okay, the the yeah, okay.

A

Yeah, it's an old email. He had an old meal, that's true! I! Guess all right!.

C

Cool, thank you yep all right. Thank you. Bye.

A

D

D

D

D

D

D

D

D

A

A

A

C

Yes, I've been I was too blessed to uh put my stupid. Take my stupid, headphones off.

C

I'm trying to finish something while I can still remember what was going on, because I was also taking notes. Did I tell you that huh yeah uh yeah uh this is when I, when I got silent, a reasonable question would be.

D

D

D

D

D

D

D

D

D

D

D

D

D

D