PANRG Agenda IETF 102 When: 11:50 - 13:20 GMT-4, Friday 20 July 2018 Where: Laurier, Fairmont The Queen Elizabeth, Montreal Chairs: Jen Linkova and Brian Trammell Minutes Taker: Tommy Pauly Jabber Scribe: Theresa Enghardt 11:50 5m Welcome, Note Well, Agenda Chairs Research group is now official (no longer just proposed!) We have two documents now, and we will discuss charter going forward 11:55 10m RG Charter Discussion Chairs After last meeting in London, had a few comments around the charter. No fundamental changes. Need to update the charter now that no longer proposed. Chris: (comment on preamble) Are privacy considerations considered in scope Brian: Yes, but we haven't written it down, and it should go in the scope list. Please propose a bullet point. Mirja: (as individual) Also add assurance about what path was traversed. Brian: Kind of hidden in "trust and risk models", but should be teased apart. Interactions with MP transports (MPTCP, QUIC, TSVWG); congestion control (ICCRG); and routing (LISP, SPRING) Borje: Also relate to ALTO? Brian: List is inclusive but not limited to. Please send a bullet point to the list! Brian: We need to not schedule against routing area people, and get them here and involved. Expect to be 2-3 meetings per year, colocated with IETF 12:00 15m draft-irtf-panrg-questions B. Trammell Open questions: 1. How are path properties defined and represented? 2. How do endpoints get access to trustworthy path properties? 3. How can endpoints select paths to use for traffic in a way that can be trusted by both the network and the endpoints? 4. How can interfaces to the tranport and application layers support the use of path awareness? 5. How should transport layer protocols be redesigned to work over path aware layers? 6. How is path awareness different when applied to tunnels and overlays? 7. How can a path aware network be operated in an internetwork 8. How can incentives of operators be aligned to realize this vision? 4-5 questions belongs in TAPS. 7-8 questions are deployment and political questions We will begin to answers from the top, in increasing difficulty levels We have some information already about the information that is bound to paths Looking for authors! Theresa: I've been doing research on characteristics of access networks and paths, and I would like to collaborate. Joeli: If you have a device with multiple uplinks that it's aware of, you want it to choose the paths, right? Brian: That's the first step, which we have already in many ways (wi-fi vs cellular). Where I want to get is to be able to do the same kind of multipath stuff when I'm only singlely connected. You could build this with many VPN tunnels off of your local link, you could emulate this. Joeli: Is there a vision that every end host would have this information about every path and host it wants to contact? Isn't that a lot of overhead? Brian: Yes, but agreed that the naive way to do this is not scalable. You could argue that Tor is like an anonymity focused path aware network. Brian: We need to add a note on the previous work in this space that had tapered off due to improved scalability (name??) Spencer: Would the new documents contain answers? Brian: Yes, that's the hope Spencer: How much of the TAPS related work is still research? Brian: So TAPS is building a standards track interface for protocol stack agility (generalization of happy eyeballs). We know how to do that pretty well. For (4) for interfaces for selection are not too hard. Stuart Card: We should not decide too quickly which properties are appropriate to expose. There may be internet complacency issues. Brian: Yes. Question 2 and 3 should focus on the internet case, but also explore other cases. Tommy Pauly: Regarding Question 4 and 5. 4 matches TAPS, there may be parts we don't cover there yet, where we could explore research here. Question 5, I wonder if that's less TAPS and more MPTCP and MP-QUIC. In these groups we haven't explored the ramification of having more links. Brian: Yes, we will need to have some thinking about how to make more than two links be scalable (see laurant's previous talk) Joeli: Any thoughts on dynamic or asymmetrical paths? Brian: Oftentimes asymmetric is written off as too hard; we should add this to the document. Mirja: I'm wondering if we need to start at the top of the list is actually correct, based on hearing this discussion. The first question (what is path property) is a pre-req, but the other don't have to be in order. We could focus on those questions that are NOT related to another working group if we want; or we could focus on the items more closely related to practical work in the IETF. Brian: I would start by documenting what has been done before, and what we've learned, and then see how we can not fall into those traps. I see this as a new way to frame very old questions. Mirja: For question (2) it's very related to alto. That's only one solution, but it is standardized. Lin Han: Do you encourage new architectures? Because current multipath is not deployable. Brian: This isn't about picking up an existing path architecture and trying to make it happen; we can look at those after first principles, but the concepts are more important. Gabriel: Do you want to also make this document a collection of references to previous work? See MIF and v6ops/PvDs Brian: I think this document is just the questions, the references should be for other docs. 12:15 30m draft-dawkins-panrg-what-not-to-do S. Dawkins "Bestiary of Roads Not Taken"! This document is an outcome of the first meeting at IETF99, to track the lessons from failed attempts. Was research even if we tried to do it in IETF. Major update -01 just submitted before IETF 102. Added pointers to IAB documents, and a summary of lessons learned from IntServ Quick Start TCP, TRIGTRAN, etc. Lessons: - Benefits of adoption must be big enough - Middleboxes are only helpful when trusted - Benefits must justify deployment - Per connection state is hard - Increasing distance is hard - Applications don't know what to tell transports Meant to be useful to PANRG and IETF. IETF will likely make same mistakes again; how can this provide guidance? This can also help guide PANRG work. Brian: I thought this was more useful than I thought it would be—it's blindingly obvious stuff, but we have data, which is great. Questions: are there more PAN lessons to document? Are there more places to look for lessons? Is additional work on this doc valuable? Should it be adopted by the RG? Theresa: I read document, found it very interesting. Want more content, so yes to both questions. Brian: how many people read? (several) Jen: I support adopting this document Spencer: I should point out that -01 is a lot better than -00, and most of the reason for that is that people sent material I didn't write. My inbox is always open ... Hum for adoption: Loud Hum for not adopting: Silent Brian: Let's submit the next version as a -irtf draft. 12:45 10m Requirement of User-network interface for Path-aware networking L. Han What are the challenges of path aware networking? Lack of architecture that can be accepted or deployed soon. Hard to deploy widely. Only deployment for MPTCP is WiFi+LTE or DSL+LTE Can we support PAN in current internet? Can we have multipath support with only one interface? Think yes for some scenarios. Can have one operator network, or operator working with on content provider, etc. Proposing creating new protcol between user and operator; but don't want too complicated of headers. Proposing new dataplane to replace existing stack. Dirk: Regarding UNI; the point of the internet was to not have the limited interface for the endpoint, and I'm not sure we really want to be segmenting where the network ends as mentioned here. Lin: Also have network-to-network Dirk: That raises more questions, and really deviates from the Internet model and has many traps Brian: I agree with what Dirk said about the internet end-to-end model, and adding back UNI and NNI, we blow that model up. What you're not showing here, however, is are all the tunnels to implement this. It's all encapsulation. I'd like to take this idea and get the good parts out. I do like the multiple data plane idea. Asking the network for what you want is probably not a bad idea. ?: You only trust the service provider due to previous agreement Alia: For thinking about this MPLS or segment routing, because a segment is used as an arbitrary identifier, you may think of that as a kind of abstraction of how you communicate what you want to tu policies; with well-known segment IDs that can be looked up to translate into more path data. As brian says, it is tunnels all the way down. Lin: We are only planning to use existing protocols for this. Alia: We can't intend this for just one service provider. Alia: You're thinking of tunnels as things that take time to set up Lin: Yes Alia: You don't have to have set up time, it doesn't have to look like an interface. You just say how you want to go, and off you go. 12:55 25m Open Mic Discussion Chairs Tommy: I was thinking of PvDs. Would it be useful to have a distinction between truly different provisioning domains (different services offered by network) and paths that differ in terms of quality/latency but are equivalent in terms of service they provide? Brian: We have topological properties and then this other fuzzy box. Is this a new question for the questions document? Tommy: I can try to formulate this as a question. Gabrial: What is the relation between PANRG and Network Slicing, especially regarding Question 7 and 8? Brian: This seems more about a single operator scenario. It gets much harder and more interesting in a multi operator scenario.