Local Optimizations on Path Segments (LOOPS) IETF 105, Non working group forming BoF 10:00-12:00 Monday Morning session I Co-chairs: Ole Troan and Spencer Dawkins Note-taker: Gorry fairhurst Recording: https://www.youtube.com/watch?v=Mu99nM2usVs Introduction and Agenda Bashing Chairs The BoF is looking at transport-independent methods that “do no harm” and can benefit people who need optimisations. Chairs: What sort of people were in the room? 1/3 transport people 1/3 encaps people 1/10 apps people 2 ops people 5 measurements people 1.5 security people 10-12 people on products/systems they do some form of enhancement. Who has read the problem draft? 1/3 room “What is LOOPS?” Carsten Bormann This topic had been discussed before the BoF. This about in-network working with packet (without modification of the end-to-end packets). About half the people had read a previous presentation of the topic. Not in Scope in this BoF: Multipath; Measurement; MTU-handling; Encapsulation/Tunnels MJM: Network coding research - The NC research group is looking at loss recovery, interaction with transports, etc. Spencer: This could be that we are considering for possible standardisation. MJM: There is lots of work that has been done before, and that may be built upon. Bob Briscoe: When you move from per-link to overlay, this makes it hard to know that the loss is due to a specific link. Carsten: A link does have knowledge. There may be several things that you can find out (e.g. the delay impact on congestion control). Bob: We should talk about that. Spencer: There are things we need to understand as research and ready for standards. David Black: There are topics that may be important current WG drafts related to tunnels in tsvwg, and an INTAREA draft on tunnels with experience - these need to be understood. ?: To me, the most interesting problem is between the edge device and the network. Stephan Wegner: The problem can be solved for more tricky links in proprietary ways. Vendors do vendor specific issues, why do we need to do more? Carsten: See next talk. What is the Problem? draft-li-tsvwg-loops-problem-opportunities-03 Yizhou Li Gorry Fairhurst: I see real dangers if we have multi-level dynamic optimisation of the choice of path - TE at layer 2/3 and then overlay and both of these with transport - How do we avoid adverse multi-layer interactions? Yizhou: We see segments that have loss and adjust the methods to match the need of segments. Aaron F: At every layer where you are doing loss recovery loss, this can be/is traded for delay: You could be interpreting other people's tradeoffs and that impacts your decision. Yizhou: We plan to do no harm. Tom Herbert: Can you go back to the topology graph? It seems the transit path is the longest part of the path. If the tunnel covers a long path, the optimisation seems less effective - because it is almost the same as end-to-end. Yizhou: That is true if the tunnel is the main part of the end-to-end RTT, breaking the path into multiple segments this helps. We can spearate binto segments and adapt the repsonse for each segment. Spencer (Individual): Aaaron and I co-chaired the PILC design and being aware of subnetwork retransmissions. That's something where the IETF has some experience. Andrew McGregor: If you hide (or smear in time) the correlation between loss and delay, this adversely impacts transport. If there is non-congestive loss this camn be a good thing. At layer 2 you can know other things about the link and respond accoridingly. If you are on a longhaul path then you don't know about the uunderlay and you should leave the information untouched. Carsten: We don't want to loose the information. This is supposed to not replace the current Internet. It is intended to put this only in places (segments) where you believe you need to optimise (via some controller that understands how the network is operating). When you think about this, do not correlate resequencing with retransmission. We want to do performance improvement without resequencing. Satellite and Enterprise Office Interconnection use cases John Border (satellite Use case) Marie-Jose: There are also people wanting to add FEC within QUIC and work in the NC RG to propose this. John Border: This is more generic. I hope this is intelligent enough to do this only when needed. Marie-Jose: There are many pieces that exist, and let's see which places we do FEC and we need to ensure that we do not work against. There is work in NC RG taht looks at this. John Border: It would be nice if this works out well. Carsten: Loops can provide FEC in places where it is needed. We think this is complementary. Lars: AS WG Chair, FEC is not in the charter of the QUIC WG at this moment: there is not any WG consensus to do this. We had an older proposal in QUIC that was not developed, a new proposal could be different. Aaron: I came to learn the problem and various solutions, and we can decide later where this could be done. Jianglong Wang (SRv6 use case) No questions. Sketches of Solutions draft-welzl-loops-gen-info-00 No questions. LOOPS Maps and Gaps Analysis Carsten Borman Gorry: How do you know which packets are "important" to enhance/recover? Carstem: We assume the controller knows - could be the customer profile. We don't describe that. David Black: The slides say this is a L3-only mechanism? Carsten: Yes, that's the scope (we may look at transport ports). David: There are some things that touch on transport, and it is not just network. Lars: The vendors of PEP products have never come to the IETF in the past (we tried in the past to do this and the vendors did not come). Carsten: Is this a prequisite? Lars: These vendors need to be in the room. Spencer: It's important to consider for charter time. Toerless: There are software vendors that have new work in this space. Nicholas Kuhn: Speaking on experience at CNES - This is also relevant for the products that do this in WANs, the discussion needs to distinguish the cope of enterprise, access etc. We should not just provie a new "layer". -: There has been a focus on loss repair, if we think of diffent path segments have multiple transport functions, and transports make various assumptions to work, if the segments are mitigating these differences (even if there is a long RTT), if they are different to the assumptions. Tom Herbert: This looks likd a piece of QoS. It also has resonances with ideas in PANRG, and could be exposed to the endpoints. Tom: The second you have multipath, you need to look into the packet (flow label, etc) to do the correct things. Brian Trammel: The approaches in PANRG are different. We really focus on the interaction with the endpoint. There may be some cross-over here. Aaron: The initial benefit was to fit loss near to where problems occur, and we should not loose focus on this. Aaron: You say this motivated by operators - have they said thaty host participation is an issue, or not? Carsten: This will be in the VPN layer, it is not in the transport. Aaron: I do not understand whether that can be a part of the problem. Toerles: Is this really out of scope, why? Carsten: Why? Spencer: Maybe when there is a charter? Toerless: Why are we limiting this? Why is this not a possibility to change a host? Spencer: The community needs to be aware of this if we discuss this further? Toerless: If the problem is on the last hop - does this solve it? It seems like this option could be included. Technical Discussion Chairs ?: The NC RG is also specifically looking at satellite use cases. Bob Briscoe: I do not understand why the overlay is doing something that could be done at the link layer. Why is not easier to fix at the link layer? Carsten: That seems interesting, in a rational world, this is is correct. Both equipment builders and operators. Bob: The link technology people can do link technology. Aaaron: This is not always the case. The link transmission needs to tradeoff how hard to try v. performance. The tradeoffs may be different for an opertaor or the user - if it is too good, it can be too expensive; if it isn't good enough someone may need to improve this. Carsten: Some people only see path segments and can't touch technologies. Bob: I think the part comes in two parts; not preservinbg sequencing is another concern. Gorry: If you start changing sequencing and transport properties this then is certainly a transport topic. Tom Herbert: Are there other applications beyond satellite - where this matters? Spencer: What if there are two types of concatenated segments. Tom: We can definitely help the short path, that it has to happen so fast that we avoid packet loss. Spencer: In the days of PILC, the optimisations were may be different (when we looked then, it was 56 kbps - things have moved on). -: IEEE 802.11p - handoff in wireless is an interesting case. Hums for the Area Director Chairs Chairs: Do we understand the problem? There were abut equal level of hums saying understanding as saying they do not understand. Aaron: I see problems, I see things that are outside the IETF, history, etc. I did not udnerstand how we take this forwrad. Toerless: I did ot hear how we differentiate the traffic, refining the scope would help me,. Brian Trammel: I vote yes. We understood the problem and have bad solutions. We need to scope the solution. Which problems do we need to solve. Joerg: I understand a problem, I do not see a common understanding of the problem. Chairs: Area there things that need engineering (rather than research)? Colin: Big parts of this seem engineering. Stephan: Research is required. Is there a demand to standarise? David Black: I hummed no - I have a big concern about the scope - there are multiple problems. I'd lie to see a clear scope. Aaron: I am not clear how important this is - I do not yet know this should be done on the Internet (yet). Bill: I have questions: What is ready for transistion? What is still research? Does the research community see issues that are hiding? How do we know engineering will not find problems? Spencer: Andrew McGregor: I think the answer is that the potential scope does include research. Gorry: I think there are many issues that need work - the scope this impacts very wide many layers, that concerns me. Magnus: Who thinks that standardisation in this space is required" Hum for - Many. Hum against this - some. There were >15 people willing to set the scope.