Minutes IETF106: panrg
minutes-106-panrg-00

Welcome to Etherpad!

This pad text is synchronized as you type, so that everyone viewing this page
sees the same text. This allows you to collaborate seamlessly on documents!

Get involved with Etherpad at http://etherpad.org

PANRG at IETF 106 - Novemeber 22nd, 2019

Agenda: _unchanged from published_

Presentation 1: Brian Trammell
 draft-irtf-panrg-questions

Document stable since IETF102

Aaron: (snarky) Should we change the title because the questions and answers
haven't changed?

Brian: Propose as editor to publish on IETF stream
Theresa: Willing to help add something to the first question (on slide)
Mirja: Does it make sense to publish as RFC or is it something that we need to
know about as a group and work on the questions? Brian: Every meeting we land
on a different answer. Right now, publish, thinking has changed over time but
publishing this as an RFC has the advantage of giving people who are working on
technology in this space who are not in this room something that they can point
to, which is a good service to the community Aaron: Agreed, given that the
answers are coming in slowly, it seems that these questionsn will be around for
a while Brian: There will be text edits coming in, but after that we may want
to take discussion on publishing to the list. Hope to get this done before
Vancouver.

Presentation 2: Theresa Enghardt
draft-enghardt-panrg-path-properties-03

Theresa: Got review on list, thank you. Want to cover scope: Discussing the
information the network exposes and how to express that. Want to confirm that
this works as a basis for developing a common language around paths? Tommy
Pauly: I think we should adopt this, I think it's a good starting point. Thanks
for all the work to incorporate the comments. I think the terms do work and are
more narrowly scoped than before, which is good. As an aside, we have the
notion of node in here, which is general (and general for a purpose), but
should we have a specification for node/type of node with regards to path
awareness. Some notes I traverse and have no choiecs, but there may be nodes
that allow me to make choices. Something that acts as a proxy or enables path
selection, especially nodes that participate with the client in measurement or
selection, so a split between transparent nodes and nodes that "actively"
participate with the client. Theresa: Maybe we want to add a property of a
node, like a node has this feature

Sabine Randriamasy: Can we assume that these will always be available?
Theresa: I don't assume anything, this is just a definition of a property so
that if a device can generate or process it then we can use this to talk about
it, but we're not trying to cover in this document how a node would come up
with these things. Sabine Randriamasy: Next question, seems that you might want
to define a representation format for paths and their properties. This looks
very similar to what is done in alto, alto designs a service which is called a
path vector, that may be useful to your work because between two endpoints you
make a breakdown on what happens between two endpoints. This would support what
you would like to have as information. A couple of interesting features that
you mentioned, like a list of available transport protocols (end-to-end), that
might be useful, so it seems as though there would be room for common work
here, please Theresa: We've read a bunch of additional drafts, we have a list
of working groups, etc. that are related, but I will go back and double check
that we're covering everything from alto

Brian: Yes, I think this is a good start, I think we should continue this
discussion in the RG, that's what we're here for. There are a couple of minor
things I would change, but we can discuss those later. Tommy's idea is
intreiguing but terrifying, I don't want to go down the node
properties/classification in the path properties document. I think there is
room for talking about this is/is not transparent, but beyond that I think
there's a whole bunch of unclarity and that's a somewhat different problem.
Theresa: We do already have service functions in there, so maybe we could
annotate? Brian: I would be careful to not try to cover all of the service
functions Theresa: Agreed Brian: Sounds good, I would like to make sure that we
generalize things in this document rather than being super specific. Re: alto,
I think there's a clear line between responsibilities in terms of building
representations vs. working on abstract categories. If we say that this is a
wire encoding for these things, then that's IETF work. Brian: Yes, I support
adoption of this, let's work on it here.

Joachim Fabini: I find it interesting to have a property of a layer X
transparency, so we could have a property on a specific layer, if you're
transparent for a given layer then you have an end-to-end conversation between
the adjacent non-transparent nodes. Theresa: Could you find a reference for
that and post it to the list, I'd like to take a list at how you mathematically
express those. Joachim: For security, is there any property about
security/encryption at a specific layer? Theresa: I could imagine talking about
trust in some way, that's really complicated, I'm not sure you want to cover
how much you trust a specific path element as a given property. You would
always have to qualify it, and encryption is not the same as encryption.
Joachim: Encryption could be done from end nodes to end nodes Theresa: I'm not
sure I'm defining a threat model in there, though. The trust question is really
interesting and we should revisit it

Philipp Tiesel: Thank you for doing this work, I see it maturing a lot and I
think it's in a place where we should work on it as a RG. Tommy's comment made
me stand up, I think it's very good starting with a generic description of a
path as a sequence of nodes, but I don't think things like nodes that
can/cannot do stuff are something useful because I would rather prefer
functions that could be on the path as two different paths (so, for example,
one with/without the node). About transparent/non-transparent, i.e. whether or
not it's breaking the end-to-end principle is an interesting property, but I'm
not sure if we need that in the base definition or if that's the first property
that we'd want to define. I'd also want a property for what information it's
passing along. Theresa: Interesting,

Mirja: Plus one on adding transparency or definition of transparency, but don't
need to decide before adoption. I think it's a good approach to look at the use
cases, but right now I'm a bit confused by what you're saying here: example,
performance montioring, but what you say there isn't what I think of as perf.
monitoring, you're talking more about general properties. Everything that's
related to measurement, the question is always about what is the measurement
timeline. My understanding is that this group was scoped over things that are
more long term, not just the last second. Theresa: Would definitely be open to
contributions to the use cases section. For performance monitoring, we can have
both, short term is delay on single packet and then you can aggregate Mirja:
That's very into the measurement methods of how to access this metric Theresa:
We're not really attempting to answer that question, right? Mirja: I'd rather
define the metric and then look for the right measurement for it. Traffic
configuration is pretty much the same, sounds like you're diving into doing
congestion control here Theresa: This can be protocol features, but can be more
general

Max Franke: Clarifiying question. You say that links and paths are
unidirectional? Theresa: Yes

Andrew McGregor: Representing different modes of a path as separate paths is a
bad idea because what you want to do is represent where the shared resources
are. If you say you could go through this tunnel or not, how do you represent
that you're sharing buffers, etc. between different versions. Those are one
path that can operate in two different modes.

Brian: Hands, who has read the draft? (Roughly a dozen hands)

Jen: Hum for <yes, adopt> or <no, do not adopt>
Brian: I heard lukewarm support for adoption, crickets on non-adoption
Andrew: There was one cricket for non-adoption

Presentation 3: Spencer Dawkins
draft-irtf-panrg-what-not-to-do-04

Spencer: Last two major revisions have been mostly summarizing the draft, goals
are to inform people outside the RG (especially engineering outside the RG),
and it seems like we need to publish to inform people outside of the RG. Even
this meeting week I've had several conversations in other groups where I've
pointed presenters to this draft because they had something in a proposal that
was covered here as an impediment. IAB has active discussion on model-t mailing
list for Internet Threat Model about endpoint and intermediate device trust, we
can't really assess risk until we understand these lessons

Theresa: I think you asked the right question at IETF 105, this question is
related and more specific, if you define risk as trust, but we had lots of
questions about deployment and things getting deployed. About the threat model:
this is interesting and we should follow and give our angle from our context,
but beyond that I'm not sure what we have to contribute

Brian: Questions on this slide are questions in the questions doc. I want to
encourage people in this room who have ideas in this space to go and
participate on the model-t list with the IAB. The sense of the room there was
that a lot of this stuff needs to be moved into the IETF sooner rather than
later. Since a lot of this is going to update the internet threat model /
guidelines for writing security considerations, the wider questions about
endpoint vs. intermediate device trust are something that need to be considered
in that effort. There's work to do there and the reason that I wanted to frame
the questions in the questions draft was to see if there's a way to restrict
scope on those questions so that we can actually make progress on them.
Spencer: What we've been trying to do in here has been to inform research
in/outside the RG and engineering.

Colin Perkins: I think if there are things individuals participating here wish
to provide as individuals to the model-t list, that would be an interesting
exercise. We should distinguish between revisiting the Internet Threat Model
which is used to frame standards and us doing research into internet security
and threat models. Spencer: We can do research in this space even if not as
part of the what-not-to-do draft Colin: This group can write a draft that says
"we believe these things are problematic". I don't think this group should be
defining how the IETF as a standards body is dealing with internet threat
model, but individuals should happily go participate over there, but IRTF
should not be trying to provide input for that.

Wes Hardaker: I think we often get too hung up in the IETF on what's blocking
what. The reality is that the work going on here overlaps with model-t, and
that's good but both groups will feed back into each other.

Spencer: Proposed next steps: Do a larger editorial revision to fix up the
phrasing and do a RG last call on -05 and request publication as IRTF stream
informational draft

Theresa: I'm in favor of RG last call and I'm going to review the document.

Brian: (as chair) My perception in watching this document over time is that the
velocity is going down, is there anything that could be gained by keeping it
open, it seems as though we're wrapping up a lot of the work in flight?
Spencer: We added material on various topics, what has been changing has been
that we've been adding more and more text that's summarizing those
contributions, we haven't added any new contributions or lessons in a couple of
IETF cycles. I think we may be at a point where it's more important for people
outside the RG to read this. Brian: Okay, we'll wait for the next revision and
then we'll start RGLC

Presentation 4: MTU is Hard
Gorry Fairhurst, Bob Hinden

Gorry: Lots of layers, lots of MTUs.
So, fragments. But fragments bad, lots of problems when lifetime and order not
shared. So, have the network tell you how big of a packet to send. Bob:
Fragmentation has gotten worse than it had been at the beginning. Gorry: PMTUD
lets us get a signal from the path saying how big of a packet you should send.
Bob: Great, but lots of boxes don't send or filter. Or have a route back to the
host. Gorry: TCP MSS made this challenging, MSS clamping is widely deployed.
Bob: IPv6 has fragmentation, but routers in middle don't do it, only endpoints.
But, didn't discourage people. Gorry: Sometimes ICMP value bad, don't trust
that the signal is from a real person who saw your packets, maybe transport
shouldn't use ICMP. Bob: Any useful network signal can be abused, need a way to
verify. Gorry: Maybe they're hints from the network about what to do, check to
see if it actually supports it. (D)PLPMTUD is here, new signals like HBH
options, path signals are advice. Let's measure! Bob: Different probes get
different values, HBH options were 0% from Bob's home router/ISP/etc. Gorry: Do
not take this as a measurement of what the internet supports, take it as an
indication of what the internet supports. We want to deploy more probes.
Summary: The only thing you can trust is your probes, but you can use lots of
hints to help you build those probes

Colin Perkins: Can you summarize here on on the mailing list what you'd need to
run one of these probes? How about a script to test if someone's network is
suitable for running it? Gorry: Will send a request to the list Colin: Is it
custom hardware or what? Gorry: Small box that runs linux, could run as a VM,
there are different ways of measuring. Tell us if you're interested.

Presentation 5: Impact of Asymmetric Path Characteristics
Gorry Fairhurst

Gorry: ACK behavior has lots of implications. ACK traffic can constrain
throughput in either direction, capacity is often different. Many people deploy
boxes on the path that compress the data, or use other methods. Radio links
bring costs per packet transmitted. QUIC, can't use a PEP for encrypted
traffic, but same problems as TCP. If we knew the path's capacity/resources and
asymmetry we could know what to do, not a great thing to signal and you often
don't know what link you're using unless you're directly connected to it. I
think this needs to be solved by the transport.

Spencer Dawkins: Thank you for bringing this here, this is terrific for us to
think about. The one thing that I was going to say to make this more of a
research problem is that I didn't hear you talking a lot about the situation
where the physical path is changing. Gorry: I think that can cause this as well
as the radio link. Spencer: But if you remember the problem and adapt and then
the plane moves, you may need to recover from that. I think this is terrific
and quite important. Gorry: If we have boxes on the path, chains of multiple
things, it would be nice to have good tools to know what's happening here so
that we can debug what's happening at a higher level.

Tim Costello: Thank you, this is a very good presentation, working on ATSSS for
5G using multipath to steer and your path may change, do you have any
consideration about that. Gorry: No, but don't trust the path at all, it really
can change. I hope it doesn't change so fast that it disrupts what's going on
at a higher level. Do we think that the path is trying to help you?

Andrew McGregor: I think the common sense here is that the layers below
transport need to supply signal at a rate that is tolerable for the transport
to know what's going on and the transport needs to be mindful of its own
learning rate.

Eric Kinnear: We don't look for path change currently but we do listen for
local changes that a path may have changed on the first hope and take that into
account locally on an endpoint.

Spencer Dawkins: We're deep into the territory about what-not-to-do, I think it
might be helpful to talk about this in the RG, let's move on to new mistakes

Nicolas Kuhn: Two small comments: Are we sure it's because of asymmetry or
large RTT, to what extent the RTT has an impact on that? Eric Kinnear: From
experiments, keeping RTT constant and changing asymmetry, it shows these
effects Nicolas: We have a draft in QUIC to exchange info from client to server
about what you have estimated about a given path so that you can exchange
information and then use that to decide if you're going to adapt your rates,
etc.

CJ Su: Very interesting talk, have you looked at BBR and the impact here on BBR.
Gorry: Yes, I'll comment on BBR, BBRv1 wasn't as good, BBRv2 is better :). I do
have some text in these slides about some of that.

Jen: That's all folks!