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!