Agenda bashing -------------- Since last IETF, Brian posted updated version of open questions draft. No major changes. Discuss next meeting, when Brian is back. Spencer's document on what we should not be doing has been adopted. A Vocabulary of Path Properties ------------------------------- draft-enghardt-panrg-path-properties How are path properties defined and represented? Draft lists useful and relevant path properties and classify them into three categories Domain properties are properties that relate to characteristics close and strongly influenced by the endpoint (first few hops of a path, for example). Tend to have a high amount of information. Backbone properties less influenced by endpoint. Likely to stay constant within the lifetime of a connection. For example, MTU, protocol availability, persence of certain devices/ASes. Change on order of hour or days. Lars Eggert asked for definition of path (not in draft). Is scope of a path within the lifetime of a packet? Each packet has a path associated with it. If a path is associated with a single packet, it cannot be dynamic. Dynamic properties: mostly end-to-end, change frequently. Rick Taylor asked about per-link technologies telling upper layer what's going on. Dynamic properties include available bandwidth, RTT, packet loss, congestion, etc. Lars Eggert said this is a shopping list of stuff to do with path, needs more formalism. If a path is something associated with a single packet, what does "bandwidth" mean, for example. Theresa: first step was to see what we have and what is actually useful. Next step is to introduce more formalism. Lars: Start with your definition of "path." Gorry Fairhurst: I used to work on modems, and nearly everything on that list can be changed. All of these are useful for knowing what happened last time but not for what will happen next time. This is quite ambitious but you may need to be more abstract. Use "capacity" rather than "bandwidth" Rick Taylor: I think this is valuable work but a lot of these per-link properties can be represented at a higher layer. Recommend looking at some radio-related specifications. This is valuable but there's a lot of engineering that has already happened. This (link-layer information) should be more abstract. Adrian Farrell: There's good stuff here, in the shopping list sense. There's work that needs to be done on how it's collected. There's IETF work on how to aggregate info. There are also "connections" and "routes" and unless you nail this right up front it's real soup. Mirja Kuehlewind: For network metrics we have a lot of work in IPPM. Next step is bringing this on a flow level and defining what a "flow" is. Rick Taylor: RFC 8175 allows you to get per-QoS metrics Questions: 1) anything missing, 2) categorization works, 3) representation, 4) adoption Gorry Fairhurst: What's the motivation for collecting the data and does that change why you're collecting it? A: for path selection. Gorry: People like IPPM have very different motivations - did my path work (satisfy SLA?). You want to predict how the path will work - that's a different set of data. Jen Linkova: You (Gorry) mentioned a question from Brian's questions draft Brian Trammell: To answer Gorry's point, I think there is indeed an element of predicting the future here. Is there a way we can get it within a certain degree of accuracy that would be useful Giovanni from TU Delft: It would be useful to look at the definition of path in ATM Spencer Dawkins: Adoption in a RG is adoption for an RG to work on. Adoption means responsibility to the RG and RG's responsibility to the author. The other thing to mention is that it's helpful to think about is that this is going to help us have a shared understanding when we start talking about what to do and stop talking about what not to do. Lars Eggert: Gorry made excellent points. When you don't know what your units are you don't know what you're measuring. If your formalism is good enough they would just fall out of it. Ref. IETF alto working group. If alto couldn't do it, something more complex is daunting. You can be worse than random if you're wrong. (missed name) identify statistical properties. If you collect more information it will probably become obsolete faster Jen: I am getting mixed feelings from the room about adoption. The draft needs to be edited for clarity Obstacles to Deployment ----------------------- Draft has been adopted by RG, led to name change. Don't describe every idea, but capture every lesson New summary of lessons learned. Ones in red (see slides) are ones added since previous meeting. Gorry Fairhurst: some routers do process in-band signals in hardware (disagreeing with slide). Processing path is not the same when you put hop-by-hop options on a packet Colin Perkins: takes issue with *have* to trust each other. Spencer: slide on summary of edits Adrian: the word you're looking for for RSVP is filterspec Mirja: I think the lesson of those three protocols is the lesson of ECN, which is that if the deployment is complicated and the incentives are not clear, it's hard. Also, Lars was kind of keen on writing something about alto Lars: since alto came up ... it was a pressing problem at the time. P2P was killing operator networks, so there were incentives for everybody and we still couldn't deploy it. Mirja: That was my point. It was not the incentives in that case. (Somebody has to write it down, still) Spencer: One goal for this draft is that we can use it to spot proposals that might trip over known obstacles Lars: With MPTCP, because it was using multiple paths in parallel and coupling to control loops, operators were concerned that users could do real-time comparisons and it might make them look bad. Theresa Enghardt: I find it interesting to know what resistance MPTCP met, and I'm wondering what sort of draft would this lesson belonging in. Spencer: People have been suggesting what-to-do ever since he started his what-not-to-do draft. Spencer's understanding of where the goalposts are: I'd like for this to useful advice from panrg to the IETF. There's no reason to think the IETF will nto "learn these lessons again". Have we learned things for which Brian does not have an open question? Theresa: I just looked at the questions draft again. We want to do path selection on the endpoint so learning from our mistakes is applicable to section 2.3 in the questions draft What next? we could look at current path-aware proposals, we could compare the draft to panrg-questions, we could reasonably finish the draft and publish it. Gorry: I can see reasons why we might publish it for another audience. People keep saying we need to bring stuff to the IETF. It would be kind of useful to have a document that would be completely informational explaining what happened Spencer: there was a HotRFC talk about LOOPS. We talked about it at their side meeting and I was pointing them at this draft in its current form Theresa: If I remember correctly at the last panrg, this group is very transport-focused and we could use more routing people. Are there routing people in the room? (yes) Mirja: I agree with Gorry. This has archival value - there's institutional memory in the draft. Markku Kojo: Draft written with Sally Floyd on cross-layer considerations. Overlayed path segment forwarding problem statement --------------------------------------------------- Motivation: Leverage cloud router nodes for best path selection (provide performance closer to leased lines). Physical location matters but is not always the primary factor. Problem 1: Slow loss recovery over long haul Problem 2: Inaccuracy in sending rate decrease at sender Rick Taylor: what is the difference between a cloud internet and a complex transit network? A: the network transited by the overlay we call a cloud network. Alia: It's a private network, only people can connect in privately or via VPN. Inside cloud provider they have their own connectivity. They're not providing transit but they can look kind of like a transit network Colin: Is there also an assumption that you're doing (packet) processing in the cloud or are you just using them as a routing overlay? Localized Optimizations on Path Segments (LOOPS) for better reliability and throughput Adrian: I want to poke again at the definition of the word "path." Your picture is fine, the labels on your picture upset me. Maybe what are labeled as path segments should be "tunnels." Three elements of a solution: 1) local recovery, 2) congestion control interactions, and 3) traffic splitting and recombination Lars: The presentation is way too broad. The key to this is signaling in combination with transport Rick: Is LOOPS a signaling protocol between tunnels? A: it's an overlay-based mechanism. Alia: feedback loop between layers is interesting. You're saying that because it's a tunnel it takes only a single path through the network. That doesn't make sense to me. Spencer: focus on the path parts of this. Whatever anybody else can help you with, panrg can help you with the path questions. Future work includes architecture, and information model for data encapsulation and measurement, congestion control, and guidelines for interaction with e2e congestion control.