TCP Maintenance and Minor Extensions (TCPM) IETF 99, Prague Monday, July 17, 2017, 9:30-12:00 (CEST) Chairs: Michael Scharf & Michael Tuexen Note Taker: Gorry Fairhurst WG status ========= TCPM working group status Chairs draft-ietf-tcpm-dctcp: I-D has been approved by IESG draft-ietf-tcpm-cubic: There has been an update after WGLC Working group items =================== TCP Alternative Backoff with ECN (ABE) (draft-ietf-tcpm-alternativebackoff-ecn) Naeem Khademi Michael Tuexen (from floor): I'm OK with ECN for SCTP to be added when this is specified in an RFC Michael Tuexen: You cannot modify "FlightSize". Naeem Khademi: We could say CWND is modified? Bob Briscoe: What does the implementation do? Naeem Khademi: It uses CWND. Chairs: How many have read this document? (about 5) Chairs: Who would review this document? Reviewers: David Black, Lawrence, Randal Stewart, Roland Bless. Chairs: Document will progress following publications being requested for ECN Experimentation, likely WGLC at next meeting. More Accurate ECN Feedback in TCP (draft-ietf-tcpm-accurate-ecn) Bob Briscoe Mirja Kuehlewind: There may still be cases where the AccECN option is needed to be implemented/used. Bob: In a Datacenter you still may need the field (in case you get seq. number wrap). Bob: The generation of AccECN ACKs with the option can happen in bursts. Andrew McGregor: If the RTT is really small. Bob: Receiver doesn't know what the timer resolution is. Andrew McGregor: Producing that many more ACKs at some time is going to cause issues with sending. Accross the Internet, this is no issue - if you know the destination is within the building then you could do something different. Can a receiver signal to say something is different. Gorry: The feedback option could be used to signal this. Mirja: If we say "SHOULD" this is maybe enough, the information is fuzzy, and the sender has to deal with this feedback. At the start of a flow the receiver typically ACKs each packet (where it matters). Bob: We can say try to do this during slow start. Michael Scharf (floor mic): There are some statements on the "success criteria" for the protocol. I think the success could be that the protocol is finally deployed. Michael Tuexen: Summary slide with overview of options for Nonce Sum (NS) bit reassignment TSVWG would trigger unassignment of the NS field within the TCP header TCPM now needs to decide what it would like to do Michael T.: Are there futher options? Mirja: We could also think of not-reassigning until the experiment is over. Gorry: We could rename the field as "network signaling" (NS) to preserve the semantics of the field. Michael Scharf (from the floor): We should be aware that this discussion has impact on all textbooks introducing the TCP header. Lars: I only care about the unassigning bit. (Leave it unassigned and leave it for the experiment to conclude). Bob: This negotiates a new feedback experiment for TCP. Lars: An IANA registration does not help. Bob: It helps some people who look. Michael Scharf (from the floor): We can not think about "bad" implementors. From my experience, "bad" implementers don't care about IANA. Bob: The problem with (a) is that the IESG may not do what we think. Mirja: I think the right thing will happen. Chairs: Does the WG see value in re-assigning the de-allocated NS field to AccECN? Humm for (decent) Humm against (few) There is strong but not unanimous consensus in the room for assigning the codepoint. ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets (draft-bagnulo-tcpm-generalized-ecn) Marcelo Bagnulo Mirja: If the ACK is not marked: If you loose some ACKs, this costs little performance penalty. Marcelo: I think we need to find out whether current deployed servers send an echo back from pure ACKs marked as CE. Mirja: That is for sure useful. If you mark a packet and have no feedback, that's not something in general to recommend. Marcelo: I will look for data. Could we CC control the ACKs? Jana: Don't use congestion-controlled ACKs, it is really complicated. You are very close to shooting yourself in the foot. Marcelo: I think it is useful to mark ACKs (to avoid drop), and get feedback on congestion. Jana: This is making an ECN signal that is not on data bytes. If you only send data ACKs this is the rate*40B or so. Marcelo: We want to avoid ACKs getting lost. Mirja: I think there are corner cases where a low rate of ACKs is useful. A really low rate may be important. Bob: In some cases reducing cwnd also reduces the rate. Jana: The problem here is the marks reflect the other sides cwnd, not the senders. If you reduce your cwnd (and may not be using), this may be irrelevent. Bob: This may be OK. In idle connection, you reduce your cwnd. If you later start to send, you change what you send. Jana: You can track more state to do this. It still seems odd that you reduce your cwnd, because your ACKs were marked. Marcelo: If we send data, there is a useful update. Jana: Agree, we can know this and it is useful. Most common deployments do not reduce cwnd after idle. Pacing after idle is useful. The ACK rate is proprotional to the sending rate, but reducing cwnd seems odd. Marcelo: Detect sending pure ACKs, then don't reduce cwnd. Jana: Suppose we send 1000 packet, then send one packet. Mirja: The problem is cwnd is a time-dependent value, reducing perhaps to cwnd. Do not send a marking, if you do not have feedback. Gorry: I see a continuous stream of CE marks on ACKs simply drives cwnd to 1 segment, this WG discussed what to do when a TCP sender sensd litte/nothing in RFC7661 that applies here. Bob: That is cited. Mirja: Loss due to path-change is a generic problem. Mirja (relaying Bob): You can't detect if you are loosing pure acks. Michael Scharf (as chair): Is there a cross-dependency between AccECN and this. Are there combinations where the two are deployed together? Should they be published together? Are there cases where someone would implement just one of these two? Mirja: There is a dependency of ECN++ and AccECN in one direction, but not the other way around. One of the big advantages is doing this on the SYN. Joao: There are (middle)boxes that parse on the ECT field with ECT(1) and then when the flow sets CE, anycast can generate a reset, because the path to routing the final box is changed. Andrew: If you hash on the entire byte and use ECN this causes problems. Most boxes also seem to have configurations that also allow this to be done the correct way. People should get it right. Andrew: I think you may wish to do ECN++ because you simplify the implementation. I think the benefit of setting ECT on the SYN is the biggest, I think the combination where AccECN and ECN++ are both implemented is important. Joao: The "whole-byte" processing is a hurdle for deployment of ECN. Mirja: I think the point of "byte-based" actions has is true of all ECN use cases. Individual documents ==================== TCP Low Latency Option (draft-wang-tcpm-low-latency-opt) Wei Wang Bob Briscoe: I read this carefully. I will send a review. I support the goals, but do not support the way you starting. Does this have benefit for the whole Internet? Once you know the RTT you know a lot about the flow. Wei: The main reason is that within a DC you have prior knowledge of some params. Bob Briscoe: It may be OK to initialise this, but once you know the RTT you can be sure what is appropriate. Jerry Chu: Why do we have max RTO? Neil Cardwell: You do not know what the other ends delayed ACK policy. Bob Briscoe: We could agree a standard part of the RTT to be used for these params. Neil: It's often timer granulaity of the end hosts. Brian Trammel: This seems dangerous to do this in an unauthenticated header. Gorry: An on-path device can do anything. Neil: It's still got the RTT term in the definition. Andrew McGregor: I think we can find a way to do this that just says the time-granuality. Michael Scharf (from the Floor): Can there be a mode that does this after the SYN, without using the scarce SYN option space? Mirja: I think you do not need to do this in the handshake. Jana: It seems like telling the timer granuality is too much info. I like the idea of utlising the RTT as an input. This seems like we need to send a constant. Bob: How do you configure this? (I think the constant is wrong). Jerry Chu: We have been using this and it is useful. Neil: The Max ACK delay talks a lot about how you see the whole TCP processing time. Jana: I don't think we should signal granuality. Mirja: You want something that depends on granuality and RTT. Neil: The two sides may have different RTTs. David: This mechanism is in use in datacentres, where you actually know what is going on. There needs to be some way to check what is actually the case - RTT helps give you the indication that things are not as you expect, and how to back-out from this case. Jonathan Looney: I think this is something we should do. Mirja: I think if you have prior knowledge, the data centre case is less interesting. Neil: In large cloud environments with stacks with different versions and many vendors this may be useful. Jana: The problem is interesting - and we can hash things out. Michael Scharf (chairs): Please look at the feedback and come back to the WG. TCB Control Block Sharing (draft-touch-tcpm-2140bis) Safiqul Islam Michael Scharf (chair): We ran an adoption call on the mailing list. We would like to know if there is interest? Andrew: I did not comment, because I did not see it. It is sometimes problematic and sometimes safe. Documenting the basics has value. Michael Scharf (Chair): Is there a belief that this is worthwhile to document? (10 people) - Are there objections? (none) There is a sense in the toom that there is value in documenting this behaviour. Michael Scharf (chair): What status should this be? Gorry: I think we can make this a BCP if lots of people sign-up to what this does. Safiqul: We could split the document into an informational appendix and short BCP line. Jana: I am not sure I am so excited to make this BCP, writing BCP based on deployed practice is not so useful. Michael Welzl (remote): The idea is to get clear recommendations about the practice. I think if we just hand wave about what is done that's not so useful. If we find "safe" things that we can decide as a WG. Jana: How do we know what is safe? If they are deployed and used? Things deployed are safe ... Michael Welzl (remote): Some things are not safe. Jana: The most useful part is the documenting the behaviour. Andrew: There seems support for publication. Michael Scharf (Chair): Is there intention if this can become a BCP? (4 people) - Are there objections to publication as a BCP? (none) There is value in adopting this work. The meeting concluded at noon.