Minutes IETF105: tcpm
minutes-105-tcpm-00

TCPM meeting, IETF 105, Montreal
Thursday, July 25, 2019, 13:30-15:30 (Afternoon session I)
Chairs:  Yoshifumi Nishida,  Michael Scharf,  Michael Tüxen
Notetaker: Richard S.

* WG status

On generalized ECN:
Bob Briscoe: Ready for WGLC for 3 IETFs now.
Michael Scharf: Comment on draft on list, please resolve that comment.

On the RACK draft:
Praveen: Seems ready for WGLC in my opinion
Michael T: The chairs share this opinion. Checking with the authors.

* RFC 2140bis
  https://tools.ietf.org/html/draft-ietf-tcpm-2140bis
  Speaker: Michael Welzl (local)
  Time: 10 mins

Gorry: What time periods are suggested in other RFCs, any data?
Michael W: No, I don't have any information on that.

* RFC 793bis
  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis
  Speaker: Wes Eddy (remote)
  Time: 20 mins

Michael Scharf (as IC): Agree, do nothing sounds like the most reasonable path
forward. Gorry: Agree from reading 1122 previously. Will read this again after
pointing me to it. Michael T: Could it be, that this is a conditional? A SHOULD
in the first case, and a MUST in the other. Wes: Also a possibility.

3 people had read a recent version.
Michael S: Volunteers for reading the document
- Gorry, Praveen (via Jabber)

Michael S (chair): Should there be a early ask for cross area review?
Mirja: Not sure if this is necessary, other areas mainly only use this, this
doesn't change the interface. Michael S (chair): Security, Ops Area may need to
be asked earlier. Mirja: Don't think that this is necessary for this document.
Matt: Comment on who is using TCP is ironic. If Application people find
something we don't,
    we messed-up here.

* 0-RTT Converter PoC over real 5G
  https://tools.ietf.org/html/draft-ietf-tcpm-converters
  Speaker: SungHoon Seo (local)
  Time: 10 mins

Michael S: Are these prototypes or is this a production deployment?
SungHoon: We are preparing a product around this.
Yoshi: You are are using a open source SOCKS, without any authentication?
SungHoon: We can add authentication in the TLV
Y: You may want to compare SOCKS version 6 with this as it has a similar
feature? S: SOCKS requires additional handshaking, over the 0rtt Y: Good to
measure this. Gorry: Socks 6 is considered as a possible Work item in TSVWG. S:
Didn't follow socks v6 fully. Gorry: And experience with socks 6 would be well
appreciated.

Other Items
-------------------------------------------------

* HyStart++: Modified Slow Start for TCP
  https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus
  Speaker: Praveen Balasubramanian (remote)
  Time: 10 mins

Jana: Any traces to show the behavior of HyStart++, understanding the dynamics
and convergence with other flows would be good to understand. Praveen:
Collecting data from the wild to do comparisons of the effectiveness. We plan
to get data for the next IETF. Jana: HyStart tries to figure out when to leave
slowstart. But this can be done at the beginning. Praveen: We find that
SlowStart is too aggressive, and this is the reason why HyStart++ is
beneficial. Jana: Paced Chirping doesn't do this; it works very differently.
Praveen: Draft is intended to document the current implemented state. Rodney
Grimes: Have you run this on networks on ECN with CE marking. Praveen: If we
get explicit CE signal, we exit slowstart. Rodney Grimes: Would like some
experiments with ECN on. Ilpo Järvinen: Pacing tries to avoid building a queue.
hystart relies on building a queue. They are orthogonal.

Michael Tuexen (chair): Document is in-scope, we would like to see measurement
data before adopting.

* YANG Groupings for TCP Clients and TCP Servers
  https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server
  Speaker: Kent Watsen (remote)
  Time: 15 mins

Matt Mathis: The only thing that bothers me, is this group makes TCP
idiot-proof by keeping the API limited. People who muck with this generally
don't understand what they are doing. Eg. in BGP they needed a separate
liveness measure, and could not rely on TCP liveness measure. This will invite
people to break things. Michael Tuexen (individual): Timeout idletime*60 [in
sec], connection is dropped when no response. There is backoff, thus the
formula is wrong. Matt: It's a long time ago we done this. It's about reaping
stale connections [where the server dies], not making sure the network is
there. Not the usual liveness question people would assume. Kent: If none of
the values are set, the defaults kick in. The values are mentioned. Mirja:
Keep-alive comes up very often. There is a exponential backoff, but only when
there is no response.  You can easily melt the network when everything is
running by having a keepalive every few milliseconds. Putting in a big warning
around this would be good.

* YANG Groupings for Transmission Control Protocol (TCP) Configuration
  https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp
  Speaker: Michael Scharf (local)
  Time: 15 mins

Matt Mathis: Comment about heuristics are evolving: TCP extended information
MIB (RFC4898). Introduction says, if you know how the implementation
works.[...] Standards should not preclude these heuristics to evolve. Yoshi:
Status would be informational? Michael S: Would be standards, as yang models
are standard by default. Michael Tuexen (individual): Make the loss recovery
and the congestion control selectable in the yang model. That would be useful -
even platform specific Mahesh Jethanandani: First, this is useful. If you don't
do this, others will model this and there will be inconsistency. Second,
regarding Standards track: if you include groups, it has to be standards track.

* Guidelines for Internet Congestion Control at Endpoints
  https://tools.ietf.org/html/draft-fairhurst-tsvwg-cc
  Speaker: Gorry Fairhurst (local)
  Time: 10 mins

Michael S: I do care.
Rodney: Do care, should have read it.
Yoshi: Thanks for writing, support this. You didn't mention fairness.
Gorry: I mentioned multiplexing and should not starve others. Routers can help.
We should talk about fairness. Bob: I support this as a checklist, not as the
wisdom CC designers have got. Different opinions on CC though. Gorry: Started
with QUIC interim. What is a reasonable congestion control. Praveen: Very
welcome, a single document with links to other documents. Like to help make
progress. Matt: Second the idea. Be explicit not to be exhaustive. Use the word
capacity allocation instead of fairness. Just to say this. Jana: I feel partly
responsible for this. very happy to see this, want to contribute text and help
shape it. I don't want this to be a checklist - it's never going to be
exhaustive. It should have considerations. It is useful what is reasonable.
Matt: Checklist is a binary algorithm - this is not. Considerations is much
better. Michael Tuexen (chair): Sort out where this work goes TSVWG, TCPM,
ICCRG after the meeting.

* TCP ACK Pull
  https://tools.ietf.org/html/draft-gomez-tcpm-ack-pull-00
  Speaker: Carles Gomez (local)
  Time: 10 mins

Richard S: Missing clear Problem Space (IOT, Traffic types) and scenarios.
Also, we have other mechanisms like TLP, DSACK, AckCC, Data ordering where a
client can unilaterally elicit an immediate ACK by (most) servers already. Bob:
More general problem, ACK rate control is also in this space. Matt: Second
this, tough part is getting data, SCTP, QUIC have partial solution. This
matters a lot for certain applications in parts of the internet for which this
would be great. Michael T: I can always send duplicate data, just include one
old byte when sending. Gorry: We have something in SCTP with the I bit, and
there was analysis there before the work was adopted. Jana: Agree with what Bob
said. It's a requirements discussion first. Praveen: Ack timeouts are nowadays
40-50ms in most OS. As a hint, there may not be additional data to be sent.