Internet Engineering Task Force IETF 114, 29 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF114-TCPM-20220729-1400

Description

TCPM meeting session at IETF114
2022/07/29 1400

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

A

B

B

C

Should we give people a couple of minutes or should we start.

D

C

Okay, I guess we can start. Can you hear me.

B

C

Okay, this is tcpm, um so if you are not interested in tcp, you might have chosen the wrong rule.

C

You have three coaches here. My name is michael jackson. I'm remote and in front of you are.

E

Ian's, what.

B

C

Perfect thanks.

C

This is the note well I've. I think you have seen it a lot of times this week, so I won't spend much time on it. It applies to this session, the logistics. The session is being recorded.

C

Thank you to richard chef and egger for taking notes.

C

We have a javascript, yoshi will look it the chat, and if there are any comments he will make sure that they come to like um one information, if you are writing a document and think tcpm is a venue for it which might be interested in it then use tcpm in the name and it's on our radar so then type draft.

C

Whatever your name is tcpm and then the subject.

C

This is the agenda. For today we gave you a short update on the working group status. Then we have four presentations regarding working group documents. Two of them.

C

Have at least been for a while on the working group last call: two of them will be in the working group class called sometime in the future, and we have two presentations.

C

um One is uh based on the feedback of the tcpm regarding the tcp yang module by gaian, who is presenting what features are needed from a user perspective, and we have one non-working good document presentation the tcpa great request, an update on that.

C

Are there any? uh Should this be changed? Any comments regarding that.

C

So I I have seen the presenters I think um mahesh is still on the train, he's heading to a hotel and once the document once the presentation is up, he should be in the hotel being online, so that should work.

C

These are the on the uh on the milestones of the working group. The tcpmao test vectors has been published since the last ietf, it's rsc 9235 and you might have seen a couple of emails regarding errata. So there's one issue, which means which is that the tcp checksum is wrong. In the example packets, when using ipv4 is the network layer. This is for 12, packets, so they're 12 or 6 in packets.

C

I think so that's why you see 16 erratas right now, it's up to the 80 to figure out whether to apply them individually or change this stuff to a single errata, that's up to up to the 80.

C

Whatever is, however, this is handled best in the in the tools.

F

Yeah spartan- um I I don't want to like- have an extended debate about this. I think, probably the least I mean you've already filed the errata. Thank you for that, but I think the least aggregate work for everyone is if we just have a single, if you just do the step of filing a single errata for all of them, that doesn't that's general to the document.

F

um Well, let me think I guess we have to. We have to tell the rfc editor. I'm sorry I'm thinking about this in real time, but I guess we have to tell the rc editor to make all the changes. So actually you know what you file the 16 I'll just approve them all, and that way the rfc end has no ambiguity but they're going to do so. I changed my mind in the middle of my comment: let's just leave it like. It is.

C

Okay, I mean, if talk to the rfc editor, if they want it in a different way. Just drop me a note. I can do that. Okay,.

F

That's a good point, I'll I'll ask them I'll ask owls before I get out of here how she wants.

C

F

C

Okay, um rfc 793 bis, that's the tcp spec uh the base back, it's an auth 48 and there have been a lot of comments from the rfc editor which have been addressed recently by wes, and so the document is moving forward.

C

The tcp yang document is after working group last call in the isg last call. A couple of comments have been raised and the authors are working on addressing them, we'll get a status update here and also we will have a presentation about uh potential additional features which some users think would be very useful. So we can, then I think they are maybe suggesting something like another more.

C

Detailed yang module the next two documents prr and the next one is cubic. uh The prr is we have a presentation on that. uh It's still in progress, uh the cubic one. We will also have a presentation on their. We are past working group last call but got substantial comments and are still in the uh in the face of discussing them. um We will. We will get a status update uh of that during the discussion. Unfortunately, the person raising the comments couldn't attend this meeting.

C

Histor plus I marked it as green. I am the document shepherd, so I read it. I have some editorial formal changes requested once that is done I'll. Do my shattered write-up and pass it to the ad. So that's from a working group perspective. It's it's done right now.

C

Accurate ecn is also uh on the list of drafts, which will be presented. That's ongoing work um almost ready for working group. Last call, I would say we have generalized ecm, which builds on that and tcp edo, which has not had lots of changes related to the last meeting.

F

Yeah, um this is all fine, but just- and you know I realize things have to be done when they're done, but if, if at all possible it's to if it's possible to prioritize accurate ecn and like maybe deliver it to me. Well, I don't know if, if it's at all like, if you have two documents in front of you and one of those accurate ecn, please process equity cn first, because the l4s stuff is already kind of going through. So I think it's a little it's a little awkward for this to be.

F

You know significantly behind that, but you know don't you know, so I hope that guidance made sense. Just if you, if, if.

C

You have any, do you have any document which you would are you asking us to delay?

C

F

So so, like the practical implication of this guidance would be that, if, like say as a document shepard, you had two documents and one of them was accurate ecn that you would work work on the shepherd write up for accurate ecn. First, this this dilemma may not arise like you may just have a document in front of you and then accurate dcn is the only thing on your plate, and um you know obviously accuracy it has to be done first and it's not done.

F

We haven't done the last call, but to the extent that you have you know, process gates and something is blocking accurate ecn like I would. I would encourage you to. I.

C

Don't think anything is blocking you accurately, so I think the the thing we are working on is uh basically is cubic yeah.

C

So so I don't see anything being blocked, so we can. We can start working the glass call of accurate ecm whenever we think it's it's ready. We are.

D

G

C

Anything and bob is coming and telling us that it's ready.

G

um Yeah this is bob briscoe. Yes, that's true. um I just wanted to ask whether we're going to get a working group last call on an attempt at it on generalized ecm as well, because that's part of the same thing.

F

So, like rule number one is, it is ready and um I'm not saying like can't, stop all work, so we all just sit here and focus on ecn, but to the extent that there's a process thing where you're doing one one working last call at a time or one separate, write up at a time or whatever.

F

If there's an ec and doc in the queue, it would be nice if those were given priority. Does that make sense.

F

Okay: okay, thanks.

C

Any other comments regarding these issues or any other working group related issues.

C

If that's not the case, then I would suggest we move on to um to the first presentation.

C

We have 15 minutes spare from our agenda and if there is for any of the the the issues we have discussed fruitful discussion, we are willing to run over the time limit in in a certain way, but um still trying to make sure that all presentations can be happened. um So then, I would say vidi.

C

Video you hear.

H

C

Yes, we do, are you running the slides from your computer.

H

I'm trying to.

H

Ask to screen share.

C

You don't need to screen share, you can just do the job. Sorry.

H

C

The document is uploaded.

H

Can everybody see the yes.

C

Slides. Thank you perfect.

H

um So uh this is um update on revised cubic um and we are, you know, aiming to publish it as a proposed standard.

H

um So there are some issues that were raised by markup and um I've been exchanging emails with him. Regarding some of the issues that I couldn't really um figure out from the mailing list and I'll talk about it in a little bit issue, one is um about the tcp friendly model and it seems, like marco said that the tcp friendly model used by cubic is not correct and he pointed to a paper I think wrote by bob. um So maybe we will take this after.

H

I present this and ask for bob's input on this issue that marco has raised. The second issue is changing beta from 0.7 to 0.5.

H

It is an interesting thing I I do. I have spoken to many other folks in parts who participate in tcpm and it seems like you know, the 0.7 to 0.5 is kind of like related to the doubling in the slow start, and when you double it and you see a loss, you have it you kind of reach the um basically you you get one x times the condition window, which still means the queues are going to be full, even if there won't be a second round of loss.

H

So um it's not the best, but it still avoids probably a second round of loss.

H

Having said that, um I have also spoken about this to a lot of folks and and the authors and my and in my personal opinion, is that changing this at this point is not something we think is the right thing to do, because there is just literally no deployment with 0.5.

H

Not in linux, not in apple, not in any stack, quick stack that uses cubic and, I suppose free psd, as well as microsoft. If anybody has or has been using 0.5, please let us know, but this is something I think we cannot change at this point.

H

um Then there was issue number three which has been resolved by neil. This issue was about.

H

um Basically, you know it's just a bug um where we were um initially, we were saying if the congestion window is over, w max then set alpha cubic to one, and there was a bug here which, where it should rather say, and the conduction window, is higher than the prior condition window. So neil has fixed the issue. Thank you neo for that, and I think he also said this issue was fixed in linux.

H

Issue number six was about the implementations that still use congestion window directly during a condition event to do the reduction and there's a pr open for this. um I think uh there is just a small edit left in this one as mark who sent an email about it yesterday, but I think this is something we can resolve.

H

um So, as I was saying, uh I did email him to ask what are issue number four and five and he replied um a day ago. So I have not covered that, but I think the issue number four. If I understand it correctly, um he mentioned that 0.5 should also be used when we are in congestion avoidance and not just after slow start.

H

um I have my opinion on that, but I would like to hear more from the folks here have any opinion about uh how does changing 0.705 impact the congestion avoidance um last slide? um There are open issues and pull requests.

H

Actually, there are no open issues on github, but there are open issues on mailing last, but there are pull requests and github. So if you are interested in reviewing them, please go ahead. We're trying to convert as soon as possible, so please help us to review the pull request and march into the draft.

H

There is support for publication um sps on mailing list as well as on in the last meeting um and then for issue two. um I just noted here it's it's not um it can be considered for future, but not now that's what that's what we think um that's all I have, but we can.

H

We can go through the queue.

B

I

So richard just an observation, so I believe uh none of the current implementations of cubic are pure um just look at just implementing cubic as it is in this draft. So for the slow start, it will typically always have some kind of high start or more advanced functionality there, if perhaps the notable exception of freebsd, but their cubic is not the default method, so maybe it would be worthwhile. So I would want to say that I agree with your statement here that it would not be advisable to change the recommended beta value.

I

At this stage, however, perhaps make a note in the document that a pure slow start, as you know in the in the past, is maybe not the best uh ideal situation to determine when to stop slowstar when running kubic. Thank you.

H

Okay, thank you richard and that's covered in the document.

G

All right bob briscoe, I.

D

G

If you are going to mention anything about 0.5 in the document- and I don't know whether that is needed, given the way richard said that, but if you are, I think um there's also potential problems with 0.5 in that you then get more queue variation, so you get more delay variation, and so you know that's that's. Obviously, something, as you say, has not been measured and if it was, I think you you'd find things were worse.

H

Thank you. Bob.

B

uh You see from the floor, this is my individual command for each one and each one is kind of overshooting issues rostered, but uh I think you know this is the issue for roster, not the security cubic. If we use cubic it's more visible compared to rena, but even we know we have overshooting issues, so I think the problem should be fixed in slow start, not a cubic which all we can do in cubic is just tuning. But at this point I'm not sure if we need to do that.

E

uh Putting my chair hat on, uh if folks could try to add themselves to the cue, uh even if you're in person uh that'd be great thanks.

B

Any more comments.

C

On the chat, um rodney is asking whether you can run high start plus for this cubic.

H

um Yes, people are running that already. It's also mentioned in the draft.

D

J

uh Stuart cheshire from apple, so my quick comment is this is largely documenting what is incredibly prevalent on the internet today. So if somebody wanted to propose a cubic version, 2 with a different beta parameter, that's fine as a proposal that the itf would discuss. But that is really not the purpose of this, and um this is reflecting the reality. As several people have said, the reality has had the benefit good or bad of lots and lots of testing.

J

This proposed alternative uh would take years of study to get to the same level of understanding about how it behaves at the large scale.

B

Okay, um any more comment and then.

E

H

Sir rodney asked on the chat: does that solve the alpha issue of issue one? I don't know if folks understand the issue, one um yeah, sorry so.

D

H

One is a little bit complicated if you read on the mailing list. It might provide some insight, but it's really hard to explain it um in. In short time,.

B

Yeah for each one is our model, and so I have some you know mark and I have been a discussion and then um I I have some comment and mike mark has some comment and then we exchange a lot of comment each other. Then um right now I have some common argument. His comment, but for babies come to argument. Contrary, I will have a counter argument. I've contacted me to comment argument. So the conclusion is this is not the easy issue.

B

That's a conclusion from my from this point, and that means in order to settle down this issue. We need more detail analysis. Otherwise we cannot settle down discussion, but at this point I don't know if we should, you know wait for the conclusion of the discussion may take years for detailed analysis and if our purpose is, you know like uh publishing the cubic draft in 2025. This is a perfect version of tubing. Then we can wait, but uh this is I don't know. This is what we want.

B

Basically, um so if that's just says no, if we want to make a cute version too, it's totally fine. We should do it, but not this draft. I think that's, I think, that's the you know general consensus of the working group. uh We have, you know analyze the consensus in the previous meeting and then we see sorry the concerns that that we are going to publish this draft as a proposed standard, and I don't see any you know big opposition to change current situation.

B

From my point of view, and the one thing I want to emphasize is: the cubic draft is not a threat for the internet. If we deploy cubic there is no congestion. Crap happen. Nobody says that so what we are arguing is if we compare renault and the cubic and then cubic might be aggressive and then some people say it's not true aggressive. It's maybe really aggressive, but some people say it's drastically aggressive, but this is you know under discussion.

B

We don't see any conclusion yet, but in order to see the conclusion we need more analysis, not the kind of situation and then at this point, um does people want to wait for the data analysis of the result? What we want to publish and then let's discuss about the qb version too, which one people want. That's the point of the discussion in my understanding and.

C

B

There is, if people any comment on this one, I would like to hear it if there is no strong opinion. I think I would like to proceed. It.

H

B

D

H

I just want to add to what yoshi said about doing these analysis. These are more research thing at this point and not something that would get to the standards or ietf organization before folks do research on it. So that's a lot of time.

K

D

L

Yeah, I am going to say again what I said last time of the night. I don't like this position. I think we should have done respect differently. This has been deployed. It's the one we're using. I think we should publish this as a ps. I think we should note down this important discussion, we're having now as part of that ps and we should keep progressing.

L

I don't think we should stop and start evaluating something different to what's actually being deployed.

C

F

Martin, do google no hats to be clear, we're talking about the 0.5 thing on whether we want to see more data there before we move forward, or did I misunderstand your statement yoshi, which issue do is? Are we debating more more study of.

B

um One thing is uh issue: one uh cubic uh tcp friendly model and second one is uh beta for rate zero point, zero point, seven to zero point: five.

E

B

Step, that's another, the two things: okay,.

F

um Well, all right well with issue one I think um the case was made that was too complicated to discuss in person um and I've not read the email. So I will. I don't know issue two like I. I think I'm gonna concur with the other people. That 0.7 is what we deployed and um 0.5 is very researchy, and I think, um like opening a research topic is not appropriate for this effort. Yeah.

B

Thanks, thank you.

C

So um my position as an individual is: um we should spend some time on discussing the issues, because, uh if it's, if it's a mistake in the specification, we can fix it as the one new fixed.

C

um If we have something like the dot zero versus dot five, I would be happy with documenting that people are now using um 5.7 and give a short description why there was a discussion that dot five might be appropriate or the better value or whatever, but it is about documenting, what's now being used, whether that is related to a mistake or not doesn't matter.

C

I

I believe we should be documenting in this draft what has been deployed where we have a lot of uh experience already. We have known that we haven't corrupted or collapsed the entire internet and going at this stage to 0.5 and holding this document for an extended period of time, then, quite frankly, nobody will actually change the beta parameter.

I

I don't know how what value that would really bring.

J

Stuart trasher from apple.

D

J

I'm kind of repeating my previous comments, but uh this conversation sounds very strange to me. Taking a step back, it is widely been observed that cubic probably the most dominant congestion control in use on the internet doesn't have an rfc specifying it and that's a gap we need to fix.

J

If we choose to write an rfc specifying some other fictional protocol that no one uses we've totally failed in that first goal, one of the goals is document. What is whether we liked or not the dominant congestion control for the last decade? Let's write it down.

G

Okay, um I I just want to switch to issue one. I think issue is stunned. From my point of view. um All I will say is that the um model I wrote up um was uh for tailed well for tail drop and aqm, and I couldn't acrom is more difficult because it depends on which one it is um and for the aqm model um results we showed yesterday, comparing prague against cubic and prague against reno gave exactly the same results in which over a range of link rates and round trip times.

G

So you know, I can't believe that no one else has done results like that, but we have results as of now that show that reno in its tcp friendly mode with an aqm, is um identical to cubic within the ability of the human eye to see differences in graphs.

H

So so, yes, that's true, and then bob presented that with those results yesterday, if somebody wants to look at it, those are available on the iccrg slides about this um 0.7 to 0.5. I want to reply to michael about about whether it was a mistake. I don't think there's pros and cons to things, uh probably in slow start, it is a little bit um maybe takes two rounds to reduce the uh to basically get below the um you know the basically avoid second loss. um It's it's for that.

H

That's the con and I, I think, um probably in slow start. There is no pro, but I have to think thoroughly, uh but in congestion avoidance, it's the queueing delay variation is lower when you use 0.7, because your reduction is smaller. That means you were you need. You need, don't need as deep buffers as new reno need, and perhaps it also makes sense for slow start, because if you have less deeper buffer, then this slow start will also kind of have low delay variation.

D

H

Correct me, if I'm wrong, but it's not it's just a mystic, it's it's about pros and cons, and we can't just look at just look at one side to make a decision. As I said, this is not going to be decided right away. It needs some research.

H

M

uh Yeah hi, can you hear me? Yes, okay, great yeah. I just had a a few comments to follow up on a few of the things said recently. um I think there was a statement made that probably no one would change the beta value in practice. um I I would tend to disagree with that. I think there are definite issues with the 0.7 versus 0.5 and I think in the future um I could see, for example, linux deploying something different.

M

um You know after appropriate research, but I agree with the consensus in the room that for this document we should document what's deployed already, rather than embarking on a research expedition before publishing this um in terms of bob's remark about the tests recently showing reno and cubic. Look the same. If I.

E

M

Correctly, those tests were reno by itself and cubic by itself, but I don't think we would expect that to show the issue one. I think issue one is about the interaction between reno and cubic interacting in the same queue where the difference is. Basically the cubic increases at sea wind every other round trip time and is therefore um you know, potentially less likely to see uh packet loss than reno is when sharing the same queue. So I think we might need more more testing really to to understand issue one more deeply.

M

But again, I think that's something that should be put off to the future. We should just document what cubic does now um and then I do another question earlier was do we?

M

What about this 0.7 versus 0.5 in congestion avoidance, and I think, as I think, as stated on the email list, I think there is a potential concern with that: 0.7 versus 0.5 distinction and congestion avoidance as well, because cubic can increase its congestion window at up to 1.5 x per round trip time, and so, if it gets to that rate of increase, then 0.7 is not enough to pull the sea wind back down to a level that will actually fit in the network.

M

So I think there is a issue there as well again worth being making a long-term research priority and not something in this document. um uh Thanks a lot.

C

I just wanted to say that that the word mistake I was choosing was not. I mean I wanted to.

C

My point was please document what is out there and in the case there is a discussion about whether anything else is better or not or this kind of stuff we might want to document it, but we don't want to discuss this for years to figure out. What's what is what is better? So it's about documenting what is out there.

C

G

It was a comeback on what neil said so: yeah um yeah, so bob briscoe yeah neil. There were results of um prague versus cubic and pride versus reno in the same scenario, so you could see, compare how reno fights a different congestion control and how cubic does as well in an aqm um and they're, also cubic with ecn versus cubic without and cubic versus, reno and so on. So it wasn't just one flow on its own.

F

uh Martin, do google again no hats? um I would like to zoom out a little bit because I think the basic tension here is between documenting what is actually out there and, like you know, because we sort of change control.

F

This document, um maybe making some fixes and correcting you know bugs so-called bugs and what what is how it is implemented- and I think the right way to think about this is that we have a bunch of cubic implementers in the room and I think, if in relatively short order, we able to reach the rough consensus that, like we really should do this with cubic.

F

And you know we will probably go back and do this in our implementations that it would be appropriate to put that in the document um and make maybe make a note that some implementations might not do this, because you know the previous consensus was x and that's fine, um I'm not suggesting we start research projects in this area that that could be a different document but like if everyone says. Oh, this number you know was four, but it actually should be five, and that was just a dumb thing.

F

It's a bug and we all sort of agree with that. Then we can absolutely make changes to what is deployed out there. um I hope that's helpful, but I think that's the right principle to apply to these sort of tensions. Thanks.

B

This is yoshi from my personal opinion and yeah. I basically I agree.

E

B

Describing the issues, but uh what I'm wondering is, if we, you know, describe the detail of the issuance and then uh I'm afraid that document is getting bigger and bigger and complex.

B

So maybe I'm thinking about you know we can write about some simple, no simple information document describe this documentation and then and motivate people to do some more experiment. That might be. You know, from my point of view, might be preferable to describe this specific issue specifically detail.

B

That's what I'm thinking.

C

Thank you thanks for the discussion. um Please continue discussing this on the mailing list and get the issues.

B

I just like to make sure that our current consensus is published. This document has proposed standard and then there is no holding back at this point. If you have any objection of it, this is a good chance to speak up.

B

C

No one does this right now: okay, thank you, um then I would suggest we move on to u-turn regarding prl.

C

Vidi, can you undo the presentation?

C

C

Will you present, will you run the slides your channel.

K

C

Sorry, I thought, will you run your slides or.

K

Should uh could you run the slide? Thank you.

C

I can try to do that.

K

Thanks: okay, um I'm here to present the second revision of the rfc 6937. This um please next slide.

K

So what is rc 6937 is to remind people is the prr proportional rate reduction um for tcp um congestion control, specifically during fast recovery. Basically, it decides what the sea would and how much, how fast to send uh during the fast recovery. So it's a kind of mini congestion control. uh Well, it's mini. It's actually can be used very very often when a connection is experiencing very frequent losses.

K

It was published in 2013 as an experimental and only implement by linux at that time, uh without rock and pop, um so it uses the previous rc 3517. The conservative stack based recovery at that time.

K

So over nine years we have done some large experiments uh through real deployments and revised the algorithm several times, and it's now default in several stacks here on linux, esd, netflix, rack, stack and windows, um and I want to emphasize one thing: is that this sort of uh fast recovery, congestion control uh is actually the default, no matter what transition control module you use in linux, except bbr, but bbr has a lot of this shirt, sort of um principle or algorithm like rc 6937 as well. So.

J

K

Think uh two a year ago, uh I think our group decided that this should move to standard now, given the large implementation expand pose and the experience that we have next slide. Please.

K

So, let's talk about the most important improvement of uh the original algorithm, uh that is when the in-flight drops below ss stretch right. So, for example, if your um ceiling was 20 and you use reno and your ssres, the ring congestion control is lower to 10, but your in flight has dropped to say three or two like below that 10 number. uh This is when the original algorithm asks you to hand pick two different algorithms.

K

One is more aggressive, uh the other is more conservative, but it comes with pros and cons. So let's look at that. The aggressive version is you during that time you slow start right, since your c1 is below excess stretch. um Obvious upside, is that it's a lock and recovery uh because it's slow starting? uh The downside is that if, during this loss fast recovery, the buffer remains very fall, um it's not just a single burst drop um or you are going through a policer which runs out of tokens.

K

That's why it's essentially dropping any excess rate that you send it through that policer. Then this could result in terrible uh losses because, literally you are pouring gas to fire. um So it will be like keep repeating shelling sense, trying to ramp up at twice the the speed that the rink is draining and those just keep getting lost uh very easily.

K

If you don't have rack that results in uh repeated timeout, because you run out of any ad clocking and but on the other side, if you pick the conservative one, um basically, it's a strict packet conservation.

K

When you get a packet sacked, you send one more into it: um obvious downside, linear recovery, time and packet losses and round trips for large congestion window.

K

um This is terrible, um but the upside is that, since you are just sending exactly as the link draining way of your connection, you are less subject to further losses in this case.

K

So the improvement really is to dynamically pick. This based on the situation uh that what the next act or the the most recent act indicates by default. We want to be conservative, uh but if the last act indicates that hey the repair is in good progress, meaning that the same una is advancing. uh That means your last retransmit has been delivered successfully right and, more importantly, since then una is advancing. That means receiver application is making progress uh as well that he can reach more um and also this act does not further indicate packet losses.

K

I mean that thing's looking good making progress and there's no further losses, then we'll do slow start, and this has been shown that this simple technique is very useful to make it dynamic next slide. Please.

K

um Another smaller issue is that the original one doesn't really define nang sac case. um What do you really do so here we apply some very simple technique that was actually implemented, but just didn't get documented, uh which is if the act is a due back right. Without fact, all you get is due back and you simply just assume that you know one packet has been acknowledged or delivered.

K

Of course, this comes with that famous caveat that neo uh found years ago that hey what if I just send you back every bite I receive so here we add some more protection, meaning that we assume that you cannot act more than whatever that has been. um That was in flight right uh as a sort of protection to this uh attack uh to some degree. um So this accounting change will allow downsack to also use pr very easily and doesn't really require any extra state next slide. Please.

K

Other minor issue, uh the original um rc, does not trying to force fast retransmit uh upon entering the recovery, uh for example in the original algorithm that you have a sencondstay variable to decide how many packets you are allowed to send um for the given act that you just processed and it's possible it's zero because you want to make sure it's proportionally.

K

The rate um is, according to the new asset stretch, whatever the sort of guiding congestion control says that what what the new window should be. This has an obvious downside is that you could potentially lost ad clock uh because you don't know if there's gonna be more act coming right. uh What if there's only one packet that survived this uh stone? um So here we added this well for the fast retransmit only once during recovery, and that fast return is also accounted in the out delivery package.

K

So the algorithm just make a little bit tweak, uh but fourth, one out to keep the ad clock uh going. This was originally implemented by linux. It just didn't get documented in the rc, um so we put it in there. um Another one is like the original, obviously didn't even define.

K

How do you calculate the seaweed- and here we define it like it's simply the in flight or the pipe plus the cent state variable, um so that, with this ceiling calculation, you would send exactly the same time number of packets out to make it more clear. Next slide, please other minor edits. We also recommend that you should use rack tlp, so that remember we talked about. We want to make the algorithm more dynamic and we want to say hey. Does this act indicate further losses?

K

um That usually means is this some fast returns, but also get lost again uh in that you do need the rack plp to detect that properly.

K

We use a recommended because there could be other techniques to detect that rack top is only one better detection algorithm and remove some deprecated way having text uh and the experiment section. Since now the extreme have been concluded um and update the examples to reflect the new algorithm. uh We also noticed that linux had a bug that was reported by bob. Thank you bob um about the original implementation, so we also send a linux patch to fix that.

K

um So that's all for my presentation. uh I hope that um we can uh maybe discuss if we should move to sort of conclude this uh this revision, so that we can uh turn the experimental rc into standard.

K

Okay. Thank you.

C

Thank you for the presentation, any comments.

C

B

um So I think I sent some kind of review comment on the mailing list a couple of months ago, and it seems the new version seems to be under some of my comment. But uh if you could respond to my review email, then this one, this point you guys updated or this coin. You know it's not necessary to update and so on. If you could do that, that would be very helpful for me.

K

uh Sure I think I went through all your comments and I believe I have addressed all of them, but I'll reply it explicitly on to your email to show where, which part I change in the draft yeah.

C

I

uh So this is richard. I just wanted to say that I'm very happy that uh this uh now finally seems to be progressing again. um I would uh want this uh to become uh uh going through. A working group last call quite rather quickly having implemented the pr on the on the old draft, and I would like to improve the especially the heuristics, but would want also to have the proper rfc at the time so that it can be made upstream right. Thanks.

C

I think gauri left the queue hopefully intentionally.

C

Any other comments.

C

Then thank you and follow up on the email with yoshi.

K

C

Okay, um I think the next speaker is bob.

C

Bob are you running your slides.

F

He wants you to run the slides, since you probably didn't hear that. Thank you.

C

I didn't hear that oh yeah.

G

um Next slide, please michael.

G

Right, a very quick recap: accurate ecn, is a change to the tcpy protocol to deal with the problem that the existing ecn feedback is only for congestion controls that need only one feedback per round, whether or not there's more than more congestion than that, um and it involves two pieces.

G

A um small three bit field is essential and the supplementary option um and having this feedback allow gives you the fine grained control that allows you to reduce delay a lot more um we're using nl4s, but it's got other uses as well. Thank you. Next.

G

So, um since the last cycle of the I or within the last cycle of the itf, it's been two updates um links there on the.

G

um If you go to the slide for the two diffs and um also an english summary of the diffs on the list um in response to requests from gory from ilpo um from again or a follow until the change to oppo and um uh finally, some work that was happening earlier in the week on the interop we found uh we hadn't properly documented the experimental ids, the tcp options and two different implementers had guessed two different numbers.

G

So um we um you'll see we've sorted that next slide.

G

So, firstly, um gary wasn't happy with the section on act filtering which updated rsd 3449, which is as the little um asterisk says at the bottom. Tcp performance implications of network path, asymmetry and it particularly updated the act filtering um part of that rfc and gauri pointed out, and he was right that that rfc referred to 3168 and so because accurate ecn says it is going to update 3168.

G

That rfc will then apply to accurate ecn as well. So we don't need to specifically update it. It just automatically happens by updating rfc 3168, so we change things around um and we added a bit more technical detail on how to do it. um How a filtering node might.

G

Handle accurate ecn feedback um if it was trying to improve improve performance, which is the whole point of act, filtering nodes. Okay, um any questions on that move on.

G

So the second change after el po had implemented this. He said the um the implementation for sending the tcp option. The accurate ecm tcp option was um much simpler than the receiving side of it, and so the the previous recommendation in the draft was um that you uh you're, recommended to at least do the receiving side. Even if you don't do the sending side.

G

Obviously I recommend it to do both, but if you're, if you're, trying to start out um do the receiving side first, and so we switch that to be do the sending side first, because that's the easier side, and that means that um anyone that does do the receiving side, if they're getting um this option arriving at them, then they sort of can unilaterally get it working by just implementing the the receiver side. This means the receiving of the option, not the risk, the data receiver, because it's the the option is feedback.

G

So it's the opposite, half connection to the to the data direction.

G

Okay um and this this um cycle in draft 20, we just added a little more strength to the recommendation as to why it's important to um to implement this and you'll see the green text. There says that I won't read it out um any comments on that um would have been on the list.

G

um It's had a I think a week, so um there's one little point there that, um because ilpo has implemented both send and receive logic in linux.

G

If that does go through to the main line, then most linux servers will be able to handle both sender and receiver, which is another argument for if you're a client receiver- and you don't really want to bother implementing this, at least, if you do the sending side, then um the server will be getting feedback on on the downstream at least okay. Next.

G

Right, um this is the point about us um omitting to register the experiment: mental ids that we've been using for this tcp option in implementations um retrospectively, registered them, or richard did earlier this week, they're now um on when as of wednesday evening, I think they're on the iona registry um as shown there.

G

But then what we want to do now is go for an early um registration, no early assignment. I think it's called of of the actual ids that we want to use, um while this is in in parallel to this, going through the working group last call process and and so on, um so that the implementations can start um using the real thing next and the next is the.

G

Next step slide, we have a um one early security error um review that ends up showing has issues, but um it was all resolved and the the author of that review has agreed it's.

G

It would be almost ready if he put that stages in again, so I believe we're ready for working group last call, I don't think, there's anything else. um I've seen on the list, anyone wanting anything done and well. The authors are all happy that everything is done. That should be done, um so um I don't know whether we're gonna do that here now.

G

I just wanted to also add the other two points there we're gonna, um I don't know whether we need or the chairs need a feel from the room, whether we should go for an early assignment as well and, um finally, whether generalized ecn- um I mean that's, that's- been ready for working group last call for some time whether we go for actually doing that it has a dependency on accurate, ecm.

F

uh Martin, duke google uh yeah, like early allocation, I think, is a good idea because if, if it turns out that whatever we allocate um gets eaten in the internet, that would be good to know before we published before before. It goes to the rcn, um and I don't know if their magic like unallocated options, that would make it through the internet or not.

F

um But you know who knows, uh I did have a question I mean you said you implemented for linux and I'm wondering if you reached out to the linux kernel maintainers about accepting any of this, in particular at least the receive side.

G

Well, the the the reason this issue came up is neil was testing his linux implementation with uh interrupt with richard's freebsd implementation at the interop earlier in the week. So, yes, neil is the guy that, but.

F

But he's saying, but he's not a kernel maintainer like the actual like linux mainline. It would be great if the sending of the option was in the kernel, because then you know commodity linux servers would do the right thing.

G

Well, I mean with um ilpo's original um patches, he produced a patch set for the net dev um community and um basically it was. It was all ready there weren't any problems, but waiting for the iatf to do the rfc, um and um I mean neil, is one of the people I mean the lens community tends to work on trust. You know, and neil is one of the people. That would be a name against that.

G

I think um I'm not okay, presuming that neil will say it's okay or anything, but you know okay, neil, but you.

F

Know all right well alex neil. That's going some other time.

G

C

um Quick question: is the linux community waiting for the um for the rfc or waiting for the option? Kind assignments.

G

You'd have to ask them sorry, but when we originally put it in, it was waiting for the itf approval. It wasn't clear whether like, if it got through working group last call or if it got approved by the aisg or whether it would actually have to you know, be a published rfc. um I don't know at what point they would be happy, but um we can find that out.

C

K

Yeah a couple things I think we definitely should get a real auction id um uh as early as possible and don't use the experimental id uh in implementation.

K

uh This is based on a a real, my my own experience with fast open, because um if you have those, then you need some way to upgrade on the id right when there is a server that only talks, the experiment and um the other one that talks post.

K

um So it's a pin um pen, another one is for the generalized ecn.

K

A quick comment is that is it possible to make that generalized easiest generalized ecn, also good for the bctcp cases, because we don't expect people that use dc-tcp ecm will hop on this accurate ecn anytime soon right because there's a real um implementation blog right. So that's.

G

My question yeah: that's a good point we can we can. I have to think how we would word that, but um because we have to be careful that we don't sort of endorse using dc tcp over the internet somehow but well well. Well, um we should be able to do that. Yeah.

I

G

I

Just to the comment around generalized acn for data center tcp, I have a private patch to do this exactly because of the same reason that aqm, that is compatible with l4s would mostly be compatible uh with database and the tcp as well, and therefore generalized ecn and data center tcp would, in my opinion, be a natural fit.

I

However, we need to progress on that on that draft. In order for this actual implementations to progress thanks.

G

Do you want to no okay? So um I just wanted to add that the dc-tcp implementation in linux already does what um generalized ecm says it just sets ect on all packets. It doesn't um not set it on sins and acts, and things like that.

G

I think I was just asking for that to be endorsed by the rfc.

K

Okay, I'm not aware of that, but they we can confront our offline. Since it's just implementation issues.

C

Yeah, could I ask martin what the procedure of early assignment is.

C

I mean: how does it work, who decides which part.

F

um I think I have to like give my approval, but um I think you could just send an email to ayanna.

C

You will approve that and then ayanna will execute that or is ayanna discussing that or.

F

He is it the secretary of state ryana that you do early allocations. First, who's, the first contact yeah just call just email, ayanna and cc me, and uh things will move forward and we'll figure it out from there.

F

I

Have the answer to this, um I'm being an australian, so I started the process earlier on an information.

G

To get closer to the mind.

I

Sorry, I'm richard I'm from austria, so I've started this process on an informal basis. um Jana is aware that this is going uh going on and, quite frankly, the process, as far as I understood, is that the formal request has to come from the chairs of this group after the group has agreed.

I

The ad has to has to basically sign it off and as soon as that is gone, just send the email with those approvals to iana, and they will do it.

F

Yeah, I would just send them an email cc me and I'll. Like just reply, I approve and we'll be good to go.

C

Okay, we'll discuss this with another choice.

B

Well, one question bob, so I think the draft is most ready for working group plus to go from my point of view, but I sometimes you know, exchange email with you and gory about some. You know editorial things I I just would like to check. We've already settled down and you can you think, you're ready for working with rascal.

G

Sorry, did you say that, uh are you saying that there's some emails, we've missed or.

B

Yeah, I think so my I'd like to confirm the discussion is still going on or it's finished.

G

I think discussion is finished, but if you point me to anything that I.

B

Missed or anything then no, I don't think I just tried to confirm.

G

I can confirm that now and I can confirm it by email as well. If you want yeah.

B

Yeah and then another thing: listen, you want to wait for earlier assignments.

G

No, I think the two can go in parallel, because um you know I don't think either needs to depend on the other.

C

Richard do you want to be in the queue or did you forgot to exit?

C

Okay, you tune.

F

Do you have something to.

K

Say: okay, could I release the mic uh button um yeah. I just want to uh double check that um we accurate ecn um is now have a working implementation that can show it works with gro and tso. Without any issues um like if we just run it now say inside, they are centers right. The tso gro will all work. Fine, no.

G

K

G

E

G

Doesn't I believe it? This is bob sorry, I believe it doesn't. I believe it should, but um I you know yes obviously test it. Yourself is the um is the answer to that question, um but yeah the code should work like that. Yep.

K

Okay, so that has been my most uh concern of accuracy yeah, but and if that's clear, then I'm happy to support that.

C

L

Very fairness, I'm just responding that I think bob solved the issues we discussed. I don't have more issues on that. One.

C

M

um Yeah I just wanted to follow up on uh youtube's questions about uh offload support. I guess the the one um big question I remember was this question of uh whether various network devices in their tso um transmission offload facilities might might do the wrong thing with the ace um bits, since they don't know that they're trying to be used as ace bits and might interpret them as other tcp flag bits. Is there anyone who can sort of quickly summarize where we are with this? This question of nick compatibility within the ace field.

G

um I can I can summarize that um the when tso and gso or gso is done in the linux stack. That's all handled with hardware. um We haven't had those discussions yet.

G

We sort of need um the community that, um uh like yourselves, so that we can start those discussions.

C

Any other questions.

C

So the early assignment stuff, we'll discuss between the chairs and then um send the appropriate mail.

B

C

So now it becomes interesting. um This is my hash.

C

Able to give a presentation now.

C

So he is not on site, he is in the train or maybe not anymore, so he dropped me a note that he might be just out of the train heading to the hotel.

C

C

Oh yeah, do you want you, do you want to run your slides.

C

It's very hard to hear you.

C

Can you say something yeah.

B

I think you're, muted.

C

No he's not muted, I can hear him, but it's very, very silent.

A

Now he's so quiet that I can't hear him at all.

C

Well, I can, but so he's not muted completely, but.

C

Yeah, that's not better.

N

Okay, can you hear me now.

C

C

So I think you can start.

C

No that's worse again, whenever you use your earphones.

C

We can even heal a bit of the music.

N

Okay, I don't know if this is any better.

C

Yes, it is just start presenting.

N

Okay, all right, sorry for that snafu, um I'm in a public place, so do not mind the noise behind me. I'm here to give an update on the tcp yang model.

N

So we started the scope of the of this yang model for tcp, with a fairly narrow scope of providing basic statistics which, by definition, were optional to implement.

N

A list of tcp connections and a newly added list of listeners for uh that was added in the recent version that definition of that listener list was established by what is existing in tcp map.

N

uh The third item: there is the modifications to support tcpao and md5. Previously we were trying to implement another by not augmenting the keychain model and that didn't go down very well. So the recent changes now add the augmentation of the keychain model to support tcpao and md5.

N

The final edition was the import of keep a live groupings from netcom, tcp client server draft, and this is mostly for alignment between the two documents.

N

The current status of the document is it's in isc evaluation. There is a revised id needed currently to address three discusses and several comments that were received and the authors are working on an updated id which will post right after the holidays.

N

uh No fundamental extensions of the scope of of the model are planned as as of this time, but some minor edits will be required to address all the discus comments.

N

Now, if I can only move to the next slide, all right, so here's the overview of the isc feedback we have got. As I said, three discusses and several comments. um A lot of them are have been addressed in a working copy that you can see the status on the right side.

N

um A lot of the discusses and comments were related to the encoding of any in the tcp listener list, and I think that does need some minor changes that we'll be working on.

N

The the other was the uh the new edition of to support tcpa, 0 and md5, and the corresponding examples that we have in the draft.

N

There were some inconsistencies in that example that we have tried to now address and then um some inconsistency in the 2019 language we have also addressed um there is no. uh There was a suggestion to remove md5 support, which the authors are not planning to, because we do have a requirement from the bgp yang model for support of md5.

N

Anyway, the status of all these and the changes is being tracked in the github location link at the bottom of the slide.

N

So as soon as the encoding of the any listener list is concerned, it's currently encoded as a union or that you see the definition of which you see below, and this definition is comes from the tcp myth and I think the question or the discuss comment that we received was how is um the ipv4 address of all zeros or the ipv6 address interpreted by this particular union and we'll um the yang 1.1 language essentially says that if in a union you have two type definitions, a you're supposed to parse the types in that particular order.

N

So if it's a interprets what it has received as a string, it will assign it to a type string.

N

But in this case, if the type is actually a value of four outputs of all zeroes, then it will be assigned the type of inet ip address and we'll try to clarify that in the next version of the draft.

N

The final slide, as I mentioned, the ao configuration examples. There were a couple of suggestions on how to make uh the containers for ao and md5 presence containers which we have adopted in the draft. It's a minor change doesn't fundamentally change the model in any way.

N

What is new and and required edition is that because tcpao supports um aes 128 and the example in the draft did not reflect the fact that the crypto type that a ao supports only 120 aes 128.

N

We needed to add that to the draft so after adding that we had to update the examples to align it with rfc 9235. Also, I think that's pretty much. All I had from an update perspective.

C

Thank you very much for the comments for the presentation and for arranging that you can make the presentation.

N

um The sheer stroke of luck.

C

Are there any comments.

C

I only have one which means um you said you changed the examples.

C

Are you able to check the examples that they still work or or.

N

Yeah so as part of the draft we do run, it run the example against the model um and we use yang lind to do the verification that the example does correspond to the okay.

C

Are there any other questions.

C

If that's not the case, then thank you for the presentation and we, this presentation was kind of an foundation to the next one given by um guyan on um what might be missing.

M

C

C

Are you running the slides locally, or should I run them for you.

C

Okay, I understood thank you. Martin.

O

Hi, my name is.

O

Hello, my name is gion mishra with verizon and I'm I will be presenting uh the next gen tcp yang model, a discussion that came up um through the um um hopster review um recently next slide.

O

So here's some motivation and some history related to the uh nextgen, tcp yang model. So during the opsec review of the tcp ganging model that was just discussed um the as a result. I we started looking at a possible uh next-gen, tcp yang model and would like to get feedback from the tcpm working group as well on this um on on thoughts regarding this uh process and if it's something that's feasible. So as a result, we discussed the yang motto and what would actually go into it on on the mailing list.

O

So yang is about visibility similar to the snmp mib and not remote management. uh Just some discussion that we've had that the current yang kind of really mirrors the snmp mib and uh from the routing area, grouping kind of what we're interested related to the next ntcp management. I mean sorry tcp yang model, so it's not really necessarily remote management.

O

But what we would like to be able to do is observe the tcp parameters um related to the tcp session state and telemetry, um either back to a controller or a netcof netcom, slash yang, just being able to pull our statistics.

O

um We would like to see. We would like to be able to see everything that could be seen um if you're looking at, like a local like an os hook into the kernel, just visibility into a tcp parameters related to the connection state next slide.

O

So the motivation here on the tcp gang model and reasons why be so, I would say the main use case. It's really related to bgp bgp has over the years, has expanded its scope.

O

One of them is related to data centers, uh massively scalable data centers and which, which uh is bgp only now with rfc 7938, and that's something that a lot of operators are looking towards so kind of really the visibility and the need for stability with bgp and being able to have monitoring capabilities related to bgp is really really important for operators next slide.

O

So this is a just a use case that came up uh it's it's. It's come up a few times in the idr working group and it's related to internet outages that have that have occurred with the tcp window going into collapsing and having a zero window resulting in a stuck state, and I just put in there the mail mailing list archives related to that discussion.

O

So in this in this state, what ends up happening is you have like a router a on the left that the control plane is congested, he's got a send window greater than zero, but then he's got a receive window at zero and then router b, he's uncongested he's got to send windows 0, but a receive window greater than zero, and then the router a he's not able to write to his tcp buffer.

O

So, even though the router b sends like a log message, notification back towards a a is congested and the session ends up staying up so we're not able to reroute traffic, and so it which results in a internet.

C

O

O

um The second use case is related to uh compute nodes and a tcp session, just being able to monitor statistics uh related to the session state and then windowing and the window scaling and mostly for throughput and application traffic. uh I guess server to server or client server. I guess response time next slide.

O

So I guess the really. The big question is that what do we want to add to this next gen tcp yang model, so just in summary, I just threw in a few just some bullets of what we were thinking.

O

One is all the tcp states that are part of the fsm state machine, tcp flags in respective states, tcp parameters that would be accessible through the local kernel, windowing parameters, tcp options and optimizations, and then um and then this the the c-win tcp uh congestion control. So the cc parameters.

O

Next slide, and so um I'd like to get feedback from the tcp working group uh just thoughts related to this. Thank you.

G

um Michael, did you just say bob, I think I read your lips but you're muted. I think.

C

L

You can read.

G

My lips correctly um just just to point out all tcp options is probably um excessive, because um probably I don't know how we make a list of those that are actually used, but there's a lot that aren't so.

O

I understood maybe parsing through, because I'm not really you know. If I I don't know what the how large the list is, but probably parsing the list and see what would be pertinent, I guess would make sense because I'm sure, if it's a lengthy, lengthy, probably doesn't make sense every single one, but just finding the ones that are pertinent. That would make sense.

F

uh Martin, duke google, can you go back to the uh use case? One sure.

F

So um I'm a little confused by example, so you have um keep going michael. Let's it's just.

C

Which one was it.

F

That one okay, so in this case, like from a to b, the both the sender received windows are nonzero, so data can be sent and then in in b to a it's um like, both sides are deadlocked right right. So.

F

um Like what is the cause of this issue, I mean: is this just a question where, like we just need to wait for an ack from b to get a unclogged.

O

Yes, so what what ended up happening? This stage of the router? A he's? A he's not able to? um I guess, he's he's the one that kind of has its management plane. It's kind of. It's hung. Okay,.

D

O

His uh since the management plan uses tcp as well as bgp, using tcp he's not able to uh like to write to the uh I guess the us is, I believe it's the uh receive window so he's not able to write to his buffer, and so he is not able to uh process. I guess anything like if you, even if he gets the uh message he had what ends up happening. He just doesn't close the session. I think that's the thing he's not aware of the other end.

O

He thinks everything is still up and he keeps.

D

O

Like I think, the best thing that would happen is if somehow he was able to like close the session or do a tcp reset and then traffic would converge to an alternate path, but the session just kind of it ends up just staying in an upstate.

O

So that's that's where the I think in like, if you it, you know, like a client server application where you have. You know tcp zero window, which happens, and then the window opens up in this particular case, because it's router to router in this. For when, when that happens, that congested state happens. It's like the management plane is just completely hung, but then the bgp just kind of because the managing plane is hung and it's using tcp.

O

um These state of the connection ends up remains remaining active and, unfortunately, bgp doesn't reroute. Okay,.

F

So the problem here is a is hung and b doesn't realize that a.

O

Is fine? Okay, that's right, but like your.

F

Remedy is to reboot a.

O

Then I would imagine it is, but I think what ends up happening. I think, with the knock whenever this has happened, because the session is up.

D

O

Hard for the not to realize that it's um it sees routes and everything seems like normal.

A

O

Able to process anything, so it takes time.

F

So so the issue, so I'm guessing that in this scenario, a is not like is not reporting yang stuff, because it's toast, so it's b is so what you're trying to do here is use b to ascertain the state of a by looking at the tcp parameters.

F

Okay, all right that that at least makes sense and just to be clear. These are not like commodity tcp implementations. These are specific to the routers that are, they have their own distinct tcp implementation.

O

Yes, probably yes, okay,.

F

O

Different vendors, I guess.

F

Or because I'm interesting like if you're just using linux tcp, I don't know you can install, I mean I doubt they're going to implement the yang and so um there's no market for this. If that's, if that's the case um yeah I mean I'm a little, I'm a little like.

F

It seems like you're not like tuning since, since by since you stated, you were not tuning these parameters right, I I do. It seems like your actual um option. You're just like reset connections, reboot stuff right and like I'm wondering if a much simpler like I am dead, locked model is much simpler than trying to like have like dozens and dozens of parameters, you're specifying and reporting and like having complex logic for what means what um just having looked at this and thought about it for 10 minutes, but um thanks.

F

I I think I understand your use case better now.

O

C

um Regarding this deadlock situation, I'm wondering I mean tcp, the tcp connection can be up and happy, even if you are not able to progress user data.

C

So if the application is stuck from from from a tcp point of view, that's fine! So normally what you do there is application layer, heart, beating or application layer test messages, and then you figure out that your peer application. You can't talk to your peer application layer anymore, but on the on these points, I'm trying to so I I don't know much about yang. So that's why I want to figure out what you, what you are looking for.

C

Looking at tcp flags. This means, like you, want to do kind of a live tracing of which packets are being sent and received and reading that you want. Where is it state you? You want to all tcp parameters that would be accessible with the local os kernel hook. This looks like a lot.

D

P

Implementation.

C

Specific values- and I think it's very hard to to to standardize them.

C

So my understanding is that you can, you can get you can get a snapshot of a state, but, like continuous monitoring seems to be different. That's correct.

O

You know as far as the tcp parameters, I think, as I think someone else had asked that question, but I think really maybe the pertinent parameters, I don't think we'd, probably need all of all of the parameters, but I think, what's pertinent to the connection state that actually would help us in determining whether a problem, I guess for like the knock. I guess if, if there's a problem and maybe parsing through the parameters- and there may be some key parameters, that would be helpful. I guess.

C

I mean: do you want.

D

C

Time stems have been negotiated, sec has been negotiated and window scaling.

C

These are the typical tcp options which are negotiated.

D

C

Your case, I guess tcpao or tcp md5 also, but that's a static thing. That's that's something you can query and get a response, but I don't see how that helps in the problem. You showed.

C

Q

Jeffrey haase, juniper networks, bgb developer yang no author, so you gave me a giant list to try to work through. I wish I could have hit them one at a time. Sorry, so uh to guyan's point the stuff: that's in here state-wise is all appropriate.

Q

uh Your point about we're not trying to implement t-speed dump on top of yang. That does not make sense so being able to look at the tcp flags modeling, all those that's not a big deal for the session. If you think about most tcp, you know stacks you're, setting these things as socket options and that's an appropriate thing to see as part of socket state as an example. There may be appropriate things like you know. If you've seen an expected tcp option on the session, you could also record that and basically say so.

Q

This was the thing that's seen, but trying to snapshot live state for flag for each packet is not part of the goal so rolling back to the use case, one stuff: no, with the stuck sessions. There's multiple reasons this stuff can happen.

Q

Sometimes you have. You know drop packets at inopportune times where each side sort of thinks that's trying to get out of the state and it just never gets there for some reason. Sometimes you have that due to specific types of network drop, sometimes authentication can cause that in certain circumstances, but in the vast majority of cases these things are either bugs or other unusual circumstances that the whole issue is this session is wedged.

Q

The client you know bgp is the example case, but this can happen for other things. It's sort of stuck waiting to get out of the circumstance, and you know if you're, not implementing a form of protocol go keep alive or hold timer. That expects to get out of the situation because, as far as each side can tell you have you know, data pending you're waiting to actually move along.

Q

So the challenge comes, you know when you get into these stuck situations, how do you troubleshoot them? And if you're on the box you're going to sit down type netstat and see what's going on, what's needed for operators that are trying to troubleshoot applications like bgp that are used in routers to be able to troubleshoot the situation, you know remotely is being able to simply get the status of the session see what's going on, and you know there may be opportunities for some level of telemetry.

Q

For these stuck situations like zero windowing is a common thing. You don't want to generate a gang notification or trap out of this sort of thing. Just like you wouldn't want to do an snmp, but it's very appropriate that if you're monitoring these things- and you see that a bgp session sort of gotten stuck being able to query- you know via netcave, you know what is the status of the socket. You know it's been zero windowed and if I see that's been that way for you know a minute, you can then take action.

Q

You like resetting the session. You know using your new router protocol, so there's a lot of options for things that you can do here. But most of this is the same type of visibility, you'd get via cli and just simply, you know putting into the management plane in a generic fashion and uh there's a throwaway comment about. You know modern stacks. You know we run bsd drive stacks, we run, linux drive stacks and we layer stuff on top of all that for management. So this is not an unusual.

E

C

O

Thank you, jeff. Thank you. Jeff.

B

Quick question again: yes, so are you going to propose a new document.

N

Sorry um so I want to generally reflect, uh I think, the comments that both jeff and michael provided, both as uh author of the bgp yang model and the tcp yang model that I think trying to keep track of state information, or at least the live state information doesn't probably doesn't make sense as a replacement for um tcp dump, but definitely for conditions.

N

Just like jeff pointed out about stuck connections and zero window, though that certainly can be helpful piece of information that we could add to the model.

O

That would be perfect. I mean that's really as jeff described. That's exactly what we're looking for somehow that we can get an alert. You know when that stuck state happens with the zero. You know when that zero window happens and being able to you know, get a report. You know you know flagged. I guess to the knock and then being able to. You know, act on it as soon as the stuck stage like. If it's stuck for a period of time, then we can act on it and reset the session.

F

uh Martin, duke google, again um so, like uh you know, obviously the bg community bgp community uses yang, and so I I'm you know we're doing getting work now for them and I think doing more work for them is fine. I just think.

F

I think the principle we're trying to apply to our yang work is to not um not try to do all of tcp, because the mib experience was a terrible one and to be very, very deliberate in adding stuff to that. So, like I mean if this work, I don't. I fundamentally object to this work progressing, but I would like to like.

F

I would like the the proponents to think hard about what kind of information would be actionable and whether you need like really fine-grained stuff, like window sizes or like where, like booleans, could be used, there's or like if there's a bunch of stuff where the answer is reboot. The box like just have like a, I need to be rebooted indicator, or whatever um uh I mean you know, I'm off top of my head.

F

I'm probably not saying that right, but um to not have like try to have a very like small yang model, if possible, that covers what you really need for this use for these use cases and um that you know that relates to actionable stuff, and that will just make this a much more practical thing to get through the process.

O

Makes make sense.

Q

Jeffrey hans, following up, I don't disagree with you. You want to keep the model as small as reasonable. Yang has the property that it can be extended, especially no proprietary, in a very easy manner, offering advice to this working group having done lobbying stuff for itf at the moment, you have a choice in front of you.

Q

You can either do enough of the work such that everybody that wants to use the stuff and you'll leave a lot of stuff optional and model it once or risk all the vendors coming out and saying you missed a important thing and every one of them doing a proprietary extension and forking everything.

Q

So it's a hard walk to do, but it's doable. Thank you.

E

O

E

D

C

Yoshi, how did you did you want to ask a question.

O

Does anyone have any other questions? Okay, all right! Thank you.

C

C

Any comments regarding the young stuff.

C

If that's not the case, then we are at the last presentation, charts.

P

Okay, hello, can you hear me.

C

Yep, are you running a slide.

P

Can you do it.

C

I can do it, you can do it on your own. You have on your upper so below your name. The second item from the left yeah.

P

You can choose your slides slightly requested.

P

So I pressed ask to share yeah okay. Now I see the slides.

C

Then you control them yourself.

P

Okay, okay, so uh hello, everyone, my name is carlos gomez, I'm going to present the updated version of the draft entitled tcp a great request, star option. My co-author is john krugrad from the university of cambridge.

P

So, first of all, let's take a look at the motivation for this draft delay. Tax is a widely used mechanism which is intended to reduce protocol overhead. However, it may also contribute to suboptimal performance in some cases, for example, in so-called large congestion window scenarios, meaning congestion window size much greater than the mss, where saving up to one of every 2x may be insufficient.

P

For example, when there are performance limitations due to a symmetric path capacity or due when we want to reduce further the computational cost and network load, and then there are also so-called small congestion window scenarios, that is a congestion window size up to the order of one mss, for example, in data centers, where the bandwidth delay product can be up to the order of one mss. In this case, the latex will incur a delay much greater than the rtt, and also when there are transactional data exchanges or when congestion window decreases, then yeah.

P

The ability of requesting immediate acts may help avoid idle times or it may allow a faster congestion with their growth.

P

So, on the status of this draft before the creation of the document, there was some related prior discussion in the area of center control of tcp x, which appeared to converge to defining a new tcp option serving to purposes the ability of requesting a given act rate and the ability of requesting immediate acts.

P

So, since the last idf we produced versions zero, four and zero five, with the address comments received in the last idea, but also uh on the mailing list and by the way thanks a lot to everyone for the useful, very useful feedback received.

P

So now, let's go through the update in the last versions of the draft. So here on the slide, you can see the main format of the option.

P

You have the old version, which is zero three and also the new format in zero five. So there are several things to mention here. First, is that in previous versions of the draft there was a feature called ignore order. However, it was not very clear whether this was actually useful. We received a significant amount of feedback in this regard, so we decided to remove it from the document.

P

A second point is that now in in zero five, we state that the kind field value is 254.

P

As you may recall, the intended status for this document is experimental, so we are following rfc 6994, which defines the shared use of experimental tcp options and, according to that, rfc, the kind field can take only two values: two five three or two five four. So we have chosen the latter and the last common, uh for this light is that uh well, it was mentioned on the mailing list that the old format having an odd length in some cases, the implementations might or implementers might want to add some padding to make the size, even so.

P

Based on that, we decided to make the size even by ourselves, by extending the size of the option by one byte. So this is by increasing the size of the r field, which carries the requested upgrade and also adding a few more reserve bits for future purposes.

P

So, uh regarding the r field, as you may recall, in version 0.3 of the draft, we were considering two different options for encoding the r value the option. One was uh using a simple binary encoding where the maximum value of r was 63.

P

Then there was option two, which was a bit more complex with mantissa, an exponent and a possible maximum value of one thousand twenty four. So now in zero five uh making use of the additional bits.

P

Now um we state that the r field carries the binary encoding of the accredit, then we also state that r equal to 0 is a special case where we request the sender requests an immediate pack while not modifying the default or steady state, acc rate, and with this encoding now the maximum value of r is actually 2047, at least in version 0.5.

P

So there has actually been discussion already in the past regarding the maximum value for this parameter, the request attack rate are so again in zero. Five. It is 2047., this perhaps is for discussion, but well in the past. There have been questions on why values greater than 63 would be needed, so there have already been some answers.

P

Given, for example, jonathan wrote, a nice and detailed explanation of why there are some values for r in the range of 100 few hundred or even one thousand, which could be even justifiable in current scenarios, for example, assuming a long rate of one gigabit per second rtt is up to the order of 100 milliseconds, but those large values for r would still comply with a sort of rule of thumb of having at least four acts per rtd, and then they have also been comments, for example by bob or juhamati, expressing that it would be nice to make sure that that our option could be useful as well in future scenarios, where the expectation is that there will be even greater link rates.

P

So uh I don't know if there are any comments on this maximum value of r.

P

If not yeah, I think there's gory in the queue.

G

L

Yeah, I'm going to argue that flexibility here isn't a good thing, but having one act, every 100 packets is still pretty infrequent. We've used it with rtp and other protocols. It's not a big overhead.

L

Why would we ever want to go to a thousand even on gigabit links, one one. Every 100 data packets is a very low load in rate or volume.

P

Okay, so yeah. I understand, for example, uh some of the reasons expressed for larger maximum values in that order would be to reduce, for example, the amount of acts that would need to be processed by the network, but also I understand that the concern uh for large values of ours so yeah, I guess- and I'm wondering how to to achieve a suitable trade-off here.

G

Hi this is bob briscoe. um I've just discovered that a male I thought I'd send. I never sent so I'll say it now. um Obviously I didn't click send and it's sitting in my drafts.

G

um I I noticed that the format of this has now become very close to the at congestion control rfc that we already have, um which is just basically an 8-bit number and the rules as to when you can send that are very similar.

G

So well, I don't like to sort of point this out, but maybe we've converged on something where you don't need to do anything anymore. Charles, we already have. We already have an rfc and we can just use it, um and um that gives you eight bits. So it's 256.

G

um as your number just just think about it. You know I I should have sent this. I'm really sorry. I should have sent that mail earlier, but just see whether there's stuff in that rfc that precludes the use cases you're thinking of and maybe it's an update to, the rfc, that's needed or whatever.

P

Okay, so I guess if, if you can send the message you had prepared with possibly the.

G

P

I think it will be very helpful.

G

Probably got some old stuff in it because it was in answer to something from jonathan morton, but that was just a side comment, so I'll send it I'll press send, but I'll put a little note on saying some of this might be out of date. Thank.

P

P

B

Bro uh your thing is that just personal opinion, if we want to save the options with just even just one byte, maybe we can use the previous version and if we need big value and we can utilize an elizabethan bit and then arrogate new formats- something like that, then maybe we can address your concern.

P

Okay, I see that there's some pressure on one hand to to maybe have uh an even length for the option, but then also we want to to keep the format short, so yeah, let's see if we can find a suitable solution.

C

As an individual, I at least looking at the tcp options we are using right now they are all they all have an even length.

C

So um that's, why are we really saving a byte if we have one option with with a knot length?

C

That was my point in suggesting. If that's not the case, then we can just use two, because you will you will pet it anyway.

P

C

I

So while while we are generally doing padding uh padding is something that we could uh really do away with, I would really more like to see an argument made that a larger field, length or option length is really valuable and, as gorge has pointed out, even a value of 100 is already quite excessive, at least at this age having having a transport protocol flying without feedback for thousands of a flight of thousands of packets, it, I can hardly imagine a transport protocol that would, you know, have a decent, decent properties with such a rare feedback.

I

On the other hand, I mean this is advisory and not a mandatory option, so the receiver can use it can delay, but it's not that it has to follow that. So therefore it's uh it's that's the other thing, the other aspect why I don't think that we need really that lengthy option. Thank you.

C

Regarding the regarding the option, um the concatenation of all tcp options has to be length divisible by four. So that's that's the padding I was referring to I by the way I closed the queue since we are at the end of the time and.

C

Carl says: let's start outside jonathan.

A

A

There's question about whether.

A

Whether the large value of r is harmful and that's.

J

A

We have the rule of thumb of having 4x per rtt, because that gives um sufficiently rapid feedback to suit the network path. It's also worth remembering that if a congestion event occurs, that will result in immediate feedback, regardless of the value of the delayed act. Timer.

C

Cards, do we have do you want to have uh show more slides, or are you basically done.

P

Well, perhaps just one which is super quick.

C

Then do that? Because we are running already over time.

P

Yeah, so just mentioning that uh yeah we have running code. So this is great news and, as michael announced on the mailing list, he has been leading the development of a prototype implementation of the draft for freebsd. My understanding is that there are some features already supported and it will be completed in the next few months.

P

C

Yes, so it's it's! Basically, it was a student's project to get this to get this implemented, and there will be some final touches before it can be open sourced.

C

Any other comments.

C

If that's not the case, then thank you.

C

Do you want to say last words from philadelphia.

B

See you in london see you in london.

C

See you in london bye.

C

C