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

[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?

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.

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