TCPM meeting at IETF-84, Monday, July 30, 09:00 - 11:30 ------------------------------------------------------- Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Note takers: Andrew McGregor Richard Scheffenegger Matt Zekauskas * WG Status chairs No comments / discussion * Shared Use of Experimental TCP Options draft-ietf-tcpm-experimental-options Speaker: chairs proxying Joe Touch Awaiting WGLC. Lars Eggert: If this goes to PS, will all new experimental RFCs have to use this, or will there be two classes of experiment? There are two classes, mptcp being the prime example. Wesley Eddy: Argue for real option number Yuchung Cheng: We recently put fast-open into Linux, using this draft. The maintainer asked what the transition plan is, so this needs clarification. * A TCP Authentication Option NAT Extension (not a WG item) draft-touch-tcp-ao-nat Speaker: chairs proxying Joe Touch Wes George: This perhaps should be bought up in sunset4. I don't think we would adopt this, due to lack of expertise in the group, but there should probably be some cooperation, since sunset4 is supposed to be focused on ipv4 specific tweaks that make CGN as functional as possible. Lars: I don't think that prevents Joe from publishing it on the individual stream now, if sunset4 wants a normative reference it could be republished on the IETF stream (ipv4 specific, which is dead, take it to sunset4) Lars: Yes, but it is in fact a TCP extension. * Proportional Rate Reduction for TCP draft-ietf-tcpm-proportional-rate-reduction Speaker: Matt Mathis Ready for last call, there have been positive comments, and it will proceed. Lars: Should we be obsoleting the rate-halving RFC with this? Matt: It updates rather than obsoletes Yuchung: It's an expired draft anyway Matt: It was always obsolete Lars: Which didn't stop people from implementing it. Point to expired draft, and make sure rate-halving is obsolete. * Increasing TCP's Initial Window draft-ietf-tcpm-initcwnd Speaker: Matt Mathis Last call ends today, looking for final feedback * TCP Fast Open draft-ietf-tcpm-fastopen Speaker: Yuchung Cheng Alan Ford: When you say per path, is that per pair of addresses? Yuchung: Per destination address and port Anantha Ramaiah: What would be the side effect with IW10? Can I send 10 segments with SYN? Yuchung: No, the client can only send one. ?: How does this work with the MSS? Yuchung: We cache the MSS ?: Does this work with MSS-clamping by middleboxes? Yuchung: What if you send SYN-data with too large an MSS? The cache will record the old MSS, or else the packet will be dropped and we fall back to standard TCP Michael: Can the server respond with IW10? Yuchung: Yes, it can send a SYN-ACK followed by 9 data packets Michael: It would be good to get some data on whether that is too aggressive Yuchung: Currently we do not have data on this * RFC 1323bis draft-ietf-tcpm-1323bis Speaker: Richard Scheffenegger Michael: Enabling timestamps late is a change, does the group think this is OK? Tim Shepard: I'm sceptical that late timestamp negotiation can work Richard: This is just sending timestamps Tim: I was planning on talking to Matt about this Matt: thanks for taking this forward, this is really important document, people need to take look at this, has many implications. There are many corner cases not known for years. Richard: Appendix C summarizes changes relative to RFC 1323 Andrew McGreagor: Regarding Nyqist -- point about Nyquist criteria not pedantically corrrect but numerically correct, and correct spirt, no reason to change Kevin Fall: not counting SACKed segments? is there any analysis of the implications e.g. with wireless networks Answer: 1323 has provision, if reordering pure acks. Sender gets conservative RTT est. So in worst case there is higher than actual RTT and conservative samples. If sender knows about reordering in forwarding path, it doesn't sample RTT in presence of SACK option, shows reordering/loss Kevin: so beyond draft, are there any documented case of lossy net w/o reordeirng that would be affected? Michael S: Removed one/half sentence, changes semantics of timestamps, enables late enabling of timestamps. Could argue this is minor, but interested in feedback, whether this hurts things. Pasi: We need some reviewers Matt and Mirja volunteered * Additional negotiation in the TCP Timestamp Option field during the TCP handshake draft-scheffenegger-tcpm-timestamp-negotiation Speaker: Richard Scheffenegger Matt: I like the idea of splitting this draft. Since you don't have a calibrated way of knowing the clock drifts, you have to measure the drift, and if you're going to do that you may as well use implicit determination of the rate. Richard: RTTM negotiation for existing implementation is very likely to get spurious RTOs Matt: So the problem is legacy code gets unexpectedly low RTT measurement Richard: Yes, which is why it happens only after negotiation Matt: It might be good to have that change over time, since there are not many implementations that need fixed and the new algorithm is in itself significantly simpler * TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart Speaker: Michael Welzl Yuchung: Do you have any plans to do real workload experiments with the Linux implementation? Michael W: Yes, there will be a paper Michael S: If there's a spurious RTO, is there any penalty? Michael W: Not a significant penalty, as there are only at most 4 packets, and its a low probability case. Will be looking at this. Mirja Kuehlewind: Did you also have reordering in the simulations? Michael: You'll have to ask the other author, I don't know Michael S: We have two drafts that addresss a similar issue Richard: They're complementary, even though if combined they may have a greater penalty. I think I simulation with both is in order Michael W: I think they're complementary but separate Adoption call: 6-7 people support, no one is against. 3 people willing to contribute cycles. Pasi: Let's take the adoption to the list, but it looks good * TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses draft-dukkipati-tcpm-tcp-loss-probe Speaker: Nandita Dukkipati Bob: Is there evidence that losses are at end? Nandita: will show later Mirja: Are these stats for IW10 or IW3? Nandita: This is IW10, but the stats are very similar for IW3 Bob: Have you thought about using application knowledge of the length of the transfer? Nandita: It helps in certain cases, but if there's a number of tail losses, not so much. * Evaluating TCP Laminar draft-mathis-tcpm-tcp-laminar Speaker: Matt Mathis Mirja: Are you planning to update the various RFCs Matt: This is a huge amount of work, and some of those documents are currently open. The reason we were planning on spinning this discussion off is that it is hard to think about short-term and long-term changes simultaneously, but it may be more confusing to do it elsewhere. This is partly why I have not requested WG status for this, because it constrains the processes. Dave Taht: At one level, you have this simplification, and you have these nice features like packet pacing, how will you reconcile this? Matt: So, that's why the code was split Lars: I think this is important, but needs a new working group for the refactor, since tcpm is too busy. Can have chair overlap to ensure continuity. Once laminar is stable, we can open the door to the enhancements. Matt: So, there are some widely deployed algorithms that are not in IETF documents, and they should be in scope Lars: Yes, but lets keep the blue sky out for the time being * More Accurate ECN Feedback in TCP draft-kuehlewind-tcpm-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option Speaker: Mirja Kuehlewind Bob: Clarify... one draft, both, neither? Mirja: Independent, because the first provides much more feedback Bob: First draft gives more information, but currently nothing else needs that Michael W: I like the idea of including the nonce, which can be useful for many things, for example spurious timeout detection Matt: I would like to advocate that the WG takes on accurate ECN feedback as a work item, but independently of these drafts. The net needs accurate feedback, but it is premature to commit to a path. It would be good to take a unified approach, it would be good to progress both documents since we don't know if one or other approach has a showstopper. Wes George: Regarding the option, we would need to be clear about the benefit of having the bits. But it's a lot more effective if you have at least one use case in mind so you can be sure the option is at least effective for that case. Beyond binary congestion, is this a matter of trying to give applications the ability to do more accurate congestion management? Mirja: Both conex and dctcp can use this. The option gives accurate information, while the 3-bit signalling can have ambiguities Wes: I was seeking use cases for the accurate information Mirja: better for very lossy networks (broad support for more accurate ECN signalling as a WG item) Bob: How about working on problem statement document, pro/cons of both approaches? Wes: In future, we should move this up in the agenda, discuss for longer... No rush in adopting the documents, so we have a new milestone and continuing with these documents in their present status * Highly Efficient Selective Acknowledgement (SACK) for TCP draft-sabatini-tcp-sack Speaker: Anthony Sabatini Matt: I'm wondering if you studied a particularly old implementation of SACK, because nearly all of the bugs mentioned are now fixed. That's not to say that we can't do better. Anthony: If they were solved, where is documentation within the IETF of this? Matt: There are a lot of sender-side algorithms which are not documented, since there has been a steady evolution of optimisations. So a lot of the improvements are not required algorithms or described in documents. * Impact of IW10 on Interactive Real-Time Communication Speaker: Ilpo Jarvinen Kostas Pentikousis: There are metrics for quality of audio, but not used in this investigation. Also, measurement is only 2 sec. IW10 is worse than IW3 but what is the actual impact on audio quality? * HOST_ID TCP Options: Implementation and Preliminary Test Results draft-abdo-hostid-tcpopt-implementation Speaker: Jaqueline Queiroz Time: 10 minutes Tim: Implementation of this is more work than bringing up IPv6 on the servers. So I predict zero implementation deployment Lars: This cannot be done elsewhere because it is a TCP extension, but advocating against doing this anywhere, and save the SYN space. * Shared Memory Communications over RDMA draft-fox-tcpm-shared-memory-rdma Speaker: Jerry Stevens Lars: Converged Ethernet (controlled) - why use TCP at all, and not different transport protocol. Would like to see analysis of different protocol. Vivek ?: Application transparency - continue using standard sockets API, security model, without changing applications Lars: Different transport protocols can be made to use TCP sockets transparently, e.g. SCTP does so --- end of meeting