Internet Engineering Task Force 109, 20 Nov 2020

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: IETF109 IRTF Open

Description

The Internet Research Task Force (IRTF) Open session from the IETF 109 meeting.

A

Okay, people are still joining so we'll give it a couple of minutes. um Can I just uh check that the audio is coming through and everyone can see the slides.

B

It looks and sounds fine to me.

A

Excellent thank.

A

A

Okay, so the uh the rate at which people are joining seems to be uh slowing down, so I guess we'll get started. um Welcome everyone to the final session of uh the uh itf 109, um sadly not in bangkok. uh I hope the time zone for you is is not too painful. Wherever you are, I I realize it's, it's not great for some of the people, but uh I hope you you've uh survived the week in whatever time zone you're on uh and I'm looking forward to some some interesting talks. To finish up.

A

uh This is the irtf open meeting. uh My name is colin perkins, I'm the irtf chair.

A

So to start up, uh we have the the usual uh notes. Well, uh the intellectual property statement, um just to a reminder that uh anything you say um in in the mic line or in the chat is covered by the uh the no well disclosures. um So please pay attention to that and I'm sure you, you know the rules by now.

A

um In addition, um we have a privacy policy and a code of conduct um be aware that uh the meeting is being recorded uh and I believe it's being streamed, live on youtube. So uh anything you uh you say, uh may be public and may be recorded.

A

um In addition, we have the code of conduct the ansi harassment policies, uh so please be uh respectful uh in the uh discussions. So this is the irtf open meeting. um The irtf uh is a parallel organization to the ietf which focuses on longer-term research issues related to the internet.

A

Unlike the ietf, the irtf is not a standards development organization, it does research rather than developing standards and while it can publish experimental or informational rfcs, the primary goal of the irtf is to promote development of research, promote collaboration and teamwork and try and get the research community and the engineering community the standards community talking to each other.

A

If you're not familiar with the work of the irtf rfc 7418 gives a really good primer targeted at atf participants.

A

If you want to find out about what we're doing, the irtf.org website has pointers to all the materials and all the research groups we're on twitter we're on facebook. We have um an announcement mailing list which is pretty light traffic, and we also have a discussion list. If you want to talk about any of the topics uh plus. Each of the research group lists has its updates, so research groups has its own mailing list, jabber room and so on.

A

Iotf is organized as a bunch of research groups. There are 14 research groups currently chartered those which are highlighted in in blue on the slide met this week. We also have interim meetings for some of the groups coming up. The information networking group has a meeting scheduled for, I believe, the first of december, uh the privacy enhancements uh an assessments. Research group was also talking about having a meeting in december um focused on ip address privacy.

A

If I remember correctly, I think there was some some talk about the thing to think research group also having a meeting, although I'm not sure that's been confirmed, so look out for those uh coming up over the next the next month or two um comment in the chat guy. I did not meet this time uh due to the uh the conflict with the um um internet governance forum. So yes, sorry about that. That's a mistake. In the slide, um we've also had um four recent rfcs published on the irtf stream.

A

uh A couple very recently, um the crypto forum group published an rfc talking about randomness improvements for security protocols. um The information-centric group has an rfc looking at research, direct directions, information-centric networking and disaster scenarios, um and there are a couple of earlier rfcs earlier in the year again from the icnrg looking at deployment uh considerations, information, centering networking uh and some some terminology.

A

um The uh crypto forum group has addressed on the argon 2 algorithm and the the network coding group has a group of network coding and satellites which are working their way through the process, and I expect they'll be going to the rfc editor very shortly, so to look out for those at any time.

A

In addition to all the research groups, we run in conjunction with the internet society, we run the applied networking research price.

A

The nrp is awarded to recognize the best recent results in applied networking uh to recognize interesting, new results and new ideas of potentially of relevance to the internet standards community and to recognize upcoming people that are likely to have an impact on internet standards and technologies.

A

In particular, we've got to focus on um bringing in people or ideas, though perhaps not otherwise get much exposure to the atf. The irtf community, perhaps not otherwise, be able to participate in the discussion.

A

The anrp works as uh as an annual nomination cycle, and then the talks happen spread over the the itf meetings in the coming year. uh The nominations for the 2021 awards are open. uh The deadline for nominations is the 22nd of november, which is this sunday.

A

um So if you know of any um any good applied, networking work uh any interesting people any interesting new ideas that it would be worth bringing into the ietf the irtf um and that you think, would be a suitable for this prize. Then please go to the irtf.org site at iotf.org, a nrp and fill out the nominations, and we encourage self nominations. If you think your work has is appropriate for the price.

A

And that brings us to the main focus of today's meeting, which is that we'll have three a rp prize winning talk talks today.

A

The first of these will be uh from deborah penn, who will talk about his work, uh designing uh network topologies for low earth orbit satellite constellations. um Georgia will be talking about her work on internet transparency and, uh finally, renisha will be uh talking about uh congestion control fairness uh and with that uh I'd like to pass over briefly to matt ford from the internet society, um who, I think, wants to say a few words uh to congratulate the the winners.

C

Thanks very much colin, I hope everyone can hear me.

A

A little quiet, maybe.

C

uh Maybe that's.

A

C

Yeah yeah, I just wanted to briefly say that it's a real honor for the internet society to be able to support the internet research task force in delivering the anrp.

C

uh It's certainly one of the most interesting and enjoyable parts of my job and whether in person or virtually, I always think that um a rp talks are a highlight of the ietf week and um we've got three great talks coming up today and it's great to see so many people online.

C

I know what is a fairly uh unpleasant hour for some um to to hear these to hear these talks. So that's great to see. I just wanted to say that we have had long-standing support from comcast and nbc universal to help us in supporting the prize. uh If you work for an organization that thinks this is a great initiative um and would like to see uh your name and on the list of sponsors for the anrp, please don't hesitate to get in touch with me thanks very much.

A

Okay, uh thanks matt, uh thanks again to to comcast and nbc universal for sponsoring this uh and uh congratulations to to to the winners, uh and so with that. uh The the agenda for the rest of the meeting uh will be the the free prize winning talks, um starting uh with deborah pam, uh then uh georgia and then renisha.

A

So the uh first talk, um and if, if me to go, can get the the the video ready. The first talk will be by deborapan, we'll be talking about network topology design at twenty seven thousand kilometers per hour.

A

uh Deborah pam is fifth year phd candidate, tth zurich and I I understand he'll be on the job market soon. So, uh if you you like this work, uh uh please chat to him afterwards. um His work focuses uh primarily on low latency network infrastructures, both terrestrial and satellites.

A

The work on topology design he presents today was published in acm connext 2019 and is one part of his work on new space satellite networking.

A

Okay uh miteko. If you can queue up the video.

D

Welcome to my talk on how to design a network's topology when its components are moving at speeds of 27 000 kilometers per hour.

D

Let me start by touching upon three fantastic recent advances in space technology, reusable boosters, which come back to earth after launching rockets, thus reducing launch costs, significant reduction in size and weight of satellites, thereby packing more satellites for launch reducing costs and automatic link tracking, which enables inter-satellite laser communication.

D

Products offering laser inter satellite connectivity at 10 to 20 g at distances up to 8 000 kilometers are already available. One caveat is that it takes a few seconds to tens of seconds to establish this laser isos. This will later be important when we discuss the various topology design challenges.

D

But what are all these developments leading up to? The primary goal is to build mega constellations consisting of thousands of low-flying satellites which provide global low-latency internet coverage. Spacex is leading the front. Their project is named starlink and they have already deployed more than 800 satellites in orbit.

D

During the first phase, they plan to deploy 1600 satellites and start providing internet coverage. Their long-term plan is to deploy tens of thousands of very low flying satellites.

D

Amazon is working on a similar project named creeper and plans to deploy more than 3000 satellites in three phases. With each phase having slightly differing configurations, various companies and startups have joined this race and have their projects at different levels of maturity.

D

We here explore how to connect satellites with each other in order to build such networks and deliver traffic effectively.

D

But before we discuss topology design, we will go through a primer, constellation design, followed by discussions on the challenges of leo networks and the utility of isls.

D

First, a brief primer on the proposed satellite constellations is necessary to set the context. How do we describe a constellation and what features distinguish this setting from traditional terrestrial networks? The first descriptive parameter I will mention, is altitude.

D

A geosynchronous or geosatellite has a height of 36, 000 kilometers and the minimum round-trip times or rtt's are nearly 240 milliseconds low earth orbit or leo satellites, on the other hand, fly at heights between 300 and 2000 kilometers, thus reducing rpts by more than 60x.

D

Another descriptor is orbital inclination. Each orbit here has several satellites while polar orbits travels over the poles. Orbits can also be inclined. Inclination is the angle between the orbit and the equator. Here. The inclination is 53 degrees, inclined, orbits, restrict satellites over densely populated, lower latitudes for polar orbits. The inclination is 90 degrees, laser or radio links can be used between satellites with laser, offering higher data rates.

D

Typically, there is a north-south, east-west connectivity pattern, which I will refer to throughout, as plus trade, to the best of our knowledge, all publicly available scientific papers, patents and visualizations assume the same plastic connectivity.

D

A key feature of these constellations promise connectivity is lower latency over distances beyond a few thousand kilometers.

D

In this example, we are seeing a path between zurich and mumbai over satellites, which is quite close to the geodesic compared to fiber, which is roughly 2x longer. The speed of light being two-third in fiber compared to free space means that the fiber path will be 3x higher latency.

D

We will refer to this inflation over geodesic, in this case 3x for fiber. As stretch we compared the rtds between the eight most popular cities over today's internet to the estimated rpts over a plastic constellation consisting of 1600 satellites, the estimated rtts are 70 lower than today's internet at the medium.

D

So if the current rtt is 100 milliseconds, the estimated rdp is 30 milliseconds.

D

The estimates for the satellite network are a bit optimistic, as we did not consider latency inflation due to encoding error, correction and other factors, but even a 20 increase in the estimate would result in an rt of 36 milliseconds, which is still significantly lower than today's internet.

D

We could also see from the plot that the latencies over satellite paths are very close to the geodesic latencies at the speed of light in vacuum. Let us now explore the system dynamics of these constellations. Satellites move very fast, related to the earth and with respect to each other. If a satellite is now over eastern brazil in six minutes, it will already reach africa crossing the entire atlantic traveling more than 500 kilometers per minute.

D

Such highly dynamic behavior translates to links becoming infeasible in minutes. We should keep this in mind while exploring topology design and prioritize links which are available for longer periods having gone through the primer. Let us now look at some of the challenges that arise due to the scale and extreme dynamicity of these mega constellation networks.

D

Our work at acm, hotmax 2018, discusses the opportunities and challenges of these networks in further details, of course, topology design is a challenge.

D

How do we define the trajectories of the satellites and set up inter-satellite links in order to serve the geographically distributed population, the various objectives, constraints and challenges, and geographically varying demands, make topology design a high dimensional, optimization problem? We do not yet know whether the starting constellation is the optimal solution to this.

D

Let us now see an interesting implication of a satellite autonomous system or ace on bgp routing. Each of the four terrestrial aces as1 through as4 here with the satellite ace, which is a set as1, has two equal ace length paths to as3 through as2 and asat.

D

The geographic distances could mean that, where ace is choosing louds based on latency as1 should prefer the telesteel route to h3. Likewise, as2 has two similar paths to as4.

D

As2 should ideally prefer satellite route to as4 in order to lower the latency. While it is already the case that aids path, lengths in today's internet are poor proxies for performance. These satellite networks may make this discrepancy larger in magnitude and more commonplace.

D

Let us now see how routing can be made, whether aware and what can be the implications.

D

Imagine this is the path through which data is delivered to the destination cloud cover can introduce significantly higher loss rates based on operating frequencies.

D

One approach to deal with this problem is to read out network traffic around such cloud cover this results in lower loss rates, but can increase the aggregate states of the network due to higher latencies. Let us now look at condition: control challenges.

D

This graph plots the time carrying latency between the two locations for a period of 2000 seconds at a granularity of one. Second, even recently proposed congestion control schemes like pcc, vivacy, vbr or coppa do not account for such variations in latency.

D

They either assume endpoint latency to be fixed or try to estimate the minimum latency to be the smallest scene over the last few round trips, any additional delay is considered as a mark of condition.

D

Note that such delay due to path latency and path changes, is highly predictable in satellite networks. Also frequent path changes result in packet, reordering, thus affecting even loss-based condition control schemes having gone through the general challenges. Let us quickly touch upon the utility of laser isos before we start discussing topology design our work at acm partners, 2020 discusses the benefits of having isos in further details.

D

Despite the high bandwidth low, latency isl promise, there is substantial uncertainty about whether or not leo constellations will successfully incorporate isls one huddle may be the burn on reentry requirement that regulators are asking operators to satisfy, thus not risking injury and damage from the orbiting satellites. In response, stalling's filings were amended to exclude mention of these components.

D

None of the hundreds of already deployed styling satellites feature isls.

D

Luckily, leo networks do not need isls to provide service. One might think how to achieve long distance, end-to-end connectivity when there are no isos remember as the constellations are being rolled out ground terminals would also be rolled out. These terminals include user terminals on land and those mounted on airplanes and ships, and also more powerful ground stations without isles connections between far separated ground terminals, bounce up and down between satellites and on path terminals yielding a bent pipe or bp connectivity.

D

Latency lowered than telescale internet can be often achieved over long distances. Even with this restricted bp connectivity, a paper in hot nets, 2019 focuses primarily on such latency benefits.

D

However, in our work we quantitatively show that, even with dense ground station deployments, there are three very significant downsides to forgoing isos.

D

Although vo networks without isl still provide low latency between many ground locations, the temporal variation in latencies increases substantially.

D

The network-wide throughput decreases heavily and the network becomes more vulnerable to weather disruption because of transit through satellite ground links.

D

In-Depth quantitative analysis of these downsides are in the paper in case you are interested, but to give some brief insight, let us touch upon temporal latency variations and impact of weather with bp. The path between massio in brazil and durban in south africa, for example, sees an inflation of 100 milliseconds over time.

D

This is because the density of air traffic is much faster over the south atlantic than the north. Hence the park often ends up using aircraft flying over the north atlantic. As intermediate hops note that this behavior not only inflates the rtt of this path significantly, but also makes the heavily used parts over the north atlantic even more congested by virtue of inter-satellite links in a dense deployment of satellites, such latency variations get reduced by as much as 80.

D

The impact of weather would be significantly higher on bp connectivity than on isl connectivity for paths consisting of isos. This value is either the first or last stop attenuation, whichever is worse, but for bp paths. This is the worst attenuation seen across all links of the zigzag path bouncing between the satellites and gt.

D

In this example, the heat map depicts the 99.5th percentile attenuation across southeast asia. Although both endpoints delhi and sydney are in low attention areas, dp ends up using intermediate hops in regions with higher attenuation.

D

In contrast, the isl path avoids this entire high attenuation region.

D

There are various other benefits of isls, which bp struggles with which I briefly touch upon.

D

Bp connectivity between certain sources and destinations is found to require gts in countries and regions that an operator would like to avoid either because of challenging topography or due to political reasons, car and kuban. Radio spectrum for the up and down links needs licensing.

D

In contrast, thanks to the narrow, beams and negligible interference issues inter-satellite laser connectivity is unlicensed. Gso satellites fly above the equator and operate in the same frequency. Bands sought for leo communication, thus leo satellites when crossing the lower latitudes near the equator, must avoid interference with gso satellites, while gt field of view is already restricted by the minimum angle of elevation. Gso arc avoidance makes this field of view even more restricted.

D

The impact of this will be much higher on bp than on isl connectivity for traffic between the northern and southern hemispheres.

D

Here is the latest update on the status of isls. In the september 3 launch video, a spacex personnel announced the testing of laser isles in leo, but a lot of uncertainties regarding iso still exist. What would be the link capacities in practice?

D

Link setup is constrained by the fact that it takes a few seconds to tens of seconds to establish laser. How do we connect satellites using isls, keeping in mind these constraints? This is what we discuss next.

D

Such analysis is also relevant for constellations like one way which do not plan to incorporate laser isos, okay, having gone through general challenges and the utility of having isles. We come back to the problem at hand. So how can we connect satellites in order to offer higher aggregate bandwidth, keeping in mind the dynamics of the system?

D

This work was published at acm conex 2019 and is the main focus of this talk. I will now discuss what are the constraints we consider and assumptions we make.

D

The key constraint of this system is system dynamics, satellites flying fast relative to the earth and to each other, but we have other constraints as follows: setting up links can take a few seconds to tens of seconds during which time the involved communication units cannot transfer data. Hence it's important to minimize changes in which links are connected.

D

Also, the maximum number of isls per satellite is limited in our work. We consider four isos per satellite following all recent fcc filings, but we believe our methods can be extended for other numbers.

D

I'll also lay out the assumptions we are making in solving the inter-satellite topology design problem. We assume that the satellite trajectories are given. We rely on fcc filings by spacex and amazon that describe their trajectories, while trajectory design in itself is an interesting question, we have not explored it in this work.

D

Knowing what precise traffic will be served on these constellations is difficult. Our evaluation uses traffic mattresses drawn from intuition, but the same approach can be used for arbitrary input traffic.

D

Our focus is on the satellite to satellite connectivity, so we assume that the ground satellite connectivity follows a simple range bounded model.

D

We treat plus quick connectivity, which I already touched upon earlier, as our baseline on the last point plus grid being the baseline. What are we trying to improve? One drawback of these very local links to adjacent satellites is that one requires large number of ops to reach distant destinations on each hop. The end-to-end communication consumes resources limiting the network's throughput we'd, just like to build networks that give short paths but also admit high capacity.

D

We don't need to stick to plusquit's very local links. The key constraint on isls is for them to not dip into the mesosphere.

D

This is the atmospheric layer that extends to about 80 kilometers above the earth's surface, beyond which there is no water vapor present. Given the altitude of satellites. In this example, 550 kilometers using simple geometry, we can calculate the maximum permissible iso length, that is about 5000 kilometers here.

D

This observation opens up a large design space, while at small scale with few tens of satellites, only simple connectivity was possible in the large proposed constellations. Each satellite can now reach many more satellites.

D

We are still restricted to being able to connect to only a few, though limited by the maximum number of isos per satellite in picking the particular subset of links to connect. What should we optimize for?

D

We use simple intuitive traffic mattresses for our evaluation. We pick the thousand most popular cities and use a population product traffic matrix, let city one city, two and city three, with three cities with different populations.

D

The traffic between ctps is proportional to their population product. We also tested a variant which relies on gdp instead of population.

D

Recall that I earlier mentioned, stretch and hop count stretch is the inflation in latency over the minimum possible that is travelling. The geodesic at the speed of light in vacuum, hop count, accounts for resource consumption and hence congestion.

D

In our paper, we show that lower half count actually translates to less condition in these networks.

D

We also define an aggregate metric as a linear combination of stretch and hop count with alpha being the weight or importance of stretch superficially. This seems like a traditional network topology design problem. These are known to be hard even in static settings, but a variety of heuristics are used in practice.

D

One key contribution of this work is showing why traditional techniques don't work here. We tried integer programming, but it suffers from two major shortcomings. It is limited in scalability. Runtime is greater than two days even for 25 cities on a beefy machine, and the estimate is roughly 10 to the power of 29 days for thousand cities, but even if we manage to speed up the ilp by a large factor or use appropriate approximation techniques, there is a more fundamental issue here.

D

The set of isos minutes apart are more than 90 different. We should remember that isl setup times are few seconds to tens of seconds. So even if we could solve the problem optimally for a snapshot, the set of optimal links vary significantly minute to minutes, hence to maintain optimality. The system would need to break and make a lot of links continually, resulting in significant disruption of connectivity.

D

We also tried random graphs, as they have shown to be useful in other settings like data centers. Although such random graph generation is faster, it also suffers from large number of links becoming infeasible within a few minutes.

D

Regaining loss connectivity is not straightforward and one would have to break and make many links. Additionally, random graphs are very inflexible and do not allow the operator to decide on the operating point. They simply yield one combination of stretch and hop count without any control over which dimension to optimize. For so, where do we go from here this?

D

This, and this picture have something in common. They illustrate the use of structure and repetition for design. In this case, visual design. We apply the same idea of repetitive geometric structure to network topology design, consider the 1600 satellite constellation.

D

This is the field of view or connectivity for one satellite which goes beyond plus grid. A motif consists of two links with two other satellites, and this pattern can be repeated throughout to build the network.

D

Note that in this case, two linked motifs are sufficient, as remaining two would be filled by other satellites connecting to the satellite.

D

One obvious benefit of using motives is the fact that they have minimum length, churn nearby satellites in adjacent orbits, move together and are always in the field of connectivity of each other and can remain connected continually.

D

We have analyzed three different constellations: a uniform constellation consisting of 40 orbits and 40 satellites per orbit operating at an inclination of 53 degrees and an altitude of 550 kilometers spacex styling phase 1, which consists of 24 orbits with 66 satellites per orbit operating at an inclination of 53 degrees and an altitude of 550 kilometers and amazon creeper phase, one which is again a uniform 34 square, constellation operating at 51.9 degrees and 630 kilometers.

D

Here we plot the average hop count along x, axis and average stretch along y axis for the different motifs note that both stretch and hop count are weighted by the traffic matrix. In this case, population products for ctps different motifs offer different trade-offs in stretch and hub count, and we can see a pareto frontier of motives superior to the rest in both hop count and straights.

D

Not only do motifs offer performance better than random graphs. They also provide higher flexibility to an operator. Note also that the random graph solution also suffers from link churn. So where is our baseline plus grid? In all of this?

D

This is where plus grid operates, with the best available stretch, but very high hop count, thus being a low efficiency motif note that the slope of this frontier is small enough on the right side, such that by sacrificing 2 percent stretch, one can improve hop count by as much as 32 percent.

D

This is one of the resulting motives for the 40 square constellation that provides much higher efficiency than plus screen using a combination of long and short links of different orientations.

D

I am showing the two links in the motif in different colors here for clarity, so the motives perform well, but can we do even better? Yes by exploring the geometry of these constellations?

D

Compare the field of view of a satellite at the equator to one at a higher latitude. We see the constellation is denser at higher latitudes. This translates to more options for connectivity as we go higher up from the equator.

D

This plot quantifies the number of motif possibilities at different latitudes for polar as well as inclined constellations. The number increases significantly with latitude, for example, for the inclined constellation there are around thousand options at the equator versus around 3500 at higher latitudes. So how do we exploit this characteristic?

D

Consider a single orbital plane. A quadrant of this orbit consists of 10 satellites out of the 40 in total. In this orbit we split the quadrant into multiple zones. Three in this case. First, we find the optimal motif for the entire constellation. Considering only the motif choices available at zone 1, then keeping zone 1 links fixed. We remove the rest of the links, we repeat the same process for zone 2 and then for zone 3 and arrive at the 3 zone multimotif.

D

This is the final three zone multimotive scheme for the 40 squared constellation. We are looking at as you can see in the plot. The multimotives offer a higher performance beyond the single motif. Frontier different alpha values result in different multimotives and, as we give higher priority to stretch the schemes move towards plus grid putting all of this together. These are the performance improvements above the baseline plus, quick connectivity stalling sees more than 2x improvement over baseline, while quipper also has similar benefits.

D

We also consider settings where the links need to be shorter due to power constraints, instead of just the visibility constraint we considered thus far in the most pessimistic case, a constellation must at least allow link lengths that suffice for plus grid connectivity, even in this worst case scenario, stalling sees a 40 improvement over plus grid.

D

I'll briefly, note that this work is just one of several satellite networking problems we are exploring in our lab. So now I touch upon some of the open questions we are trying to attack. How do we design satellite trajectories in order to improve network performance?

D

There are various dimensions to explore, including the number of shells, orbits, satellites per orbit, inclination and elevation. We are working on routing and congestion control challenges, as I briefly touched upon earlier. In this talk to help bootstrap research in this area, we are actively developing packet level and flow level simulators that capture the necessary system dynamics.

D

With that, I thank you for your attention and now I'm open to take questions.

A

Okay, thank you deborah. That was an excellent talk. um Thank you. Does anyone have any questions.

A

Okay, uh jonathan.

E

Hi good morning um does it uh so when you say rooting um and congestion control is the idea that you would send traffic on a longer route over less populated areas, just to avoid other traffic.

D

Yeah, so so that's a very good question. uh um What we have seen is like, of course, uh when it comes to um routing condition, control if we send packets along just the shortest paths, it doesn't work, it's uh it's very inefficient in the sense that it consists some areas of the network heavily. For example, imagine all the traffic between north america and europe uh using links over over northern atlantic, so these links would be heavily congested. So, of course, we will be needing some sort of spreading traffic like uh k.

D

Shortest path is something that comes to my mind immediately, uh which can actually spend the traffic more. But beyond that, what is interesting when it comes to uh uh into the intra domain. Routing is like uh because the network is moving, so this is unforeseen this. uh This has not happened in the past, much that the network nodes are moving at incredibly high speeds. uh So what happens is like the expectation uh would uh change. So as the link moves away from a set of paths, it would start catering to new paths as well right.

D

So uh so, even if you try to kind of send optimal traffic via some parts, those parts would see the link utilization, the independent, the individual link utilizations changing over time as the links scattered to a different set of end-to-end paths. So this is also very interesting, and what can be done here, possibly is that uh given satellite trajectories are uh are known in advance somewhat.

D

So so this this dynamicity is kind of predictable in advance, so that advanced knowledge can be applied uh in order to shift traffic from links which are going to become more congested in the.

A

Future super interesting. Thank you. Okay, great thank you, uh wrote.

F

Echo the comments of other people in the uh chapter. This is a really good talk. um Think you addressed this question in the talk, but I want to, but I'm not sure I fully caught the answer. So you were talking at one point about um variability in the path latency done terrestrially, um but of course, that that variability you the physical path itself, the latency is actually fixed.

F

The variability comes from queuing delays and traffic competition, um but I'm I'm not sure I caught how how much you were modeling that along the satellite path, because the satellite paths, I think, are lower total bandwidth and so they're actually potentially vulnerable to congestion at um some point as well right or lower length bandwidth, I'm not sure if the aggregate is actually lower or not.

D

Right so uh so I agree with that when it comes to the uh by that, I mean that uh I agree that uh this variability in case of satellites uh in case of uh paths usually come from queueing and congestion, but in case of satellites it also come from the fact that the links are changing. The link lengths are also changing continually and there are often path changes as well. So when it comes to the topology design work, that was the main focus of this talk.

D

We, uh we were sticking to the path length, so this is just a propagation delay without considering any queuing delay or something when we compute the latency and the variations thereof. uh The variation I talked about was in a more recent paper which was published in hotness 2020, but beyond that, so there we kind of quantified uh what the impact of uh foregoing uh isle is like, if you just use main pipe connectivity that increases uh the variation of these end-to-end latencies.

D

But beyond that, what we are doing now is like we are trying to understand this impact of variability when it comes to end point congestion control. So there are two aspects to this number. One is like um the link lengths are continually changing, because, even if the satellites which are having intersatellite links between them are moving together because of the earth's geometry, they come closer at higher latitudes and go far away at lower latitudes near the equator. So the link latencies are continuously changing.

D

That's number one and number two is like the parts would change as well, so as parts become more and more inefficient after a while, uh the end-to-end traffic would need to use a different path. So these path changes are also frequent. So these two actually impact endpoint congestion control heavily.

D

So uh so we have to understand like this is not really condition. These are changes that are uh expected like um like path, changes and path, latency changes, but this would still impact congestion control if not handled properly.

F

Okay, and so the the work in in your paper, was an apples-to-apples comparison of not considering the the traffic congestion for both for both the terrestrial and satellite.

D

So um so, when I uh talked about path variations like variation in latency, that was the hotness 2020 work where we compared ben pipe connectivity and iso connectivity right. So what happens? If a constellation has isles versus what happens? It doesn't have isl.

D

So there we have this apple to apple comparison right, but when uh so, when I was uh explaining the plot where we uh compare internet latency, that is uh the ping latencies from wonder network data to satellite latency there we give some sort of edge to the satellite network, so there, uh the internet latencies, of course, were also affected because of condition and stuff. But satellite was just propagation delay. But if you see the difference, the difference is in latency. Endpoint latency is almost 70 at the medium.

D

So even if there is some overhead incurred due to uh due to um end to end or even link level like uh modulation, encoding and error, correction and stuff, that would uh still that inflation would still be. If we consider that in inflation, then latency would still be significantly lower than today's internet. That's the expectation! Now, of course, I mean when we bring in queueing and congestion into the scenario. Things will be more interesting, but we're trying to uh simulate that.

D

So at the moment we are building a packet level simulator and we already have a paper out, so this simulator can simulate entire constellations and cross traffic. So there we are also getting some interesting results uh which arise due to cross traffic and condition thereof.

A

Okay, thank you any other questions. I don't see anyone else in the queue.

F

If you don't have anyone else in the queue, I actually have a second question that I was going to do.

A

F

Got a couple of minutes so go ahead, um so the the topic that I brought up in the chat which you already partially answered about about the inter-city traffic model. Is that model original to you or is there a reference to that? I've downloaded your paper, but I didn't find a reference in the paper yet.

D

uh Yes, so uh finding the right traffic matrix was difficult because you know when it comes to satellite networks, we should also address the temporal changes in traffic demands. So this we didn't do uh we. We were sticking to very simple traffic mattresses. So that's the reason we just picked this population traffic matrix and the and the gdp traffic matrix and then stick to the gravity model, which is uh uh which is the population product uh and and the traffic demand is proportional to that. uh But uh but you know I mean uh this tool.

D

uh Whatever we built in the context of this work, it's uh it can be um used with any arbitrary traffic matrix. Of course, we didn't do any uh like more sophisticated ones where we also consider the temporal variations, uh but but these are the traffic matrices. These two are the ones that for that, for which we have results.

F

So the the the product of uh city population is equivalent to the gravity model, so.

D

I'm not sure yeah I mean.

D

There is, uh there is another uh variant of it where we also consider the distance between city pace uh but uh and and the product and the demand is. uh It gets reduced as the distance increases, uh but this is one reasonable traffic matrix which uh have been used in the past. I mean in couple of different papers. I can, I can offline, send you a couple of uh references.

F

A

Okay, great, thank you, um excellent talk uh and uh a reminder to everybody that, uh as I said at the beginning, that deb is on the job market soon. So thank you. Debra fm next up is georgia, who, whose talk is about morphing packet reports for internet transparency.

A

uh Georgia earned her diploma in electrical and computer engineering from the national technical university of athens and she's, currently a fifth year phd student at epfl's network architectural laboratory, where she's co-advised by katarina, agueraki and brian ford.

A

Her research focuses on enhancing trust around the performance of network systems and its implications for user anonymity and uh the privacy of networked topologies, okay uh mitako. If you're ready for the next video.

G

Hello today, I will present you our work on reconciling anonymity with internet performance transparency.

G

This is joint work with my supervisors at epfl, caterina, jirachi and brian in today's internet, when packets are lost or delayed beyond expectation, there is no systematic way to identify the network where the problem has occurred. This has important implications to network users.

G

First, users cannot check whether internet service providers meet service level agreements, for example, if an isp honors a less than one percent packet loss promise. Second, users cannot check isp compliance with neutral regulations.

G

Consider the scenario on this slide where a broadband isp receives all traffic. This is video streaming traffic originating at netflix and other traffic through the same in the domain at some point, netflix streaming, quality deteriorates due to large delays, begging. The question why exactly this results in appearing dispute, similar to the one between netflix and verizon netflix, blames the isp for discriminating against netflix traffic. While the isp says I am doing nothing wrong, it just so happens that the in the domain link is congested.

G

The result is an ongoing dispute during which netflix users experience bad video streaming quality.

G

So what we need is more intent, performance, transparency, in other words, we need more visibility into the performance of the various networks that make up the internet. Having more transparency would enable network users to trigger check service level agreements and neutrality regulations.

G

However, transparency comes at the cost of anonymity. In particular, popular unlimited networks, like torque, fundamentally rely on limited internet performance transparency in order to achieve the learning the goals, and this is because, at a higher level, anonymity relies on hiding the communication patterns of users. Whole transparency brings them into life.

G

Hence the goal of this work is to reconcile both transparency and learning. But first let me recap the properties of torque that are relevant to this talk. Imagine two users alice and bob that you start to communicate with each other, and they do so by exchanging a series of packet counts.

G

We call a flaw, for example, here alice talks to bob by sending to him a certain number of packets during the first time unit, then fewer packets during the second time unit, and continues like that there is these three relay nodes in the middle or equivalently. This onion that provides the falling property an adversary sitting at either position one or position two cannot tell that alice is starting to go.

G

However. Prior work shows that, given enough location diversity of the adversary, she can be anonymized traffic in this example. If, if the adversary is present at both locations, 1 and 2, she can potentially tell with high confidence that also starting to bog. This is true when, if sees independent, down-sounded versions of the actual packet flow at the two locations, but it is also true if it does not observe a single flow application too, but instead, an aggregate which is a composite of close, the red and green one here.

G

The good news is that in today's internet that operates in the absence of any transparency system, it is still reasonable to assume that such a global, passive adversary is rare. Let us take a step back. Stor is an overlay over the network of isps that make up the internet. We argued that we need more internet performance transparency.

G

So let us explain what is a transparency system and what are its implications on unlimited building. Transparency into the internet fabric boils down to networks like isps that publish information about the traffic they observe at their boundaries, and then internet users, regulators and the networks themselves that uses public information to analyze its other's performance.

G

In particular, if an isp joins such a transparency system, it would have to deploy spatial weakness logic where traffic enters and exits domain. You can see that as the orange nodes in the slide witnesses observe traffic and periodically send packet reports on traffic aggregates to a logical, centralized entity. We call the ledger upon having all these reports the laser and anyone who has access to it can trace problematic, behavior, specific areas and check for compliance with service level agreements and neutrality.

G

However, as you might have guessed, by deploying an intern transparency system, we are essentially introducing a powerful global passive adversary.

G

So this talk is about assessing what this new powerful adversary could do to anonymity and then, given the risk reconcile the need for both transparency and unlimited here is the roadmap of this talk.

G

After describing the metric we use to quantify anonymity, we will assess the risk that the basic transparency system will post anonymity, then to strike a good balance between anonymity and transparency. We will continue with our solution, which is adjusting the time granularity of the reports.

G

We will conclude with some experimental results and future work, we're considering an adversary who aims to trace the target flow, for example this one that also is using to communicate with bob.

G

Let's assume that this flow is truly contained in the red and green aggregate, now suppose that, concurrent to this aggregate, the transparency system publishes two more aggregates the black ones. On the slide, then the advertised goal reduced to determining which of these aggregates are more likely to contain the target flow. The adversary has the following information.

G

This is the close pattern, as well as the pattern of each of the aggregates published by the transparency system within the given time interval.

G

What we are searching for is an anonymity metric that has the following properties: if, if the adversary has no information or equivalently, if she believes that all three aggregates are equally likely to contain a target flow, anonymity should be high.

G

If, however, it is true that the flow is the correct aggregate, anonymity should be low, it has some information. Our nudity should lie somewhere in between these two anonymity points.

G

So far from what I have told you, it seems that the traditional along limited set size is a metric. We are saying this is true, except for when the adversary has misleading information, for example, if eve is pretty sure that an incorrect aggregate includes a target flow, for example the bottom one on the slide.

G

In this case, the traditional unlimited set size would give us low anonymity, the red point on the slide, but we are gluten limits to the high being the blue point of the slide, because in this case, misleading information is as if no information our metric, which we call the thin limit set size addresses all this. You can find more information about it in our paper.

G

Now. It's time to assess the risk that the basic transparency system would pose anonymity. This experiment, as well as any other experiment, I'm presenting today, consider serial internet traffic traces obtained and made available by canida in 2018..

G

Here we have 50 target flows, each of them being contained in a separate advocate out of 50 count at once. The aggregates are dense in the cells that each of them is a composite of many flows.

G

512 here intuition is that dense aggregates are highly likely to hide the patterns of the individual clause because they simply contain many of them. The basic transparency system we are examining here. Reports packet counts on aggregates every one millisecond.

G

Let us now switch the graph on the y-axis. We see the cumulative distribution function or simplicity f and on the x-axis we see our metric within a newted set size.

G

A theorem set size of one is the best case scenario for the attacker who successfully traces the target flow to the correct aggregate. On the other hand, a team unlimited size of 50 reflects the worst case scenario for the attacker, because he thinks that all 50 aggregates are equally likely to contain a target flow. As a result, the attacker would like for the cdf of the tin limited set size to lie towards the left hand side.

G

While we aim for the opposite, the orange curve shows the cdf of the team limited size for the case of one second observation time interval. This is simply the time window during which the adversary knows the pattern of the target flow and all candidate aggregates, as you can see for the case of one. Second, things are pretty bad for the adversary, because now only a few flows have a fairly low, thin and limited size.

G

However, things change as we increase the observation time interval from 1, second to 10, seconds, 1, minute and finally 10 minutes, because now we can see that the adversary can more and more reliably trace flows, in particular for the case of 10 minutes, which corresponds to the green curve. Here there are about 20 percent of the flows that are uniquely identifiable.

G

Also, there are about 60 percent of the flows that are up to 5 anonymous, meaning that the adversary, traces them to fewer than 6 aggregates.

G

To sum up long observation time intervals can result in low anonymity for a number of laws, even in the case of dense aggregates.

G

This brings us to the anonymity transparency trader. Today we have thor and if we deploy a basic transparency system, we would have perfect transparency, as shown on this point here. This is because our transparency system can essentially report whatever we like at an arbitrary precision.

G

However, anonymity can be bad, as I have just showed you adding differential privacy. Noise would be one approach. However, we would end up on this left corner, which essentially tells us that the rigors differential privacy guarantees come at the cost of no transparency.

G

You can find more information in the paper that shows that the straightforward application of differential privacy would not work in our context, and this is not surprising, because differential privacy is not meant to be used for verifying service level agreements or neutrality.

G

Hence, the focus for the rest of this talk is how to strike a good balance between anonymity and transparency.

G

However, improving anonymity is not easy, as your solution must take into account two more constraints.

G

First, the thai speech must hide all flaws, because any of them could be a possible target, for example, for this aggregate shown on the slide. We don't know a priori which of the flaws will be targeted, it could be either the red or the green flow.

G

Second isps must make local decisions because we would like for them to avoid any kind of coordination, because these are different administrative domains.

G

We've seen that if we add performance transparency to the internet and without thinking much about it, there is indeed the damage on the limit to alleviate these damage. We propose a tie speech course in the timeline of the package reports before publishing them ledger intuitively. What that means is that corset time, regularity, better hides the flow patterns, because it results in the loss of fine grained information that would enable a good pattern matching between flows and aggregates.

G

However, it is the very same loss of detail that impacts report utility because the ledger may now not be able to precisely localize in time. Certain events, for example, bears of packet loss stay compared to additive noise methods like differential privacy is the advantage of our method lies on the relayability of the reports. It produces packet loss rates computed from accurate, yet coarser reports will also be perfectly accurate, albeit average over longer time internet.

G

Let me show you how our algorithm operates on the right. We see the input of the algorithm, and this is packet counts over time for the red and the green flow that make up an aggregate observe here that each packet count refers to a single time unit.

G

Now, on the lower part, we see the output of the algorithm. We say again the same aggregate, namely packet, counts over time, but now observe that the granularity for some of the reports is coarser than a single time unit, for example, for the first packet. Can we see that it refers to both the first and the second time when merged the same happens to the next packet count, but then you can see that for the last packet count it refers to a single time unit.

G

Of course, the question here is how course to make the beans, for example, beans that last one year may not be so useful in the context of many applications.

G

Given the course's granularity, we would be willing to tolerate, say two time units the next thing to do would be uniform being and the uniform billing statically merge packet counts every two time units. However, the static beaming might not always be the one that hides the most of low patterns, in which case it also introduces unnecessary noise.

G

What we propose instead is adaptive bing, given an upper acceptable time, granularity its isp dynamically decides how coarse or fine grained the imported pins of an adjective should be so as to hide the worst of them.

G

You can think of this flow as a virtual flow, namely a composite of real flows, which has a property that clicks the most across real flows for a given being to better explain what I mean. Let's go back to the previous example on the right. We see again. Packet counts over time for an aggregate that consists of the red and green flow on the left. We see the liquids for each of these clause.

G

The goal of the adaptive binning technique is to improve the leakage for its flow, and this leakage captures the likelihood that the respective flow belongs the correct aggregate.

G

Here we have at least two options with respect to binning. We could be with the red or the green flow in mind when winning according to the red flow. Our goal translates to hiding the vulnerable part of this flow, which is this packet burst that occurs in the first half of the observation window.

G

One being that accomplishes this goal is this one in that case the leakage for the red flow? You can see that it improves. However, this is not the case for the green flow for which the leakage may stay the same or even increase, as is the case here.

G

If we be now, according to the green flow, we would get similar results.

G

The takeaway here is that we must go optimize for both flows, because optimizing independently for each of them may result in some flow left exposed, and this is exactly what we do through the virtual flow construct.

G

The purple beaming slow shows the meaning that minimizes the ligase for the virtual flow, which is this one here, and this flow upper bounds, the liquids for both the red and the green flow as a result, if you look at this purple point, both flows ligas benefit from this being.

G

Now that have presented to your solution, it is time to evaluate how the solution improves flow non-limit. The experimental setup stay the same as before. The focus is on the 10-minute observation case that proved to be challenging before, because the attacker could de-anonymize a large number of closure.

G

The graph shows again the ctf of the theologian size. The green curve corresponds to the basic transparency system we have examined before, and the blue one corresponds to an adaptive, beaming solution, subject to the constraint that no beam can be larger than 64 milliseconds.

G

There are a few important things we can observe here. First, with our solution, uniquely identifiable flows no longer exist.

G

Second, our solution achieves approximately a 4.4 times improvement for up to five anonymous flows, because you can see that there were around sixty percent of the flows that were up to five anonymous before and we have managed to bring that down to less than ten percent.

G

But, most importantly, these improvements are achieved at the sub-second variability. Remember that here the course has been is 64 milliseconds. That means that many applications can benefit from the packet loss rates that our system exposes.

G

In the paper, you can find an extensive evaluation of an algorithm that includes other experimental setups like sparse aggregates poisson traffic and another special type of traffic. We call honor the results I have presented to you today are representative of these other setups.

G

Also in the paper, we examine the cost of differential privacy to reported data, and we also show that differential privacy noise would result in packet loss estimates that differ from the action ones by tens of percent of the points.

G

Finally, you can see how our algorithm scales, meaning that our algorithm is deployable to conclude, if not carefully thought, transparency can greatly damage their anonymity. We also find that adding noise to the traffic reports so as to ensure differential and privacy would make the reports unusable in the context of a transparency system.

G

Instead, we propose morphit an algorithm that causes the time granularity of target reports in order to hide the flow patterns that are most vulnerable to tracing our solution. Navigates, an unlimited, spicy tradeoff in an intuitive way and prove to be useful in many realistic scenarios.

G

Of course, there are many other aspects of indian performance transparency we are currently working on or we are interested to others in future work, for example, whether an alternative solution that leverages isp coordination would achieve. A better trade-off still remains an upper question.

G

Also, our ongoing work focuses on the trustworthiness of performance metrics because to improve their competitiveness networks may have an incentive to lie and claim better than the true performance. Another aspect of female transparency also pertains to privacy.

G

However, this time the focus is not users but networks themselves, specifically who are interested in hiding the topology of networks, because it is possible to reverse engineer. Topology, give an inter-network pathways trivially exposed by transparency systems, and with that I would like to thank you and I'm now ready to take any questions that you may have.

A

Okay, um thank you and another excellent talk. um Thank you very much. um I see, though, there's a bunch of discussion in the chat about multipuff and I see uh jonathan has joined the queue. um I guess you want to follow up on that.

E

um I actually was uh going to ask a different question: um do you consider in your model an attacker who might uh vary into pocket times like they might try and delay some packets and not delay? I guess other packets to try and increase the signal.

G

By the flow itself, what you can just do is uh observe the packet flow somehow get access to. What is what does it look like and then try to find which of these published aggregates that are published at the last hop, for example. Here this is the scenario we consider is more likely to contain it, so we don't consider more sophisticated attacks where the adversary can also play around and be active with respect to how he can attack the system.

E

Mistake. Thank you. Thank you.

A

Okay, thank you. Anyone.

C

A

A

So um I had a question about the uh the the complexity of the adaptive binning. um Does this get uh expensive to compute with very large aggregates, or is it still manageable.

G

um Yes, so yes, the the complexity depends on the number of aggregates, but not all the number of other gets published overall in the internet, because this is uh local to the isp. So, yes, it depends on the number of arguments per isp, but time interval, of course, but to to reduce the complexity to and make and make it run in reasonable time.

G

What we do is that um we, we split uh the time into intervals around the algorithm independently for its time interval so because this is the parameter that mostly affects the cost of the algorithm. With respect to that, not the number of aggregates.

A

Okay, thanks thanks uh and my other question was um how sensitive is: is this to correct implementation of the the adapted binning? um Does it degrade gracefully? If people uh do this slightly incorrectly or does it fail catastrophically.

G

You mean how important it is to use a particular algorithm.

A

Yeah or if um I guess, if the binning isn't quite implemented right, um is it really sensitive to getting the precise spinning correctly or is it.

G

To be honest, uh not so much, there are benefits to using this algorithm but, for example, we consider a variant of the algorithm where the the the isp would uh maybe statically merge uh every let's say, 10 time units and there are still benefits doing that to having no uh yet have no deployment. No I'm going to be deployed at all. So it's not that crucial, but still coarsening the time granularity is crucial. Yes,.

A

Yes, okay, great thank you all right does. Does anyone else have any questions for georgia.

G

I think there are some other questions from the sun, but they can take that offline.

A

We have time if you want to and answer them if you want to answer them, live.

G

So jonathan, I think uh he's asking um I think, he's uh thinking whether it would be better to use game theory or all details.

G

So jonathan, would you like to clarify what what do you mean by game theory here or editors.

E

Yeah, so it's just, I was just thinking like if, because I assume you also have to measure um traffic between isps and so you could somehow have it. That isps would also talk about what happens between asses.

E

That's the right grouping, um but basically the idea would be one isp lying makes other isps, look worse or better or presumably worse, and so you could have it such that.

E

The isps would be honest because they're worried about their uh competitors, making them look bad they're, just sort of has this uh prisoners dilemma style like we all have to work together or else we'll all look bad.

G

Yes, that's a actually it's it's really great that you brought it up. It's uh something uh that I'm currently working on. Our current work is exactly on the honest device piece so, but this is a bit of orthogonal to this paper. So this token I talked about today, it was about. Let's assume isps are honest and let's take this, let's make this assumption and then try, given that it is intel in their benefit to protect the privacy of their users. How would they try to fight? How would they import these uh packets this?

G

uh How do they report in order to fight um who is talking to whom, however, like what you mentioned, is really a great topic? Why would the isps ever be honest to us with respect to what they do with packets? Why? Because, if I am an asp, I would rather say that I'm I'm doing fine, I don't, I don't lose in packets and I'm not delaying any packets and blame my neighbors.

G

However, in our current work we actually show that, yes, we model that with game theory, we are completely right and we show that there are incent, given that users have um care about certain metrics like packet loss, for example, the isps we form again theoretical against a game, a theoretical game where I spaced.

G

uh um Where is published the reports and based on what they published, we were able to detect inconsistencies, and we argue that they wouldn't like to be inconsistent, because this is bad publicity, because they they are connected to their neighbors and no one would like to enter such kind of disputes.

G

For example, if you think about fatigue loss, let's say we have two only isps in the internet, uh we know ntns. We assume that the ends know how much packets, uh how many packets are lost. Then it has to be that either the first or the second is below the packets. So in that case it couldn't be that nobody lost them. So if I yeah, if I have the first isp and I'm losing the packets, then if I claim that I do not it's as if implicitly I'm claimed, I'm blaming my neighbor.

G

So we argue that this, these kinds of incentives do exist and I wouldn't actually like to enter such kind of disputes.

G

Thanks for the question.

E

Super interesting, thank you. Thank you.

G

So, yes to add to this, so our ongoing work explores what's what kind of metrics we can incentivize the isps to report honestly and we can show that at least packet loss mean packet loss and also mean packet, delay and furnace of delay. This matters should we come to expose in a trustworthy. Thank you for the question.

A

Okay, thank you. um I don't see anyone else in the queue. um So thank you again great great talk uh and I guess we'll now we'll move on to the uh final talk, uh which is uh renisha, we'll be talking about uh her paper uh beyond jane's fairness index uh setting the bar for deployments of congestion control. Algorithms uh renishaware is a fourth year phd student in computer science at carnegie mellon university.

A

Her current research focuses on challenges arising from the deployment of new transport protocols and congestion control, algorithms in the internet. Okay, thank you.

H

Hello, so today I'm really excited to talk about this joint work uh with matt who's, now nafeli and justine and trini, who are my advisors at carnegie mellon and my name is ronishaware.

H

So today I'm going to talk to you about this work um on congestion control deployment. So let me start by motivating why we care about this and why you should too.

H

So we want to answer the seemingly simple question: if you design a new congestion control, algorithm taco, how do you show that taco is reasonable to deploy in the internet today.

H

Well, typically, we try to say a new algorithm. Taco is reasonable to deploy in the internet if it fairly shares with widely deployed legacy. Algorithms pair, for example, here are a bunch of graphs and tables all trying to use fairness to make the argument that their algorithm won't be too aggressive towards the status quo, which today is typically regarded to be cubic, but here's the thing everyone falls short of actually achieving fair outcomes, but everyone still has to try to make these arguments that their algorithm is deployable.

H

So, let's look at some examples of what these arguments look like, so I don't want to dig into the graphs here.

H

I just want to draw your attention to the arguments so in the cubic paper they show results where cubic is unfair to reno, but argue that this is outside of the tcp friendly region and that this doesn't highly impact reno's performance, whatever that means and in early presentations on bbr google showed that bbr v1 was unfair to cubic in shallow buffer networks and basically said they'll fix it in later versions of bbr by modeling those shallow buffer situations.

H

Pcc vivace also showed it could be unfair to cubic but argued that as the number of cubic centers increases, it achieved. The best fairness among new generation, algorithms and coppa makes a similar argument that it's much more fair than bbr and pcc and it uses bandwidth that cubic wasn't going to use anyway.

H

So I highlight all of these arguments here to drive home this point that in practice we really can or even want to achieve fair outcomes, because it turns out fairness is either too restrict restrictive or impractical.

H

Consequently, everyone ends up just sort of having to make these excuses about why their algorithm is still reasonable to deploy, despite having unfair outcomes- and it's really unclear if these excuses are okay.

H

So the problem is we're basically left with no real bar or threshold for what makes a new algorithm safe or reasonable to deploy in the internet today.

H

So in this paper, in our paper- and in this talk, we argue for the need for a practical deployment threshold that is a bound on how aggressive any new algorithm, which I'll refer to as taco throughout this talk, can be to any see any legacy status quo widely deployed algorithm, which I'll refer to as pair in this talk.

H

So the outline for this talk is as follows. First, I want to describe for you the desirable properties for a good deployment threshold. Then I'm going to define a new deployment threshold based on harm which, unlike fairness, has all of these desirable properties.

H

So let's jump right in and start by discussing what are the desirable properties for a good deployment threshold. Well, in our paper, we identify five such properties.

H

We say a good deployment threshold should be practical, multimetric status, quo, bias, demand, aware and future proof, so those are just a bunch of words that don't mean anything to you yet. So, let's start by defining what we mean by practical.

H

So we've already seen that a threshold based on fairness just is not practical right, because no one can actually achieve fair outcomes. Therefore, a good deployment threshold needs to be practical, in that it should actually be feasible in practice for a new congestion control algorithm to meet the threshold. So that's what we mean by practical next we say a deployment threshold needs to be multimetric.

H

So let's illustrate what we mean by multimetric through an example, so assume so consider the scenario where, let's say beyonce is at home, she's trying to talk to her daughter, blue ivy, um over skype and over her home wi-fi access link- and let's say her access to the internet is really slow. So her access link is a slow bottleneck link here and let's say it's using some new algorithm pair.

H

Some sorry, let's say it's using some old legacy: congestion contracts and pair now, let's say, base connection using pair, is able to achieve about five megabits per sec, megabit per second throughput and a good low latency. So this is when it's not sharing the bottleneck here, it's just alone, but now, let's say her husband jay-z comes home and he wants to download the windows operating system for some reason. So this is going to be a large long-running download and the server he's downloading from is using some brand new congestion controls and taco.

H

Now, let's say taco is able to use the rest of the available bandwidth, but that this comes at a cost and bay's latency is going to go way up. So maybe now her video quality is terrible.

H

So the impact on latency matters here as to whether or not we would say it's acceptable to deploy taco in an internet with a ton of latency sensitive applications using pair.

H

Therefore, it's important that a deployment threshold be able to consider a variety of metrics beyond just throughput. Some metrics beyond just throughput are becoming increasingly important in the internet. Today, when we have more and more applications that care about things like latency or jitter or loss rate, however, we can never really talk about anything other than throughput when we're stuck talking about fairness.

H

So we're used to thinking about deploying algorithms as if the network is a pie that we're cutting up to share, but that doesn't make sense for performance metrics like latency loss or jitter.

H

So that's what we mean by multimetric. Now, let's walk through an example to illustrate what we mean by status quo, biased now, let's say beyonce is downloading the linux operating system from a server using some popular legacy algorithm pair. So this algorithm. Let's say it works well in wi-fi networks, so her download speed is just using all of the available bandwidth.

H

Jay-Z comes home, he's still downloading windows and he's hit. The server he's using is using some new algorithm taco. Now, let's say, unfortunately, this time pair is too aggressive and so taco is only able to get one megabit per second throughput, while beyonce still gets nine.

H

So in this case, though, there is imbalance, I would actually say it's perfectly acceptable to avoid taco alongside pair right. This is because the currently deployed legacy algorithm pair is the one being too aggressive towards the new algorithm taco, not the other way around.

H

So when it comes to deployability, we don't actually care if the new algorithm is the one being hurt. Thus a deployment threshold needs to be status quo, biased. It should only be based on the impact that taco has on pair and not vice versa.

H

As an example, james fairness index is not status. Quo bias right, james fairness index would assign the same score if the new algorithm was one being harmed, as if the old algorithm is the one being harmed. So it can't distinguish between these two scenarios, so it's not status quo, biased.

H

So next we say a diploma threshold should be demand aware. Let's illustrate demand awareness through what an example.

H

So now, let's say again: beyonce is trying to download this large file and the con and the server uses some legacy algorithm pair, but now, let's say pair, really sucks at fully utilizing. All of the available bandwidth in a wi-fi network, so she's only getting a download speed of three megabits per second.

H

So now, jay-z comes along trying to download that windows os still using some fancy new algorithm taco. Now, let's say taco's much better at utilizing the available bandwidth in this wi-fi network. So but it's able to do that without hurting bay's connection, so it's able to just use the rest of the available bandwidth and get seven megabits per second.

H

So here again, it's perfectly reasonable to deploy taco, because it's not hurting beyonce's connection at all, although they're not equally sharing is only using bandwidth that pair wasn't using anyway.

H

So this is what so, a good deployment threshold should not penalize taco when pair already has inherently poor performance. This is what we mean by demand aware example: maximum fairness, which accounts for the demand of a flow, is demand aware, but equal rate fairness, which just says each flow, should get. The same rate is not so less. Lastly, we say a deployment threshold to be feature-proof, so by future proof we just mean that a good deployment threshold should be useful on a future internet where none of today's current congestion control items are deployed.

H

So we care about this property, because many discussions around new tcps considered something called tcp friendliness, so tcp friendliness focuses on behaving just like reno to be fair to to reno, even though very few center senders on the internet probably even still use reno anymore. So I'm going to give you a little silly toy example. That explains why it's really silly for us to keep binding ourselves to reno so consider this example where, in the past, skype and a bunch of other services use some algorithm, taka tomato, but let's say tomato was terribly inefficient.

H

So today, skype, along with many other services, switched to using a much better algorithm and they're now using pair now when taco comes along, does taco need to be nice to pear and tomato or just pear. Well, if no one uses tomato anymore, new algorithms only need to be nice to pair whatever the current status quo is so.

H

This is what we mean by future proof that a future-proof threshold would only require taco, be nice to pair whatever the current status quo is so I say all this to make this point, that traditional notions of tcp friendliness are just not future proof in a future where no one uses reno at all. We should not be relying on thresholds bound to reno or any other particular algorithm's behavior.

H

So these are the five properties of a good deployment threshold.

H

So next I want to define a new deployment threshold based on something we call harm. So let's begin by motivating this.

H

So when we're trying to show deployability, we typically run experiments where we have pair whatever the current status quo is versus taco, our new algorithm, and we want to measure performance. So if we care about something like throughput, that might look like this right, so we have payers performance, we have tacos performance and fairness would say, compare these two bars, so you want to say: um is this outcome fair or not, but remember because of status quo bias? We don't actually care what happens to taco's performance when the two compete.

H

We only care about what happens to pairs performance in particular. If this was if this uh was pairs performance alone, we care about how pairs performance has changed now that it's complete when it's competing with taka, so comparing this red and green bar.

H

So this leads to the proposal in our work, which is that a deployment threshold should be based on how much harm taco does to care. So let me illustrate what we mean by harm with an example.

H

So we're again here bae is trying to do her video conference and let's say that pear is able to use all of the available bandwidth and gets low latency when pair is alone. But now when jay-z comes along with his taco flow, beyonce's throughput goes down and our latency goes up. So here we would say that jay's connection has harmed beyonce. So let's be more uh sort of formal about our definition for harm, so harm is measured between zero and one and, like gains fairness index.

H

uh Sorry, it's measured between zero and one like jane's fairness index where zero is harmless and one is maximally harmless harmful. So our harmful function takes two inputs. The first is x, where x is pair solo performance, so this is pairs demand and it takes y where y is pairs performance when it's competing with top, thus to compute harm for more is better metrics like throughput harm, is x, minus y over x and for less is better metrics like latency harm is y minus x over y.

H

So in this example, then taco causes 0.5 throughput harm to pair and taco causes 0.95 latency harm to pair. So you should be able to see that harm is multimetric right. I can compute throughput harm latency harm, jitter harm loss, weight harm, whatever other kind of metric. I want it's also a status quo bias, so the two numbers in our harm calculation are only based on pairs performance. I don't care what payer's performance is here, and it's also demand aware.

H

So here we define the demand as pair solo performance, so harm gives us a way to talk about taco's impact on players performance, but I haven't said how much harm is okay.

H

So for this we need a harm-based deployment threshold and our key in proposal in our work is that a harm-based threshold should be the following: taco should not harm pair much more than pair harms itself, so that is any new cca shouldn't harm the status quo more than it harms itself. So what do we mean by much more than well so far, we've computed the harm that taco does to pair, and now we want to compare the harm taco.

H

Does the pair to the harm pair does to itself and say: how do we compare these two things?

H

So in the paper, we discussed three possible ways to compare these, um but today uh I just want to discuss one possible threshold which we call equivalent bounded harm and equivalent bounded harm. Just like its name says these two things should be equal, so the harm taco does. The pair should be equal to the harm pair does to itself.

H

So, returning to our previous example, we looked at what happens when taco competes with pear and can see a certain performance, and we compare that to pair solar performance to compute the harm that taco does to pair, and now we have the same scenario but with pair versus pair, and we get certain performance outcomes and we want to say what's the harm that pair does to pair.

H

So, let's go back to our harm calculations to compute this so before this is with the harm that taco did to pair, and now we want to add in what's the harm that pair does the pair. So here you should see that the throughput arm is the same, because I get the same throughput for top for pair when pair competes with taco and one pair competes with itself so under equivalent bounded harm.

H

Taco would be okay, but if we look at latency harm, it's clear that taco is much more harmful to pair than paris to itself, so under equivalent bounded harm, we would not consider taco deployable.

H

So a harm-based threshold is practical. We can already see that pair can achieve certain performance when it's competing in practice with pair. So it should also be possible for taco in practice to get similar performance outcomes. Certainly, if pair can do it, then so can taco and it's future proof right. There's no baggage here, there's no tomato here that I'm trying to behave like the only thing that matters is what is the status quo and how does it compete with itself?

H

So if tomorrow, the status quo is banana, then that's what we compare against so is equivalent bounded harm like the perfect deployment threshold.

H

Well, it certainly meets all of our criteria, as we previously discussed, while alternative thresholds based on fairness or thcp friendliness, certainly do not so it's better than what we had before, but we do have some concerns about equivalent bounded harm. So let me show you a little example, so here um I'm illustrating uh an issue with equivalent harm where, let's say, when pair competes with pair for two long running downloads, one flow gets seven megabits per second and the other only gets three.

H

So there's significant imbalance here when pair competes with itself and under equivalent bounded harm. Any new taco algorithm couldn't improve this imbalance, which seems problematic. So this is a hotness paper and it's an open question. What's exactly the right harm-based threshold and in the paper we define two other thresholds that allow taco to take a little bit more bandwidth.

H

We're not sure what exactly is the right threshold and there are other open questions uh in the paper. For example, when you run performance experiments, there are, of course going to be a distribution of these results, so should we care about the average worst case results or something else also, we can't possibly measure the performance of pair versus taco in every possible scenario.

H

As we add, so we ask what are the right workloads and networks we want to test for deployability, and even if we have a threshold, can we really even enforce it? So while we haven't exactly settled on the perfect threshold, here's what we do believe fairness is wrong. It's not working as a practical threshold, and thus we need to stop making excuses for why our new algorithms are not reading an unrealistic goal like ferris and lastly, reasoning about harm is the right way forward and it's going to give algorithm designers a much more realistic goal.

H

So that concludes this talk. um Please look at the description box for a link to the paper and if you have any questions, please shoot me an email or ask me a question on twitter and thanks for listening.

A

All right, thank you, excellent talk. um Thank you. Yeah welcome, renisha. I know it's a a terrible hour of the day for you, I I I see a bunch of questions on the chat. Does anyone wanna wanna jump in at the microphone line.

A

Surely someone must do well we're waiting for that um I mean you. ah Brian go ahead.

I

I'd like to hear which one you came up with, it might be the same. One.

A

Okay, I I was going to ask about- uh I mean you know you mentioned some some limitations, some other open issues. I was just going to ask if you've done any more work, since uh I mean that this is a paper from a year ago, if you've done any more work to address those open issues and if you'd like to say anything about that.

H

I so I actually so we have a project where we're trying to actually um apply like you use a harm-based threshold to show whether um or not uh applications we see in the wild are fair, um and so, while doing that work, we've like tried to refine what we mean by like if equivalent bounded harm is the correct thing or in the paper there's like other ones. uh Symmetric bounded harm worst case bounded harm.

H

um So uh I guess my work's kind of focused on how do I actually use this home-based threshold to say something in practice? um Yeah, that's sort of great thing to do. Yeah.

I

H

I

Hi uh brian trammell, um I'm not going to ask you any uh difficult questions, because it's like what it's for in the morning there, which is 5 30., 5, 30.. Okay, that's still terrible. um uh Thank you very much for this talk. um Like you know, looking at your your last slides, I think there's been like wide consensus that fairness isn't cutting it in the community for a very long time, um but that just went into complaints, and this is actually sort of like okay, we're gonna address the complaints.

I

I would um uh not my not my research group, but I would invite you to try and find a way to come to the internet, congestion control research group at ietf 110, and I would hope that we could have sort of a uh sort of a long, open discussion about how to actually use harm um as a metric to talk about uh measurement of some of the work that's being done there.

I

um I think that that you know that's a really good room to actually sort of expand um the applicability of this metric, I'm I I need to think about. You know some of the you know the the questions about setting thresholds here and exactly how you would take this dimensionless metric and compare it to other sort of like the benefit side, because now we have the cost side and we can. We can talk about the benefit side and that actually kind of changes.

I

The um the the ability to reason about this in a multi-dimensional space, which is super exciting, and I really like to see that followed up on in iccrg 110, which will be in march online in a european time zone, so still not great for pittsburgh, but much less bad than this time zone. So hopefully we can make that happen. I look forward to talking to you. There.

A

Yep next is jake. I think.

J

uh Hi, thank you for this talk. I I I would put this at my favorite talk in the last decade at least um wow thank you, and uh so I would be very, very interested to see uh a sort of example walk through, and I think we have a couple of very relevant natural experiments uh from recent history. One of them being um the uh you know, just I. I would love to see like how this is quantified as the harm of cubic torino.

J

This is a thing that actually sort of happened uh and also the harm of reno to vegas, for example like if we think about you, know, sort of the early history of uh of when congestion collapsed was the urgent matter that sort of drove the deployment of reno and vegas happened within that year, but kind of got.

J

um uh You know we we know uh from some of the early vegas papers that it didn't get deployed because it loses so badly to reno right so like in a sort of um counter factual world, where we had managed to land on vegas, which is better for everyone, uh but tried to deploy reno like what would that harm have looked like, because uh you know having having worked with some congestion control.

J

uh uh You know in in practice on the internet um like dealing with the loss-based congestion control uh approach as trying to deploy a a delay based. uh I was working with fast, tcp and and fast for some years before we were acquired and that um yeah it would be nice to know sort of like we felt this impact constantly and having a quantifiable uh value for like how bad was it that we adopted reno.

J

uh I would be very interested to to see that analysis, regardless of uh you know how useful it is going forward, but just sort of as an example of how to apply this research. Thank you.

A

I I like the idea of counterfactual alternate histories of the internet. We should look into that.

A

F

And that was a. It was a great talk and everybody's saying it, but it really was um my work. These days is on quantum networking and we're doing some simulation and one of the next tasks. One of our one of our big tasks, that's at hand, is actually comparing multiplexing schemes so we're looking to compare time, division, multiplexing versus stochastic, multiplexing and buffer memory, space multiplexing, and things like that can can your measures be used for for comparing multiplexing schemes or os scheduling schemes as well as well as congestion control.

H

um I don't see why not um I mean all you really need to have is like an uh scenario where you have some status quo and you want to compare. Does this new thing harm the status quo? um So as long as you have.

F

That then, yeah um yeah in the case of a multiplex thing, it's going to be so. Presumably the schemes when we're comparing things like tdm versus statistical multiplexing, it's going to be more of comparing one simulated network scenario using one versus a network, simulated, the same network simulated using the other, and so it would be two different scenarios rather than competing in the same network, most likely. Oh.

H

F

There's probably a way to do it, but I don't. I haven't thought about it a lot yet and I don't know how so I was wondering if you had thought about whether you were.

H

um Yeah the idea here is, I have these two things competing in the same network and um I wanna see if it's one thing is harming the other okay.

A

Thanks: okay, thanks jonathan.

B

Yeah so um my colleague pete hyston, and I um already working on um a test suite to help with our congestion control development process, and uh we are planning to incorporate this um harm metric into it. Now that we know about it and it makes a heck of a lot of sense.

B

um So it occurred to me from the discussion just now that um possibly artists um harness or something like it would be helpful for examining these.

B

Counterfactuals, so maybe we can discuss that at some point. Okay,.

A

Yeah I mean there are a bunch of um you know a bunch of people building test harnesses. It would be great if there was some way of integrating these ideas into those, so we could automate some of these metrics.

A

uh Bob, I think you're next.

K

Hi, um I wonder if you've thought of the situation where, um let's, let's give it a a numerical example uh where we talk in terms of bytes instead of bits per second, so let's say a 100 gigabyte flow starts at the same time as a um say: a 10 megabyte flow and then 10 seconds later. Another 10 megabyte flow starts and then 10 seconds later, another 10 megabyte flow starts and so on.

K

So you've only got two of the flows running at any one time, um but you've got very um you know reasonably small, but you know still large 10 megabyte flows running against um this much longer flow, so overall all the 10 megabyte flows.

K

If, if they all got equal bit rate um sequentially, um then um by your heart metric, they would be perfectly fair. um You know, or there'd be equal amounts of harm, but if the larger flow that goes on longer and hits all the other flows were to go slower every time. One of the other flows was there and the other flows that were shorter were to go faster.

K

They would all complete earlier and then the larger flow would also complete at the same time.

K

So the point there is that bits per second is not the right metric in the first place to measure the harm, because you have to look at the length of the flows as well.

H

Okay, um so my my definition for harm and everything says you can use whatever metric you want, it doesn't have to be.

K

I know I know, but you that that's the point you have to use the right metric and all the examples people are thinking of um think you can use any metric. You can't use any metric. You have to use the right metric to measure harm in a particular situation. That's my.

C

K

Yeah and and the problem is, people are measuring, measuring this with bits per. Second, that's the problem in the um in the forum wherein the ietf that people don't realize that there's a there's another dimension here, but it's time I'm not saying um you know it's not useful to have your harm metric. What I'm saying is that we also have to be careful which actual units we use to put into the dimensionless equation.

A

Yeah yeah, it sounds like you're saying we need to be careful with which of the particular metrics. We we choose and to think about, what's appropriate metrics for different applications to compare them.

K

Yeah, but in that scenario you can't know what was useful to those flows, whether it's completion time or whether it was bit uh rate you're. Just looking in the network.

K

That's the problem anyway, yeah um it has to be.

A

Treated there's a lot of literature.

K

About this, um but uh just just to explain to people it's not just equal bit rate or you know it's not even equal equal harm. If you're measuring bit rate.

B

So I think that will need to be incorporated into various test suites um so that these uh different metrics of harm are automatically uh generated, so they can be evaluated all at once.

K

But but but my point is that, looking at from the network at that situation, you cannot know um what is important to each of those um end systems. You don't know whether it's completion time or bitrate, so you can't can't measure the harm from the middle of the network.

K

C

K

This is this is um why it's important to measure the congestion that they all cause and and use that as the metric.

A

K

um This this requires a deeper conversation than we can have here, but yeah. Thank you.

A

Very much sounds like we should uh move this to to the iccrg uh list or somewhere.

C

But yeah, I think.

A

So I think, I think the metrics uh that the hum metric can cover those it just needs to be applied correctly. uh Sylvester.

L

Hello, um thank you for the excellent paper and and uh talk. I I really like your paper last year when I I read it and still did you do any kind of comparison, for example, uh cubic and and bbr or any two position controls, because I I still have feeling that the harmbest bar is a much better buy than, for example, james furnace, but it's it's still close to impossible to meet and innovate. At the same time,.

H

I'm sorry I'm confused by what's your question.

L

Do you test your uh your home-based uh threshold with actual condition controls over the internet and did you find that that, for example, a new like cubic is is really fair to reno or not, or whether bbr is fair to cubic or not, because I still have the feeling that for every new congestion, control and old condition control power, you can easily find the uh scenarios when this bar is not met.

H

Yeah, um so we're actually working on that now um and yeah it depends well, we found it depends on the application. So we've looked at things like just long running downloads, um but also video uh and compared.

H

uh If you have two video applications and let's say you care about bitrate at your um just using you know, having cubic and bbr compete, just performance degrading.

H

um I'm not I'm not remembering the findings off the top of my head, but um to uh we'll see that in the future, when I finish that.

L

Okay, okay, thank you.

A

Excellent uh jonah you get the last.

H

M

um Thank you for presenting this work here. I have long wanted this work to show up in one of the irtf places, and I'm glad that we should showed up here. um So I want to see if I can try and articulate what bob was trying to say, because I think there's what bob was trying to say is actually something. That's uh that's actually quite important.

M

um On the one hand, I think that what what work is doing is challenging people to move away from notions of fairness, notions of thinking about flow fairness, flow level or bitrate level. Fairness. uh On the other hand, there is a risk and the risk is that now people get attached to what I would think of as a similarly um uh constraining or ossifying notion of uh flow level harm.

M

So if one simply thinks of uh bit rates, then you effectively end up with the dual of the the previous problem right, you're, simply thinking about harm now, but in a very sort of micro.

M

Benchmarky way still so, the fact that you moved away from fairness is helpful, but the problem is that one gets still stuck to being with micro benchmarks, um but I know that that's not what you're thinking, but I think that there's a risk in simply having a metric and thinking that, now that we have this, this is the one true way of measuring condition, control, usefulness.

M

um But, to your point- and I think you've said this in other places- uh uh that it is important- we said this earlier to sylvester as well- that uh it is important to consider the impact on other applications.

M

So, ultimately, what matters is the metric that applications use to determine what usefulness or useful work is for them, uh and that tends to be quite difficult and it tends to be moving by giving this the today uh youtube has a certain way of doing things and therefore certain metrics become important tomorrow. It's something else.

M

It's gaming or it's I don't know it's twitter or it's tick, tock or whatever it is, and they have different metrics and as network use changes, we will find that there are metrics that get more or less harmed for the same set of congestion controllers uh and that's something that we have to keep in mind, and I think that we want to be mindful of uh not uh we. We want to be mindful that we can't find a silver bullet here.

M

There isn't one really, but there is a process that one can think about how to evaluate a congestion controller in a better than we've done in the past, for a set of circumstances that happen to be true today, and we might want to evaluate this in the future because as circumstances change as application workloads change, the notion of harm from an application's point of view will change, and I think that's important to keep in mind um as you as you work on this. I just encourage you to think about it. That way as well.

A

Okay, thank you. Everybody. um Thank you again to to all the speakers. um Congratulations to all the prize winners. uh I think this has been an absolutely great. um So thank you and congratulations again, um I'd like to remind everyone that the deadline for next year's uh nominations for next year's anrp is this sunday.

A

um So if, if you want to get uh talks this good next year, please nominate some good work uh and go to the iitf.org, a rp site and nominate the work uh and with that uh that's everything we have for today. Thank you, everybody and I hope to see you uh in person eventually but uh online in march.

A

That's what we can do thanks.

F

Everybody make good choices.

M

Go get some rest, everybody. It's been a long.

M

M