TCPM meeting at IETF-113 Meeting : IETF113, Wednesday March 23, 2022, 13:30 - 15:30 UTC Location : Grand Klimt Hall 2 Chairs : Ian Swett Michael Tüxen Yoshifumi Nishida AD : Martin Duke URL : http://tools.ietf.org/wg/tcpm/ Note Taker: Richard Scheffenegger -------------------------------------------------------------------------- 1: WG Updates - Chairs * Generalized ECN: Richard: Would support starting WGLC on Generalized ECN, no technical discussion in quite some time. Yoshi: if you can initiate discussions on the ML, we can think about if it's ready for WGLC. Bob: The document has a reference to the accurate ECN document, so it has to wait in the RFC Editor queue for the accurate ECN document. * EDO draft Jonathan volunteers to read and review TCP-EDO draft. * SYN OPT extensions Wes: Opt-Ext long time interest, ideally the WG handle this in a consensus solution. Indecent stream should only be last resort. Richard: Agree with Wes, independent stream is last resort. Would like to see this adopted because eventually extending the SYN option space will become urgent again. Martin (AD): Agree with Wes. Make a comment - lack of review bandwidth or interest. If it is lack of interest, we should not bring it in. Wes indicated interest in reviewing drafts in the space of options and SYN extensions (chat) Mohamed Boucadair: EDO should progress, syn-ext needs more cycles and vetting against Yoshi's proposal. -------------------------------------------------------------------------- Working Group Items -------------------------------------------------------------------------- 2: HyStart++: Modified Slow Start for TCP - Praveen Balasubramanian Gorry: Which implementation uses the latest implementation from the draft? Praveen: Windows 10/11 have the latest version, also FreeBSD is based on the most recent draft. Gorry: Thanks, will provide feedback Yoshi: Will confirm on list if this is ready for WGLC. -------------------------------------------------------------------------- 3: Revised Cubic as PS - Vidhi Goel Gorry: I think the 7661 is not an issue for this document. It did the right thing. Michael W: Is that the thing that Marco brought up? Vidhi: Yeah, other improvements that have been talked about. Lars: Not read all the comments yet - because cubic was deployed on the internet without following the process, IETF can not do this without undergoing this processes. People deployed cubic, and it worked. It did not happened in the way is should have been, but it we acknowledge that and publish as PS. Or we revert to Reno. The process we expect was not follow. Perhaps, we should declare NewReno historic, Gorry: agree with Lars on the first part. process was not followed, but running code and consensus. If there is no process, we need to invent one. Second: Don't agree with Lars on NewReno. Michael T.: There is a procedure how to deal with new CC. cubic didn't followed that. Lars: The process is good guidance, but requiring that to be followed hasn't aged very well. Yoshi: BBR is an experiment. All drafts should be created equally. I think RFC9002 is PS and a bit aggressive. if we set the high bar, it should not only on Cubic Draft - we should set it throughout. Praveen: Cubic as Standard makes sense. It doesn't not make sense to have it not as PS. Cubic has wide deployment experience. Martin: CC bar is high enough. Deploy at scale once deployed by large companies. I think we need to rethink this. Colin: If cubic doesn't meet the bar for PS, then nothing will. It should have been published as PS years ago. Jonathan: PS is just fine, as that is the consensus. Yoshi: Raise Hand for PS: 27 from 64 participants, 0 against Don't publish as PS: 29/66 against. 0 in favor. Publish as EXP: 1 in favor 28 against. Publish the doc as it is: 11 in favor 7 against Lars: If people are of publish as is, would like to know. Martin: People who would like to publish as EXP, should state their reasons. Michael W: What specifically are wrong, Text should elaborate on reasons that Marco raised. Lars: Thanks for volunteering to write the appendix. Vidhi: Some changes based on Michaels comments. If there is suggested text, happy to add it. Michael W: Marco mentioned on list around 8368 and some procedural things, don't know if these have been resolved. IMHO this should be a PS. Colin: I'm struggling to see what experiments can still be done here cubic has been very widely studied -------------------------------------------------------------------------- 4: AccECN updates - Bob Briscoe Jonathan: Swapping AccECN Option behavior around is opposite of interop principle. Alternate way of getting generalized ECN done. Bob: Please send on list, don't understand how this conflicts. Ecn++ is a different thing, making control packets ECT. Gorry: Thanks for the proposal on list. Not happy with strongly recommend, just explain why it is so important. Yoshi: Please continue on list, then we consider if this is ready for WGLC. -------------------------------------------------------------------------- Other Items -------------------------------------------------------------------------- 5: TCP ACK Rate Request - Carles Gomez Martin: Mantissa formula: you cannot encode 0. Doesn't zero have a meaning? Carles: It used to, but not no longer. Martin: TARR not sent reliably. Is this not a concern? Carles: We added because there was a suggestion for SYN space consideration, but maybe don't need to consider. Yoshi: Option 2 - I don't know the use case for such a large value (1024). Carles Some people said a max val of 64 should be fine. but Bob mentioned several years from now, a larger value may be good. Bob: inaudible -> list Gorry: I favor option 1, I don't know any value larger than 64 can be safe. Carles: future proofing was the main point from Bob. Yoshi: Please continue the discussions on the list. -------------------------------------------------------------------------- 6: Updates for Multipath TCP Extension for Robust Session Establishment - Peng Liu Yoshi: What we expect is additional experience when you can demonstrate this is a great idea. Also how to deal with the IPR issues would be helpful for the community. Michael T: Parallel connections setup or using timer based retransmissions is available in SCTP for a long time. So there is prior art for SCTP. Does your IPR also cover MP-QUIC/MP-DCCP or is it specific to MPTCP? Peng: I believe it is only for MPTCP. Michael T: Is it needed to be implemented in an open source OS, or only on a proprietary system? Yoshi: Really difficult to judge if this is ready for WG adoption (test result, deployment experience). I think we need more support/experience. Martin: I wonder if the Robe draft is better positioned as a MPTCP thing in TCPM or a multipath thing in TSVWG -------------------------------------------------------------------------- 7: TCPLS: Modern Transport Services with TCP and TLS - Maxime Piraux Yoshi: As this is an Application protocol, not directly with TCP. Focus of draft is different from focus of tcpm. Maxime: People in interest in MPTCP may be interested. That's the reason for the place to be here. Jonathan Hoyland: Is there a reason for not using session resumption? Maxime: Not looked into this. This is something we can look into more to invent less Jonathan H: Inventing new bits and hoping they work is scary. Maxmie: This approach is similar to MP-QUIC and DTLS discussions. Jonathan H: Cryptanalysis by intuition is generally not recommended. Yoshi: I think this is an interesting idea, not sure if this is the right venue though. But, please continue the discussions on the tcpm ML.