TCPM meeting, IETF-100, Singapore Thursday, November 16, 2017, 9:30 - 12:00 Chairs: Yoshifumi Nishida, Michael Scharf, Michael Tuexen (remote) Note taker: Gorry Fairhurst Jabber scribe: Mirja Kuehlewind WG Status updates Speaker: Chairs ***************** Status of drafts reviewed by TCPM Chairs. draft-bonaventure-mptcp-converters Mirja (speaking as AD for TCPM and MPTCP): I would like to see a use-case for this document. Is the main use mptcp? David: As TCPINC chair: I back the question mark on TCPINC, I would not try to make this draft applicable to TCPINC. That would make a man in the middle attack. Mirja: The endpoints collaborate. David: I will look at this. Chairs: We will run an adoption call on the mailing list and look for feedback Working Group Items =================== TCP Alternative Backoff with ECN (ABE) draft-ietf-tcpm-alternativebackoff-ecn-02 Speaker: Naeem Khademi ***************************************** Gorry (as TSVWG chair): The proposal is the right thing to for SCTP. Unfortunately, the ECN spec for SCTP never got adopted. Praveeen: Recommended value is 0.8? Are the implementations using 0.8? Naeem: Yes Praveen: Has there been any work to explore what happens after applying the feedabck using 0.8 in the following RTT. Should it reduce more after loss? Praveen: You don't known if there is AQM. Gorry: This is only for ECN marks. If there is loss, the standard congestion control applies. Praveen: Still, one could get more ECN marks. Mirja: What happens if there are losses and ECN marks? Gorry: I think the loss reaction is taken. Mirja: Clarify the behavior if there is both loss and ECN marks. Naeem: With ECN, one would only react once per RTT. I will check the patches. David: The scenario is ECN CE-mark in one RTT, loss in the next RTT. Michael Welzl: Question: This is more about the behavior ECN, than about ABE. David: As long as ECN and loss reaction is the same, it does not matter. Gorry: We have to read the code. ?: Sally's papers on ECN are very clear on that Lawrence: The FreeBSD code does not apply any additional backoff. David: I have reviewed this. Most of my comments are editorial. My obverservation is that the text focuses a lot on recent AQMs only, and not on what else might be out there. ECN++ Updates draft-ietf-tcpm-generalized-ecn-02 Speaker: Marcelo Bagnulo ************************************** The WG mailing list was asked about to handle pure ACKs. Bob: The AccECN option is needed to get bytes. If a middlebox strips this then we lack info. Michael Scharf (from the floor mic): I would like to understand the differences when AccECN is used and the dependencies. I wonder if we need to deal with all possibilities. draft contains this. Could simplify the document? The current ID defines when AccECN is negotiated and when it is not. There could be editorial work, we could separate the two documents. Michael: Even for the SYN we can discuss whether it matters when we see a CE-mark in the SYN. Marcelo: This may be more pure. Mirja has made a statement that you should not ignore the CE signal. Gorry: the current doc is a little hard to read. I think we need to decide if the document would be simpler just specifying the one case, either version requires a change to the sender. So why not just say we do this for one case. Mirja: The document would be simpler if you only want to use AccECN. Marcelo: We could do two descriptions for AccECN and non-AccECN back to back. Mirja: We could just say only if AccECN is negotiated, then the rest of the process is Michael Scharf: I don't buy the argument that for the SYN you really want need to care about CE marking. I have seen this IETF one working group and one research group discussing very aggressive behavior, including not reacting to loss. Then why do we need to react to CE in the SYN? Mirja: The second point is do we care if the SYN is marked. Mirja: As soon as we see marking on a SYN - we have real indication of congestion. Marcelo: If we believe in AccECN as the way forward, the draft could state the case only for AccECN and simplify the draft. Bob: If the other end does not support AccECN, then you still need to say what happens. Mracelo: If the other endpoint doesn't support AccECN the remote will still respond reporting the CE-mark received. Bob: I am Ok to being more liberal to loss, but I think the SYN is a different case. There needs to be a response to marking on a SYN, that was the cause of congestion collapse in the Internet. We need to have a loss. Michael Scharf: Do we care about the ECN CE-mark? (a drop is VERY different). Gorry: I will send my review, this may help for the next rev. Marcelo: I will try to update the draft to focus on acc ecn case only. Is anybody against it? No one spoke up. Presentation on measuring ECN++. Ingemar: This is from the client towards the mobile network. Is it the mobile network? It could be the modem chipset that makes the difference? (on the mobile device). Stuart: You suggest that mobile handset may be at fault? Marcelo: Not so, the hardware is the same and works in the other cases. Mirja: Did you also test on non-mobile cases. Marcelo: Yes on planet lab. Marcelo: The RFC5562 spec appears to be not being used. Bob: The RFC5562 draft is odd. . Marcelo: The present ID plans to obsolete this. Stuart: I wonder what you hoped to achieve with paper? - I am concerned by the message of people reading the paper title only. Praveen: I see the paper as good news, saying it is fine to deploy AccECN update draft-ietf-tcpm-accurate-ecn-04 Speaker: Bob Briscoe ******************************* Michael (from the floor): Regarding the wording on "deployment": I owe you some text, I will send. How could a standards-track version of this be negotiated? Bob: The counter start value could indicate a different version, the current version allows such a start. Michael: I'd like to plan for the final transition to proposed standard, as this consumes a bit in the TCP header. Mirja: i think we could change the implementation. Michael: Let's plan ahead. Chairs: We will review this. We are looking for reviewers for this. Praveen: I will review. What sort of offload are you speaking about? Are you talking about full TCP offload? Windows required vendors of LRO not to group ACKs togther. I can send info about how this works. Mirja: I think this is mainly ACK aggregation. Lars: On general ECN, this is also being talked about with relation to QUIC, but decisions on how to handle ECN in the first release need to be taken this year. Bob: There is a discussion about this in the IETF today. TLP RACK Update (Remote Presentation) draft-ietf-tcpm-rack-01 Speaker: Yuchung Cheng ************************************* Gorry: Regarding middleboxes (slide 9): What was invalid? Just random numbers? Yuchung: There is an offset in the response, which makes them invalid. Praveen: You show reodering is a theoretical problem, what happens in practice. We try very hard to minimise reordering. Is this a real problem? Yuchung: All data shows that a quarter of the RTT seems sufficient. Reordering seems mainly be caused by FEC. Praveen: Is there data for really low latency links (10's usecs), can we elminate fine grain timers? Yuchung: We don't really need high-resolution timers even in data centers. It is still better than DUPACKs. Praveen: Packet-based detection is not that complicated. How come 70% of transcations recovered by timers? Yuchung: Most http server responses are a single packet - there is not much else you can do. Ilpo: There are also other cases for Linux that have this problem. It is a pretty typical number. This is about tail losses at the end of the window. Yuchung: HTTP/2 lowers the number due to pipelining. Ingemar: You can expect reordering in future 5G systems... this is important to consider. Yuchung: We can do a reorder-window, e.g. per route. Other Items =========== Extending TCP sequence number and TCP receive window draft-bagnulo-tcpm-esn-00 Speaker: Marcelo Bagnulo / Yoshifumi Nishida ***************************************************** Lars: Why can we not just use 1 bit to signal a larger sequence number space? Stuart: I think Lars suggests the sequence space works in segments, not bytes (as an option). Marcelo: We could think about that. Michael Scharf (from room): As a note, the TSOption is one of the candidates that we do not need to have in SYN... that's not (necessarily) needed in the SYN. Marcelo: The nice thing about using the TSoption is that the Extended Sequence Number simply replaces the functionality of PAWS, and this benefits from using an existing field supported on the wire. Michael Scharf (from room): The TSopt is also used for measuring RTT by monitoring tools. Most systems sample, they often do not see the SYN - it is commonly deployed as a monitoring system. Yoshifumi (from room): This is something to explore. Praveen: The default recieve window seems OK for current use. You could run multiple sessions to run faster. I worry about modifications to SACK and other things in the network that may cause this to break. We have been hurt in the past. Marcelo: I would be happy to look for data. Does it make sense to work on this? Lars: QUIC is being designed and could have solutions that scale to high speeds. This seems complicated for what it gets you? Michael: I think we are allowed to think about how to maintain TCP's usability (other protocols may not need to do this). This problem seems to mainly matter for very high-speed links (40G, 100G). Thus, we also need to think about off-loading as a key question. Mirja: Why not scale everyting? If there is a recieve window scaling, we also scale the sequence number (as proposed by lars). Laurence Stuart: Could you just use multipath TCP? Updates on Windows TCP Speaker: Praveen Balasubramanian ******************************** Jana: What data do you send in the connections? Praveen: We connect ordered in time (if there is a real problem we don't try to resume). Stuart: What does "network" mean on the slide? What happens if a particular site I visit has a box on path that I visit from multiple starting networks - do I think the networks are all broken? Praveen: Windows has a way to identify unique networks. Yes, we try to explore problems near the sender. Patrik: Firefox has a lot of mitigation strategies. The one case that kills us: when TFO is negotiated, then TLS 1.3 has a high error rate? Are there other things you cna do? Can you tell us what the timeout is on slide 5? Praveen: The full data timeout is when ... . We do not have experience yet with TLS 1.3. Jana: Thanks for doing this. I'm interested how much of this (timeouts) is linked to other problems, rather than just TFO. Praveen: We will look for these numbers. Stuart: Thanks also. It is important to make TFO safely (not necessarily a priority to make it work everywere). Meeting closed.