TCPM meeting at IETF-98 Meeting : IETF98, Wednesday March 29, 2017, 9:00 - 11:30 Location : Zurich E/F Chairs : Michael Scharf Michael Tüxen Yoshifumi Nishida AD : Mirja Kühlewind URL : http://tools.ietf.org/wg/tcpm/ Note taker: Gorry Fairhurst ---------------------------------------------------------------------------------- TCPM working group status Chairs Accurate ECN - Being revised by authors (no presentation) Cubic - Awaiting update (no presentation) Chairs asked for additional review by the WG. DCTCP - Review seems sufficient for moving forward. Other drafts being discussed today. draft-gomez-lwip-tcp-constrained-node-networks - liaison with TCPM going forward. ---------------------------------------------------------------------------------- WG items ---------------------------------------------------------------------------------- draft-ietf-tcpm-tcp-edo TCP Extended Data Offset Option Wes Eddy Michael Scharf: This document seems stable. We'd encourage implementation experience to help this progress. Yuchung Cheng: EDO does not currently work with GRO. There are other drafts that have problems with TSO and GRO, this is not being addressed by other drafts. Joe Touch: It is more correct to say that there is a bug in GRO - it should not consolidate options in different segments. Yuchung Cheng: They do not work together. Wes: The draft suggests falling back to not use GRO when this is known to detect. Praveen: There are some hardware limits. Joe: There could be potential hardware issues (not seen yet), and we see in Linux some problems (but not repeated) that there is coalescence of packets that should not be coalesced. Wes: Even if GRO worked correctly, this may prevent performance benefits from the hardware. If someday the hardware is updated this can take advantage. Joe: The acceleration (GRO) may not be needed in end systems - it may be more important for server farms. Yuchung: I read the draft, I have not implemented this. We see GRO helping on high speed links. ??? (Huawei): We would like to see this progress. There is no extension space in the IP space. Michael Scharf: I would like to see more reports on experience using this, it would be very interesting, anyone with interest in implementing this should talk to the authors. Jana: How mature is the implementation? Joe: There was a first implementation, but needs work to make a reference implementation. Jana: Implementation experience would be really useful. ---------------------------------------------------------------------------------- draft-ietf-tcpm-rfc793bis Transmission Control Protocol Specification Wes Eddy Plan to finish. (Charter says finish this in ~6 months.) Yuchung: I appreciate working on this. Michael Scharf: When it comes to WGLC, we could review in detail part by part. Can we check things part by part. Yuchung: I could review some parts. I wonder what we should say about the minor improvements in Nagle? Wes: I think the Linux code matches the change, so we could call this out and let implementers choose. Michael Welzl: Some TCP implementations have a low watermark function to control data sent via TCP. Is this a place it could be described as a possible implementation? Micahel Scharf: We may first need a draft. Michael Welzl: You don't need an RFC to do this, it is just a hint for an implementor at the sender. Wes: Seems harmless. Yuchung: I am on the fence, but it seems implementation-specific. A sentence or two may not hurt, and may help. Praveen: I agree a mention on memory constraints would be useful. Michael Scharf: If we normatively reference the RTO RFC, this would have implications. Mirja Kuehlewind: If we place stuff in here that is in a RFC, there is no problem. I am sure this document will get some review on the IETF list, and I expect this to proceed through the IETF progress. ---------------------------------------------------------------------------------- draft-ietf-tcpm-rack RACK: a time-based fast loss detection algorithm for TCP Yuchung Cheng Implemented in Linux 4.10 and presented an update on the spec, TLP, and CC interaction, reordering changes. Mark Allman: Why do we care about cwnd if this is the last packet? Resend and done. Jana: This is the last packet in a packet burst. Mark: I perhaps buy that, but then the example needs to be clear. Praveen: This could recover in this case based on SACK. Yuchung: Yes, in this case. Retransmission in some cases will depend on RACK. Jana: What happens if we were pacing, can we continue to pace? Yuchung: Gorry: What does "no ACK clock" mean, when you also don't have packets in flight? Yuchung: This is just after the last transmission. Gorry: This seems like the very "edge" of a discussion on flywheeling like CWV did, but this is just at the start of this happening. Yuchung: Will be careful in describing this. Ian Swett: The NACK in QUIC is different, but the way we did it helped reduce the time for this case. Praveen: The cost of delay has impact on battery nodes. Is reordering important (ECMP tries to not reorder)? Yuchung: We do see reordering of data - especially smaller packets first in a burst. Jana: Devices on the network may do this. You need to keep reordering window less than RTT, this needs a case. Bob Briscoe: I was imagining how we may adapt the level of reordering allowed with time. If we change TCP, then we can relax this for TCP. If you adapt the limit. Over years the network will evolve to do more reordering. Matt Mathis: The TCP and video codecs responded badly in a design of fabric (20 years ago) and this would allow us to make less expensive equipment if things evolve. Yuchung: I think the concern is that equipment evolves on longer time scales. Bob: We need to cap the amount of re-ordering. Jana: What do you mean by "longer" time scales. Bob: The time scale over which equipment is deployed. Jana: We can move away from reordering constraints we do not need to pin flows to forwarding paths. Michael Welzl: +1 Michael Scharf: Relaxing the ordering constraints in networks also would impact other IETF activities and published BCPs. This is scheduled for EXP, so that is OK. ---------------------------------------------------------------------------------- draft-ietf-tcpm-alternativebackoff-ecn TCP Alternative Backoff with ECN (ABE) Gorry Fairhurst Draft adopted. It is simple to implement, and will work on patches and contributions, and will report on what we see in the next IETF meeting. ---------------------------------------------------------------------------------- draft-ietf-tcpm-rto-consider Retransmission Timeout Requirements Mark Allman (remote) Update on document edits. Mark: There is no min RTO. There is an initial RTO of 1 second. Jana: I think we can talk about reducing the initial RTO when there is other side information (in a cookie). One thing that strikes me is that the notion of an RTO is two things: both a congestion timeout, and also a retransmission trigger. Mark: I did not disagree with what you said. The timeout can be used for different things. I would like to see the document finished. Jana: I think this applies without the retransmission parts and that would still be a different case. Mark: If we remove the word retransmission, and use the timer to detect loss. Jana: Yes, that is what I said. Matt: That simplifies down to result in exponentially decreasing load in the absence of feedback. Ian: Is there wording for FRTO? Yuchung: If I do linear backoff at first, then exponential backoff, will I violate the RFC? Mark: I did not nail-down exponential backoff. Gorry: When the authors wrote RFC8085, the intention was to cover a wide range of UDP usage, in one case I think it actually calls out backoff, in bulk usage use IETF CC methods with examples of TFRC, etc. The intention is to reduce load. Jim Roskind: We also should think about large numbers of thin flows. Michael Scharf: I hear comments, and think some of the guidelines need to be thought through, and that this document can't easily be published as a BCP. Mirja: We are consistent with RFC8085. This does not need to update that. We can still decide whether this is BCP/INFO status later. Gorry: Just to be clear, a WGLC in TSVWG for BCP will need people to check consistency with PS and BCPs that it relates to... an informational document requires less review. Jana: If it applies to QUIC there can should be input. ---------------------------------------------------------------------------------- Individual documents ---------------------------------------------------------------------------------- draft-touch-tcpm-2140bis TCP Control Block Interdependence Michael Welzl The authors request adoption. Mirja: Can you explain why BCP is the correct status? Michael Welzl: It reflects best current practice, saying what is safe based on experience implementing in OS. Michael Scharf: We will determine status later. How many have read this document? 5 people have read the document. 4 people think this ID would form a suitable work item for work. 10 people showed interest in work on this topic. Michael Scharf: There is no clear consensus yet on this, so we will take the decision to the mailing list. ---------------------------------------------------------------------------------- draft-looney-tcpm-64-bit-seqnos 64-bit Sequence Numbers for TCP Jonathan Looney Please read and provide feedback. Matt: This does not reference the "TCP Options considered harmful" draft. There are lots of impacts, and it seems you are refollowing the path of QUIC. Wes: How do you avoid the GRO issues we heard about earlier? Jonathon: If you need high performance, we need to do what Joe said. Yuchung: The IETF really needs to specify GRO to move forward with leveraging this. ---------------------------------------------------------------------------------- (No draft) TCP improvements in Windows Praveen Balasubramanian Mirja: Do you have any TFO measurements? Praveen: Facebook and Google have data. We plan to post measurements when we have them from deploying. Jana: Did you try implementing Hystart with the new Cubic implementation. Praveen: We did not have a good spec, we need to look before we decide. Gorry: What is LRO? Praveen: A way of compacting the ACK information. Yuchung: Linux does a flavor of ABC that used pacing. TCP stats: we could provide better info to the apps which they can use. Michael Scharf: There could be potential in TCPM to look at what stats is a minimal useful set. Meeting closed at 11:35.