# LOOPS IETF107+ "design team meeting"

Repo: https://github.com/loops-wg/ietf107

Blue sheet: Please enter your name and affiliation here:

1. Carsten Bormann, TZI
2. Martin Duke, F5 Networks
3. Michael Welzl, University of Oslo
4. Zhiwen Liu, Tsinghua University
5. Mohamed Boucadair, Orange
6. Marie-José Montpetit
7. Colin Perkins
8. Martin Duke, F5
9. Mirja Kühlewind, Ericsson
10. Jianlong Wang, China Telecom
11. Joe, Huawei
12. Nie Shizhong
13. Yizhou Li, Huawei

Note takers:

1. Michael Welzl
2. ____

## 1504Z: Quick overview (10)
(slides, no discussion)

## 1514Z: Technical discussion about specific items (50)
Slide 19:
Marie-Jose Montpetit (MJM): question about overhead of ACKs. Can be large in high-speed networks. Could it be done without ACKs?
Carsten Bormann (CB): not entirely but could be reduced. Assumption that it's ok to have a few ACKs per RTT.
Yizhou Li (YL): We have experience with using NACK instead of block 1 / block 2. Not much loss, so not much overhead. Some of the ACKs are piggybacked.

Slide 23: asking for feedback on beacons
MJM: what happens if the beacon itself is lost?
CB: then you have to wait
MJM: in network coding, there's one mechanism that can work very well with lost feedback, and many don't and that can be bad. There were issues with source queues.
Colin Perkins (CP): are beacons forwarded on the reverse path?
CB: both
CP: like RTCP, seems like a useful feature
CB: relatively infrequently, right?
CP: less than every RTT but not really infrequently in a lot of cases. making retransmission decision a local matter would make a lot of sense, so it can evolve over time.
Martin Duke (MD): scope question: could it work over a path that only has loss as acongestion signal, or does it require ECN? Does it apply to all traffic? Does it depend on how congestion control works, and if so, how do you classify traffic accordingly? If loss is the sole congestion signal, I would argue that eliminating loss is a bad thing. If retransmission is the means of recovery, that introduces delay spikes, can be pretty bad. Maybe a bit ambitious to be generally applicable to all paths and protocols.
CB: can try to be as general as possible, but will scale back that claim over time as we develop the protocol. E.g. having ECN-capable transports is very, very useful for us. Certain level of reordering tolerance too. These are parameters where we still need to understand which of these we want to support.
MD: to be a WG, would have to answer these questions
CB: at chartering time, knowing applicability range would be asking a bit much
MD: maybe not exact boundaries of scope, but create at least some bounds on what you're attempting to do
CP: for chartering discussion, having a work item to understand what the applicability is would make sense. Clear analysis to figure out when this is helpful / harmful. Wouldn't gate starting the work on having done the analysis, more on understanding what kind of analysis would have to be done.
CB: We have some proofs of concept out there that show that for some applications, this is useful, so I'm a little confident that the end result will have a useful range of applicability. Also helped by ECN, reordering robustness becoming a bit more available.

CB: back to beacons
Question of overhead related to traffic load; how the ingress decides the beacon rate will be interesting.
YL: clarification question. Only generated block 2 ACKs, end of block 2 ACKs would only be triggered by beacon?
CB: Interesting; this is one way of doing it. That gives ingress complete control.
YL: should we protect the beacon itself? Depends on whether beacon itself has a unique sequence number.
CB: I think you would never retransmit beacons; send new one with most recent information. The fact that the beacon wasn't ACKed may be a reason to send it more often.
YL: slide 23: should probably think more carefully about how block 2 ACK interact with beacon, if block 2 ACK is only generated upon beacon, then it may take more than an RTT for generating block 2 ACKs. Interesting for keep-alive, but need to think how to work together with ACKs.
CB: slide 22 shows a case where DupACK is triggered fast.
CP: do we need to specify when to send ACK blocks? Can we write some suggestions and allow implementations to evolve?
CB: need to spec enough to guarantee liveness (?), but not much beyond that.
CP: I agree

slide 27:
CP: keep-alive info is maybe a little high
MD: Say I have 20 packets per beacon. Egress gets beacon for 1-20, and egress reports that it hasn't seen 19 (depending on how much reordering it tolerates), it can wait for the next beacon interval which is quite a bit longer and incurs quite a bit of latency penalty. Depends... ingress can be very aggressive about retransmitting, or there is a latency penalty. There are interesting dynamic properties.
Mirja Kuehlewind (MK): also wondering if this is the best design scheme. If you don't need a keep-alive, this may just be unnecessary traffic.
CB: cost is low if you do exponential doubling. Only paying two more beacons in total in addition to the ones that you wanted to send anyway. But need more math, so far hand-wavy. Useful input.

## 1604Z: Quick recap (10)

## 1614Z: Relationship to other WGs and RGs (40)

MK: GRE work is usually done in intarea. GRE-in-UDP encapsulation draft, IPv6 support for GRE, ..
MD: write a draft that needs input from e.g. TCPM, and present to TCPM to get their feedback, is that an export?
CB: this is missing a fourth category. Inverse of "watch" - would be "consult with".
MD: have ICCRG in mind. Generally, "consulting" is probably more important than importing / exporting drafts.
CB: good input, should have a fourth category.

Slide 34:
CP: AVTcore should be added. Interactions between LOOPS and other protocols would need to consider real-time traffic. AVTcore is doing base protocol, and RMCAT is doing congestion control. RMCAT is fairly dormant for a year or so, until decision made to move docs to standards track. Watch it but don't expect it to do much.
CB: what happened with draft-ietf-tsvwg-tunnel-congestion-feedback ?
YL: expired. Maybe reason is that author is not so active in IETF right now. Maybe work in service function chaining relevant.
MK: presented long ago, IIRC there were no major concerns about the general approach, but also not a lot of interest and not a lot of use cases

Slide 39:
CB: does anyone know of other interesting encaps work?
MJM: when we do network coding, we do encapsulation. Not encaps per se but tunnels and encaps and stuff. Application specific. Just a nit. Have tunnels, add headers and sequence numbers, ID numbers, all kinds of stuff. Have to be recognized by the encoders. Tetrys draft has an implementation.

Slide 44: does someone know how PANRG might influence what we're doing?
CP: PANRG is looking at path signaling; to discover LOOPS nodes this might be relevant.
CB: so we could be exposing information outside, but also might want to look inside our segment to find out what's going on there. Looks like long-term.
CP: yes, not short-term; but guidance documents that are relevant. Might want to watch like ICCRG, MAPRG.
MK: good to have an eye on them. Being RGs, shouldn't have a huge impact on this work.
MK: not sure about classification watch, import, export. Rather: is there any work that the WG should use rather than re-invent? This is something to do before chartering WG. Figure out what technologies you can use rather than trying to re-invent. Tunnel feedback used ECN and IPv6, simple draft, looking at this is something I would highly recommend. Only if you pick some of this tech you need to put it in the charter. Not sure if the classification provides too much insight.
CB: close cooperation would be covered by "consult". Need to split "watch" into more heavy cooperation and...
MK: becomes more clear if you have picked a protocol to use, but it's a very long list now, uncommon to have such a long list in charter.
CB: next step is to condense this gathered info into something for the charter.

## 1654Z: Wrap-up, next meeting