On 10/26/2020 6:20 PM, Lucas Pardue wrote: > > > On Tue, 27 Oct 2020, 01:12 Matt Joras, <[email protected] > <mailto:[email protected]>> wrote: > > Indeed, but as much as I love HTTP it's not the only protocol we > have on top of QUIC. A consistency argument can also be made for > having a connection-level metric tied to a connection-level > semantic (i.e. a QUIC frame) rather than the transactional-level > semantic (HTTP header). > > > I agree! A QUIC-level frame could be the most appropriate thing in > this case. I think this will be an interesting space for innovation. > And let's not forget all the other datagram-oriented protocols that > have preceeded - so perhaps there will be some re-innovation.
I am glad that we agree. Now, we have an issue regarding security. Nicolas Kuhn and his coauthors have pursued a design in which the server sends an encrypted blob to the client, and then client echoes it in the new connection. This is largely based on concerns about potential attacks. Suppose the client said "I received at 1Gbps last time", when in fact it can only absorb 10 Mbps. Some bad stuff might well be happening along the way. But then, Matt is looking at passing statistics from server to client, so the client can debug issues, display statistics in the app, and potentially also reuse the statistics to inform server that the last connection had an RTT of 600 ms and a data-rate of 100 Mbps, and maybe we should shortcut initial congestion control in order to gain lots of time. How do we reconcile these multiple goals? -- Christian Huitema
