Tcpm Status PagesTCP Maintenance and Minor Extensions (Active WG)
Tsv Area: Zaheduzzaman Sarker, Martin Duke | 2004-Feb-05 —Chairs:
IETF-110 tcpm minutes
Session 2021-03-12 1300-1500: Room 9 - tcpm chatroom
TCPM meeting, IETF-110, online Friday, March 12, 12:00 - 14:00 UTC (120 mins) Note taker: Richard Scheffenegger WG Status updates ------------------------------------------------- Time: 10 minutes 10/120 Working Group Items ------------------------------------------------- * Status update on draft-ietf-tcpm-yang-tcp https://tools.ietf.org/html/draft-ietf-tcpm-yang-tcp-01 Speaker: Michael Scharf Time: 10 mins 20/120 Richard: I would like to have the reset in the YANG model, not optional. Implementation could cover limitations of base OS. Michael T: R/W status on the YANG: You can not create a session, but there may be use in closing a connection. Michael S: We can look into this, may be useful. Michael T: The SCTP MIB supports it. Lars: I was reluctant when this model was adapted. Why are we doing this, if it is not referenced by anyone. Michael S: We are working to get the reference from the IDR model. From the NETCONF, we don't need the reference. The need for TCP-AO comes from IDR, not NETCONF. Documenting how to use certain things may be useful even if the YANG model is not fully implemented. * Finalizing ECN drafts: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14 Speaker: Bob Briscoe Time: 10 mins 30/120 Martin: Definition of a TCP Proxy - is that transparent? Bob: Probably not. Martin: Probably a word-smithing thing. Mirja: Ack-on-Ack: If we don't ack, counter may run out of sync, if we not ack-on-ack, no future extensibility for Ack rate limiting. Bob: Not only Ack CC, also congestion info for next volley of data, in the correct direction. Yoshi: Please continue discussion on this topic on the mailing list. Other Items ------------------------------------------------- * Updates to CUBIC RFC 8312 https://tools.ietf.org/html/draft-eggert-tcpm-rfc8312bis-01 Speaker: Vidhi Goel Time: 10 mins 40/120 Lars: We are still using GitHub. Yoshi: If you want to raise issues, please report on the list or on GitHub. Lars: Hasn't the adoption call finished today? Michael T: Yes, today or yesterday. We will inform on the list about adopotion of this draft. Richard: Still in support for adoption. * TCP-AO Test Vectors https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-02 Speaker: Juhamatti Kuusisaari Time: 10 mins 50/120 Michael S. from the floor: The YANG model references this draft. That would be one reason to adopt it. Yoshi: Moving to do the adoption call... 6 for adoption, 0 against, 60 refrained to cast a vote Bob: You didn't ask who has read the draft. Yoshi: We will follow up on that. * TCP ACK Rate Request https://tools.ietf.org/html/draft-gomez-tcpm-ack-rate-request-02 Speaker: Carles Gomez Time: 10 mins 60/120 Gorry: How to you interop with offload engines? Charles: We don't have any good baseline yet. Appreciate pointers how this is in current deployments. Yoshi: I worry about reordering. If we ignore the order, we may have to wait for a timeout. It is risky from my point of view. Charles: Agree, need guidance in the doc, when it is safe to use this. Michael T: Any implementation expirence? Charles: Not yet. Jana: How valuable and real world can this have? If we don't have an implementation, we can not evaluate the impliciation in the real world. Do we gain anything - and I don't know either way. Charles: It is not like we have no implementation, but we have not been able to experiments and measure the impact with this yet. We have some use cases for where this is useful. Ingemar: In mm-Wave user equipemnt is power limited. It would be good to reduce power consumption in this use case, also avoiding ACK aggregation / ACK thinning by downstream devices in the network. Gorry: Agree with Ingemar, but the trick is knowing if the endpoints want to do this. * MPTCP subtype capability exchange during handshake https://tools.ietf.org/html/draft-kang-tcpm-subtype-capability-exchange-00 Spekar: Jiao Kang Time: 10 mins 70/120 Yoshi: I would like to see more tanglible usecases. Martin: Is there a problem with v0/v1 MPTCP host not supporting all subtypes? Jiao: Not sure, I will discuss with my team about this possibility. Martin: This is addressing a current problem, not just an extention of codepoints? Yoshi: Please take it to the list. * Multipath TCP Extension for Robust Session Establishment https://datatracker.ietf.org/doc/draft-amend-tcpm-mptcp-robe/ Speaker: Jiao Kang and Markus Amend Time: 10 mins 80/120 Michael T: If I implements this for Linux it may be OK. What about non-Linux implementations? Markus: The information is provided by Huawei. If this is related to FreeBSD - I don't know. Jiao: Licencing was provided by company legal expert, I cannot answer this here now. Please ask in writing. Michael S: There are two IPR disclosures: from DT and Huawei. The slide was apparently from Huawei, what about the DT IPR declaration? Markus: Unfortunately not part of this prensentation. Thinking about giving this for free for non-commerical use. Michael S: Please write this down, and collect feedback if the licence terms are agreeable. Yoshi: A "possible royality fee" is ambigous. Markus: For members it may be free of charge. Yoshi: I am not a member - what will happen? Markus: Please ask Huawei. Jiao: Will forward this to our lawyers. Lars: Past IPR example in TCPM was Eifel: IPR meant nobody ever implemented it. Markus: OK for non-commercial? Lars: This won't work - Linux / FreeBSD are used in both commercial and non-commercial settings. This is so complicated, I am against adoption, purely because of licensing. Michael T: I wouldn't commit this to the FreeBSD tree, because this causes a lot of pain. Gorry echoing Tom Jones, Rodney Grimes from chat: With this unclear IPR, they would not upstream this. Martin: Ask if people are intersted in the technical merits, before fighting about the IPR on the list. * Aggregated Option for SYN Option Space Extension https://tools.ietf.org/html/draft-nishida-tcpm-agg-syn-ext-00 Speaker: Yoshifumi Nishida Time: 10 mins 90/120 Vidhi: I like this draft. What options are you thinking about on the 3rd segment? Yoshi: WS is tricky, I think about future options, where people run into option space issues. That is the focus, rather than currently used options. Vidhi: Sounds great. (if time permits) * RTO-dependent flow label generation Speaker: Alexander Azimov Yoshi: Not all implementation use a skhash. We don't want to standardized the hash calculation. Alex: We want to specify TCP behavior, not hash calculation. Gorry: It would be interesting to see if people are using this for flowlabel. This is part of a much larger discussion. Alex: I am using flowlabel in this way. Bob: I have posted a reference in the chat on the cost of cheap pseudonyms (Friedman, E. & Resnick, P. The Social Cost of Cheap Pseudonyms Journal of Economics and Management Strategy, 1998, 10, 173-199). One can shard flows and take advantage of this. If you use an additional field to say what other fields say, it break the linkage between the function of the original fields and the identifier. Alex: Example? Bob: E.g. FQ Queue prefers short flows. Then sharding gives advances. Michael T: Question whether you should have these 1:1 maps, since this is changing the flow label in the middle of a session? Alex: This is only changing during establishing the session. Jonathan: Re Bob's observation: To guard against this, one would check on port and fairness within the same 5-tuple, in addition to the flow label. Bob: I think the purpose of this work is not to go to L4 in the network. Alex: I am not sure if I want to author this document, I want to facility this work. Yoshi: Please provide a draft, then let's discuss how to proceed.