TSVAREA @ IETF-102 (Montreal) Wednesday, July 18, 2018 15:20-16:50 - Wednesday Afternoon session II Room: Viger Michael Tuexen - Note-taker * Administrativa - TSV ADs - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing - TSV Overview and status Spencer (remotely) and Mirja walking through the slides... The ADs thanked the TSV Area Review Team members for their help. We do have a few working groups finishing their chartered items. If people have new work to propose, the next couple of IETF cycles would be a great time to let the ADs know ... Kent Watson has asked for help from TSV on a proposed statement about application-level keepalives. Please provide feedback on the TSV-AREA mailing list, in the thread with subject "statement regarding keepalives" - TSV AD expertise and reporting/feedback from current ADs Aaron Falk: How much time do you need to read e-mail? Mirja: Trying to keep the time for AD work including e-mail down to two days a week. Spencer: I filter my IESG mail into "documents I'm responsible for", "other telechat documents", and "everything else". That helps with prioritizing. Also, as Mirja has mentioned a couple of times, there are topics that the IESG thinks about, or worries about, but we don't need 15 people thinking and worrying on every topic. If you're the right person to do something, you do it, or if you're one of two or three people who care about something, you spend time on it, but otherwise, you don't need to be involved with everything that comes to the IESG. Mirja: at the beginning, it freaked me out a little bit, but it's doable. (Brian Trammell helpfully provided a pointer to Mirja's Pechakucha on becoming a TSV AD in Jabber: http://snaggletooth.akam.ai/IETF-097-Seoul-videos/) Spencer: If you have questions about anything involving the AD positions, please ask - we have unlimited interest in answering them! * How hard can it be? Adding Multipath TCP to the upstream kernel - Christoph Paasch Christoph going through his presentation, which is a modified version of a presentation given earlier in the Linux Network Developer's (NetDev) conference. This presentation included a description of the impact that protocol design decisions had on implementations - not all of which were recognized at the time. Using a TCP option seemed like the right thing to do, but had a major impact because the TCP Linux kernel implementation is so optimized - even adding elements to a structure can cause more cache misses and cause a performance impact. Aaron Falk: You said that protocol design directly impacts implementations. Shouldn't implementation constraints also influence the protocol design? Christoph: Yes, absolutely. Aaron: is the list of constraints you encountered written down anyplace? Christoph: not really. It's mostly mail on developer mailing lists. Writing it down would be a good thing to do. Aaron: You've identified a pretty big issue here - we're doing things like using Github to reduce the distance between protocol designers and implementers, but protocol designers are making decisions that make their protocols less deployable. Christoph: recognize that a lot of these constraints are specific to the Linux TCP implementation. Even in iOS, we kind of don't care about the same things. Brian Trammel: "TCP Options are best used for 'unreliable' signals". The farther away you are from the core specification, the less you can count on it working. There seems to be an architectural issue here. Christoph: How should this influence multipath in QUIC? Brian: this seems to be easier for QUIC with versioning. ????: How much of this is specific to SKBUF, and to Linux? How much is directly applicable to iOS, or to userspace implementations? Have you compared notes with implementors for other implementations? Eric: Yes, we have compared notes, but we definitely should write this down. It would be good to put the information out. Ian Sweet: In QUIC it seems simpler to evolve the stack, but we're ACKing packets, not byte sequence ranges, which makes multipath a lot simpler. ???: Linux has gone a long way down the road on optimizing unipath implementations. How much would it have cost if the Linux stack would have been designed to initially include multipath? Tim Shepard: There's also the question about whether the MP-TCP working group could have made different decisions. I recall a meeting where somebody (Michael Scharf) raised concerns. But using TCP options was very popular in the WG, and we went that way, and here we are. Could we do MP-TCPv2 that didn't use TCP Options? Yoshifumi: The performance is not only tied to using TCP options. If you could do it knowing what you know now, would you put the information in the payload, not as a TCP option? Christoph: In a clean-slate design, I would add the sequence number to the data stream and use options for the data ACKs. Mirja: Let's defer redesigning MPTCP to the MPTCP working group, because we're running short on time, but I'm glad there is a lot of interest on this topic. * QUIC Internet-Scale Deployment on Linux - Ian Swett Ian going through his presentation, which is a modified version of a presentation given earlier in the NetDev conference. ???: If you ACK every packet or every other packet you might run out of send opportunities (WiFi). ???: Do you delay the time when you create the packet, do you delay the time when you send the packet. Is that a difference. ???: Who does the timestamping? Ian: It is the release time, which is in the future. ???: Is the crypto the bottleneck or the kernel? Which offloading helps more? Ian: If the acceleration on a platform is working well, crypto is now pretty cheap. The expensive part is if you have to touch memory. * Wire Images, Path Signals, And the (Inter)network ahead - Brian Trammell, Ted Hardie - see also draft-trammell-wire-image and draft-hardie-path-signals Brian and Ted going through their slides. The IAB is looking for feedback on both of these drafts. Roni Even: You need to be sure you have no security and privacy issues with the signals. Ted: Done. A good example of this is the analysis that a QUIC design team did to determine whether the spin bit could leak geolocation information to an observer in the middle. After a lot of work, we learned that what you can determine from the spin bit is much less precise than what you can learn about geolocation from a variety of other sources - it's not an effective leak. But after you've done the analysis on your proposed bit, you can't be sure that this data won't be put together with other information in the future. This is why these bits must be optional. Dan: One bit per use case can be very challenging. Can we do a general framework? Brian: Considering the Spin was was relatively easy because there were no other bits that we had to consider interactions with. Dan: Need a better way, a common framework. Tim Shepard: Wasn't aware that the spin bit caused privacy concerns because you can discover the RTT. I'm now realizing that clients could lie about RTTs when they set the spin bit, if there were reasons to lie. Brian: Don't want to talk about this specific case... Ben Schwartz: How will clients make the decision to use wire frame features? Ted: Is the bit valuable for the client. Does the client care if the network observers can measure the RTT? For example state timers in NATs - in IPv4, you might want to expose the RTT to prevent rapid aging of NAT bindings, but in IPv6, you might say "there shouldn't be any NATs, so I won't expose this information". You can make decisions based on address families. Brian: For Diagnosis it might be important. Could be controlled via the UI when you're in debug mode - the user can enable it, if necessary, but usually leave it turned off. Lorenzo: Spin bit is opaque. Why not send every 12 packets a RTT of 12 bits. If you exposed more information, would that be more likely to give intermediate devices enough information to give you the policy outcomes you want to achieve? Brian: We haven't been able to come up with a framework for exposing more information. Ted: You need to consider what both ends are going to get out of any information they expose, as well as the network devices. There's a lot of information we collected during the spin bit analysis about specific application patterns, that's applicable here. Chris Steel: As an operator I would like to have a few bits that tell you specific things, rather than having to infer everything. * Open mic (We didn't actually have time for this - please talk to the ADs!)