Internet Engineering Task Force 111, 29 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-PANRG-20210729-2330

Description

PANRG meeting session at IETF111
2021/07/29 2330

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

A

Okay, let's start on time, so welcome to our networking research group. Brian, unfortunately, is not with us today, because he had to make a hard choice between this session and his vacation. As you can see, he did the right. He made the right choice. So that's going to be interesting because I'm going to do it single-handed, let's see how good I am at multitasking, which probably means I might miss something in the chat room.

A

So please, let me know if I miss anything important so note. Well, I hope it's the right one, I'm quite sure, we've seen it before you've seen it before, I'm not going to read it out loud.

A

So if it's the first time you see this slide, please look at the meeting materials and the agenda and make yourself familiar.

A

It's all been recorded, including the chat by the way so think twice before making jokes. There.

A

Housekeeping first of all, please, unless it's your turn in the queue or you're presenting keep your audio and video turned off. If you want to comment, raise your hand, wait for your turn and then send out your video.

A

It would be really nice if you don't forget to leave the queue it would prevent some confusion on my side. I guess: we've all learned it, because it's already thursday on friday for me that, if you cannot hear me, it probably means you should turn off your vpn.

A

I don't want to expect you to stay your name out loud and affiliation as well, because in most cases we can see who is speaking, but it still might be a good idea.

A

uh Dear speakers, I hope we all gonna use this share, preloaded slide presentation, so you can control it. Let me know if you want me to advance slides for you. uh The biggest problem we have right now. So we cannot proceed is that we need a minutes taker and, as we now going to call it jabber medium someone who will convey the messages from the chat room and make sure that I am not missing them. Please we need volunteers.

A

Thank you teresa for being away medium. We still need the minutes. Takers.

A

Come on, I know it's a hard job, but I kind of do everything not today.

A

We need a new feature in meet echo right when a random participant is selected is volunteered as a minutes taker.

A

Come on, we have 65 people out of those 64. Someone definitely could take minutes. We cannot proceed as far as I know. If you don't have minutes taken.

A

I cannot ever bribe you by offering a drink not on the virtual meetings.

B

This suspense, I can do that, but uh it would be extremely good if somebody was over there um at least checking my work and, of course uh anybody can be in the anybody can be in the uh kova kovmd uh uh document.

B

You know anyway, so anyway, I'll see if I can get started and- uh and please uh do corrections even if you're not hi,.

A

Thank you, spencer and tom for helping yeah. I guess tom. Your help will be needed when spencer is present. In particular. Thank you very much. So we have a full agenda.

A

So let's try to be on time and before we proceed uh what's going on in the group. First of all, congratulations, everyone and spencer, in particular, for publishing our first rfc of obstacles to deployment great job. I'm really happy to see it happening. Surprisingly, it was. It was published before the question draft question draft is currently in the rsg poll, so hopefully we'll see it as published document as well soon, and we have one active research group document which will be actually the next presentation so cereal. The floor is yours.

C

Okay, uh can you hear me.

A

I yes, I guess I shall share slide. You, okay, request.

C

A

Brill, yes, I think it's what I I'm doing the right thing now.

A

Yes, okay, I can see your slides now.

C

Okay, perfect, so yeah. Let me get started um so today, I'll present um the new revision that we did on the vocabulary of path properties draft. I think it will probably not take 10 minutes. So since you have full agenda, I guess that's a good thing um yeah. So, first of all, thanks for all the for all the um participation, the mailing list and for the good feedback.

C

So one of the main things we did is we revised our transparency property.

C

So the transparency property is now defined as follows: if a node performs an action on a flow transparently, with respect to some meter information, if it performs the action independently of this given meter information, so this transparency property is defined on a flow with respect to an action. Sorry, this transparency property is defined on a node with respect to an action, a flow and some meter information, and we defined some examples of actions.

C

But this list is non-exhaustive, so actions can be blocking packets, modifying either packet headers or packet, payloads, or forwarding packets, on specific outgoing interfaces, for example, and then the meta information can, for example, be the existence or the content of the different protocol, headers and also of the payloads.

C

So the main difference to the last revision is that we more clearly defined this this item, so we more clearly find the actions and the informations and we defined them on on the flow instead of on the packet as it was before.

C

To give you some examples here we have this table with three columns. The left column shows a type of node and in the middle and right column, we can see whether this node is transparent to transport, layer, headers so, for example, tcp and udp headers, and whether it's transparent to ib headers.

C

So first, you have a very simple ip router which decides where to forward the packet based on the ip header so based on destination ip address. However, it does not even need to look at the tcp and udp headers, so it's transparent to them. However, it's not transparent to the ip headers, and then we have kind of the opposite, which is a very simple firewall rule which simply blocks incoming tcp syn packets.

C

So such a node would be actually transparent to ip header, since it doesn't even look at information in the ip header to decide whether to block.

C

However, it will not be transparent to the tcp and utp header contents, since it performs the action blocking based on the content on these headers, and then we have a network address translation node, which is neither transparent to the transport layer headers nor to the ip headers, since it might block packets, it might forward them to different on different outgoing interfaces and they might even modify the port or ip addresses for numbers or ip addresses, and then there so. The term transparency is also used in other ietf draft, and this sparked some confusion.

C

So we added a node which says, um for example, a transparent http proxy, which modifies some mutable fields in the http header would not be considered transparent. Given this definition and in the same vein, the in the transport protocol path signals rfc a node reacting to either implicit or explicit path. Signals would also not be considered transparent.

C

However, the way we define this transparency property is that it's easily extendable, so that you could, for example, define a specific action for hdd proxy, which says um only modify um immutable, http fields, and then you could still define transparency in this way. But we do not want to um try to come up with all possible transparency examples. So we try to give some intuition and then make this definition. Extendable.

C

uh The second big change since the last revision is that we added the formal definition of the term entity, so we actually already had this term and we used it, but we didn't give a formal definition, which was slightly confusing.

C

So now we defined an entity as kind of the most basic term in our document, so an entity can be a physical device or a virtual device or just a function applied over a pack set of packets.

C

It can be an onpath entity, so basically a node or it can be off path and it can be in the data plane or in the control plane. For example, um a cdn controller is a sdn controller, an entity can process packet, they can measure path properties and it could also access. Informations information gathered about specific paths and basically, every node is an entity.

C

However, not every node, not every entity, is a node, so I said before an sdn controller may be off path and thus not be a node.

C

Yes, these are the two main changes.

C

So if you have any thoughts on the this transparency definition or the new entity definition, please um comment here or on the mailing list later and one other item was: do you think this document is ready for last call or are there still big issues that need to resolve need to be resolved?

C

um Yeah? So that's it for the presentation.

C

Please ask questions.

A

Yeah questions.

A

Okay, sabine, please.

A

Please go ahead.

D

Sabine. Okay, can you hear me? Yes, um can you get back on the previous slide, please regarding.

E

D

D

Well, I would figure out an entity as being some part uh characterized with respect to the fact that it is some part in the network, but uh also.

D

So you also characterize it with respect to some actions.

D

So do you um so this seems it seems that there are maybe like two several parameters that characterize an entity and that characterize the fact that it is an entity for example. Here in your bullets, I would figure uh the the the one of the parameters would be, what it is, what animal.

E

In the network.

D

It is a part of a path, a device or a functionality, and also a role. Do you have such characteristics for entities.

C

We don't have these characteristics right now, so the the way we use entity in in this document is to describe, as you said, something in the network, essentially anything in the network. And then, if you want to be more specific, we have a lot of terms, for example, a node which is on path, a host which is generally at the end, a link which connects two nodes. So we have all these terms building on top of an entity. That's why an entity can is kind of the anything term, but we didn't clearly define it before.

C

So we just try to use this anything term to then define further more useful um terms.

D

And then uh just a quick question, so do you foresee to uh specify a set of parameters that would uh characterize an entity and also a set of parameters that would characterize the fact that it is.

F

C

um Yes, we do it in we do it by by like kind of them, this inheritance style right, but um to define it for the ante itself might also be interesting to look at.

C

I need to think about it um which of these classification would make sense or would be useful to have in our terminology, but I think there might be merit to to already kind of classifying the entity definition so specializing. It.

D

Okay, thank you.

A

Okay, so we have 30 seconds so one last question and I'll close the queue robert.

F

Can I ask a question.

A

Yeah yeah, I should have, should have started yeah after you. After you close the queue yeah go ahead.

F

Okay, I'm richer, so uh two questions number one. I likely that you mentioned uh the entity somehow should be in the context of inheritance, for example in I want to look at, of course, I'm I menu. I look at entity. I would map it to concept like, for example, the object class in java, but the reason why you introduce object class is essential server as some kind of root object. Is you want to introduce all kinds of functions right, clone equals finalize and you put a bunch of object into it. Therefore, you do wait notify.

F

So what exactly some functions you invent some very common functions. Would you you envisioned? Would it be would exist across all kind of entities? Do you have even some kind of very concrete functions you have in.

C

C

F

I am, I lost hello.

G

No cyril's audio seems to be off so, if I may jump in as the other author of draft, um you.

F

Can't share it.

G

Yeah sure so um we uh so we as we say we don't have like a formal classification of entities or properties of entities, but we do already mention different entities in our use cases section right. We talk about path, selection and there could be an entity on the path doing the path selection. There could also be an entity of the path uh to do path, selection, and so I guess that would be a starting point. If we are going to have more.

F

Yeah, because the main reason you introduce entity is something like you, you know you introduce a root object, essentially you're doing some kind of like a refactoring, and you want to extract some common property, for example. In this context, I would imagine you want to have some kind of common id every entity would have common id somehow, then it makes sense, but otherwise, if you have no, I have term, but without any like a binding properties. It sounds a little bit too abstract and therefore somehow oftentimes.

F

This type of, like a good object, should be somehow deleted from the the class hierarchy.

G

Okay, yeah will think about that.

F

Okay, so a second, very quick question: can I second question? Oh okay,.

A

Quickly, quickly,.

F

Okay, so second question would be what's the purpose of defining transparency and what kind of accuracy do you want? For example, and I took a very quick look at your definition of transparency- I will look at essentially defined. You can be defining a very precisely using mathematical expression.

F

Basically, you define that it's transparent to a to a field basically means you're transparent to a set, and you always get the same value right and you always get the same value. Would that be considered as transparent or so what exactly all can be? Maybe, for example, if I have a firewall on that, I would always what no matter what it is. I would always always put the same value. Would that be transparent?

F

um Yes, I think.

C

You might shouldn't.

F

Even read, for example, I'm sorry like in the card, there are two ways you can program. Language design. One way is no matter. What I do I return constant. Second one is even from my team's analysis. I should not even look at your code if I look at I'm tinted, so therefore, I'm not transparent so which one are you you're trying to go? Go ahead.

A

Why is give a quick answer? And I think we should take the rest of it to the list, because we are like out of time sorry.

C

um Yeah because I don't have an exam- maybe let's just discuss it on the mailing list and continue.

A

Cool, thank you, so spencer, you are next. This is another path topic, past selection,.

A

A

Okay, yeah, do I do you want to use the preloaded slide, so you want me to.

B

Is it okay, if you do the slides.

A

I do the slides okay yeah. I can do the slides okay.

E

A

Okay, sorry sure okay looks good.

B

Yes, thank you, um and uh so this is uh talking about something that I've been talking about in the ietf for a while and probably needs to be talked about in the ietf irtf more than it needs to be talked about the ietf.

B

um This is uh talking about path selection when you've got multiple paths at a pretty high level, so stepping back next slide. Please.

B

So we've had multipath transport protocols, some tsp for a while we've had them for tcp uh we've had them for sctp. uh We just we're starting we're, starting to start an adoption, call for dccp multipath in tsp working group, as opposed as of this morning, um and we've been talking about that for quick, never mind.

B

uh So there are a bunch of interesting technical questions like uh multi-path, sequencing and loss uh detection and congestion control and reordering and stuff like that, but there's a less technical question I wanted to focus on, which is what are applications? Try actually trying to do. uh There have been a lot of use cases put forward in discussions, especially in the quick working group, and not a lot of commonality between use cases. So I wanted to step back and ask how many path selection strategies are enough.

B

I got this question from christian wiedema on a previous document next slide, please.

B

So here's what I've seen so far and these links are actually active if people have curiosities uh in the in the slide deck that's in the proceedings, but there are at least 10 past selection strategies that were described in discussions in the quick working group. So far, that's been the that's been the most active place for talking about use cases that I'm aware of um the number of desired strategies is growing over time, and it's not obvious to me that there's an upper bound on the number of strategies.

B

uh There is a um very children's fairy tale about uh goldilocks of the three bears and the uh the uh punchline, for that was uh something is too big or too small, or you know, is never just right um and that's kind of how I feel about uh the path selection strategies.

B

uh Just using three that are uh described in more detail in the draft uh you could have.

B

You know I want to go for the path with the lowest rtt or I want to go for uh the path with any path that has a rtt below a certain threshold, or I want to use all you use all the paths that have roughly equivalent rtt those are really close together and that's interesting um and the other thing that's gotten really ugly in discussions uh is that the arbitrary combinations of of past election strategies um is not just possible.

B

It's already happening, it's happening uh in uh ietf and in three hbp, where uh which is another place? A lot of this stuff has been uh talked about, and uh so um next slide, please so that you know and, like I said, I've got. These are all live links if you look more closely um just because we don't have unlimited time here, but my question was: can you rather than continue to ask past election strategies? Can we identify building blocks and use them to use?

B

Do strategies support these strategies, and the thing I wanted to focus on here is that there was another strategy that was described in an arw paper this week earlier this week, so um uh cheapest, uh cheap uh selected, cheapest path. So that's not any of these, but you know anyway, um so next slide, please.

B

So what I'd like to do is to uh assume that multiple active paths is going to become more realistic over time, not just use wi-fi when you got wi-fi and 5g when you don't, uh even even at 3gbp now right now uh there are. There is the concept of having uh 5g or 4g or public wi-fi in a couple of different variations or private wi-fi, and uh we could talk. You know we could talk about that.

B

So the definition of the goal for path splitting would be beyond utilizing all available bandwidth across two paths, which is kind of where we are right. Now um I, what I'd like to do is trim down the strategies as much as possible.

B

I think we could eliminate- maybe a couple of them just based on um just based on how similar they are, but they're not the same but um and whether you know like latency versus bandwidth is a uh is a strategy, but no one chooses high latency um and but I want to more than that, identify building blocks to assemble and support new strategies.

B

So next slide, please.

B

So here's why I'd like to do that? There's some implementers that really can't handle multi-paths just by today, either doing a granular control uh which we can talk about in more detail. Certainly the nice people at apple have have talked about that in more detail um or bandwidth, aggregation which, which was a common use, which was a common conversation in 3gpp and in places like the broadband forum and stuff like that either granular control or bandwidth aggregation.

B

Yeah glad, I said great, I think we're really at the beginning of making multi-path broadly usable I'd like to make it easier to use for applications uh kind of basically saying well if multipath multiple paths are available, why wouldn't you use them, but using using multiple paths means different things for different use cases.

B

I'd like to support multi-cath without cut requiring constant library upgrades. You know questions like how many selection strategies do you put in the library how many libraries do you ship with a application and at least some strategies get standardized, so there's more maintenance work as they get added with no upper bound uh next slide.

B

So um these are the things I'm hoping that we will talk about, um and uh the first one is is this research? uh I actually was kind of pleased to hear.

B

Martin duke uh say earlier today that uh he thought a lot of the.

B

High level uh discussion about multipath really really was research and not engineering. So I'm feeling I feel like at least somebody agrees that that might be a good place that the prg or someplace like it would be a good place to have that conversation.

B

I'd like to find out if it's interesting to anybody and I'd like to think of people, I'd like to find out if people think it's doable and of course do you want to help. um We can talk here and we've got about seven and a half minutes to talk, and we can talk about and gather, and we can talk on the mailing list and we can talk about github uh there's.

B

Actually, uh if you look at my draft, there's actually a github repo um that accepts issues and things like that also uh that was, I believe, my last slide. uh No, let me put yeah, please go to my last slide and then come back to this one.

B

Thank you all. Please make good choices now, let's go back.

A

Okay, cool the reason.

G

uh I liked your draft, I read it, uh it's interesting it it's well in this group I would say- and I am willing to help by reviewing, for example,.

B

uh Thank you, uh tom you're, taking notes right now and please make sure you get uh get theresa's name. If you don't get anybody else's name.

H

They don't worry, that's next.

F

I did really very quickly. This is richard and I found a problem to be very interesting, but I also want to see that actually, it can be very hard depends on what kind of outcome you want. For example, for example, uh I'm going to send you a link which I have a paper, uh I think it's become 2018.

F

paper is called the trident and if you look at table 1 of that paper, the sitcom 2018 called the trident paper. We have something called the result. Algebra basically means that one we will call it out. We don't call the path, but somehow you can think about it somehow very similar to a path in some sense. Okay, and we tried very hard to come up with something called algebra. If you read it, essentially, we define around like eight nine operators.

F

Therefore, every single operation like australia, you you mentioned, can be somehow composed you using this call something called algebra, but I still remember those three years ago and obviously come reviewers like. Why is this a framework complete and why this optimal all kinds of things, which I don't know how to answer so, I presume I think you are trying to somehow coming out, because you want to talk about all the 10 strategies. Do you have some kind of algebra to essentially to be minimal?

F

Yes, and I can send the link and of course uh we can of course talk offline.

B

uh Yeah, uh can I can I ask you to send the link to the uh to the uh penalty mailing list and uh we'll make sure that it gets into the minutes. Also.

B

I I appreciate that uh a lot lot lot and uh that's exactly the kind of thing I'm hoping for the other thing that I didn't you know, because we have a short period of time uh to talk about. Was um that not all these? Not all these uh strategies are at the same level, uh so you know so so uh you know some of them were pretty high level. Some of them are at the at the level of of you know, especially once you start combining things to say. Well, you know I have.

B

I have three paths, so that's like close load, chair, uh load balancing, but when one of them goes away, I want to. I want to fell over to the two passes, still work. So that's like something else. So um let me say I I I look. I look forward to seeing the paper and uh I look forward to continue discussions and penalty cool anybody else.

A

Perfect, thank you. I think we're getting back on track time, wise, which is just fantastic. Okay,.

B

There's no way, there's no way that brian will ever believe that I stopped talking early. So uh tell him. Tell me what a good job you're doing. We.

A

Have a video proof of this and by the way I would I do prefer people to have communication about this on the mailing list, or maybe on github and mailing lists at least important things. Please keep them in the mailing list as well. Even if you discuss them offline somewhere. Okay, let me stop sharing slides terminal next.

A

Okay, do you? Are you going to yeah? Okay, let me grant you permissions.

H

I've never used these buttons before.

A

You shiny thing should work. Okay. Let me stop this one. Okay,.

A

I'm gonna start the timer for you.

H

Awesome hi, I'm uh I'm tom jones, I'm a researcher at the university of aberdeen. um We have written this draft, um we've called it transport for satellite. We think with tsvwg prefix. There might be temporary, but we'll see.

H

um We've we've written this document because there's been work in the ietf on satellite systems in the past and there's increased interest now, um but the most contemporary work on transport protocols and satellite came out of the tcp set working group that uh concluded in 2000, tcp, sat produced, two documents at 24, 88 and 2760 and 2488 did a really good job of describing the physical characteristics that limit geostationary satellite communication, um and it suggested some improvements and 2760 followed up with tcp changes, which were experimental at the time that really helped the protocol communicate better when used in a geostationary satellite situation.

H

If you look at these now, they're they're out of date in respect to tcp and the numbers other than the physical content, constants are sort of out of date as well to what satellite services have so satellite services today are are much much faster.

H

um Sadly, tcp over satellite, the speed comes uh from peps rather than the protocol itself, uh and so we have a situation where peps are sort of a key component to geocommunication and peps are also a deployment barrier for other protocols and so perhaps make it hard to deploy tcp modifications over time. um They drop a lot of support for things they make it.

H

They make the satellite component of the path invisible, actually to a lot of networks uh and they're now impossible with quick, because the split tcp model of operation is gone with uh encrypted, authenticated transport uh and now we're starting to see a wider range of satcom systems come into view, so we're seeing larger deployments of of leo systems and we're seeing deployments of mio systems, and so we tried to to write this document to try and capture some of this.

H

We think that satellite systems require path awareness. I I think you could reasonably say that the pep, so the performance enhancing proxy in a satellite system is, is path aware. It knows what is happening inside the network, and it knows it has this long delay, and that is part of. Why is able to accelerate connections so well um and we have satellite topologies in in all sorts of different forms as well? So we're not just talking about um internet looking paths. Look like broadband internet.

H

We see big distribution networks where we have point-to-point links where we're pushing out video. um We see transit networks and we're starting to talk about um almost uh delay, tolerant networking style like blob networks that we can use in the satellite, and so we we have this uh network component. That has many different views to it and it is becoming part of an end-to-end path um and user traffic gets to experience the the interesting components of satellite as well and so satellite capacity.

H

uh We have long variable delays and we have wide range of access to leds, and so this can make it a bit hard.

H

So we've written this draft. The draft originally started as advice for quick because there's a lot of concern in the in the the geo market. That uh quick was just not really going to work very well. uh Early results showed that quick uh did was reasonably competitive compared to tcp with a pet, so quick actually got a nice feather in its cap, um and so I'm just rushing up trying to finish so we can talk, um and so we've laid out the document uh in a way following from uh 2480.

H

So the document originally came from quick and it was very quick centric. But I came and joined the author team and I thought maybe we'd better try and offer generalized advice to the designer of transport protocols and and how the considerations of of satellite networks uh lead on to these.

H

And so we have a new format where we talk about the different types of networks and then how these networks mitigate the complexities of satellite networks, and then we hope to talk more in detail about different protocols, and so we are going to find it really easy to get tcp specific mechanisms for geo and maybe a bit harder to get more magazines for other places. There is ongoing work uh to look it quick uh and so for panergy. We have a couple of questions for you. um We we think this is.

H

This is great and we think this is a sort of a core area where path awareness is required and we need to design around this and we'd really like to generate advice for transport protocol. Authors we'd like there to be a document to point out in the future, so you can say um that this is why you need to be able to deal with like long rtts or this is why you need to deal with massive spikes in uh in latency.

H

uh We need input from people that uh operate leo and mio networks, um operators, users, people receiving selling the networks. We really appreciate input because we're sort of lacking in information here and then for pan rg. We wonder if this is work that is of interest to pan energy. We think it might be because the path component is so core and we'd love to hear people's thoughts on how we should move forward with the draft.

H

A

Okay, yeah and after gory I'll close the line because we have about four minutes for people in the queue.

B

So I just wanted uh suspense. uh I just wanted to say that um thank you for bringing this work here and uh the the generalization that you're talking about and the focus on uh advice to pro transport protocol designers. um That's the way that the pill working group uh work uh with with uh wanting you know one. You know. Basically, if you, if you look at uh the output of the concluded uh pill, quirky group uh there's a rfc number, which I don't remember what the rsc number is, but it's advice to some network designers.

B

uh That's that's again, very generalized. So what you're talking about is very consistent with uh what we've, what we've, uh what we've done in the past that worked well. Thank you.

H

If you could follow up with the rfc spencer, that'd be really nice.

A

Okay, hisham you're next.

E

So have you done work on the convergence of terrestrial networks and satellite networks.

H

Are you talking about um handover where you might have uh redundant links? Is that some sort of situation you're talking.

E

uh About when one one idea, the other one is instead of using links between certain lights, we can use links on telstarian networks.

H

Yeah- and so we do have a section talking- uh we have a section left open for for hybrid deployments, um but what we need is information about real networks and, ideally, networks that we can experiment inside of, uh and that would help us uh characterize the network so that we can uh create advice for the designers of transport protocols. And so we are.

H

We are happy to consider um a variety of different networks, though particularly we're focused on satcom and this sort of leo geo meal deployments uh and networks that we can play with we'd love to play with.

E

So what what what forum you mentioned, you said you have a forum about hybrid networks,.

H

Right so in the in the document right now, we've left a section open, so we can talk about hybrid networks um right now. Discussion for this is happening on the the e2 e2sat uh itf mailing list uh and I'll pull up that and put in a note in the minutes after I stopped speaking.

E

That would be good. Thank.

H

G

Okay, yeah quick comment, so I read your draft. I liked it. I think it's. uh It fits well into a penergy as well, because it's a specific example of path. Awareness like you list path, properties that some entity is aware of, I would say, and then uh and then you optimize, so I would say: maybe it's not just advice to protocol designers. It could also be some protocol configuration right, so your your pathway entity could say.

G

Oh maybe quick should use a specific algorithm because it's on a satellite network- or maybe your tcp parameters- could be in some way because it's on a satellite network- and so maybe maybe that would um fit in there as well. I'm not sure.

H

Yeah thanks teresa. That's actually that's really helpful so for for tcp. We have a hard experience with this, because you have to tune buffers to make tcp go fast when you don't have a pep, um and so specifics for for tcp and quick could be actually quite interesting to include in the document, if not in an appendix, so that at least that information is captured thanks.

A

A

um We can't hear you if you're speaking,.

A

A

A

Okay looks like we have some audio issue, or maybe he's just speechless so excited.

H

He's just so happy.

A

Yeah, nothing to add here right, girl, okay, so I don't know I gotta wait. You can put your questions in the chat or in the my link list so tom. I suggest you forward the draft to the mailing list right and we can continue discussions there. Okay, yeah cool, okay! Thank you! So what are you next.

A

Let me grant all the exploits okay and okay I'll start.

I

Timer, do you hear me well.

A

Yes, we don't hear you loud and clear. That's.

E

A

I still do not see it happening for some reason.

I

I don't see those lights here. Yes,.

A

That's that's interesting. There we.

I

Go, can I try? Yes, I got it. Okay. Yes, all right, uh you see the slides, don't you all right! Thank you very much.

D

I

So I wanted to talk about the lightning filter, which is a product that we have developed as a showcase for drk.

I

uh The the particular thing with um with this filter is that it's high speed- and it's um quite that expensive. So I think it could be interesting for um for developing later drk and also to start a discussion. Maybe maybe people will will find out that this is a an interesting thing to to talk about all right. So this is the uh the index. I just left it here uh for anybody later to take a look at the slides.

I

Maybe the high level characteristics of the filter is that, of course, it's based on the arche, and that makes it suitable for high-speed connections uh which at the moment is running with uh four times.

I

40 gigabits a second uh ethernet cards running actually in a normal pc, uh quite an expensive, as I was saying before, um the um the thing is that every packet is uh source, authenticated cryptographically and that the speed of the filter doesn't depend on the number of flows or centers, actually also not, of course, a number of paths, but only the number of packets that are transiting that filter I'm going to be using this um scenario, this deployment scenario for the presentation.

I

This is the science dmz, the uh in which, on the right hand, side. On top of this slide, we can see this kind of computing cluster that is accessible uh from a set of clients that is predefined at the beginning, and nobody else is able to access them.

I

Traditionally there will be a normal fireball, so a traditional firewall over there, but the problem is that they are typically quite expensive if we wanted to run at 200 or 200 gigabits. A second, and thus the deployment that we have done in this scenarios is replacing that firewall with a lagging filter. Some of the different deployments we co-locate the the filter with a with a traditional fireball, but in this one would be just replacing the firewall completely.

I

So the the basic architecture for the filter is um well the data plane we'll see that in the next slide. But it's just the filters themselves is a modular design and then we just rearrange the uh the pipeline as we as we find suits the control plane. Is there just to support the data plane, of course, and uh in the presentation I'm just going to be talking about the fetching of the drks themselves, because the other parts are just quite standard all right. So this is the pipeline of the filter itself on the left.

I

We have the entry or the entry point of a new packet arriving. We just have the top of um of the pipeline taking care of the regular iep and this forward into the traditional firewall. Then we have that uh distinction between ipm scion, which is just a path of where um architecture run with the r key. And then, if that's the case, we just do the uh the normal work for the filter then check that the destination is not saturated. We can configure a rate limit for that destination.

I

If that is the case, we just drop the packet. Otherwise we continue and we do the check of the uh the source authentication for that for that packet. I'm gonna be talking about that one in particular, then, if that is correct, then we go on and we check for duplicates. If that is not a duplicate, we would forward it to the uh computational cluster.

I

In that case, all right, um so drk is kind of necessary in this in this product in this uh filter, because otherwise we wouldn't be able to process at that speed and so that we we need to process packets in nanoseconds really, even even with, um because we want to run it in a like. We said in a normal pc and then that would be impossible to be to derive keys using, for instance, asymmetric cryptography. We have to use this kind of different techniques um also because we can source authenticate each one of the packets.

I

We are going to prevent source spoofing source address, spoofing and also um it makes sense now to do a duplicate, suppression or duplicate detection, because now it's not trivial to to have a different packet. So we can, for instance, use bloom filters uh to detect duplicates easily and just uh for anybody that would be interested in this in the drk terminology.

I

Slow path is, is the client or the different clients that we have sending data to the um um filter or to the computational cluster and the the fast path is the uh the filter itself, so that, yes, with the filter, leaves all right. Just as a quick reminder, I think I still have some two minutes left. um The the communication in the r key is about oh well. All the the procedure is about exchanging the keys and then deriving keys later from that case that we haven't exchanged.

I

So we have three different levels: zero, one and two levels here is just the secret: there's, never like leaving the the aes itself and it has tight or bound a validity period. Then we have level one which is just uh the the keys used to communicate between pairs of aess, always with a fast and slow side for the derivation.

I

And then we have the level two key, which is the actual key that we use to compute the mac of each one of the packets. Those uh that key in particular level. Two key is going to be derived live every time that we see a packet, but that's derived in nanoseconds. It's faster than an actual memory lookup.

I

This is going to be interesting, interesting also for um what we want to do later, which will be introducing um authentication of each one of these steps that we have taken along a path and thus path validation and um an authentication whether we have traversed that path or not, and that's the reason that we also want to take a look at the r key for path. Aware.

I

Networks um in this slide we're just seeing an exchange of another one key, which is just a regular thing that we do in the control plane, meaning that we do that ahead of time. Typically, like two periods ahead of time or one and a half periods ahead of time. um So in this case we have just one aes with some clients over there and then the asb is where our filter lives. And since we have that scenario configured, we know that we have to retrieve the l1 so the level one key for the asa.

I

We do that with every aes, where we have clients configured in this mode of operation, we have to retrieve the old ones. um If we wouldn't know um the different sources, we would have to choose a different um configuration for drk, which we actually share a bound to protocol levels hierarchy instead of a level monkey.

I

So I think that was that was the the end of of the presentation. I would love to have some questions about either the visibility of some scenarios or drk itself. Thank you very.

A

Much so, oh god, I can't get back to the so, do you have anyone on the pew? Sorry, my browser is misbehaving now, uh so no one.

A

Okay, so thank you juan. Maybe you can send it here to the mailing list and unfortunately I found the list been rather quiet recently.

I

So maybe you can.

A

Send it and bring some lives there yeah anyway, we just have one minute, so maybe people have comments, but they are so substantial. They don't want.

I

Of course, the mailing list would be a great forum to to ask.

A

Questions yeah, so please do. uh Okay and last but not least, tony gonna tell us about passover, routing.

J

A

J

The document sharing thing.

A

Yeah grinding all yours.

J

Alrighty, hello, everyone, I'm sorry! I was just coming over from the iab open meeting, so I apologize that I missed all the other lovely presentations earlier, um but thanks for giving me this little bit of time.

J

So I wanted to share some thoughts about um kind of pathway, routing based on some work that we're currently doing in deployment for uh deploying some mass proxies and I'd love to see how these topics could converge in the future.

J

So as a background, um the kind of production product that we're doing right now is in ios, 15 and mac os monterey, which are the current betas. We have a new feature called icloud private relay and it's a it's. A user privacy feature that's trying to separate out client ips from origin servers, um and it's based on two fundamental technologies.

J

uh One is mask proxies, which are quick, http 3 based proxies, and we have a multi-hop network of these to make sure all the data is separated. Think like like a mini tor like thing and then we're also using oblivious dns over https for all other traffic. That's not fully proxied!

J

Okay, so why? Why is this here like? Why is a privacy proxy relevant for pathway, aware networking, um and I think it you know actually is pretty relevant, because if you look at the architecture that we're working with uh you have kind of maps that look like this, in which you, uh when you're trying to get to any particular destination.

J

We now um have a lot more choices that the client can make, and this is true for tor and stuff today. But with these mask proxies, we actually have a lot of different ways. We can choose to route traffic along different nodes and combine them and figure out many many different paths through this, and this is something in the architecture that we have. The client is in control of and has awareness of, mainly as a privacy thing, but it also opens up a lot of path-aware properties in general.

J

So there are some. You know: privacy benefits that we get from having path, awareness and path control. So the clients can learn about a diverse set of different proxy hops and try to route their traffic in a way that makes it less likely that they're going to be tracked.

J

They have control over which jobs are used, and this uh where things are going, where you're actually routing on your path, because these are secure. Quick handshaked uh proxies you're, validating the identity of every node along the path, so you're really sure where you're going um and it's separating the data out of who can see your ip address versus who can see where you're going and that improves privacy and you're also able to switch paths periodically and rotate them to make sure that you're not sending all of your data to one spot.

J

So they can collect a lot of information about you. So those are good privacy benefits, but then there's also a lot of good performance benefits and that's, I think, some of the things that we normally would talk about in this group.

J

You have the fact that I can select an egress proxy, so the thing that I'm going out of to be very optimally co-located with the content right now. The things that are hosting these proxies for us are some of the biggest cdns in the world, and so we're able to get right to their content while also doing uh this uh privacy, preserving mechanism and um the clients also have the ability to switch over and fail over between different paths as they realize that maybe one is broken or there's a better performance on another path.

J

They can choose to switch and do measurements on these also because this is using quick, quick supports migration, and so um there are avenues that we have still yet to fully explore about. You know what it means to do: um uh migration across different paths, so you can have like your final egress proxy, be stable, but end up. Trying migrating that connection over many other different intermediate proxies and see which combination ends up working best.

J

One of the things that we've also been you know trying to make sure of here is that by using a proxy, you don't have to have the thing that people often think about of as like, oh vpns and tor is going to be slow.

J

um Proxy connections are actually really great because you can kind of always fast open on them.

J

There's a thing that we're working on in mask to make the proxy a quick aware, so it's able to forward packets without any re-encapsulation and be very, very efficient, and so in a way you can think of these proxies as really just uh authenticated and validated nats or routers that you can essentially prove which natural routers you're putting information through but other than that they're really just forwarding encrypted packets up and down the stream.

J

um And then so you know this right now is something that we're doing as a particular deployment of a product, but we'd like to see it kind of expand in use case, um there's new work that can be done on how you do. How do you discover new proxies and new paths you can take? How can you discover which hosts are have better affinity towards specific content that you can reach, and I think there are a lot of really interesting research topics that we could do around?

J

How do you migrate traffic efficiently and split different connections on different paths through proxies to optimize traffic and then you're kind of looking forward? If we see things like mass proxies become more ubiquitous, and I know there are proposals for them to be used for different three gpp um technologies.

J

You could imagine you know ingress proxies being hosted in all isps and carriers having specialized ones for zero rating and different paths that they can take different purposes.

J

Egress proxies essentially hosted by content, and so we're allowed then to have really really good privacy, but also have really cool properties about path selection anyway. So this is just a topic I wanted to introduce to this group and get people's thoughts on. We are out of time. I know, um but I'd love, to hear what people think and we can talk about it on the mailing list too or in the chat.

A

Thank you very much tony. This is really exciting. Actually, so we have strictly speaking one minute for the session time but yeah if people willing to stay a bit longer. I don't know so spencer.

B

Tommy, are you going to be in gather after this and that will hang up yeah the.

A

Point good point:.

J

Yeah yeah, we could do that.

A

Okay, in this case, this concludes the session. Thank you very much everyone. I think, we'll need to schedule a longer session next time so see you and in the next 30 years. Thank you very much, especially for those who uh I was taking many meeting minutes and was looking at the jabber. Thank you very much.

A