Hi, Kuhn, Martin, What Martin wrote down is correct. Just two minor comments below.
2020年10月30日(金) 8:06 Martin Thomson <[email protected]>: > 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. > Yes. theoretically, it is true that we need a protocol for constraining the send rate during the connection establishment phase. Though in case of QUIC v1, I'd assume that endpoints can (and will) use the transport parameters (e.g., initial_max_data) for that purpose. So far, to me it seems that the only case where a protocol extension makes sense is the use case that Matt brought up: sending server's view of the connection for letting clients decide what to request. > 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 > > > > -- Kazuho Oku
