Internet Engineering Task Force 105, 23 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-AVTCORE-20190723-1710

Description

AVTCORE meeting session at IETF105
2019/07/23 1710

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

A

All right, it is five tends to only have an hour slot. Let's get started, welcome, David décor, I'm Jennifer, mrs. Rachel. We have Magnus being jabber scribe.

A

So if your remote either join the medical queue, if you want to speak to us using the protocols we invented or have Magnus relate, if you want to do it be a protocol, some other ITF working group admitted James, James crusing is don't take her back there he's doing in the ether pads. So if you want to look, you know also join and correct any typos. He has or anything like what I'm sure he'd appreciate it.

A

Blue sheets are going around, make sure you sign them and we have a medical, remote participants. So when you say anything make sure to use the microphone so that they can hear you and we can have you on the recording. So we can figure out what you said later.

A

Nowell Nowell applies make sure you understand this if you're gonna say anything or stay quiet. If you don't understand it.

B

Somehow we got a bit of Chinese over that, but I don't think that's a big deal. Okay,.

A

So so now you can so under, so you can understand that well in Chinese. Also alright. So today, I'm starting with this agenda bash talking about various of our working group documents that are not in that are not the amount of specific agenda items. Then we'll have 20 minutes for Colin to talk about our MCAT CC feedback draft and then we'll be handing over to Ronnie to talk about the status of the payload working group, which is our close sibling working group and then we'll finish with anything else.

A

Anybody wants to talk about anybody have any comments on that agenda. It's a fairly standard agenda. We just copy and pasted from session to session.

A

What's up a OCB okay, so he gives me this okay telling that something cuz I feel like. It feels okay, cool working group documents: a number of things are still in cluster 238, which allegedly will be clear, real soon now, I'm sure that we very exciting, especially if you're the RFC editor and frame art and lrr so awaiting on frame working. So first item is multiplex guidelines, which I think Magnus said he has enough to talk about. So you want to talk. Instead, that's.

C

So, yes, we finally updated the update the comments, not quite done now. You submitted the drafts and people could review what we talked so far. They're still I would wish that somebody looks and I think includes some of my co-authors.

D

C

Look at these questions of mailing lists and then was about to say: okay, if they have anything, was safe about those. So.

E

B

Does a co-worker.

E

Who has a close with the draft referral services? It looks at the questions in the mailing list. Animal toy. What changed in the draft and I didn't really have anything that the draft seem like a reasonable response to the questions. I.

F

Live it to serve.

G

A

Right so then frame marking you talk, you know how long this has been around. It's a Navy TX draft, which was a working group that hasn't existed in several years. Now that MOCA meeting said they know. So we thought we were going to go. Do a pub wreck on it after the last IETF and then a bunch of more comments were submitted on the draft which I asked the authors to respond to which they did not so I spoke to the author yesterday and he swore to me that he would respond to it.

A

I'm not, but I will probably need to nag him a few more times, but hopefully we'll be able to clear those up relatively quickly. If smoke smell comes in. We will try to get him to commit to that at a microphone, but maybe he's smarter than that, and not bothering the event.

A

And then people, if CC feedback, is the main agenda item today. That's it. Okay,.

B

A

There he is moe, perfect timing, you thought maybe or you're going you. You thought you could wait until after we were switching so yes, so frame, marking.

H

And it still had some comments that I think needs minutes all of them. A lot of the comments. I think we can clarify and explain, but there's going to be a few, that the draft clarify texture again.

A

When do you think you could have that clarified by the end of this week? Okay, okay, so at that point, do we think it's ready for pop rock or do we need to the.

H

Authors do have much feedback to the sites. Okay,.

A

I mean basically I. Consider that to be part of working with blast calls so I think I, don't think, there's anything that would require a second work last call or anything. As far as I know, there's been no major technical changes right.

A

It's kind of supposed.

H

To just clarifying text, okay, the only thing would have been a major technical changes. uh So one of those comments- this is around getting guidance about how to use these things. I thought we decided as a hooker earlier that this will provide guidance. It wouldn't be normative and how a message you should operate gives the tools and it's up to implementers to decide because there's so many different implementation options. Press use well I think it's the first to get guidance about.

H

To do certain things all.

A

D

C

D

As? To which scalability votes.

C

H

Compatible with yes, the when you say scale, blending modes, I think you mean the restriction that it only works for nested several layers.

D

Right, like yeah in particular, I know what I'm thinking about is like if I look at all the weird scalability, both the maybe one, surely there's some set of those it would not work with and well.

H

As I'm sure you're aware, Bernard anyone doesn't plan to bring to peel a draft to this working group and does nothing to use the free marketing draft at all.

D

H

D

The weird thing is that the Weber.

H

C

Facial spray, marquee.

D

Unless it's ripped out so anyway in that in that in in trying to figure out that question, how you would implement free marketing with everyone, that question has come up. Yes,.

H

I agree: it's an issue, but I, don't think it's an issue that that this draft can solve I think it's a larger issue that the media would have to bring that into work at diets. You have to be able to do.

I

Something about it.

J

Don't go away, I heard you heard it I heard that this is not going to be in a book, because Carla asked.

C

H

It's complicated, there's, no, no one has been working towards a public draft in the ITF on anyone, yet my knowledge she was working on it. So.

H

Don't say you guys some some guys decided not.

H

That's that's an open question too about whether how would you register, Omega and I know registration disaster.

D

Yeah, what I'll stay, though, is the same question that arise for benign and then because.

C

D

Now supported in vp9, so even if we keep baby one out of scope, there's still a question about the implications of negotiating it. For vp9 I mean.

A

Most periods already supported non temporally, nested temporal layers, so I think they're. Just the the thing in what frame marking says is if you're encoding in a way that's not compatible with this spec dump. What frame markings on it.

H

So the real restriction is that, in order to be able to understand what's coming in the stream and SS, you would need a lot more. A lot more elaborate information than the frame marking provides, maybe even more that could reasonably be signaled. If the scale data structures are unconstrained, it would it would you basically have to have a full dependency tree, all of the prior frame until debris, the last night, which is unreasonable to say so, without constraining scalability format without having some fixed scalability layer information, it becomes very difficult to have so I.

A

Mean I feel like we just remarking just needs to say is this is not capable of expressing every scalability mode that the codecs support. Therefore, if you're, if you're encoding a mode that this doesn't support, you must not put trademarking on it, then maybe that's so. You.

H

Might already say that, but we burn our doors, is that okay is, that is that too much of a constraint for real implementations? Well,.

D

No I I'm not asking that question because I'm just asking, if you can make enough of a statement in the document, so it at least it's clear what modes would be supported or not. We can figure out what the implications of that are. There probably lots of situations where the supported modes will be sufficient for a particular application, and then they can turn on frame marking and you know, use it to the hours contact.

A

Yeah all right so I think that's it for frame marking and let's get to CCC feedback.

A

Did you have the no.

B

No, they didn't do that, all right, so Tuesday, yes, Tuesday afternoon three, there.

I

B

Can yeah I think so, but we didn't hold on see? Who are you that there we are.

E

Will that work, what we can work is amazing, all right, I'm, glad to see we have a working good chair who knows how to work the Chromebooks because I, certainly don't ok, so hi I'm Connor can't talk about the RTP congestion control feedback draft.

E

This is a draft that is joint work with ahead and Varun and Micah Romero. Some of these slides and I think most of the changes. This time are all my fault, though. So blame me for all the mistakes.

E

Okay, so this was discussed last meeting. There was a bunch of people, Jonathan and I. Forget who else three or four of us were playing at the hackathon in Prague, give a bunch of really nice feedback on this draft. We had some discussion of the last meeting about what to do about that and I've submitted the zero for Russian attitude. To reflect that experience, you will be pleased to know there are no changes whatsoever to the packet formats. We've done. It's made a bunch of clarifications to the text.

E

Ok, so what have we changed? We have added an example of how to use the rtcp feedback attribute on the basis that both myself end up is one of the implements has got it wrong when when I was writing the draft and when it was being implemented. Hopefully what is on the slide is now correct and if you're on a Greece, that's right way of doing it, but there's no us on example in there. So, hopefully people keep agreeing that this is the right way of doing it.

E

We've added a clarification that, if you've negotiated, if you see or retransmission, then you should send a congestion control feedback for the fake packets for the retransmission packets. Since this, it's all things which are being being transmitted and contributing to congestion, so you should send feedback on itself.

E

We clarified that when you're using the STP bundle extension, the congestion control feedback, signaling matches the rest of the ACK feedback for a TCP F, the rtcp AFB attribute, which is s which is identical per payload type. According to the draft STP, but MUX attributes, it's fine entirely clear what identical payload type means night-time it clear to me what identical payload type means when you have a wild-card payload type, but that's something we should clarify I, guess in STP MUX attributes and they did send email to their music list about that.

E

But no one replied on that, but they were a music worried about that and we're putting. We have a long discussion of the last meeting about what should happen. If these, the off the SDP offer includes several different ways of providing congestion, control feedback and the drafter now says, the receiver should pick its preferred mechanism and use that consistently. And so, if you get a rien vite, you should, where possible, reply with the same mechanism in terms of the actual, a TCP congestion control feedback. Again we didn't change the feedback at all.

E

We put in some clarifications. In particular, we we put in some text that says if you send feedback, which indicates that some packets are lost. That is not an explicit request that you retransmit, that the sender retransmit those lost packets. It's just an indication that those packets were lost on this is affecting the the state of the congestion, so this doesn't act as an explicit neck. If you want, if you want so next, you should send max in the same way.

E

Equally it doesn't prohibit the sender from retransmitting those lost packets, if it says, negotiated a retransmission packet from that, but it doesn't explicitly require it so, as usual, a sender what, if you have retransmission, enabled couldn't choose to retransmit any or all of the packets it feels like, and we put in a clarification that, if you configure your, are TCP bandwidth fraction Wiggly, you may end up having to generate some.

E

Very large congestion can draw a feedback packets, in which case you may have to split it across multiple, our TCP / rtcp packets, because it won't fit in the MTU.

E

My advice, that is, don't do that configure your a TCP bandwidth fraction, so you put in enough rack in enough feedback band which the seminary costs more often, and it won't be an issue yeah I.

A

Think the section this came up with in the hackathon, because we, you know one side- wasn't sending feedback at all so that the other side was ramping up. So still, basically one side was successfully ramping up to several megabits. The other side was still stuck at whatever it's the minimum. Its minimum starting rate was so. It basically was making its artistic came back bandwidth, its practice media bandwidth, which was still stuck at 50 kilobits or something so yeah yeah. Yes,.

E

So if you do something dumb with the amount of feedback you're allowed to send, then you will have to generate large packets and it will go wrong. Don't do that. We added a section on congestion response when the congestion control feedback packets are lost. Now, what this says the important bit is it says that, like all our TCP pay, packets, the congestion control feedback packets are unreliable and might be lost.

E

Therefore, if you're designing a congestion control algorithm, you must specify how that algorithm response to loss of feedback packets and we then added some advice which says well, if you just lose one feedback packet, you should probably assume that things haven't changed significantly and carry on at about the same rate you are you are sending before. If you keep losing feedback packets, you go for a long time when you're not getting congestion control feedback.

E

This is probably an indication that that either the forward or the reverse path has failed, and you should be fairly aggressively ramping down your sending rate and the circuit breaker has some guidance there, which suggests you should stop sending after I forget how many, but after some number of error, reporting intervals without getting any feedback. The.

C

E

Though, is that the congestion control algorithm should specify what it should do and that should be to to ramp down fairly aggressively.

E

So that's it. I have new technical, open issues with the draft of non technical issues which is still to do are to add a comparison with the Google draft and explain the design, rationale and various trade off various design. Trade-Offs of the two approaches, and so I have some discussion on how you convert between the per SSRC sequence numbers, which this uses and unified sequence numbers which the whole my draft users just just as part of the discussion. That was the different trade-offs there.

E

So I hope that we will have that already for working group last call long before the Singapore meeting, so we've been here before, but hopefully we're really getting there. This time, money.

J

So just a question or Anya.

C

J

It's a question: is this a different behavior than if I suddenly stopped receiving our DCP messages, if I don't receive any congestion control.

E

So if you stop receiving our TCP recent surveys,.

J

You know most of the issue that the congestion control people like it's almost okay, yes, but that means that, is it different behavior from the receiver of the RCP feedback that feedback, then, if he doesn't receive other rtcp messages, I.

E

Mean this, this draft is about congestion control. So that's.

J

Why do you doing here not taking something it was the normal.

E

Behavior in these.

J

E

Rfc 3550 doesn't say anything about what happens if rtcp packets stop I.

A

Think that was really the circuit.

E

A

C

Generic guidance.

E

This draft is specifically about congestion control, so it gives some specific guidance relating to congestion control, but you know I mean I, think it's generally good practice that if you know if you're sending packets and the feedback stops, it's probably a sign that something is broken and you should. You should stop sending very.

A

In the very weird circumstance, and if you stop getting any CC FPS but get all other rtcp, probably somebody's watching, you attack on you usually weird.

G

E

Okay, anything.

B

E

A

So you expect to have that draft out. Sometimes.

E

A

The summer yeah, before your run, yeah.

E

Before the students get back, is my plan.

A

And Ronnie, how do you wanna handle this.

A

And yeah anybody not get a blue sheet Justin. You came in late in oh yeah, sorry I, don't mean to pick on. You well came in late to one another. Stellar's, there's two going around so there's one the other ones up here. So Justin, that's the only one! That's convenient. Does anybody right now, I think Colin was raising his hand for blue sheet and.

J

Okay, as as in the last meeting, we are just trying to provide to take this opportunity and provide just the information, the status, the status of the payload working group. The presentation was done by me and by Ali my culture who's, not here at the meeting next slide.

J

So since the last meeting, we have RFC 86 27, which is the flexible faq published, which was needed by the RTC web, and we are happy to have it already did that. Thank you more there's draft does the t's. This vc is tailored to publication on february, and the ad change will Mar. So we are hoping that we will start were looking at. Did this one because there's no other thing next night, so the world of documents there's the Tetra, the tetra payload. That was ready. This one was strange because it was registered.

J

The the payload would register by group from Etsy in the middle of our development cycle. The auto claims on May 19 that they made this year that they want to proceed, but they never did any update on the document. So I need to ask it again because it's expiring, the JPEG xx XS.

J

There were comments on the list and the author will submit the new revision bed with the conclusion that was last last messages were from last month's, the 50 ml. This one, the media subtype, was registered by w3c, and this document specified the RTP payload 48 ml.

J

We had a working class call which ended of July 18, but there were no reviews in the past before that. Well, he w3c reviewed the document before the one who press call and- and they were ok with the textile acident again at least to send a message saying that that's ok for them to to continue. If anyone would like to review if it would be helpful, the only one the only one document that still open vp9.

A

Some speaking as an author that I meant to so I mentally do a refresh of the document after the last one, but I didn't so, but I did talk to Justin earlier this week and basically he asked me to turn the various two dudes in the document into actually open issues, the github repo which I have done, and he says he'll find he'll convince the other co-authors who I believe worked for him to do something like that.

A

The one as I was doing that I realize there was one actual technical, open issue, which is that the way we have SLI defined doesn't actually work with a special scalability.

A

It may be that nobody cares about SLI I believe that it's not it widely believed was implemented in WebRTC stacks, for instance, so the answer might be to say not supported, I, don't know if anybody has any. If nobody cares about SLI, that's probably the easiest thing to do, because it's all. Obviously it's a lot easier to add it later. If somebody says, although I needed after all than to try to fix a broken definition, does anybody have any opinions anybody ever use SLI, throw it out yeah.

J

K

J

J

A

On throwing out SLI- and you know I think I believe they've it up. There's another minor change to the draft which one of my co-authors check into github, but which I saw like a nerve that this week, the other ones it depends on how quickly justin can look the other Walters.

F

Justin you ready Google I, think if you folks on vacation right now we're co-authors but I, think that right time frame would be before 106, okay, I think before 106. Yes, we all want get the saga bytes.

A

Yeah, all right and given that it's been shipping in chrome, for like three years now, we probably ought to have a special for it. Okay,.

F

Is there an official so we could have repo for a VP for organization no.

A

This would be payload, but I, don't think we don't.

J

A

Yet now so I can stay in there as an author, because.

J

Everyone is doing their own stuff, I mean it's like every document comes from a different group of people. I mean it's not like. There's some regular people who were here in pain. Oh do you know you come into the payment, then you go away from from that. Okay, that just to say that there are no any there, no, no individual graph that waiting to become four new payloads. So this is the all the work that we currently have at the moment.

J

Any questions comments. Okay,.

A

If not, when we managed to finish in half an hour so go us accepted I. Think by believe that car Colin had some other business.

E

I'm sure many of.

E

This group was originally.

C

E

By Steve Kozma.

C

E

The group was founded if I have check my words correctly over between second IETF sense of faith in 1891 and Steve steps down in 1857 back in 2003 Magnus delivers. Yes, you would be pleased to hear that it has not any fewer who founded the music working group will be awarded theatrically internet award in 2020 mmm for distinguished leadership in developing standards for internet multimedia, informative contributions of designer in cement multimedia protocols, including RTP, and this working group.

A

All right so I believe that's it. So thank you. Everybody we will, you know, have enjoyed the social and or whatever, antisocial, you're, doing and see you all around this week and.

I

A

Depends how much we get motive yeah, no matter, but not need to me.