Internet Engineering Task Force 101, 19 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-TSVAREA-20180319-1740

Description

TSVAREA meeting session at IETF101
2018/03/19 1740

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

A

Terry I was in here thank.

B

You so much thank.

A

B

C

May be okay, yeah many ways, many ways to fail right.

B

So you're running.

D

This right sure.

E

C

E

C

Seem like more, you laughs.

C

What do we got.

C

So, everybody's all uploaded and everything right.

E

C

I'm, obviously, incompetent.

B

C

Gonna do recall me.

A

Remember this Joe.

A

We can start.

E

This is enough.

C

So if you're in TSP area you're in the right place- and that means we're in the right place too and if you're not in TSP area, you probably should be looking for. You are we're getting a start, just a couple minutes late, but that's not bad for slow start.

D

C

We have the blue sheets coming around, we have the blue sheets coming around and we have an area director doing a last-minute grab of a scribe.

C

This will take just a moment. Well, while we're doing that, you can review the note well, which is much like what else you will see this week as the second slide in pretty much every presentation.

C

So we are Monday afternoon session 3 with this agenda. Is there anything that we did? Anybody needs to do to the agenda that we need to fetch it.

C

Hearing, no other unis hurry, no suggestion, so we will. We will love blow forward so.

D

Yeah I found a minute taken to mean time, so thank you. Magnus.

C

Excellent, we always we always try to say thank you to the TSP area. Review team and I want to do a special thanks this time to the people on the triage team, Wes, Magnus and Martin.

C

This is this is gonna. This is looking good now, and this is looking better I think this is going to be looking better in the next IETF cycle, but we're way more hooked into the data tracker. Now that we have been and the request tools and stuff like that. So what to thank the people who did whose names are in bold, who did reviews for us and these reviews really helped I mean we.

C

We, both both Mary and I, have balloted fairly serious ballots. Basically, you know this started out with the transport area review team reviews. So thank you for that talk a little bit about the updates I'm gonna just blow through mine, real fast, the delay-tolerant networking. The best draft for the bundle protocol is past working group last call the TCP Convergys layers and working list group call and BP sack is still in progress. I ppm the fun thing I wanted to do, for that was.

C

We are finally updating our CE 23:34 ipv6, because we hear that's going to catch on that's in an ad evaluation right now and there I wanted to also notice that there were nine working group drafts or revised for this ITF meeting so pretty in pump two about that. Nfsv4 is not meeting at IETF 101, because they're at a hackathon. That is an excused absence.

C

Quick continues to focus on the quick core protocol specifications for a quick version, one in November taps since the last ITF recharter to announce analysis of transport security protocols as well. Those were explicitly out of scope when we chartered caps they're explicitly in scope now and they're gonna they're, going to be spending some time on that some enjoyment of time. On that this, this meeting, if I remember it correctly, tram, is finishing up their final deliverables. Stun bisque is on the next hello, Chad and turn business in working group.

C

Last call and tspwd is indescribable because they have 11 working group drafts that were updated for this ITF meeting Maria. Would you like to share your thoughts so.

D

I, just I just want to highlight those groups that are trying to wrap up some of the work so also is really trying to finish their current milestones and tcp inc is basically mostly done. The one of the document is already approved, the other one is in I hg evaluation and the third one we will process, hopefully quickly so I hope, I can press some clothes working, Go button suit.

C

C

Especially when the documents are met, I'm sorry did I say that out loud all right, we should have introduced ourselves, so you are yeah.

D

C

Spencer Dawkins I am the outgoing area, transport transfer area director and that's next March, but I want to get used to you guys hearing it so I want to get used it.

C

We got lots of stuff done and the thing I want to call a special, especially attention to this time is the number of things that slid all the way throughout being are published. Rfc's I'm I'm getting really impressed at the stuff that is coming out of the working groups on my side of transport, I, hope, you're. Having the same experience.

A

C

But I mean like we haven't had one that was mostly RFC's published since I. You know, since I joined the ISG, so I say thank you for continuing to do a lot of work and continuing to do work that is easier to get through the publication process and into a form that people that more people will see it and more people will use it.

C

D

C

We wanted, we were doing a. We were doing a short advertisement for this draft from Fernanda, and this is about ipv6 address usage recommendations, it's being chatted about, and taps taps is actually working on things like connection racing they've been thinking about things like choosing between paths and choosing between transport protocols, but there's also choosing between IP address families. Topic that's relevant and the answer you get is probably going to depend on how you do the right, how you do the racing we're not going to talk about that in here.

C

Please keep an eye on it if you're interested, because the impact is way wider than taps thanks.

C

We would like to call Tommy Pauly to the stand and to talk about experience with tcp encapsulation for Ike yeah.

D

And after the presentation, we will have a little bit room for open discussions, because we see more and more protocols that request TCP encapsulation and we would like to get some community feedback on those approaches.

F

All right, hello, everyone, I'm, Tommy Pauly from Apple and the area directors asked me to just talk about some tcp encapsulation experience that we've had. This is mainly just one use case that we've had or using TCP as a encapsulation tunneling strategy that we have done in the IETF and we've also done measurements around. There definitely others, but hopefully this can give a starting to the conversation and some light into that all right. So next slide, please so all right, so why?

F

Why are we looking at TCP encapsulation at all, so we were looking at this for Ike and IPSec over UDP traffic, particularly in the cases in which Nats and firewalls are badly treating our UDP traffic. This is not everywhere, but when it happens, it's pretty bad.

F

So, even in the good cases in which UDP can get through the networks ESP traditionally, when it's going over a NAT recommends having a 20-second keepalive timeout so that you send a if there's no other traffic, you send a UDP packet every 20 seconds, just to keep the NAT happy, that's pretty terrible for radios and power.

F

But then, beyond that, as of when we started this work back in 2015, we were seeing somewhere between three and eight percent, just total failures for getting any responses over UDP these. This is generally to be port 540 500, and that generally is not too terrible of an issue.

F

Traditionally, we think of I can IPSec being used for VPN access, so sometimes that just doesn't work when you're at your hotel sucks.

F

Other strategies include a lot of proprietary, TCP or TLS based VPN solutions which are presumably doing something like T speaking capsulation, but they're, not quite public about how it's being done, but this became more of a problem because we were using ike for doing things like Wi-Fi calling. So this is telling back to your carrier and so, if you're, roaming, internationally and you're at your hotel- and you want to make a phone call and that just would fail all the time because of you being blocked.

F

That was a more critical problem than just the enterprise use case, so it had more visibility for us and so there's mainly being blocked on captive net works. Hotel networks, cafe, networks, enterprise networks, I think we saw higher failure rates in like Asia other. It was less of a problem in some of the US markets and more of a problem internationally and of course, TCP gets through the networks with a much higher success rate and, to some degree it's even better when you just look like HTTP traffic, so next slide all right perfect.

F

So what this turned into as work was something that has been published in RFC. This is RFC, eight two to nine, which is T speaking capsulation for ICANN IPSec. So what it defines is how to take a series of traditional UDP, iq2, packets and traditionally UDP encapsulated ESP packets that normally go over port 4,500 and stick them over some stream. um So the RFC defines sending those messages over port 4540 CP. um You can configure other ports if you need to get through evil middleboxes, but as ITF we don't like sanctioning that usage.

F

We decided to begin the stream with a stream prefix such that whoever opens the connection sends essentially a little bit of magic, bytes saying that I'm doing this TCP encapsulation thing. The main point there was that we are concerned that there are existing deployments of proprietary.

F

Non-Standard iq2 over tcp implementations that have been broadened by other companies and we wanted to really differentiate this standards-based version from those the actual strategy of encapsulation is very, very simple. You just have a 16-bit length field at the beginning of every otherwise Datagram and you send that and then you send what you would send us your Datagram and then you send them a length field, etc, etc. So it's really really minimal. Essentially just takes your traditional IP packets and put UDP packets and sends them over the tcp stream.

F

Instead, this is kind of multiplexing multiple protocols here, because we are running, I can DSP, but luckily this particular issue was already taken care of by UDP encapsulation for ESP, so that strategy is putting if the first four bytes of the message are all zero, then it's ike. Otherwise it's going to be ESP packet, so it's a multiplexing basic tcp, encapsulation stream, so it works, that's how it functions, but then how does actually perform and when do we want to do this or not next slide?

F

So there definitely are concerns with this approach. We recommend quite strongly in the document that it is only something that you should be using as I can fall back when you don't have access to network over UDP, or there are particular problems with that. So there are a number of issues that we were concerned about and we tried to measure and look into so. The first is around what happens when you have TCP within TCP and when you're dealing with packet loss generally, what this happen will have.

F

What happens here is a loss on the outer TCP connection turns into what just looks like a delay to the interior TCP connections, because it's going to be a reliable stream on the outside and will eventually deliver the lost packet from the perspective of the interconnections.

F

So this can induce a fair amount of burstiness so that you won't see a lot of loss but you'll see a whole bunch of retransmits or other things on the interior connection coming at once.

F

We also ran into concerns with window size issues, because if you have the two, if you have inter connections and outer connections, especially when you're running ESP within this and so you're running, two levels of TCP they'll both have to do a slow start, and if there are problems that occur on the connection, it's much more likely that the interior connection will kind of fall back into a slow start and overreact.

F

When there are any issues on the connection and, of course, whenever you're running something over TCP, that's not traditionally over TCP you're, adding a lot of head of line blocking and reordering that you wouldn't have over UDP. So if you are doing multiple streams here on, that does cause issues and later on Stewart. If you would like to comment anything I'm sewer is also involved in a lot of the measurements and discussions around this one. We were first looking at it back next slide.

F

So when we were first doing this, we did run a number of performance tests to try to understand. How is this TCP encapsulation thing going to affect our traffic, so the setup was that we had essentially just a standard, vanilla, IQ, VPN server and in front of it was put the relay box. That would do the translation from the TCP encapsulation into the standard, UDP packets that were going to be expected by that VPN server.

F

The client side was modified to take the packets that was already going to send frankly to in ESP and just encapsulate them like we've mentioned before into that TCP stream, and then for the actual performance tests. We ran multiple instances of I prefer doing TCP through that tunnel to see how it would be affected by various changes, and so, when we're doing those tests, we had several variables that we were looking at first. What is the strategy for encapsulation, so we ran as a control just iperf without any tunneling at all.

F

We ran it with just ESP directly over IP, so a completely uninhabited version of that, but still using encryption on a tunnel. We ran that with ESP over UD piece of the standard encapsulation and then also ESP over TCP, so using TCP encapsulation and in the two ways that we tried to impair. The link were to induce a fixed random loss between zero and three percent I'm using a Sarah router.

F

This is fixed and random, so it's not necessarily truly realistic, but it's a number and value that we can look at to get a good picture of what are the basic reactions of a tcp encapsulated connection here and then also we modified the delay anywhere between zero and 500 milliseconds added in this error, router so next time.

F

So here's the basic results that we saw when we were playing with loss. So the top blue line that looks pretty good is just the iperf over just a direct connection, no ESP going on at all.

F

So we see here that we're on around 100 megabit link and then, as we increase loss up to 3%, that does degrade fairly strongly the green and yellow lines which are the ESP directly and ESP over UDP track pretty closely to each other. They do degrade pretty quickly when you have loss, and this is just having the normal encrypted non TCP encapsulated link get impaired by loss. He was interesting what we saw when we did run it over TCP, actually at the lower levels of loss.

F

We saw a better performance overall for the throughput and we believe that's mainly because the loss was being hidden and turned into a somewhat minor delay, and so the interior connections wouldn't actually see the same negative effects until it got much worse, but once we reach around 3%, then the throughput for that T screencaps of the link does tank and become quite bad.

F

So, while it's good it's pretty good and while when it's bad, it's quite bad, but when your alternative is essentially no connectivity whatsoever- and you also take into account that even the onion capsulated versions at 3% loss are relatively poor compared to the normal case. We believe this was a reasonable trade-off to take.

F

And now, on the delay side, we saw slightly less impact again. The uninhabited unencrypted version does quite well and then the TSP capsulated version tracks pretty closely with what we see for the UDP and IP encapsulated versions of the same test. So on that and it was relatively performant.

F

G

Last one so.

F

The conclusions we drew from this were that the TCP encapsulation does work and is certainly preferable to no connectivity at all. When we have UDP ace protocols, we did make sure to do this in ITF, because we wanted to have an actual standard solution for doing a TCP or TLS based VPN, which was not possible before the performance is tolerable.

F

It degrades roughly at the same points as the other approaches, but it does have some pathological cases and I'm sure that if you did a more thorough investigation of this, there would definitely be certain scenarios that behave quite badly with TCP within TCP some of the areas that we think could be very interesting to look at.

F

If we do see this become more common, that we have TCP encapsulation as a strategy is tuning that outer TCP connection, maybe make it a little bit more intelligent about what traffic is going through it, especially when we have multiple TCP s within each other may be interesting to see what are the right ways to pass ecn markings through? Should you even create your own ECM markings when you know you're experiencing loss on the outside? Should there be any coordination of the window sizes of the various connections with each other?

F

Some of those approaches, we believe, could mitigate some of the pathological cases, but we haven't fully explored those. So that's it any.

C

Questions please come to the mic. Please remember to state your name as you're talking for the describes. Thank you. Hi.

H

Vladimir o'donnell UPB, so I've had a bit of success: running TCP inside of TCP. If I marked the TCP packets, with congestion experienced whenever the the outer connection experienced losses. Okay,.

F

Yes, that was one of the approaches we were thinking of so and that works great I mean.

H

It doesn't work perfectly, but nothing.

F

Ok, Tom Herbert, so when I first saw this presentation, I was slightly alarmed because I thought this is gonna, be stt. Are you familiar with that? No yeah so ftt? The idea was to use TCP as a header form. Oh.

C

F

Know they were encapsulating with that? No so recognize one slide one just to make sure this is encapsulation within an actual.

C

F

E

It have a question on.

F

The performance when you consider in the UDP case, if Packers are out of order, you can actually deliver out of order packets, whereas in TCP you have to wait for all of that.

F

Did that have an impact on performance so in these particular tests, not so much because they weren't really targeting that I think but I think you definitely would see that, especially if you had more connections running in parallel that you don't that when we're running I prefeer they already required a fair amount of in order miss between them, because there was a lot of packets there. But if you have a lot of bursty small connections, I really have no relationship to each other, then I imagined it would be a lot worse.

F

Whenever there was a loss or delay emerges.

I

Whose multipath TCP.

J

My name is Joe Cheshire from Apple I. Think. The thing that told me was hinting at earlier relates to this a couple of years ago. We did some work with John Iyengar recently at Google, and he had when it was a research professor had a protocol called minyan, there was an extension to TCP allowed delivery out of order, and we were very excited that this would give big benefits and it didn't- and it was kind of a surprise and it turned out the TCP in order.

J

Delivery model is actually not bad, because most applications need data in order as a HTML page or a style sheet or a video stream doesn't work. If you're missing the iframe, then all the P frames and B frames that depend on it can't be decoded and when the packet loss rate is only one or two percent. Most of the data is in order. So the number of opportunities you have to deliver. Data out of order is small and the number of situations where that's helpful is even smaller.

J

So that was educational, because we've gone into this confident that media would show these huge benefits and we were kind of surprised that not as much.

F

Well, that makes me think like if we had some use case not like the current use cases that you mentioned, that was naturally much more lost, tolerant. That expected like, as we see these particular modes, we were putting over here, already degraded heavily. Whenever you hit three percent loss, if you had another type of load, which was perfectly happy to receive a bunch of loss on you to be connection, then it would see a much worse decoration by adding it yeah.

J

I think a lot of the thinking in this space goes back a long way before TCP had fast retransmit and if you lost a packet you're waiting for a timeout that was a huge performance penalty with fast retransmit. It's one round-trip later the missing data is filled in so you're left with the sweet spot for this out of order. Delivery is stuff where one round trip is too long to wait and.

C

J

Applies for videoconferencing, person-to-person. It doesn't even really apply for YouTube or Netflix for that fixed video streaming, because a half-second playback buffer is ample to cover one round-trip and the.

F

Fast retransmit here is critical to making this work well,.

I

Last I heard so I wonder if the stats are shown in the beginning about UDP, not working over a bunch of paths. Have you seen any change in the last three years? Has it gotten better I? Don't.

F

Have the updated numbers on that I was looking for that, as I was putting the slides together, um no I mean it seems to be relatively similar to what I've seen for the quick UDP intolerance numbers that were given initially asking because sort of three.

I

Years is basically the time creek has been around yeah, so one prediction could be that if quick gets deployed more, it's gonna push UDP into networks where it currently doesn't work. Well, simply because people will want to fix that alright, so there's there's one potential future, where the need for this kind of accent, encapsulation might go away because CBP is going to work better. However, we don't know right, and it's.

F

Still a concern that, even if UDP packets do make it through, and maybe only certain ports for quick, would make it through that the net timeouts for UDP ports that are not well recognized are not going to be treated well in lieu of some other connection type header. So the cases which I need to be able to receive a phone call and I'm just sentry camping on a NAT for a really really long time sometimes does work better. When we have a TCP connection to leave that NAT mapping of them, but.

I

It doesn't do anything for knots, I.

K

Ritchie from Telecom Polytech ah I was looking at the first bullet here and I'm thinking. If a protocol is being designed to use UDP, there is a reason so maybe doesn't want all the heavy machinery that comes with TCP. Now you put that protocol on TCP is.

K

There is any negative impact on the from the TCP machinery on the protocol. Have you thought about that? Yes,.

F

I mean I think all of the things that were looking at here are the negative side effects that were having from using TCP instead of UDP. This particular case I, imagine, is one of the worst, because the previous use of UDP was to tunnel many many many TCP connections in all of their IP packets case, in which you really don't want any relationship between the delivery of those packets and so I. Imagine other direct UDP applications that aren't necessarily about tunneling would experience similar effects, but hopefully less than this.

F

K

Me be introduced. Ok, what if there is I mean a way to turn off the congestion control or some part of the machinery of DCP, when the purpose is just to go through right.

F

And that source of getting to some of these other approaches of oh just use, TCP as the header to her and I that gets into a pretty messy space. I think.

D

So, thank you very much. Thank.

C

You very much yeah.

D

I think this was really good to understand the main use case we see and some of the problems, so we would like to actually get some feedback for the whole community. Can you go on? The next slide should be another one yeah one more I should say this was just a few. Oh, this is not really how it's supposed to be so I'm.

D

Just speaking, just out of my head, I put up some fewer seats that were recently published and drafts that are kind of under submission, or a work really work in progress already work in progress. That kind of cope was the same use case and the same problems.

D

So we see this more and more often, it's not like one one use case where we will receive mail box problems and where people think that disappear in collab encapsulation might be the solution to their problem and therefore, basically, what we would like to ask the community is two questions. First of all, what do we think about this? Is this an acceptable approach? Do we know any better and no matter what we think about it? Can we do?

D

We have to provide more guidance to the rest of the community outside of the transport area, how to do TCP and collect encapsulation correctly any thoughts.

F

Hi Tommy, so just one part based on that, the RFC that we did for Ike was in the security area. So it's not a group of people who are used to transport.

F

Necessarily, it was very useful to get the transfer orders review on it, but when we were doing it, it would have been really useful if we had a document to refer to that essentially gave here the guidelines on how to do this, and when it's a good idea to do it or not, and the pitfalls that you'll hit and we essentially wrote up at large. You know performance considerations section in there and it would have been great to have just another RFC to point to you like. Look at this. This explains all the problems.

F

D

Nike to other areas, it's also not clear that like TCP streaming protocol and UDP the data one protocol, and if you put data on the streaming protocol, then you probably need to figure out where your message starts name. So these are like very general stuff. We think they are not very complicated, but writing them down, as reference might make sense.

L

All right burned, Ram I got up because nobody was getting up. No and yes, one. No yes, um question for Tommy. um You've done a lot of the work in order to like make this document makes sense. You already did a lot of the work for writing the guidelines document can like. Can we use that text as a starting place? Yes, I think we should do that and I think I mean I think it should be. You know there should be. It should probably.

L

Capture than no answer in one, but it's like yeah, don't do this, but we know you're gonna, do it anyway. So here's how not to blow your feet off right if.

D

You know if people have this problem and the ant says: don't use. Tcp can capsulation and what's the what's, the alternative right.

L

They're gonna do something even worse: free, like.

D

Anything well, for example, we.

L

Just heard you can put TCP headers on things that aren't TCP, so that would be another way to do it so um yeah, it's I mean we're here so and actually I. Even this was a Pecha Kucha slide of mine right. What happens when you run TCP and TCP, and that was I realized when you were giving this talk. That was in the pre fast recovery era right that was, and that was in the 90s when, like yes, anything.

C

L

If you look at it funny al RTO and that's gone away now and okay, so I mean which means if it works. If these sort of approaches work as well as they do up to three percent loss, then you know I, don't how many, how many VPNs are running over PPP over SSH and I'll? Probably a lot um and yeah I think that I think that a guidelines document here would be useful and I think you should offer it because you already wrote half the text so cool thanks.

G

Kyle arrows so I was just thinking about the question that was asked earlier about. You know what, if the title protocol doesn't like what TCP is doing somehow that got me thinking about what could be one allocation of that, and maybe the protocol running over UDP actually cares about packet loss. That tells us something about the network, or maybe it's trying to figure out information for the network to maybe fall back on something else.

G

If there is packet loss, would it be possible to push you know, give access to that information, those metrics from the TCP layer up to the upper layer protocol, so.

F

This kind of reminds me of the guidelines for ecn in tunneling protocols. I think a lot of synergy there. So if I'm running something that is expecting like as an application, I'm expecting UDP but I happen to be tunnel over TCP I could either see the idea of OTP gets a loss. It actually fixes it, but then it tells the application.

F

Oh you lost the Packer, it just never delivers it, so you could do that or you could deliver the UDP Datagram, but make sure that the UDP API gives sufficient signaling of ecn bits, and essentially you add, on a an explicit congestion experienced bit onto there to make it look like hey it's as if a router saw a loss, so you should react as if there is that. So that's a good reason to have ucn api is for UDP, which would also be useful for quick.

I

Largos quickly, gonna reply to this with this API exists already. If you look at TCP info, for example, right you need a poll it kind of, but but it does tell you when your TCP connection, retransmits and- and you can, you don't see the loss. But but if you see that counter go up, you can sort of infer that something has happened at a lower layer. um It's an ugly API and it's not not at all related to any. You know socket API or that, but it is there on many platforms right and.

F

That also gets into how do we expose TSP capsulation, because one approach to doing is kind of make it hidden for the application just take their packets and stuff them in a TCP pipe? If they are aware that they're going over TCP, then they could check this.

M

Pet J holin, the milk box, seems to be the problem here. It's dropping VP right so without insight into the reasons that they're dropping UDP or do we have this insight? Is that documented anywhere, like I'm, not really clear, whether encapsulating in TCP is just going to also get blocked after dpi and then it'll have to be inside TLS and yeah I mean yes.

F

But you can put it inside TLS and put it over a report for four three. So.

M

Is that going to be the next step of the recommendation if we make the TCP I, don't.

F

Think we want to recommend that so the that was an interesting line we flirted with for the IKE stuff, and essentially we just defined here's, how you put it over a stream and left it at that. I mean.

M

Is there a channel to provide suggestions for standards for middle boxes.

M

Maybe that sounds good. Sorry.

D

But just because we read something in an RFC, it might not happen. You know and I'm not sure if, if it makes even if the situation gets better, it might not make this case going completely away, because in some cases your business cannot risk to just have not connectivity. So you really want to have a solution. I.

N

Bhisma understand you: KP is mostly used for real-time service, even yes, peace. You take, for example, in the enterprise there was a key in the prior in the enterprise. What he used also used the USP, a yes V, but my concern for your performances. You're only talking about the delay or not a loss rate and the performance of the circuit, but there is no loss rate and the delay because for the was a peon other, will you attend service a delay and is very critical or summer time service?

N

Former insignia- and you know some these performance tests and some or some other words for the world, IP sign so I kind of reassess what n7 maybe have some problems in there and the price? Yes,.

F

I definitely think that if you are running a YouTube protocol, that's being used for real time services calling and stuff, then the effects of the delay. The the bursty delay that you get from fixing up the loss on the other TCP connection would be fairly visible in certain cases and.

N

Also, we have I used some TCP to different the defense service, but for the TCP, even though she used PSAP, because this secret lambo dependence so even use this reason, mmm no use for the TCP connections, so I mean my main concerns how to support some your tongue there's some different service. If it is being solution, is used.

F

Right- and there is definitely an open question of what do you do with per packet markings like ecn or essentially the traffic class markings on packets when you're putting them inside a stream and they're different, you could say drop them. You could say, apply them if they're uniform within that segment, that you read that you're transmitting, but that would need to be discussed.

C

So Spencer Dawkins the responsible area director for a few, a working groups that are relevant to about what I'm about to say first, is, it seems, like you know, as we're headed this direction. Also.

C

The taps working group, when we charred it was, was pretty yo, Pete Resnick leaned over to me during the buff and said this is right on the hairy edge between research and engineering, but I like it, and you know now we're saying you know now we're saying: oh well, you know, but we need to be looking at this purity trace for security protocols as we were picking a we're picking a path you know and we're saying.

C

Oh, we need to be looking at address families as we're picking a path and I'm waiting for somebody to send me a charter request for a recharger request for technical taps. It says we need to be looking at things like loss rates and stuff like that. So we'll know whether to start doing things like that. So this, the second thing I was gonna, say I'm taking off my 80 hat. The second thing I was going to say, was if I knew anything when I got to the ITF.

C

It was that you know running running tcp over x.25 was the wrong thing to do, and that was that was a long time ago, and it's I think it's really a good good thing for us to say you know well with Destry transmitted.

C

You can get away with a lot of stuff that you couldn't get away with when you really had to reliability, mechanisms that were beating on each other a lot more a lot more violently than what you were seeing was beating on it to each other, and the third thing, I want to say is I'm waiting for the day that you know says: quick runs over UDP and it has really state-of-the-art at loss.

C

Recovery, I'm waiting to see if anybody tries to run that over TCP as a fallback and now I'll go sit back on the stage. You're welcome.

J

Hi Stuart Church again I just came up to answer the question that Jake asked about why we have short timeouts for UDP and I. Think it's a good question, because we often forget the reason for that in the ITF. We generally don't like middleboxes, but there are places where they provide a useful service. The battery on my phone would run down if random strangers could bombarded with packets, so I'm actually glad that my phone carrier has some kind of stateful firewall.

J

Maybe not an ass baby doesn't need to translate these expresses, but I do want it to I. Do want it to block wanted traffic and I think that will continue to be true for battery-powered devices and many other cases. So TCP has a thin bit. The middle box knows when the connection is over and because of that it can keep the state trusting the client to give it a fin bit and say I'm done now.

J

As long as UDP has no fin bits, the middle box will just accumulate piles of stale State to never know when they were done so UDP I think inevitably has to have short timeouts and I I worked on PCP port control protocol, which was an attempt to provide signalling there, but I don't think there are enough incentives for carriers to deploy that. So we're back stuck with there being no way to know when a UDP flow is over one option.

F

Which would be interesting to consider is if quick being over UDP provides the correct, signaling and middleboxes do adopt that connection, because this connection went away type of signaling for quick. How hard would it be to essentially take the approach? That's bad for TCP of Oh send it in something that looks like TCP, but don't really do TCP to do that with a quick wire format to say, let's send what looks like a quick packet, but not actually be running reliability within it and just use that as your encapsulation method, I have.

J

Not been following quick closely: is there a move to put a visible fin bit equivalent in quick that middleboxes could see I.

C

Would defer to the people in the room who would know the answer to that question as of about two hours ago,.

J

Okay sounds like no pressure: I Brian.

L

Trammell it's been discussed, there was an if you filed. um There was not really interest in it, because the working group didn't see it as problem that you know this.

J

K

L

The the so I think.

K

We don't care as long as I.

L

Think, what's in the zero-one of either the applicability your manager or should be in there is hey you're gonna be dealing with short timeouts. So if you don't have anything to send over 30 minutes, that's why you have a pink rim right! That's the 30! Second I said 30 minutes yeah 30 seconds, yes, Oh, ping, ping, Aubry ping. Every fast is the is the guidance now, if that's not what it should be.

L

There's a working group and there's a github and you can probably a few again but I, don't think there's a lot of appetite for that.

C

Yeah, and and thank you all thank you all for the clue on that Kylie.

G

Rose, so this goes back to some. It's related to the you know, quick discussion, and someone just pointed out that you know why? Don't we just use quick with that reliability and assume that that's gonna somehow keep the firewall state open earlier we discussed just using a TCP header with no no TCP stuff involved. What if we use the state machine of TCP, but not the congestion, control and sorry the recovery mechanisms? Reliability?

G

Would that be horribly breaking or.

J

What you're describing pretty much is Jana Iyengar's research work, which was called minion. He had a bunch of academic papers and we had an implementation of using something that looks like TCP, so it gets through the network, but actually we can do our own thing inside the payload and what we found is you end up having to mimic TCP so closely that you are in fact TCP one of the things about minion? Was it had a mechanism to skip retransmissions?

J

If the data was timely and it was stale, it will just skip the sequence number ahead. There were enough middle boxes that would recognize that as bogus and tear down their connection, so we had to retransmit the data we didn't want anyway, but as long as that was only less than 1% of the traffic, it wasn't a significant overhead to send the data we didn't want and with fast retransmit it's only one. Round-Trip latest ended back with TCP I love.

C

The Internet I just like to say that I.

M

J holin again I just want to mention that there was a set of drafts called Plus that tried to talk about this very problem. As I recall, it got a mixed reception sort of and that's.

C

Fair I was sitting at the front of the room. That's fair, yeah.

M

So I mean this is the maybe the question is: is the recommendation that we should release mechanisms in light of the feedback that was given then to address this problem? That is still present for you to be I.

D

C

To but I don't think that's.

D

The solution people look forward to right now, because it's something that Nick has certain deployment effort and will not happen tomorrow.

I

Not not talking about plus so one difference with quick in the space event so because of 0rg t. If the client actually has a pretty low overhead of just establish a new connection and then finally state x out, however, you still have the problem. What if you know you want a connection open without pinging constantly, and that is not solved, but at least these sort of overhead, if you have a tcp / yeah TLS over tcp with opening a new connection is gone or not nearly as bad.

F

Right and to that point, the reason that this came up for us with Ike was not about outbound connections, because I has mobike we can re-establish in one RTT it's great. The problem was that we were using these connections to receive incoming phone calls and we need to be camped, and so, if we ever want to use some variation, maybe it's quick v2 or something like that to receive incoming connection incoming pings on a long live like push style connection, then we'll need something to indicate to the network that I'm still around.

F

Don't kill me right and right now.

L

That's pink right right now! That's right!.

F

But that, but yes that drains your battery yeah.

L

Great right exactly, but so you.

I

Go ahead because I'm probably.

L

Gonna say what I've got to.

I

Get to translate so um the the problem with its pinyin is probably gonna stay ping, and the reason is that, even if we did put the bits on UDP traffic by the time middle box gets up to actually do something. Different will be pretty long. Given the update cycles. And um how do you know before you send the traffic or even while you send a traffic, that you have a path where you have such a middle box? So you don't have to don't have to ping so frequently.

F

Yeah you do there.

I

Are mechanisms to.

G

Do that no binding.

F

Time but a couple times right, you you, you start with a somewhat something low and then you just wait slightly longer. You keep increasing the time out between writings, ten seconds until you lose it. It only helps you out for a long time where you don't move. That's true. That's true, but four mechanisms that do need a long live connection to receive incoming phone calls. If I can do this discovery mechanism over the first hour, I'm in my hotel and then be able to only send a ping every hour from that point on, it's.

L

Yeah, the PLP tod path, packetization, lair path, I'm not discovery, yeah.

C

If I could, if I could just.

A

C

Thing here my close personal friend, Aaron Falk, is in the process now I. Think of trying to figure out. If we're supposed to be doing another hot RC, lightning talk around later in the week I, don't you know, I mean he's trying to figure that out I think he put out a doodle poll saying you know, would you know, do you need to you need to do this, and would you come and stuff like that? I haven't looked at the doodle poll, but whatever he asked he's asked.

C

If that, if that happens, I would recommend that somebody get up and say that and see who follows them out of the room.

L

Okay, good point: um I did actually the thing that I was gonna, say what Laura said. I do actually want to get up and say that again, so what Laura said? No, with respect to a stop bit on on quick, a reason not to do that is okay, we're uncertain if it would get used and for the current application. That quite cares about which is HTTP as HTTP is often used, but not always used like there.

L

There are things that do stuff with WebSockets that are gonna fall over in interesting ways, but for right now for vanilla, HTTP, 3 or whatever gonna call it over quick. It doesn't really get you anything and during for the deployment lifetime at version, 1 yeah, the the deployment of middle box will be negligible, but it's probably something that should be raised when we talk about putting other applications on top of it, because there are applications where having a long-lived connection, where any either side could decide at some point to send on you need to.

L

You need to know that that stage there and maybe that maybe the solution is feel PT whatever timeout discovery. And maybe the solution is some sort of signal, ni discovery, plus some sort of signaling, when the hope that the some sort of signaling will use the feature or.

F

Alternatively, the recommendation, at least in the meantime, is you have a TCP connection open to receive that right.

L

No, you can you do quick, yes to it,.

F

L

You could do that to print.

F

L

Could migrate the crypto, yeah, ok, yeah, Christmas, stuff.

C

Ok, cool Thanks, if I could do just a ad interrupting here, we bet. Is it seven more minutes? Is that right and and we try, we always try to end TSP area. Would the opportunity for the community to get up and tell us the IDS? What the ADEs need to know is. It was anybody planning on saying anything get over in my time and if you are to like it just displace your hand, so we'll know I guess.

D

We're actually wrapping up this discussion anyway, so yeah I'm happy that nobody freaked out and screamed at me when I saw it set TCP encapsulation, that's a good sign, I think there's interest in getting providing guidelines and you committed yourself right now. Okay, perfect sure, perfect, say it any more people who wants to help just contact, Tommy and I think that would go to T's woodworking group. Actually, we don't want to see arrogance.

D

I'm, also happy that people have a lot of ideas about what to do about n capsulation. So we should keep talking and thank you very much for this discussion. So now, if you have any other thing, you want to scream at us, go to the mic.

D

I'm taking this as a sign that everybody's.

O

Absolutely happy with our work great: let's go for dinner, good steak! You all.

C

Travel safely out of here and travel safely into Montreal and hi to our listeners at home, bye, bye.