I think that Kazuho was saying something else. That is, there is no need for a protocol here*. If a server was able to send at X previously, it can "remember" that by packing some extra information into NEW_TOKEN (or the session ticket, but again I agree with Kazuho that NEW_TOKEN is more appropriate).
The usual caveats around the stability of network capacity over time apply, which is why there might be some value in a document explaining how not to do this. For instance, just because you managed 1Gbps last Tuesday at 1am, it doesn't mean that the same capacity will be available next Thursday at 8pm. But the idea that you might be able to do something better than starting at a default congestion window isn't crazy. * Where a protocol might add value is not in storing values, but constraining their use. If a client successfully hits 1Gbps and wants to send 0-RTT at nearly 1Gbps when it resumes, the server might want to be able to provide some constraints. On Fri, Oct 30, 2020, at 01:33, Kuhn Nicolas wrote: > > There were comments on the security aspects of the approach. > > > > Christian Huitema: > > 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? > > > > Kazuho Oku: > > Loss recovery and CC states are properties maintained by an endpoint. > The peer should not be given the right to change them (e.g., CWND, > RTT). > > Servers might offload the state to the client, but that state has to be > encrypted and integrity-protected. NEW_TOKEN tokens cover this purpose. > > > > [NK] Indeed. Depending on how the 0-RTT extension is set up, the client > may not be able to tune the values or the server may remember the > values for cross-checking the information. We can rely on the transport > parameter integrity protection already described in 7.4.1: > > *The server can remember these transport parameters, or store an* > > *integrity-protected copy of the values in the ticket and recover the* > > *information when accepting 0-RTT data.* > > > > > > Nicolas and Emile > > > > *De :* Ian Swett <[email protected]> > *Envoyé :* mardi 27 octobre 2020 14:39 > *À :* Kazuho Oku <[email protected]> > *Cc :* Christian Huitema <[email protected]>; Kuhn Nicolas > <[email protected]>; IETF QUIC WG <[email protected]>; Matt Joras > <[email protected]>; Lucas Pardue <[email protected]> > *Objet :* Re: New Version Notification for > draft-kuhn-quic-0rtt-bdp-07.txt > > > > I agree with most of the points made by Kazuho and Christian. > > > > In particular, I think relying on information the client repeats back > to the server which is not encrypted by the server is potentially quite > dangerous. Even with that, there's real potential for abuse, > particularly when combined with 0-RTT, so if we're going to document > something, I believe we need a lot of MUST NOTs to prevent that abuse. > Using the same token across many connections seems particularly > concerning. > > > > On Mon, Oct 26, 2020 at 10:30 PM Kazuho Oku <[email protected]> wrote: > > > > > > > > > 2020年10月27日(火) 11:14 Christian Huitema <[email protected]>: > > >> > > >> On 10/26/2020 6:20 PM, Lucas Pardue wrote: > > >>> > > >>> On Tue, 27 Oct 2020, 01:12 Matt Joras, <[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? > > > > > > I think that the answer is simple. > > > > > > Loss recovery and CC states are properties maintained by an endpoint. The > > peer should not be given the right to change them (e.g., CWND, RTT). > > Servers might offload the state to the client, but that state has to be > > encrypted and integrity-protected. NEW_TOKEN tokens cover this purpose. > > > > > > OTOH, servers can expose any information to the client regarding the > > quality of the connection. It is totally reasonable to give the client the > > bandwidth information that the server retains, so that the client could > > choose a good bandwidth. There are no security concerns providing such > > information, regardless of the medium being a QUIC frame or a HTTP header. > > And that's because it does not affect loss recovery or CC. > > > > > >> -- Christian Huitema > > > > > > > -- > > > Kazuho Oku >
