Minutes IETF110: tcpm
minutes-110-tcpm-00

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.