owned this note
owned this note
Published
Linked with GitHub
# LOOPS IETF107+ "side meeting"
Repo: https://github.com/loops-wg/ietf107
Blue sheet: Please enter your name and affiliation here:
1. Carsten Bormann, TZI
2. Michael Welzl, University of Oslo
3. Nicolas Kuhn, CNES
4. Zhiwen Liu, Tsinghua University
5. Mohamed Boucadair (Med), Orange
6. Colin Perkins, University of Glasgow
7. Magnus Westerlund, Ericsson
8. Martin Duke, F5
9. Fengwei Qin, CMCC
10. Mohamed Boucadair, Orange
11. Jianglong Wang, ChinaTelecom
12. chi-jiun su, hughes network systems
13. Zhouxingwang (Joe), Huawei
14. Yizhou Li, Huawei
15. Marie-Jose Montpetit (part time)
Note Takers:
1. Michael Welzl
2.
## Status update
Presented by Carsten Bormann (CB)
## Narrowing down the charter discussion
### Discussion item: encapsulation
Mohamed Boucadair (MB): may get a solution which can not be deployed in near term because of assumptions
CB: yes, easy to fall into that trap, emphasis on deployment interest
Yizhou Li (YL): (something about Geneve: missed)
Colin Perkins (CP): bear in mind that whatever we're designing looks feasible to alternative encapsulations too.
CB: and what about UDP options (email to the list)?
MB: would be good if solution could use other transport encapsulations, e.g. UDP options, uses trailer part, with that approach we can run GENEVE, GUE, IP-over-IP, whatever. Generic information that we can call LOOPS-supplied information that we can put there; LOOPS ingress nodes will have to supply UDP options that will be understood by remote LOOPS node. Interesting to investigate. Might not have stable spec of UDP options in time, but good goal to have something generic, if we need something specific to the needs of LOOPS we can just go to a WG and ask for support. But then not sure if we'll have something by the end of next year.
CB: not sure about deployability.
MB: There are already experiments on UDP options, e.g. on fragmentation. Issue about checksum but there are solutions. Needs further experiments. Completely legal to use this space in packets, uses surplus area because of a difference between IP length and UDP length.
Martin Duke (MD): Perfectly reasonable to have an Informational draft that explains requirements on encapsulation.
MB: specs on options will be made in other WGs. Do we need to send a draft to NVO3 WG for this spec? Needs checking if it's ok to use GENEVE.
CB: current draft does this within boundaries of Geneve, needs no NVO3 codepoint. Proof-of-concept that this can be done. So doesn't seem necessary. IANA registries etc. available, NVO3 has defined GENEVE such that this should be possible without involving the WG.
YL: 1st 3 months: deliver generic model. If we want to choose Geneve, would we write another document on how to do this with Geneve, or all in a single doc?
CB: no strong opinion
Zhiwen Liu (ZL): good option to focus on one encapsulation such as Geneve. What are we considering when choosing Geneve instead of others? Easier to deploy?
CB: best to have something that can be implemented at user level, over UDP. Personally I'm a fan of doing this over GRE but more plumbing required. I think we should be doing it at some point in time but maybe not within first 12 months or so.
ZL: agree. We are trying to do this with GRE since it has a sequence number. But hard to make an extension. Not sure IETF will like extending GRE.
CB: at the last meeting, we identified intarea as WG to talk to when doing work on GRE. Not sure if there's a lot of energy there of supporting GRE extensions. Seems difficult.
ZL: I investigated the bundle protocol. Scenario of using bundle protocol is somewhat similar to LOOPS.
CB: Bundle protocol was done by DTN, alternative approach to IP. Don't rely on continuous connectivity as in normal protocols. Seems very different.
Michael Welzl: Agree with CB that we should focus on one encapsulation to begin with. Implementable in user space, over UDP, is a strong point. Other encapsulations could be considered when the WG has been doing its work for a year.
CB: but don't want to discourage anyone from doing experiments in this space. But the WG should focus on one encapsulation now.
CB: if this were a WG and I would be chair, I would declare consensus on this.
### Discussion item: ECN relationship
Jianglong Wang (JW): ECN is widely deployed in datacenter. Increasing interest in DC-interconnection. Routers in production network in single administrative domain we can ensure that path segments which are LOOPS-enabled are fully ECN-enabled too
CB: thank you; DC's "out there", not easy to reach, are surely a good use case; ECN enabled on LOOPS segments is encouraging
YL: you only mention ECT(0), why not ECT(1), is it because of L4S discussion?
Magnus Westerlund: clarification, current status of ECT(1) is "reserved for experimentation".
CB: if industry makes a massive move for advanced ECN features within the next month, are we missing an opportunity?
Magnus: Tunnel between ingress and egress needs to provide a response to e2e flows independently of whether it's classic or L4S, need to carry both behaviors if you don't want this restriction. Tunnel, ingress or egress, whoever's going to mark traffic will be forced to adopt L4S in order to treat it correctly.
CP: adopting L4S marking doesn't seem fundamentally difficult for LOOPS, just a diferent marking function
MD: is it worthwhile to implement an L4S queue or just lose the thing? Better to wait for dust to settle a little bit. Not super concerned that L4S will take over the world. If we come to that point, then...
CB: summary: we have some time for getting this working with classic ECN, where ECT(0) is the codepoint, can probably isolate ECN-style specific decisions enough that we can adopt e.g. L4S marking when it settles. Sounds like a strategy.
CP: Looks like L4S is going to take sufficiently long to settle, we don't want to wait that long for a decision.
CB: good if we can ignore things that are hard to predict.
CP: item 1) on the slide (ECT(0) e2e) has advantage that we know how to build it, rather than trying to do the difficult case first.
YL: path percentage, I don't have a number. Apple have already enabled ECN by default. That's a good thing to show. Just information from the website.
MD: the last I've seen are that endpoints are almost universally enabled. Question is how many routers use it versus just dropping. Should be fine.
CB: benefit is that this could create incentive to turn on ECN. Agree that endpoints with current OS are ECN-enabled in principle, but not always turned on by default. Passive side enabled, but active side I'm seeing different results from different people. Single command can enable it. LOOPS might be one of the reasons why you may want to do this.
CB: summary, we are a bit cautious about this but I hear voices for requiring E2E ECN.
### Discussion item: reconstruction or retransmission
MB: if we will anyway have retransmission, that means that some provision will be done in the protocol itself. If we start with retransmission and the exp work we'll be doing, depending on scope, size of segmments on which LOOPS will be enabled and such. If we conclude that pure retransmission solution cannot meet initial expectation, then we can move to a solution with FEC, and re-use retransmission building block .. . suggest to start with pure retransmission first rather than FEC. Simplification of cost and so on. Interesting to see if we can solve some of the problems with retransmission; if we then need to plug additional block, it can be FEC.
Nicolas Kuhn (NK): need to be sure about what level of reliability we need, be sure whether we need one or the other or a combination of both solutions. For example for our satellite use cases capacity is very expensive, time to retransmit very high, so huge trade-off here; not sure whether in cases with low delay and high bandwidth the questions are the same. Not sure if we can answer this in general, depends on use case. That's why we always have different retransmission mechanisms, depending on wireless technology that is used. For example, in satellite, we don't retransmit but repair a lot, but in WiFi the solution is different. Protocol should enable both, then maybe a specification depending on the use case may be possible.
CB: pretty sure that we want to have both at some point. Question is, can we start with one of them and add the other later? Adding one later can give us more complexity than starting with both at the same time. What are the loss rates that we're addressing? Don't have an answer, would have to come from use case. Have often said this is for cases with 10% loss or less: with 10% loss a lot of questions about adding load to network that is already loaded become less important. That's a simplification, 10% one wouldn't be able to measure in a lot of cases, normal fluctuation.
CP: might need more sophisticated signaling, more parameter choices, more possible choices with FEC.
CB: could be appropriate to think about that signaling as low rate signaling, not per packet but in RTT timescales
CP: I was thinking of negotiating which FEC coding scheme is used, parameters at startup.
CB: but we have said setup is out of scope.
CP: but with FEC you need this negotiation.
CB: yes, but could still be done with a setup protocol outside of LOOPS.
CP: yes but LOOPS would have to identify deployable setup protocol.
CB: Agreed. I was thinking about dynamic adjustments to FEC.
Magnus: That time scale wouldn't be more often than RTT level, can easily be multiple RTTs and still work fine, I think. Another thing: unfortunate that people involved in spec'ing FEC transport have disappeared.
CP: likely that we want FEC at some point. Right expertise in NWCRG. Whether we design framework and leave these things for later or include in 1st version...
CB: patent claim issues need experts.
CP: simple parity codes we could do safely. Q of how we do signaling. Will need to make it clear that apps will need signaling, else we get something where apps can't negotiate and we can't get support it later. If we believe we need both we should implement it from the start just to do the negotiation.
YL: Ideal if we can start with retransmission first. We have use cases where local recovery is on a short segment, hence less problem with re-ordering, could also start with parity code. So, proposal is to start in parallel, do not try to get the best FEC scheme rolled out in early results, real FEC can wait - but focus on interoperability testing, see if FEC works in principle,
to make sure that the initial design can acocmmodate FEDC in the future.
CB: this seems to agree with what CP said, I take this as the result of today's discussion.
## Next steps
MD: seems you have what you need to update the charter and go for a BoF
CB: do we need a BoF?
MD: didn't attend your last BoF. Don't know. Magnus?
Magnus: I think there are clear points of having another BoF. To show: hey, we worked on the side on this, now we have a proposal on what we want to do so people can easily can say "yes we want to join this work". Number of participants has been on the low side, might be good to have it as an advertisement. Getting scope right rather than just IETF review of the charter.
Magnus: Regarding previous question on what's worth adding to a charter: circuit breaker. Do we have enough of safe deployment of this that it's not going to be a massive issue? Something around saying that this has enoug considerations that it's not going to heat up all the bandwidth, important to show that charter is clear on that.
MD: BoF deadline is June 12, would require fairly quick round to find consensus.
CB: not much experience with running BoFs online; IETF 107 BoFs worked amazingly well, maybe online is good, but maybe it was the BoFs themselves.
Magnus: seems to work well. This is WG forming, going to have input charter, discussion is focused. You have quite a lot of material for the focused background for the problem scope. You can keep this clear and distinct and discuss the charter. Should not be a problem to run this BoF.
MD: Want to make sure that there are people saying they want to work on this.
CB: we had pretty good feedback on this aspect at the end of the non-WG-forming BoF, but didn't ask with specific charter.
CB: seems we know what we have to do. Will propose BoF before deadline. Will get necessary agreement on input charter on LOOPS ML before that. Update docs too. Will ADs find BoF chairs?
MD + Magnus: we'll figure something out.