Skip to main content

Minutes IETF109: irtfopen
minutes-109-irtfopen-00

Meeting Minutes IRTF Open Meeting (irtfopen) RAG
Date and time 2020-11-20 09:00
Title Minutes IETF109: irtfopen
State Active
Other versions plain text
Last updated 2020-11-20

minutes-109-irtfopen-00
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