Minutes IETF105: panrg
|Meeting Minutes||Path Aware Networking RG (panrg) RG Snapshot|
|Title||Minutes IETF105: panrg|
|Other versions||plain text|
PANRG Agenda IETF 105 When: 13:30 - 15:30 UTC-4, Thu 25 July 2019 Where: Laurier, Fairmont The Queen Elizabeth, Montreal Chairs: Jen Linkova and Brian Trammell Minutes Taker: Tommy Pauly Jabber Scribe: Tal Mizrahi Documents draft-irtf-panrg-questions draft-irtf-panrg-what-not-to-do draft-enghardt-panrg-path-properties Open Questions in Path Aware Networking B. Trammell -02 document, new in May. No structural changes to the document recently. Got some good comments. Question about being a living/open document, or publish as a snapshot in time This document hasn't been updating much and is essentially expiring. Rather than being a zombie document, why don't we just publish it? Aaron Falk: Maybe add the timeframe to the title, like "Open Questions in 2019" Spencer: I'm expecting to refer to this in my later presentations; please let me know if I should point to it as a draft or an RFC Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken) S. Dawkins Not getting a lot of new material, mainly refining existing lessons learned. Want to review the lessons learned and validate what is still true and what changed. - Overcoming entropy: I think will always be true for path aware networking - thumbs up - Providing benefits for early adopters: Same, also always true - thumbs up - End-to-end mechanisms may respond quickly enough that they can overshadown path aware mechanisms. More thoughts requested. LOOPS talked about is the complexity worth adding the extra knowledge. Can't you burn more round trips and just be simpler? Brian: Modifying middleboxes to tell you measurements won't get you there faster than just measuring. BUT for aspects that change slowly and are hard to detect, there is a benefit. Flip the question around a bit, rephrase in terms of properties. Path RTT is a terrible property to measure here. The link type (satellite link) is a much more stable property. Spencer: First thing, may have a -04 with new subsections, and this could go there. Second thing, be clear when we talk about long lived data is good. Tommy: Agree that rephrasing would be good—tell us what about a protocol mechanisms makes it more or less useful on this scale. Theresa: Discuss things that explain what the endpoint can tell on its own versus with the path's help. Spencer: - Follow the money; I think will always be true (thumbs up) - Operational practices can be show-stoppers; worth discussing; why are some protocols operationally train wrecks, and others are not? See invariants in QUIC. This is a changing area. Brian: This one also has a flip-side. Path awareness that improves operation may also be an incentive. Spencer: - Per-connection state can be an impediment; may be worth discussing, not always true. Eric Kinnear: The problems isn't that the per-connection state exists, but what is done with it. If you do have state, what is fine; but what is hard or harmful. How expensive is it? Philipp Tiesel: Stepping back, adding new functions to a network can be adding work to devices next to the routers, not on the routers themselves. This change makes it more feasible. Spencer: - In-band mechanisms might not be a fast path; similarly, this one may have more recent changes and exceptions. - Can the nework path trust endpoints? We need to talk about this! Brian: Right now, SAG is talking about discussion for opening the internet threat model to include new things. This is the path-aware internet threat model. Igor: If the endpoints have no incentive to be truthful, some mechanisms benefit truth-tellers more than liars. Spencer: - Can the network provide actionable information? Again, likely always true for path aware networking. Brian: If the information is available from measurement, why get it from the path? Spencer: - Do the endpoints know what the path needs to know? True in general. - Can the endpoint tell the path what it knows? Want to let TAPS API play out around this one. Performance Implications of Path Characteristics S. Dawkins Please read this document! Had side meeting at IETF 104 and IETF 105. Not a lot of warning on the list. Yesterday morning meeting. Had good people show up for current research on this area. (about 10) Bad news is that almost everything is still research, not concrete protocol advice. Why not do PIPC in PANRG? - This isn't for research, it's more like a BCP in the IETF (want IETF review) Paths exist, but they may change. Explaining paths on their own is good. Are all parts of a path equal in usefulness, trust, etc? Cases like wi-fi plus satellite is interesting Hints like ECN exist; hints seem safer than directives. Tell hosts "here's the path, do the right thing!" Brian: There are some properties that will tell you "you'll have a bad day if you ignore this" Are directives even possible? No. Igor: Looks like these hints are the things that try to ossify protocol, RFC8558 (explicit signals). This is dangerous to consider as a hint or directive. Spencer: Yes, that's a tension that existed in the room. Erik Kline: Certainly watching IP TTL changes on a certain network (126.96.36.199 had vastly different TTLs on different ports). Signs of interference not just path, but similar. Spencer: Another point was "trust no one!". Some applications don't want to trust anyone! Don't trust any signals into or out of the network? Want to remove all signals. A key about PANRG is that we want to guide those protocol designers too. Erik Kline: I've been contemplating a "hybrid" network architecture. What do you trust? The less you ask people to trust, the more useful it can be. Let me give local multicast a hint that there's some change. Limit the scope of what to trust. Tommy: Regarding trusting parts of the path, I think it's about provisioning; we can know only when elements of the path are aware and coordinating with one another. We can get a hint that different entities in the network and path are provisioned similarly or together. Spencer: There was a talk in IRTF open about hardening NTP, and preventing "time travel". How should you allow changes to your time, based on the sampling you have from multiple entities? If you had a sample of a quarter of NTP servers, at a regular interval, it would take an attacker 100 years to skew the clocks by less than a second. Can models like that be helpful for us? Recommend imitating that. Nicolas Kuhn : You may want to consider Gorry's draft on guidelines for congestion control - presented in parallel at TCPM https://tools.ietf.org/html/draft-fairhurst-tsvwg-cc Communication is a good thing! Brian: This room is a good place to have this conversation. Can a research group give advice to IETF? Yes, as long as it isn't binding. Do you want the advice to be binding or not? John Border: Does PANRG want to take on the analysis task? Brian: This seems a good a room as any. Looking around, there's an unfortunate conflict with TCPM; we conflicted with routing before too. Would not want to look around the room, and just see the transport people who care here, and no one else. Spencer: It would be good to update the conflicts. Tommy: We've often had too little external involvement here. Can we solicit more direct presentations from IETF protocol groups (like QUIC, say) on their path awareness work to present here in PANRG, to get communication. That way our documents can reflect that communication? Brian: We'd have to check the charter and ask the ADs. Also note that there are different path definitions in different situations. Will talk with ADs and Chairs and Spencer. A Vocabulary of Path Properties T. Enghardt, C. Krähenbühl Draft aiming to answer the first question on the PANRG draft: how do we talk about path properties. Mainly looking at terminology, making it more rigorous. Nodes process packets (hosts or routers); joined by links. Nodes and links are path elements. They join to be subpaths. Paths end with hosts. Eric: Is the sequence of path elements adjacent, for the purpose of measuring properties? Theresa: Maybe the properties are just routers, so its a sequence not a subpath. Philip: And there is always a link between nodes? Theresa: Yes. There may be a virtual link. Erik Kline: I assume this unidirectional? The path may be asymmetric? What is the flow made of, packets or subpaths? Brian: A flow is an entity made of packets to which the traits of a path or set of subpaths may be applied. Alia: You're assuming the endpoint is always a host? You're deliberately leaving out overlays in this case, which are really everywhere. I encourage thinking about overlays here. Theresa: In our definition, the overlay between routers is a subpath. Alia: The overlays may have sub/micro-flows that are different than the original end-to-end flow. So this does have implications. We keep talking about paths here as if they're static—they're not. Think about hashing, etc. Have a way of discussing the time-relevance of a path definition, and the liveness of the path. Stu: What do we call a flow when it doesn't satisfy the definition of the flow that requires it to follow a single path? Brian: You're not making any constraint on the layer on which a link exists, right? Spencer was asked to create a document to define a path, and if you apply the comments you've received, it becomes that document. We can't have an IETF-wide definition of flow or path; micro-flows, etc. Y. Richard: Great to talk about the path definition in this research group. Paths often come from graph theory. Do we design by path or flow? You have a problem enumerating exponential possible paths. Nicholas Kuhn: We may have unidirectional links with links different in each direction. Brian: Should we call for adoption? Spencer: Yes, that would help Theresa work on this with the rest of the Research Group and get more eyes on this. Brian: Also, does this first half of the document fulfil the need you (spencer) have for a definition of path? Spencer: Yes, and I think having something concrete will help us communicate about our work here. Eric Kinnear: Our abillity to communicate with others will be much improved by having this as an RG document. Al Morton: This actually matches well to what we do in IPPM. Brian: Will follow up on the list for adoption call. Experiments with Property-based Path Selection T. Krüger First IETF! Working on the SCION project, so coming from that perspective. Looking at questions 2.7 and 2.8: 2.7: How to reconcile conflicts of intent between endpoints and operators? 2.8: How can the operators be incentivized to let go of path control? This all depends on the specific path selection behaviors of the endpoint. "Path selection should aim to not be worse than the default case". Corollary is that path selection should not be to the detriment of the network. In a Kantian sense, let things be universally applicable. Path selection needs to work when all endpoints follow the same behavior. If this is ubiquitous, does it work? If there is a sudden burst of traffic, does the system scale? Did experiments with naive approaches to show that you get oscillations that are hard to dampen. Should we provide guidelines for path selection? Would it be okay for networks to misrepresent paths depending on who asks? Theresa: Very interested here, want to see more details. Related to question 2.3 as well. How can we trust, etc. Sabine: Thanks! In car traffic, a variation of 5% can cause a traffic jam. Very similar. Brian: I like the Kant reference, will use in a draft =) Very valid contribution. What's the ask? Do you want a draft? Lots of the questions are similar to transport area for bad feedback. The graphs aren't new, they just have new axes. Tommy: Yes, I can totally see this group being an ICCRG for these other dimensions of coexistence (across path selection). Philipp: I think the network should not be able to lie to the endpoints about the path properties. QUIC vs PEP Over Satellite J. Border We're looking at how we can make QUIC work well over satellite, since we can't do the same performance enhancing proxy we have with TCP. See slides for numbers on relative performance with different variables. You need a large window to get to high speed, but also enhanced loss recovery. We would like to collaborate with a high-speed connection to a QUIC server to do experiments. Want some control over BBR, etc. Theresa: Isn't this what LOOPS is for? Why can't we use LOOPS? John: LOOPS doesn't go the the end host, and most of the loss is on the first hop (Wi-Fi). QUIC makes me end-to-end. I have proprietary solutions for LOOPS type stuff in the middle of the network. Colin: I think LOOPS was open to considering this use case. Erik: Re the difference between HTTP/1.1 and HTTP/2, since HTTP/2 as built-in flow control, how did that change? C. Su: HTTP/2 has data stream flow control (6 or 12 MB) Brian: Please also take to QUIC and TSV lists. QUIC Over In-sequence Paths with Different Characteristics N. Kuhn Satellite links don't generally have visible losses, to the concerns are different. Highly asymmetric links with high jitter. Waiting for QUIC v1 for building full solution. Currently testing with QUIC-GO See slides for traffic patterns and results. Looking at FEC, also interactions with MASQUE proposal.