TSVAREA Minutes - IETF 103
MONDAY, November 5, 2018 - 11:20-12:20
Room: Chitlada 2
Co-conspirators: Spencer Dawkins and Mirja Kühlewind
Notes thoughtfully provided by Magnus Westerlund
Meetecho recording is at https://play.conf.meetecho.com/Playout/?session=IETF103-TSVAREA-20181105-1120
Administrivia
The ADs opened up the meeting with Note Well, TSVART recognition, and status for active working groups
We noted that TSVAREA is returning to forward-looking discussions about the evolution of transport - all of the talks at this session came out of discussions of "HiNT" and "HELIUM" in the ART DISPATCH and HTTPbis sessions at IETF 102.
HTTP-initiated Network Tunnelling (HiNT)
https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/
Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)
https://datatracker.ietf.org/doc/draft-schwartz-httpbis-helium/
We expressed our appreciation to the review team, including the newest member, Gorry Fairhurst, and invited people who would like to help review documents from a transport perspective to contact the TSV ADs.
We noted that Spencer is STILL the outgoing TSV AD, stepping down in March 2019, and encouraged people to provide feedback to Nomcom, who will select his replacement.
Feature Requests for Advanced UDP Proxying - Katharine Daly (Google)
Katherine proposed five features for "inconspicuous HTTP proxying":
Katherine explained why TCP proxying meets these criteria, and why existing UDP-based mechanisms (TURN, SOCKS6, and various forms of VPNs) would not - the best strategy is to "blend in" with QUIC UDP traffic.
Christian Huitema - your requirements are very similar to a TLS WG draft that's currently in WGLC on requirements for SNI encryption, so that is something to look at as there are related issues.
David Schinazi (Google) - This type of proxying would be really useful. If we can make this work in QUIC, it would be amazing.
Eric Kinear (Apple): This is really interesting. I can think of several use cases that would need more UDP proxying, as the amount of useful UDP traffic grows due to QUIC and other efforts. I don't want to get too far ahead to solutions, now, but this is good. When you're talking about the HTTP CONNECT with TLS to the proxy and maybe even TLS through the proxy, lots of HTTP connections are fairly short-lived, but the setup costs for these connections are high. If you're proxying, the setup costs are amortized over more traffic, but someone doing traffic analysis won't think your proxied traffic looks very much like web browsing traffic. That's going to be an interesting tradeoff.
Katherine - that's definitely something to consider - length of connections, length of packets, timing between packets ...
QUIC addendums - Lucas Purdue (Cloudflare)
https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-quic-addendums-lucas-pardue-00
Lucas focused on the QUIC-ish aspects of HiNT for HTTP/2 over QUIC tunneling, which we can't do right now. The use cases and security associations are discussed in many slides from IETF 102. Lucas noted that we may be talking about significantly nested protocols ("QUIC over QUIC over QUIC").
HTTP/QUIC uses CONNECT to set up an ongoing TCP connection - Lucas is looking at what it will take to do onward QUIC connections to provide QUIC end-to-end. He started with RFC 8441, "Bootstrapping WebSockets with HTTP/2" at IETF 102, but learned a lot there, and since then (see slide 4 of his presentation).
QUIC is talking about MESSAGE and DATAGRAM frame types now.
TOR would like to use QUIC end-to-end, not just hop-by-hop.
Jorg Ott and Colin Perkins are looking at the needs of real-time media.
We've been talking about multiplexing protocols at the UDP level, but differentiating them in QUIC might be useful, avoiding some problems.
And there's discussion with WebRTC, and with TAPS, and ... there's more.
Lucas wants to understand the problem before moving into solution space.
Can we keep distilling down the features of multiplexed flows until we have a usable feature set?
Mirja requested people to read the drafts and provide transport feedback on HINT and Helium to the authors
Proxying Encrypted Traffic - Thomas Fossati (Nokia)
https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvarea-proxying-encrypted-transports-thomas-fossati-00
Thomas talked about the impact of encryption on "Performance-Enhancing Proxies" (described in https://tools.ietf.org/html/rfc3135 and https://tools.ietf.org/html/rfc3449), and why these devices are used, especially in mobile networks (satellite networks do similar things), and what problems these devices cause while they're trying to fix other problems.
Encrypting transport avoids the problems PEPs cause, but doesn't help with the original problems that PEPs were solving in the first place. Mobile networks still have the same problems that they did before deploying PEPs.
Are PEPs still needed? What does a modern PEP look like? Should new transports take PEPs into consideration at design time?
HiNT and HELIUM might be helpful here - are they? If not, what would be helpful?
Need to keep in mind that inner and outer congestion controllers interact with diverse links and user mobility.
HiNT/HELIUM provide an in-band control channel. How can it be used?
Stuart Chessire (Apple) (in response to a comment during Thomas's presentation) A common misrepresentation is that transport protocols don't retransmit at the average RTT, they retransmit taking the standard deviation into account, so a highly variable link will just push the retransmissions later. Also, when IPv6 started rolling out in volume, all the measurements showed better performance than IPv4. It's hard to know why, but one of the speculations was because none of the PEPs supported IPv6 ...
Spencer Dawkins as former WG chair for PILC, which produced the PEP RFCs - we did the work on the PEP RFCs 20 years ago. I can have opinions about PEPs, but what I want to say here, is that we can talk about whether something is the right thing to do every 20 years or so, whether we need to, or not ...
Benjamin Schwartz (Google) I want to agree, and disagree, with something Thomas just said. Agrees that we need to have any proxies be explicitly addressed in a QUIC world, but the security associations don' t need to be terminated. We need to distinguish between end-to-end security associations and "something else" - should explore designs that can do PEP without terminating end-to-end security associations. Thomas agreed that some security context needs to be terminated in the proxy - but not the end-to-end security association. Benjamin also pointed out that client devices aren't monolithic - there may be applications that aren't aware of these proxies, running on a device that is aware.
Open Discussion
Martin Duke (F5) - I agree that these problematic environments exist, but there are other solutions, for example better congestion controls that are adaptive across all domains. QUIC started with a "no middleboxes" approach, but we've already bent the rules - we admit that some people need stateless load-balancers, for example, and we're talking about anti-DDoS devices. We need to hold onto the notion of explicitness, rather than having these devices be transparent, as they are in TCP-land. This won't happen in QUICv1, but we're talking about separating transport keys from data payload keys allowing for debugging, and that might also allow PEPs that are explicitly addressed but not terminating security associations.
Gorry Fairhurst (one of the authors of RFC 3449) - PILC said, 20 years ago, that explicit was better because you know someone is fiddling with your traffic. Gorry has tested QUIC over satellite links. QUIC performance was slower (factor 3x) for 90 percent of the traffic they measured. QUIC could be designed better. We can fix the problem here like Thomas suggests, but if we don't, 95 percent of satellite traffic will run slower, and that will make QUIC undesirable. I'd love to see us fix the problem at the IETF.
Spencer (apparently as AD) - I'd just like to echo what Gorry said. John Border, one of the authors of RFC 3135, told me in London that he's seeing an order of magnitude slower throughput for QUIC traffic than TCP traffic, and the way satellite network operators are solving their performance problem is by blocking QUIC. That's one algorithm, but maybe we can do better?
Gorry - Following up on what Spencer said, John is using quite a bit higher-speed satellite links - 100 Mbit, which is where we should be going, and the problem gets worse as speeds on links goes higher
Colin Perkins - following up on that discussion, we need to be careful to compare immature QUIC stacks with TCP stacks that have had 20-30 years of tuning - they aren't mature implementations. QUIC performance will improve over time. Following up on the explicitness issue, the PERC WG had done a multi-level security scheme to allow middleboxes to do "semi-trusted" processing. They're addressing a different problem, but in a way that seems applicable to proposals that would allow middleboxes to see some headers but not content.
Lorenzo Colitti (Google) - I've written one of these, for my use at home, because I watch video over a path with 300-msec delays, and the freezes are longer than the RTT. Of course, my PEP only works with TCP. But backing up to Thomas's "Mobile Example" slide, I submit that this isn't a transport problem. This is an IP layer problem. We're trying to tell a sender that no matter what kind of packets you send to this destination, they're going to be delayed. This is a queuing problem. Maybe it needs a signal to tell the sender this is the issue. Maybe we should revisit the deprecation of ICMP signals, if the alternative was middlebox errors and ossification, and if the facts have changed, we could change our minds.
Spencer - this is definitely a conversation that we need to have, and we need to NOT have it while we're trying to standardize a specific transport protocol. That's why we brought these talks to TSVAREA, so we wouldn't distract people who are trying to finish QUIC in (mumble) months. Thank you for the observation, and please talk to me in the hall, because I have more to say.
Mikael Abrahamsson - Commonly deployed middleboxes clamp MSS on TCP connections. It's like Lorenzo said. Sometimes it's good if the network can tell you something. There are some signals from the network that you really DO want, so when you design transport protocol headers, you should think about how intermediate devices can provide the information that you want them to provide. There was a tunneling protocol designed a few years back that was very explicit about "these are the header fields that intermediate devices can understand, and other header fields is encrypted". I think that's a good model.
Chi-Jiun Su (Hughes) - I work for a satellite operator. We don't want to have middleboxes or PEPs because they cost money and resources, but with encrypted header fields, performance degrades significantly. We're seeing 200 Mbit/sec for TCP and 20 Mbit/sec for QUIC - it's an order of magnitude slower. We don't want PEPs. QUIC should be better designed to handle all kind of links, even satellite links. Satellite delays, even at the physical layer, are 600 msec. You can fix some problems with congestion windows, but even 2000 packet windows are not enough. The best solution for us is if QUIC works with satellite links.
Aaron Falk (Akamai) - Lorenzo's comments made me think. One thing that changed since we did TCPSAT twenty years ago, is that queuing in the network is getting less as bufferbloat is addressed. Also PANRG is a good place to revisit this topic, and move forward from SPUD and similar conversations about signaling from the network to the end systems, and this is a good time to revisit this topic. I do ask that the ADs pick one place to have this conversation, so that we don't have it in every working group this week (or forever).
Spencer - start on the TSVAREA list, and we'll take it from there.
Natali Elkins - come to the IPPM working group, because PDM and MPDM work is directly applicable to this topic.
Lars Eggert (NetApp) I want to echo what Stuart said earlier. No one is debating that PEPs can help, but someone installs them, and then they rot and no one knows if they help or reduce performance. If we can solve that, people would be very happy to talk about what QUIC and PEP could do in the future, but you can't know, really. Everyone wants to believe that networks are carefully managed and orchestrated, but they're not, not all of them, anyway.
Thomas - explicit addressing of PEPs allows one to choose whether to use them or not.
Lars - I can choose to use them, but I don't know whether they are helping or not.
(mysterious voice) - that's when you measure!