Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt

[Kazuho Oku <[e-mail]>]

Hi Mikkel,

Thank you for your comments. My responses inline.

2019年4月4日(木) 15:15 Mikkel Fahnøe Jørgensen <[e-mail]>:
>
> Nice work.
>
> Just a minor thing on priority in the appendix: what about IPv6 priorities? That, and flow labels - are we starting to bypass much of the IPv6 design because it is not (yet?) sufficiently widely deployed? Or are there security implications, and if so, should QUIC consider authenticating parts of the IPv6 header?

I do not have an opinion on the design aspects of IPv6, but I can see
at least two use-cases where you would want to use the priority scheme
described in the I-D.

1. Prioritization between different browser tabs. A web browser can
raise the priority of a connection that is bound to the window tab
that's in the front. This is the type of signal should not be exposed
to on-path observers, though we have thought that it's beneficial
between endpoints (IIRC that was one of the use-cases when we designed
the HTTP/2 prioritization scheme).

2. End-to-end cross-connection prioritization on a connection using
VPN. Related thought: maybe we need a separate TP that allows a client
to opt-out from a server using IP precedence.

>
> Also, on name based alternative:
> I’m wondering which non-HTTP/3 connections would really benefit as new designs can build in multi-purpose into the protocol whereas HTTP/3 must follow HTTP semantics. You could argue about WebRTC/3 - but then - what should it co-locate with which has sufficient intelligence to share the congestion controller? You could argue share with HTTP/3, but that would probably not rule out a name based solution either.
> I’m not saying name based CG sharing is necessarily better, I’m just wondering.

I am not sure if I am following, but I'd argue that there are two ways
of using the token. One is to consolidate the congestion controller,
and the other is to reuse the most up-to-date path information (e.g.,
BDP, RTT). For the former, it's essential to use the IP address as the
scope, because that's what identifies a server instance within which a
state can be shared. For the latter, the scope does not matter, though
the probability of receiving a fresh taken rises as the scope gets
bigger. That's one of the reasons the scope proposed by the draft is
"union of server-name and server's address tuple" (the other reason is
to avoid sending two types of tokens).

>
> OTOH if name based sharing is used that could place some assumptions on a given load balancers tuple stickiness, if I understand correctly. That could be unfortunate. Or, if name sharing is only to target address validation of the client perhaps different server hosts could share that information successfully with a random or round robin load balancer?
>
> Mikkel
>
> On 4 April 2019 at 07.22.32, Kazuho Oku ([e-mail]) wrote:
>
> Hi,
>
> I have (finally) submitted "Address-bound Token for QUIC" I-D, that
> proposes a QUIC extension allowing tokens to be shared between
> connections that go to the same server address, even when the value of
> SNI is different. Having such tokens would maximize our chance of
> skipping address validation and slow-start phase.
>
> The I-D and the repo can be found at the links below:
>
> I-D: https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
> Github repo: https://github.com/kazuho/draft-kazuho-quic-address-bound-token
>
> Please let us know what you think.
>
> Rationale behind the proposal:
>
> The startup phase (a.k.a. slow-start) is one of the things that has
> negative impact on user experience. QUIC, in addition to reducing the
> connection establishment latency from TCP, provides the possibility of
> a server skipping the startup phase when a client provides a valid
> token.
>
> However, the probability of a server being able to skip the startup
> phase relies on how frequent a user revisits a particular server,
> identified by the value of the TLS SNI extension. To put another way,
> there is a missed opportunity if a client is visiting a server
> instance that it has previously visited with a different server name.
>
> Our proposal addresses exactly that. The proposed extension allows a
> client to use a token for a different server name, if the server
> address is the same. This maximizes the chance of the server skipping
> address validation and the startup phase.
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: 2019年4月4日(木) 14:17
> Subject: New Version Notification for
> draft-kazuho-quic-address-bound-token-00.txt
> To: Kazuho Oku <[e-mail]>
>
>
>
> A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name: draft-kazuho-quic-address-bound-token
> Revision: 00
> Title: Address-bound Token for QUIC
> Document date: 2019-04-04
> Group: Individual Submission
> Pages: 6
> URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-token-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
> Htmlized:
> https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-token
>
>
> Abstract:
> This document describes a QUIC extension for an address-bound token.
> This token can be used for sharing address validation and congestion
> controller state between the same two endpoints across multiple
> connections and origins.
>
>
>
>
> 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
>
>
>
> --
> Kazuho Oku
>


-- 
Kazuho Oku