Hi David, Thanks for writing this up. I think that it helped clarify things a little in my mind.
I had been separately thinking about the problem and did reach a conclusion. I just needed time to write a response. I think that there are two things you might want to separate here: what might we do to engender good protocol design hygiene, and what do we do about HTTP/2 and HTTP/3. Like Cory, I didn't find this persuasive regarding HTTP/2. It is even less persuasive for HTTP/3, where I have evidence that half-RTT data is being used successfully (this comes first hand: ngtcp2 hit a performance bug in my code). The idea of creating a 0.5-RTT -> 1-RTT marker somehow is an odd idea, and one we've talked about maybe using in a new version of TLS, but I hardly see justification for that here. A lot of your reluctance to use half-RTT seems to be based on the buggy IO pattern you identified. Coupling send and receive flow control in the way you describe is - at least in my view - a defect in stacks rather than something to engineer a protocol around. An endpoint that refuses to read until a write is complete invites deadlock in a great many situations in HTTP/2, and we even have specific text in RFC 7540, Section 5.2.2 (https://tools.ietf.org/html/rfc7540#section-5.2.2) that recommends against deferral of reads. I realize that some applications don't work that way, but that doesn't mean that their TLS and HTTP/2 stacks need to be allowed to have the same bug. Full disclosure, I think that NSS could have this bug under some usage patterns. We don't buffer incoming data when we don't need it for the handshake. But I'm not sure that we need perfect here. This might come down to "well don't do that then", rather than the IETF embarking on a protocol engineering drill to fix these implementation issues. What is somewhat odd about TLS 1.3 is the way that applications can write to the socket before the handshake is complete. But reads are only possible afterwards. That does create some problems for incoming data, but it is always a modest amount to buffer. A new version of TLS might even allow clients to limit 0.5-RTT data, if this turns into a real problem. In any case, I can see some advantages to something like ALPS for WebTransport. The operational problems aren't any better, and I might not agree with you about the severity of the other things, but the protocol design hygiene aspects are pretty nice. Thinking about QuicTransport, the ability to signal the requesting URL and origin to the server outside of the use of streams and other application data makes the whole protocol much easier to structure. You no longer have to reserve streams or set aside control codepoints. That said, if you need control codepoints or stream reservation for other reasons, the value is diminished somewhat. After all, this is not magically reliable. When you add stuff to the handshake you make the handshake bigger and more fragile. If you really need this stuff, waiting on stream data to be retransmitted is no better or worse than waiting on the handshake. Indeed, binding to the handshake could be less performant in those cases where you are able to do some work ahead of receiving configuration. You can't even buffer incoming data when the handshake is incomplete, but you could if you were waiting on receiving configuration that was sent on a stream. On Fri, Dec 4, 2020, at 08:55, David Benjamin wrote: > Hi TLS and HTTP friends, > > At the last HTTPWG interim, there was a question of why one would want > something like ALPS (draft-vvv-tls-alps) for HTTP SETTINGS > (draft-vvv-httpbis-alps) over TLS 1.3 half-RTT data. I know we've also > had some discussion on this topic in the TLSWG as well. At the HTTP > meeting, folks suggested writing up what a half-RTT-based mechanism > might look like, so I put together an I-D below. I hope it helps > clarify some of our thinking. > > (The I-D is not meant for adoption or publication or anything. I > figured an I-D was probably the most familiar format for folks.) > > David > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Thu, Dec 3, 2020 at 4:22 PM > Subject: New Version Notification for draft-davidben-tls-alps-half-rtt-00.txt > To: David Benjamin <david...@google.com> > > > > A new version of I-D, draft-davidben-tls-alps-half-rtt-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-alps-half-rtt > Revision: 00 > Title: Comparing ALPS and Half-RTT Data > Document date: 2020-12-03 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-alps-half-rtt/ > Html: > https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html > Htmlized: > https://tools.ietf.org/html/draft-davidben-tls-alps-half-rtt-00 > > > Abstract: > This document compares the Application Layer Protocols Settings > extension with the half-RTT feature in TLS 1.3. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
