IRTF Open Meeting ================= Friday, 20 November 2020, at 09:00-11:00 UTC Room: Room 5 Chair: Colin Perkins 09:00 Introduction and Status Update IRTF Chair 09:15 Network topology design at 27,000 km/hour Debopam Bhattacherjee https://people.inf.ethz.ch/asingla/papers/conext19.pdf https://doi.org/10.1145/3359989.3365407 Jonathan: Would you send traffic on longer route to avoid congestion? DB: shortest path is inefficient due to congestion, because network is moving, expectation changes. dynamicity is predictable so this knowledge can be used to predict future congestion. Rod van Meter: really good talk. you were talking about variability of path latency on terrestrial links - how much did you model that along the satellite path? DB: on satellite, link lengths (and hence latency) change continuously, path changes are frequent. hotnets paper published in 2020 talks about this variation. now we are trying to understand the impact of this variability when it comes to endpoint congestion control. Rod van Meter: Intercity traffic model - is that original or is there a reference to this? DB: Finding right traffic matrix was difficult. We stick to very simple traffic matrix (population and GDP) - don't consider temporal variation in traffic demand. Rod van Meter: so the product of city population is equivalent to the gravity model? DB: there is another variant of it where we also consider the distance between city pairs - demand gets reduced as the distance increases. I can offline send you a couple of references. Rod van Meter: Thanks! 09:50 MorphIT: Morphing Packet Reports for Internet Transparency Georgia Fragkouli https://content.sciendo.com/view/journals/popets/2019/2/article-p88.xml Jonathan: Do you consider an attacker that might vary inter-packet times to try to increase the signal? GF: attacker can observe the packet flow and then try to find which of the published aggregates is more likely to contain - we don't consider more sophisticated attacks. Colin Perkins: Does the adaptive binning get expensive to compute with very large aggregates or is it still manageable? GF: depends on number of aggregates per ISP, to reduce complexity we split the time intervals around the algorithm independently CP: how sensitive is this to correct implementation of the adaptive binning? does it degrade gracefully or fail catastrophically? if binning implementation isn't good does it still work? GF: not so much, we consider a variant where the ISP would statically merge every, say, 10 time units and there are still benefits to doing that, so it's not that crucial. coarsening the time granularity is crucial. Jonathan: i assume you have to measure traffic between ISPs, so you could somehow have it that ISPs could also talk about what happens between - one ISP lying makes other ISPs look worse (or better) - what is the game theory here - prisoners' dilemma? GF: our current work is on honesty of ISPs, but that's orthogonal - this work assumes ISPs are honest. ISPs disincentivised from publishing inconsistent data. our ongoing work explores the kind of metrics that incentivise operators to report accurately - mean packet loss and mean packet delay are useful metrics in this regard. 10:25 Beyond Jain’s Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms Ranysha Ware https://www.cs.cmu.edu/~rware/assets/pdf/ware-hotnets19.pdf https://doi.org/10.1145/3365609.3365855 Colin Perkins: You mentioned open issues, have you done any more work to address the open issues since this paper was published (around a year ago) RW: we have a project using a harm-based threshold to evaluate applications we see being used in the wild. we're evaluating whether metric-bounded harm is the right approach or alternative bounded harms. Brian Trammell: thank you for the talk - looking at your last slides - i think there's been wide consensus that fairness isn't cutting it for some time, but that was just complaints - your work addresses the complaints. please come to internet congestion control research group at IETF 110. would like to understand how the benefit side is impacted Jake Holland: thank you for the talk. I would put this as my favourite talk in the last decade at least. I would be very interested to see an example walk through - how this is quantified as the harm of cubic to reno (which actually happened), and the harm of reno to vegas. if we think about the early history where congestion collapse drove the deployment of reno and vegas happened within that year, didn't get deployed because it lost out to reno. we felt impact constantly, would love to have an analysis that quantified how bad it was that we adopted reno. Rod van Meter: I work on quantum networking, we're doing some simulation. We're comparing multiplexing schemes - comparing TD, stochastic. Can your method be used for comparing these schemes as well as congestion control? RW: I don't see why not, you need to have a status quo and want to understand harm of a new thing to that status quo. RvM: would be two different scenarios rather than competing in the same network RW: I haven't thought about that. Idea here is that we have two things competing in the same network. Jonathan Morton: my colleague Pete Heis and I are already working on a test-suite to help with our congestion control development process and we are planning to incorporate this harm metric now that we know about it. would our test harness be useful for examining these counter-factuals. maybe we could discuss that at some point. CP: there are a bunch of people building test harnesses - would be great if we could build this into those to automate some of these metrics. Bob Briscoe: I wonder if you've thought of the situation where we talk in terms of bytes instead of bits per second. 10MB flow starting every 10s - only two flows running at one time - by your harm metric this scenario would have equal amounts of harm. Bits per second isn't the right metric to consider harm because you have to look at the length of the flows. RW: we're saying you can use any metric BB: i know, i'm saying you have to use the *right* metric - problem is people are using bps and there is another dimension (time). i'm not saying it's not useful to have your harm metric, i'm saying we have to be careful which unit we use to put into the dimensionless equation. problem is you can't know what is important to a flow (throughput, ) from the middle of the network. JM: need to incorporate different metrics into test suites BB: you can't know what is important to the end system from the middle of the network - which is why it's important to measure the congestion that they all cause and use that as the metric. Szilvester Nadas: thank you for paper and excellent talk. did you do comparison between e.g. cubic and bbr? did you find that a new cubic is fair or not, for example? it's easy to find scenarios where bar of fairness is not met. RW: working on that now. it depends on the application. look out for the paper in future! Jana Iyengar: thank you for presenting this work here. I want to see if I can try to articulate what Bob was trying to say because it's important. On the one hand your work is challenging people to move away from notions of flow or bit-rate fairness. there is a risk. risk is people get attached to a similarly constraining or ossifying notion of flow-level harm. fact that you've moved away from fairness is helpful but we're still stuck with micro-benchmarks. risk of simply having a metric and thinking it is the One True Way of measuring CC utility. It is important to consider the impact on other applications - metric that applications use to determine useful work is important - tends to be difficult and tends to evolve. As network use changes we will find metrics for more or less harm for same set of congestion controllers. we need to be mindful that we can't find a silver bullet here - there isn't one. there is a process. notion of harm from an application point of view isn't static. i encourage you to keep this in mind as your continue to pursue your research. RW: thank you. CP: thanks to all the speakers. deadline for nominations for next year's ANRP awards is this coming Sunday. please nominate good work to get great talks next year. 11:00 Close