TCPM Meeting, IETF-101, London Monday, March 19, 9:30 - 12:00 Chairs: Yoshifumi Nishida, Michael Scharf, Michael Tüxen Notetaker: Gorry Fairhurst WG Status updates ---------------------------------------------------------------------------- No comments Working Group Items ---------------------------------------------------------------------------- * TCP Alternative Backoff with ECN (ABE) https://tools.ietf.org/html/draft-ietf-tcpm-alternativebackoff-ecn-06 Speaker: Michael Welzl Document currently in WGLC. Praveen: I saw there was a research paper. Has there been deployment on the Internet? Michael: Implemented in BSD (currently off by default). Chair: If there are no more comments then we'll close the WGLC with editorial changes. * AccECN Update https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-06 Speaker: Mirja Kuehlewind Michael Scharf (from floor): There is a non-editorial comment on the way the AE bit is assigned in the EXP spec. Compared to an option code, this is a scarce resource. Mirja: If the experiments ends with no deployment, then we have to know how to release this. Michael Scharf (from floor): If there is partial deployment, this bit remains as a "burned bit". That needs to be documented. Bob: Can we clarify? Michael Scharf (from floor): My problem is that if the PS spec changes the outcome of the experiment, then we could end-up needing one additional bit to be used for the negotiation. This could for instance be solved by using an option to indicate this usage while experimental. But I have not fully thought about the details of a design. But at minimum this must be explicitly mentioned in the document as a downside of the protocol. Praveen: Is there scope for receivers to implement - it says you MUST parse the option if you receive this? Bob: The receiving implementation must be able to parse the option. Is this OK? Praveen: It would be nice to leave this as SHOULD - to the implementer. I'll discuss on the mailing list. Mirja: We will revise the wording. Matt Mathis: There is a similar case with SACK. Be careful in the wording. Praveen: I think it is nice to not have to implement fallback. Bob: If you need to parse an option on receive this is OK? Praveen: OK Chairs: I would like to see the issues addressed and then we go to WGLC. * TCP RACK Update https://tools.ietf.org/html/draft-ietf-tcpm-rack-03 Speaker: Yuchung Cheng Jana: You said there were two approaches, in the first why would you have to keep per-packet timestamps after the data is acknowledged? Yuchung: This is processing SACK. (The timestamps are collapsed in TSO - this becomes complicated.) Bob: What are you trying to avoid? Yuchung: This is trying to avoid spurious retransmissions. A loss-based method (especially without Eifel) can have spurious retransmits. Matt: We would like to be able to support any specified reordering. Suppose there is a path that shuffles every 4th packet ... that would make things break. There is no explicit reordering threshold. Yuchung: The maximum is one RTT. Praveen: Do we see this sort of reordering? In what environments? Yuchung: We see this at the server side, we do not know where, but it is at scale. Richard Scheffenegger: Is this true? Yuchung: It is one sentence in the RFC. Yoshifumi (from floor): The RFC allows sending a probe packet - an optional mode. Richard Scheffenegger: What you are saying was the way we expect this to be. Jana: In the slide "6" (1,2,4,6 were lost) is within the reordering period. This could be too early to tell the loss of 5 (i.e. there are not more data segments after the potential loss). This seems like early retransmit. Yuchung: This is not early retransmit that requires a congestion window less than four. Jana: It is worth saying in this case the DupACK threshold has become one. I think we need to point this out. Chair: Does FeeBSD support version 3 or version 2? Is it version 2? Praveen: Windows supports an updated version 1 of the draft. Yuchung: This document seems ready. Michael Welzl: A time-based method seems to release lots of segments all at the same time, do you need to pace the data when there is no ACK clock. Yuchung: I agree. That is why we use PRR. TCP can cause bursts anyway - this is a general problem. After FR cwnd=ssthresh, this can result in lots of credit and a burst in transmit - but why is this only important in loss recovery? Praveen: This assumes timestamps per packet sent. In our implementation we tracked per sequence space, Which is different. It may be useful to compare these methods in the draft. Yuchung: There is something in the draft. Praveen: Which parts of PRR are needed? Yuchung: One part of the idea of PRR is to use pacing and gradually reduce the cwnd. Praveen: You could do this by controlling the increase in cwnd. Yuchung: Linux does both. Bob: It would be good to clearly state the objectives, to make clear what are the goals of the approach. Yuchung: Would you like to work with me on some text? Praveen: You said your implementation has replaced DupACK with RACK, did you think this replaces the old method? Yuchung: We see both existing. Chairs: I'd be interested in seeing implementer feedback on the latest versions. * 0-RTT TCP Converter https://tools.ietf.org/html/draft-ietf-tcpm-converters-00 Speaker: Olivier Bonaventure Lars: Do you insert the IP address in the payload, rather than the DNS name? Olivier: We currently insert the IP address (for speed). We could add a TLV for the DNS name, too. Matt: Are you aware of the window scale option and the rounding errors that can result with large windows? Olivier: We can discuss offline. Matt: Has there been discussion of interactions with TLS? Olivier: You need to rely in server CERTs. This does not change things, TLS works at the payload, it only impacts the bytestream. Yuchung: I do not understand the motivation. The most useful MPTCP is to solve the parking lot problem. This does not seem to match the cellular/wifi multipath usage. What are key examples of use cases? Olivier: A proxy could be put in the operator who runs in the network. The access provides both wifi and cellular case. Yuchung: This seems not common in the US. Do many ISPs provide cellular and wifi? Olivier: Many networks provide this. There are examples in RFC6041. Jonathon Looney: I found tension between the idea of a client specifying extensions, whereas the client has less control on the conversation between converter and the server. Oliver: The original goal was to support MPTCP, we have not yet looked at other options and plan to do this in the future. Jonathon Looney: This seems like a form of middlebox, and we need to avoid the normal pitfalls. (There are considerations we need to address and identify issues / problems. Example: Measurements with timestamps.) Oliver: This type of convertor is really explicit. We will make sure we explain this and extend the middlebox section. Mirja: A big difference I see is that you open an end-to-end connection to the convertor. Praveen: What about the error cases - with DDos/validating the client source address. Does it relay all TCP packets? Oliver: We only send a SYN+ACK once it has seen one from the server. To be sure the connection is established. Praveen: How do you relay DDoS prevention that retransmits SYNs. This one IP address seems to open lots of connections from the converter. Oliver: The server has a block of IP addresses that it uses (this will be clarified in the ID). Jake Holland: What happens when the client has multiple paths - some of which do reach the converter? Oliver: The client can try multiple paths and see which succeeds (bootstrap done), it uses these. Tim Shepherd: Is the convertor inside sometimes inside the OS - does an app need to be reworked to do this? Oliver: This is a little like a SOCKS proxy. Bjoern Metzdorf : What happens if the client addresses change and you own a TFO cookie? E.g. in a load-balanced server. Oliver: You may keep a table, and you may have "sticky" behaviour that keeps working with the same client. The converter knows how to manage the lifetime of the cookies it has. Special care is needed for load balancing servers. Yuchung: A walk-through of how this works would be really useful as an example. Focusing on a setup. Oliver: We could provide one example in an appendix (there are really many scenarios). Yoshifumi: Can this be implemented in user space or does it require kernel-space modifications? Olivier: It requires kernel-space work. There are three implementers I know about, and we will talk. Other Items ---------------------------------------------------------------------------- * TCP Sequence Number Validation https://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-03 Speaker: Fernando Gont (remotely) Matt: This particular set of bugs hits new implementations. A self-consistent description would be good. Yuchung: Could we merge this in RFC793.bis? Chairs: The way we decided to change RFC793.bis agreed that we would only update based on RFCs published. We would need to see. Yuchung: We should first agree on what this and whether we wish to document. Chairs: The group should decide first on whether there consensus on a solution or on guidance to implementers. Yuchung: What is wrong with a one-byte window probe? Fernando: We can do multiple byte probes - that is also possible? Yuchung: I see the problem, I need more time to read this. Michael Tuexen (from floor): What is missing is a survey of implementations other than Linux. Please reach out to implementers. I offer help for FreeBSD. Fernando: We propose what BSD does, I thought zero-window probe is specified for one byte. Lars Eggert: We should file an Errata, or update RFC793.bis - but we should not force people to make changes (make them uncompliant) because of this change. Fernando: Do we need to fix this before RFC793.bis proceeds? Chairs: The 793bis text describes this problem informationally. The working group could decide to address the bug formally. Matt: There are bugs in RFC793. The idea is to fix bugs. This bug may be one we address, we have known of this for two decades. Chairs: Who thinks it is important to do work on this topic? In favor of dealing with the issue (approx 20). Against (none). * Update on TCP Fast Open Deployment Speaker: Praveen Balasubramanian Jana: How do you define subsequent? (is it time-bound?) Praveen: It is a retransmitted SYN. Jana: On the presented data: One error (seen by Apple) was that the entire IP range got blackholed. Praveen: I mentioned this. We looked at this, but we did not see that this type of blackhole in our data set. Jana: That is encouraging. I think this should be still EXP, fallback algorithms need to be understood - I think we need more data on this. Mirja: Do you have data for mobile paths? Praveen: We looked at a range of networks, more data is needed. Mirja: +1 documenting fallback. Chris Paasch: Do you have plans for handling the unknowns. There are many ways you can mess this up in a middlebox. We saw very weird behaviours, one was with a 109 second idle period in the middle of the call. Bad things can happen, seems like we are not ready for a standards action. Michael Scharf (from floor): As an individual, I support moving towards a PS. We seem to have quite a bit of data on the outcome of the experiment. We see others using TFO - which also motivates the PS status. Matt: A small number of bizarre behaviours should not cause us to be delayed. Jana: I think fallback remains important. Yoshifumi: I have concerns about making TFO a PS. We need to decribe idempotency better. Yuchung: I think the TFO requirement has to be clear, but this is documented already - I do not see this as a barrier. Bob: +1 Jana: Can you explain the cases that were really bad? Praveen: We can talk after the meeting. Ron (?): Do you do happy eyeballs for v4/v6? Praveen: We just use the connection. Chairs: Who would support doing work on a PS for this work? In favor (approx 15). Against (none). * A New Congestion Control in Bandwidth Guaranteed Network https://tools.ietf.org/html/draft-han-tsvwg-cc-00 Speaker: Yingzhen Qu Short presentation, please discuss on the list.