Subject: 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: 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 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?

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: 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:
> session

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

> 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 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: Roland Zink <[email-masked]>
Date: Thu, 7 Mar 2019 15:49:35 +0100

When the previous connection had a big BDP then this doesn't necessarily 
mean the new connection has a big BDP as well. What happens when this is 
not the case and only a small bandwidth is available?

Roland

Am 07.03.2019 um 13:03 schrieb Mikkel Fahnøe Jørgensen:
> 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.
> 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.
>
> session ticket based on knowledge gained from a previous connection, 
> so perhaps it it is not really an issue other than explaining best 
> practices?
>
> On 7 March 2019 at 11.36.49, Kuhn Nicolas ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>> Hi,
>>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 7 Mar 2019 19:53:06 +0000

True that the past sometimes does not predict the future, however, often the past does predict the future. Certainly in cases where the endpoints are the same 4-tuple this is often the case for similar times in the day.

Having experimented with something similar for SPDY in the past (the client cached the cwnd, which is a function of BDP), I can confidently say that this can help, however you can also do better—a rate is what you really want, not a BDP. You can represent that as an RTT and BDP, or by dividing them out explicitly, but BDP alone can result in bursts, and thus burst-loss.

I’d suggest that you might want to consider changing your extension to report RTT and BDP so as to be able to better tune the congestion controller/packet scheduler to avoid bursts while completely utilizing the path’s BDP.

-=R

From: QUIC <[email-masked]> on behalf of Roland Zink <[email-masked]>
Date: Thursday, March 7, 2019 at 6:50 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: Transport in 0-RTT connections for high BDP

When the previous connection had a big BDP then this doesn't necessarily mean the new connection has a big BDP as well. What happens when this is not the case and only a small bandwidth is available?

Roland

Am 07.03.2019 um 13:03 schrieb Mikkel Fahnøe Jørgensen:
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 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?

On 7 March 2019 at 11.36.49, Kuhn Nicolas ([email-masked]<mailto:[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.
https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkuhn-2Dquic-2D0rtt-2Dbdp-2D00&d=DwMDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=derZFDyl7N_8qFkmYAQEB-aUHfJdrmX9x3VHqSEp1U4&s=LrZIso7muiIHhBotgc3CJ87mRmn1DLqlLrNR9mPmgY0&e=>

Abstract

Kind regards,

Nico & Emile

---

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.

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 07 Mar 2019 16:25:31 -0500

As you say, this is a congestion control topic, not as much a QUIC-specific one.  And you are equally correct that this does not require standardization of any signaling to use it.

However, we have typically attempted to document congestion control strategies.  So in that spirit, it's a fine thing to do.

All that said, we explicitly decided to not address this particular question early in our process.  Saving information about congestion window from one connection so that it could be used to jump-start the next connection was a feature cut from HTTP/2 as well.

---

From: <[email-masked]>
Date: Fri, 8 Mar 2019 08:13:03 +0000

We use the BDP value in the extension field to keep it simple on the client side.  IMO (it deserves more discussion) , It could be just a one bit flag.
The server pushes more detailed info in the session ticket, as usual.

De : QUIC [mailto:[email-masked]] De la part de Roberto Peon
Envoyé : jeudi 7 mars 2019 20:53
À : Roland Zink; [email-masked]
Objet : Re: Transport in 0-RTT connections for high BDP

-=R

Roland

Abstract

Kind regards,

Nico & Emile

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 8 Mar 2019 10:43:50 -0500

On Thu, Mar 7, 2019 at 4:25 PM Martin Thomson <[email-masked]> wrote:

> As you say, this is a congestion control topic, not as much a
> QUIC-specific one.  And you are equally correct that this does not require
> standardization of any signaling to use it.
>
> However, we have typically attempted to document congestion control
> strategies.  So in that spirit, it's a fine thing to do.
>

Folks interested in this thread might find a recent iccrg comment from
Keith Winstein thought provoking: (in full
https://mailarchive.ietf.org/arch/msg/iccrg/LHRAWIjbFktaqLC5hFqgG37M9zk)

> "My honest view is that congestion control is not a natural subject for
the IETF process -- it doesn't really affect interoperability, practice
diverged from the RFCs relatively early in the Internet's history and
hasn't returned, we lack a real understanding and common language about
some of the fundamental concepts and hard parts, and  there is an economic
incentive for the traffic sources to cheat a bit (perhaps in increasing the
IW, or perhaps in rolling out BBR, or CUBIC, or more
connections-per-application) and not try *too* hard to discover and be
concerned about how that might be harming their competitors. If there is a
silver lining, maybe it's one of Mutually Assured Destruction -- in that
Google, Netflix, and other major traffic sources do have a substantial
economic inventive in the Internet's continued health."

my own view is somewhere in the middle - that this kind of approach needs a
pile of data and experience first and then is pretty valuable as a best
practice contribution after the fact. OTOH ietf/irtf provide good forums
for development of these ideas and collaboration, we just need to separate
these functions from standards track work at times.

>
> All that said, we explicitly decided to not address this particular
> question early in our process.  Saving information about congestion window
> from one connection so that it could be used to jump-start the next
> connection was a feature cut from HTTP/2 as well.
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 8 Mar 2019 17:27:16 +0000

Past performance is no guarantee of future results. There is no QoS or min bandwidth guarantee on the Internet and connections between same IP pair do not take the same paths due to ECMP and LAG. Unless you are on a constrained network with min bandwidth guarantees, each connection will have to probe for its fair share. Network conditions change drastically over even short intervals of time. There’s been lots of discussion on what information should be cached and reused for future connections in tcpm. Today’s TCP implementations cache and reuse the bare minimum information and certainly not the old window information. Please see https://www.ietf.org/id/draft-touch-tcpm-2140bis-06.txt.

+1 to what Patrick says, lots of experiments and data needed for this.

From: QUIC <[email-masked]> On Behalf Of Patrick McManus
Sent: Friday, March 8, 2019 7:44 AM
To: Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Transport in 0-RTT connections for high BDP

On Thu, Mar 7, 2019 at 4:25 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
As you say, this is a congestion control topic, not as much a QUIC-specific one.  And you are equally correct that this does not require standardization of any signaling to use it.

Folks interested in this thread might find a recent iccrg comment from Keith Winstein thought provoking: (in full https://mailarchive.ietf.org/arch/msg/iccrg/LHRAWIjbFktaqLC5hFqgG37M9zk<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ficcrg%2FLHRAWIjbFktaqLC5hFqgG37M9zk&data=02%7C01%7Cpravb%40microsoft.com%7C036f08944a7744f376a908d6a3dcf377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636876566715916713&sdata=Vjl34Km0Rfz2Kw%2BR78rA0jGFuKGTVhkuoeTaGELycG0%3D&reserved=0>)

> "My honest view is that congestion control is not a natural subject for the IETF process -- it doesn't really affect interoperability, practice diverged from the RFCs relatively early in the Internet's history and hasn't returned, we lack a real understanding and common language about some of the fundamental concepts and hard parts, and  there is an economic incentive for the traffic sources to cheat a bit (perhaps in increasing the IW, or perhaps in rolling out BBR, or CUBIC, or more connections-per-application) and not try *too* hard to discover and be concerned about how that might be harming their competitors. If there is a silver lining, maybe it's one of Mutually Assured Destruction -- in that Google, Netflix, and other major traffic sources do have a substantial economic inventive in the Internet's continued health."

my own view is somewhere in the middle - that this kind of approach needs a pile of data and experience first and then is pretty valuable as a best practice contribution after the fact. OTOH ietf/irtf provide good forums for development of these ideas and collaboration, we just need to separate these functions from standards track work at times.

On Fri, Mar 8, 2019, at 08:04, Kazuho Oku wrote:
> 2019年3月7日(木) 19:36 Kuhn Nicolas <[email-masked]<mailto:[email-masked]>>:
> >
> > Hi,
> >
> >
> >
> > https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-kuhn-quic-0rtt-bdp-00&data=02%7C01%7Cpravb%40microsoft.com%7C036f08944a7744f376a908d6a3dcf377%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636876566715926705&sdata=G8rCpp5EPSNBP4kcExyNjlP8PSsHi20k%2Baq5rIy1Uno%3D&reserved=0>
> >
> >
> >
> > Abstract
> >
> >
> >

---

From: Roberto Peon <[email-masked]>
Date: Fri, 8 Mar 2019 18:52:13 +0000

We’ve had this conversation in the past in the H2 context.
I had evidence that such caching is no worse in terms of erroneous behavior than not.
In any case, all you’re doing is picking the starting condition; you’re not talking about a new algorithm or any other fanciness.

Tongue in cheek: Historically, we’ve determined congestion control starting points by looking at historical data… Predicting the future based on incomplete past information is always erroneous, but there isn’t any other data by which you can do so…

While I’m happy to continue to discuss this topic here, I suspect that it might be better suited to some other forum as this doesn’t really affect the standard in any interesting way.

-=R

From: QUIC <[email-masked]> on behalf of Praveen Balasubramanian <pravb=[email-masked]>
Date: Friday, March 8, 2019 at 9:27 AM
To: Patrick McManus <[email-masked]>, Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: RE: Transport in 0-RTT connections for high BDP

Past performance is no guarantee of future results. There is no QoS or min bandwidth guarantee on the Internet and connections between same IP pair do not take the same paths due to ECMP and LAG. Unless you are on a constrained network with min bandwidth guarantees, each connection will have to probe for its fair share. Network conditions change drastically over even short intervals of time. There’s been lots of discussion on what information should be cached and reused for future connections in tcpm. Today’s TCP implementations cache and reuse the bare minimum information and certainly not the old window information. Please see https://www.ietf.org/id/draft-touch-tcpm-2140bis-06.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dtouch-2Dtcpm-2D2140bis-2D06.txt&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=BJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o&s=SN4b47ErXRSv9QrWtboyFZHC-mESbQQavgfRqTHJGPg&e=>.

Folks interested in this thread might find a recent iccrg comment from Keith Winstein thought provoking: (in full https://mailarchive.ietf.org/arch/msg/iccrg/LHRAWIjbFktaqLC5hFqgG37M9zk<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmailarchive.ietf.org-252Farch-252Fmsg-252Ficcrg-252FLHRAWIjbFktaqLC5hFqgG37M9zk-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C036f08944a7744f376a908d6a3dcf377-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636876566715916713-26sdata-3DVjl34Km0Rfz2Kw-252BR78rA0jGFuKGTVhkuoeTaGELycG0-253D-26reserved-3D0&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=BJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o&s=82FUmp5MVGgEPRq_mTfvqHMFAYOCzpVjFzyRxb2Qdg4&e=>)

On Fri, Mar 8, 2019, at 08:04, Kazuho Oku wrote:
> > https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dkuhn-2Dquic-2D0rtt-2Dbdp-2D00-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C036f08944a7744f376a908d6a3dcf377-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636876566715926705-26sdata-3DG8rCpp5EPSNBP4kcExyNjlP8PSsHi20k-252Baq5rIy1Uno-253D-26reserved-3D0&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=BJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o&s=4Tvh4ZaXXSpM6QjUZTiSrH9Y5marBvLM3SF4o2h7j_Y&e=>
> >
> >
> >
> > Abstract
> >
> >
> >

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 8 Mar 2019 21:33:30 +0000

For better or worse that de facto starting point today is 10 packets worth in TCP and the same value is in QUIC recovery draft. For TCP there are knobs to increase the value on servers. Agreed that this discussion is more suited to another forum.

From: Roberto Peon <[email-masked]>
Sent: Friday, March 8, 2019 10:52 AM
To: Praveen Balasubramanian <[email-masked]>; Patrick McManus <[email-masked]>; Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Transport in 0-RTT connections for high BDP

-=R

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Praveen Balasubramanian <pravb=[email-masked]<mailto:pravb=[email-masked]>>
Date: Friday, March 8, 2019 at 9:27 AM
To: Patrick McManus <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: Transport in 0-RTT connections for high BDP

Past performance is no guarantee of future results. There is no QoS or min bandwidth guarantee on the Internet and connections between same IP pair do not take the same paths due to ECMP and LAG. Unless you are on a constrained network with min bandwidth guarantees, each connection will have to probe for its fair share. Network conditions change drastically over even short intervals of time. There’s been lots of discussion on what information should be cached and reused for future connections in tcpm. Today’s TCP implementations cache and reuse the bare minimum information and certainly not the old window information. Please see https://www.ietf.org/id/draft-touch-tcpm-2140bis-06.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_id_draft-2Dtouch-2Dtcpm-2D2140bis-2D06.txt%26d%3DDwMGaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3DBJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o%26s%3DSN4b47ErXRSv9QrWtboyFZHC-mESbQQavgfRqTHJGPg%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Cc1423491496140004ea508d6a3f74585%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876679758247136&sdata=5IB%2BJEYQIQsSWB88RxxdMqV2LuytQqM2sUGuVpKOdgs%3D&reserved=0>.

From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Patrick McManus
Sent: Friday, March 8, 2019 7:44 AM
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Transport in 0-RTT connections for high BDP

Folks interested in this thread might find a recent iccrg comment from Keith Winstein thought provoking: (in full https://mailarchive.ietf.org/arch/msg/iccrg/LHRAWIjbFktaqLC5hFqgG37M9zk<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmailarchive.ietf.org-252Farch-252Fmsg-252Ficcrg-252FLHRAWIjbFktaqLC5hFqgG37M9zk-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C036f08944a7744f376a908d6a3dcf377-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636876566715916713-26sdata-3DVjl34Km0Rfz2Kw-252BR78rA0jGFuKGTVhkuoeTaGELycG0-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3DBJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o%26s%3D82FUmp5MVGgEPRq_mTfvqHMFAYOCzpVjFzyRxb2Qdg4%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Cc1423491496140004ea508d6a3f74585%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876679758247136&sdata=mHjpo%2Fy24j0br%2Bth4zNgPuURcDb%2Bb5PhVznNlqKF3rg%3D&reserved=0>)

On Fri, Mar 8, 2019, at 08:04, Kazuho Oku wrote:
> > https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dkuhn-2Dquic-2D0rtt-2Dbdp-2D00-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C036f08944a7744f376a908d6a3dcf377-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636876566715926705-26sdata-3DG8rCpp5EPSNBP4kcExyNjlP8PSsHi20k-252Baq5rIy1Uno-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3DBJq9FvRziFJ7rGx8uSR0ccn2Skr77EAiM4EwqVNKL2o%26s%3D4Tvh4ZaXXSpM6QjUZTiSrH9Y5marBvLM3SF4o2h7j_Y%26e%3D&data=02%7C01%7Cpravb%40microsoft.com%7Cc1423491496140004ea508d6a3f74585%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876679758257128&sdata=OubHgFuUQG3KBdUvvhB1QbTVXiwBKcLk83AgjRMbkjg%3D&reserved=0>
> >
> >
> >
> > Abstract
> >
> >
> >

---

From: Kuhn Nicolas <[email-masked]>
Date: Mon, 11 Mar 2019 15:54:44 +0000

While I agree that knobs can be used to increase the value on servers, having these knobs specifically for SATCOM use case is not realistic.
That being said, the proposal does not reside only in increasing the IW; knowing the path MTU or the fact that the BDP is high would open the door for client level improvements.
We have illustrated some more gains in an updated version of the draft : https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/

Cheers,

NK

De : QUIC <[email-masked]> De la part de Praveen Balasubramanian
Envoyé : vendredi 8 mars 2019 22:34
À : Roberto Peon <[email-masked]>; Patrick McManus <[email-masked]>; Martin Thomson <[email-masked]>
Cc : IETF QUIC WG <[email-masked]>
Objet : RE: Transport in 0-RTT connections for high BDP

From: Roberto Peon <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 8, 2019 10:52 AM
To: Praveen Balasubramanian <[email-masked]<mailto:[email-masked]>>; Patrick McManus <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Transport in 0-RTT connections for high BDP

-=R