Re: New Version Notification for draft-kuhn-quic-0rtt-bdp-07.txt

[Kazuho Oku <[e-mail]>]

2020年10月27日(火) 8:24 Christian Huitema <[e-mail]>:

>
> On 10/26/2020 2:36 PM, Kazuho Oku wrote:
> > Hello,
> >
> > Thank you for the draft. I just had the opportunity to read it, and
> > therefore am leaving comments.
> >
> > First of all, I think it is a good idea to write down how endpoints
> > can reuse information from previous connections when reconnecting.
> > Many people have been talking about the idea, it seems that there are
> > pitfalls, and having a compilation of good practices could help.
> >
> > At the same time, I was puzzled with the following two aspects of the
> > draft:
> >
> > 1. The draft requires the characteristics of paths be communicated via
> > session tickets. IIUC, QUIC resumes the properties of the *endpoint*
> > using TLS session tickets, while the properties of a path (e.g.,
> > peer's IP address) is to be remembered by a NEW_TOKEN token. The
> > draft's use of session ticket goes against that principle.
>
> I also think that forcing the information in the session ticket is a bad
> idea. As Kazuho says, the session ticket is used to resume sessions, not
> necessarily from the same network location at which the session ticket
> was acquired. Using a "token" is better from that point of view. It also
> has the advantage that tokens are fully managed within the QUIC layer,
> without any dependency on the TLS stack, which makes the implementation
> significantly simpler. However, there is still an issue because New
> Tokens are normally sent just once at the beginning of the connection,
> and are used to manage the "stateless retry" process. If the server
> sends several New Tokens, the client is expected to remember all of
> them, and use them only once.
>
> It might be simpler to create a new frame, very similar to the "New
> Token" frame, maybe calling it "BDP_TOKEN", and a "bdp_token" transport
> parameter. The frame carries a binary blob that encode server defined
> data. The server sends the client whatever blob it wants. It may send it
> several time, in which case the client only remembers the last one. The
> client puts the blob in the bdp_token TP, or if no token is available
> sends an empty blob to signal its support for the process. The server
> may reply with an empty token if it does support the process.
>

I tend to agree with the high order design, and it is my understanding that
use of NEW_TOKEN tokens is fine for the purpose.

The transport draft has a paragraph stating that a server might send new
NEW_TOKEN tokens as the state of the connection changes, and that it makes
sense for the client to use the most recently received NEW_TOKEN token.
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.3-9


> >
> > 2. The draft suggests that the server's properties (e.g., server's
> > BDP) be shared with the client. Is there any reason why they have to
> > be shared? I tend to think that each endpoint unilaterally remembering
> > what they prefer provides the most agility without the need to
> > standardize something.
>
> I think that "the endpoint remembers" should be the starting point. For
> one thing, we should also care of the scenario in which the client
> pushes data to the server, in which case the client needs to remember
> the BDP and RTT of the previous connection to the server. The server
> could do the same thing, just keep an LRU list of recent client
> connection addresses and the associated BDP and RTT.
>
> The whole business of sending blobs is just an optimization on top of
> the "endpoint remembers" strategy. We may be concerned that servers have
> to remember data for too many clients, that local server storage would
> not scale, or maybe that the same client hits a different server in the
> farm each time its reconnect. Hence the idea of storing these parameters
> in a blob, sending the blob to the client during the previous
> connection, and have the client provide the blob back during the new
> connection. Also, we seem concerned that the server does not trust the
> client, because otherwise the client could just add a couple of TP such
> as "previous RTT" and "previous Bandwidth", based on what the client
> observed before. Managing blobs has some complexity, so the tradeoffs
> should be explored.
>
> -- Christian Huitema
>
>
>
>
>

-- 
Kazuho Oku