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.