Path Aware Networking (PAN) Proposed Research Group Thursday, November 16, 2017 -- 13:30 -- Collyer -- IETF 100 Singapore Chairs: Brian Trammell and Jen Linkova Minutes: many thanks to Tommy Pauly! Agenda Agenda / Note Well / Bluesheets/ Refresh Chairs, 10 min There are lots of work in various areas around path selection! MPTCP, QUIC mobility, BANANA, PLUS, IAB StackEvo, etc Illustration: Today, you have endpoints that have no control other than to route to the ultimate destination In a path-aware model, the endpoints get to have much more control over what happens to their packets We have one document so far, from Brian that covers open questions in path-awareness. Please read! One suggestion in Prague was that signalling in transports for path awareness has often not worked, and we should understand why Spencer Dawkins: I think this cataloging effort will be really useful, and I'm happy to help start cataloging. draft-dawkins-panrg-mpdiediedie We'd like to have a workshop, asked for one in SIGCOMM, which would be Budapest 2018 (which may replace fall 2018 IETF meeting) Dissemination of Paths in Path-Aware Networks Christos Pappas, ETH Zürich, 20 min Motivation in research group: Endpoint discovery of paths Discover properties of the paths that are static or dynamic How do they select paths, and how to inform the network about which paths to use? Three steps: Path construction (explore topology to endpoint) Path selection (choosing the construct path) Path representation (encoding the choice to the path) In SCION, path construction happens through beacons and creation of up and down segments. Beacons sent between ASes, etc. The beacons can disseminate more extended path properties in the beacons [Details of SCION beacons and up down segments between ASes, see slides] Multipath paths can be constructed from many segments Paths are represented as interface level forwarding instructions, with identifiers per segment. In another related scheme, NIRA, there is a similar set of steps: topology construction, path selection, and representation. Source/dest IPv6 addresses represent the paths. Pathlet Routing again follows similar steps. vnodes are used for construction. Path selection is unspecified, and path representation is done like MPLS with opaque identifiers. Take aways: We have ways to handle multiple paths, and pass properties Questions: how to do dynamic properties, how to send to apps, how to lookup paths for endpoints? Tommy Pauly: I like the representation of the three steps; I think they apply beyond just these future internet models, but also for more present solutions. How can we make applications able to transition? Christos: This looks more at the network layer, but we can imagine applications first getting information before they can truly select. Thomas Schmidt: How to announce peering links? Christos: This makes the relationships more explicit, not just hidden by BGP Thomas: Isn't this in the carrier's interest to hide? Christos: The providers don't want to do it, indeed. Philip: How does this work inside the AS? Christos: This left out that problem. The issue is scalability with more disjoint information within a domain. Aaron: In a project I worked on, it had the idea of letting users select long distance providers. This was about providing hints. The intent wasn't about fine-grained control, but to differentiate providers and services that users could take advantage of. Interfaces for Path Selection Laurent Chuat, ETH Zürich, 20 min We use multiple processors, CPUs, disks for speed and redundancy. What about network paths? If one path goes down, we can have better reliability. We can also have mobility and migration (not truly multipath). Some would believe that using a single, very good path. But I argue that there is no perfect path. Information can only travel 2/3 the speed of light in fiber, so latency is a problem. Wireless is convenient but problematic. What will tomorrow's network paths be made of? Infrastructure and FIAs. MPTCP is part of the story, but since it hides paths from applications, it cannot do everything. Should we optimize for throughput or latency? We often want both. It's not easy to optimize for both. Does the application need reliable or unreliable? If contents need to be delivered, use MPTCP. If its a simpler model, just use datagrams that can be path-independent. Why do the current models fall short? There may be two paths: high bandwidth with high loss, high delay, and one with low bandwidth, low delay, and low loss. You can send on the high-loss path, and fill in gaps on the low-loss path. This allows reaching optimal bandwidth. Path diversity helps. Paper covers the function for linear optimization between two paths with different characteristics, with math and simulation. Objective: A more expressive sockets API would help here, have more knobs, on which packets, etc? What should the application learn about how the transmission went? This relates to the Post Sockets API in TAPS. Message properties are important here. Lifetime/partial reliability, priority, dependencies, idempotency, and immediacy. Lifetime: reliable vs unreliable is false dichotomy; can have partial reliability (see SCTP, D2TCP) Priority/Niceness: related to lifetime, says how well it gets out of the way Dependency: Antecedent messages show serialization between messages These problems get hard: Assigning packets to paths is very difficult as the number of paths goes up. Good news is that the problem doesn't need to be solved for each packet. Not finding the best solution doesn't rule out good solutions New APIs can drive new research into multiple paths Brian: (no hats) The graph is going up logarithmically for calculations, so may want to remove path options?? As TAPS, we want to pick the stack based on application needs to hide the complexity, while you want to expose the message properties. Provisioning Domain PvD: network giving information to clients Eric Vyncke, 15 min Work in Internet Area that relates to path selection. If we look at networks, there is often a lot of complexity of links beyond the local connection of a device. Multiple service providers, etc, just through a single local interface. VPNs too. How does the application select the right thing? In IPv4 with NAT, you select one path and just use that. With IPv6, you may want to select one of multiple addresses that you received from different providers behind your access point. The application needs to be aware of multiple paths and their properties. The MIF group defined RFC 7556, for Provisioning Domains. This is a coherent set of information for a device. Up until recently, most devices saw a single PvD. But when we have multiple, we want to identify them and understand them. We also extend the definition of PvD to point to application layer extended properties. The protocol uses IPv6 Router Advertisement. The PvD ID is defined, along with a generation count to manage instances of information, along with a bit indicating how to access extended information via HTTPS. This extended info will carry information about the network, such as its quality, walled garden, captive portal, cost, etc. Being implemented on many platforms in open source and by corporations. Also related to work by the NEAT group. Brian: Nasty question as someone who was only vaguely aware of PvD: this is a less hacky way to extend DHCPv6. Gives you more space. Architectural question: limited to first hop right now. Anything further could be segment routing, and to go interdomain. Lightning Talks on Path Properties [5 mins each] The IETF ALTO Protocol and its Extensions Sabine Randriamasy, Nokia List of open questions circulated last week. ALTO is working on exposing path properties being defined and represented, etc. The ALTO protocol guides the application in selecting paths via RESTful APIs. Built on mutual trust between entities. The properties are exposed as a cost map. While PANRG may look at HOW to connect, ALTO looked at WHERE to connect (path identification). Path Awareness for Congestion Control Xingwang Zhou, Huawei Usually, congestion is discovered passively just by observing loss, etc. ECN makes congestion an explicit signal from the network. In research, having still more path properties is very useful (ingress/egress rates) to futher optimize the bandwidth utilization. Explicit notification allows much faster adaptation, or handling variable qualities. ECN is one way to use two bits to signal congestion. For these experiments, used further extended properties as a new path-layer property. Dawn: How do you control the path properties from the application? Xingwang: No way specified for this. Can interact with resources allocated for them (?) Introduction of Open Questions (draft-trammell-panrg-questions), Brian Trammell, 5 min Sent out draft with PANRG questions: - How are path properties defined and represented? (ALTO cost maps, PvD key/values) Are these properties always the best properties? We could have a common vocabularity, but they don't have them yet. - How do endpoints discover trustworthy properties? (SCION and ALTO have trust involved) - How can endpoints select paths? (Addressing and more may work) - How can interfaces to the transport and application layers support path awareness? (Post Sockets is one point here) - How can a path aware network be effective operated? ? ? - How can the incentives of operators and end users be aligned to realize the vision of path aware networking? ? ? Lin (Huawei): These parts are huge. For address selection, are you referring to source routing? Brian: Well, we use remote addresses all the time, but I was referring to segment routing? Lin: What about v4? Brian: Why do I care about the legacy internet?... My personal view on that is that many enabling technologies work much better on v6 than v4 for this. If v6 does this much better than v4, then it's easier to move to v6 while we rewrite applications anyhow. Lee: I could imagine writing in NAT Zones Brian: "Addressing Zones" Lee: Yeah, that could come out of this work. Swetha: With the open question of how the path aware network will be operated, wouldn't the networks use this signalling between one another, not just the client? Some networks have path awareness, other don't. Brian: Very good to think about. Swetha: Also doing IPPM work that seems relevant here, defining what could be collected about the network for path properties. Would we modify the transports to carry this information? Tommy Pauly: This sounds a lot like CAPPORT problems when we talk about incentives. Brian: I like the point Aaron made earlier about the fact that multiple paths can be driven by an 'open market' for letting clients choose which provider and services they want to use. Brian: Looking forward to more in London! Smaller this time than first time, but still good interest. Allison: We need way more conflicts listed to allow everyone to come from other areas. Maybe have two different sessions to get a wider audience.