Subject: [EToSat] Transport in 0-RTT connections for high BDP

From: Kuhn Nicolas <[email-masked]>
Date: Thu, 7 Mar 2019 10:35:27 +0000

Hi,

We have uploaded a draft that describes a solution to improve QUIC's performance during 0-RTT establishment in a high BDP context.
https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00

Abstract

   0-RTT is designed to accelerate the throughput at the establishment
   of a connection.  There are cases where 0-RTT alone does not improve
   the time-to-service.

   This memo discusses a solution where a fundamental characteristic of
   the path is learned during the 1-RTT phase and shared with the 0-RTT
   phase to accelerate the initial throughput during subsequent 0-RTT
   connections.

Would it be possible to have a small slot to present it during the next IETF meeting?

Kind regards,

Nico & Emile

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 7 Mar 2019 08:32:00 -0500

On Thu, Mar 07, 2019 at 01:03:47PM +0100, Mikkel Fahnøe Jørgensen wrote:
> That said, I think the bandwidth, the connection RTT, the ticket timestamp,
> and perhaps the PMTU are all good things to have available to an 0-RTT
> session

For example, in GQUIC, the client can send an IRTT tag to specify the
initial value to set the RTT to.

> On the other hand, a client could be caching these data along with a
> session ticket based on knowledge gained from a previous connection, so
> perhaps it it is not really an issue other than explaining best practices?

I think the idea is to allow the server to start blasting away if it
learns from the ticket that the connection has a large BDP.

  - Dmitri.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Mar 2019 13:03:47 +0100

I find BDP_value as bits per second confusing because BDP means bandwidth
delay product so I would expect it to be multiplied by RTT.
The text could use some practical examples and implementation guidelines.

That said, I think the bandwidth, the connection RTT, the ticket timestamp,
and perhaps the PMTU are all good things to have available to an 0-RTT
session, and perhaps should be made mandatory either in the ticket or in
the stored transport parameters to the extend this is not already the case.
This avoids having an extension. An accompanying document could explain how
to handle high BDP connections based on the available values.

On 7 March 2019 at 11.36.49, Kuhn Nicolas ([email-masked]) wrote:

Hi,

We have uploaded a draft that describes a solution to improve QUIC’s
performance during 0-RTT establishment in a high BDP context.

Abstract

   the time-to-service.

   connections.

Would it be possible to have a small slot to present it during the next
IETF meeting?

Kind regards,

Nico & Emile

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Mar 2019 15:00:47 +0100

Yes of course

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Mar 2019 15:03:12 +0100

On 7 March 2019 at 15.00.47, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

Yes of course

In the context of recent replay attack discussion, this should be
interesting.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 8 Mar 2019 06:03:43 +0900

Thank you for writing the draft.

I think the approach is fine, though I wonder if we need to a
specification for this.

The server has the freedom to store whatever it wants in a session
ticket. Therefore, I do not see why we need to define an extension.

Also, it has been my understanding that token (sent by NEW_TOKEN
frame) is a better place for storing the RTT observed in last
connection. This is because token is a per-path information that is
updated per each path, compared to session tickets that are expected
to rarely be updated mid-connection.

2019年3月7日(木) 19:36 Kuhn Nicolas <[email-masked]>:
>
> Hi,
>
>
>
> We have uploaded a draft that describes a solution to improve QUIC’s performance during 0-RTT establishment in a high BDP context.
>

-- 
Kazuho Oku