* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tcpm Status Pages

TCP 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

Minutes

minutes-110-tcpm-00 minutes



          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.
          
          



Generated from PyHt script /wg/tcpm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -