Re: [iccrg] draft-kuhn-quic-0rtt-bdp-08

[Kuhn Nicolas <[e-mail]>]

Hello 

Thank you very much for your useful feedback. 
I have included most of them as issues in the current repo hosting the draft: https://github.com/NicoKos/QUIC_HIGH_BDP/issues 

In the meantime, there are some comments below. 

Thanks,

Nicolas


-----Message d'origine-----
De : iccrg <[e-mail]> De la part de Bless, Roland (TM)
Envoyé : mardi 9 mars 2021 22:22
À : [e-mail]
Objet : [iccrg] draft-kuhn-quic-0rtt-bdp-08

Hi,

just a brief followup after today's presentation by Gorry.
https://datatracker.ietf.org/meeting/110/materials/slides-110-iccrg-transport-parameters-for-quic-0-rtt-connections-00
Basically, I find the idea quite nice, but there should be probably some more safeguards.

First of all, there should be a definition of "BDP"
at least when using the abbreviation the first time.
In 5.1:
"The recon_bytes_in_flight parameter is higher than the number of bytes in the actual BDP since it may include bytes in buffers along the path."
[NK] You are definitively right - we should be clear about what BDP is. There is a difference between the experienced BDP and the basic product of bandwidth and delay. We will make it clear in the update of the draft. 

So what do you consider as being "_the_ _actual_ BDP"?
[NK] we meant basic product of bandwidth and delay - but we should clarify and discuss the impact of queuing 

Please note that one typically measures only the _current share_ of the bottleneck link capacity and this share varies with the number of flows present at the bottleneck.
In case more flows are sharing the
bottleneck link at the next 0-RTT resume, the previously measured "BDP" may be too high and thus unsafe, thereby preempting other flows and creating queues or even packet loss.
This is a special but common case of "capacity *could* have changed"
mentioned on slide 5, meaning that the available capacity or share for the flow may have changed (due to an increased number of flows).

[NK] That is a very relevant point. We will mention in the document that the network could change could be due to increased number of flows. This is why a 'safety' check, so as proposed in the appendix of the previous version of this draft should be applied. Pacing is indeed recommended - we should make it clearer. 

So I guess you refer to "the actual BDP" as being a CWnd so that all inflight packets of that flow are "on the wire" and none are queued in any buffer.
But as mentioned above, the number of packets on the wire varies with the overall number of flows present at the bottleneck and any excess packets will be queued. Therefore, I consider the hyjump variants plus pacing as being safer. 
[NK] Indeed - I agree with you on pacing we pointed to references proposing such approach in the document. 

Nevertheless, an increase in the RTT while increasing the amount of inflight data could also be a sign of self-inflicted congestion. This could also be considered during resumption.

One more question: how many (other) flows are present at the bottleneck shown in slides 4, 10, and 11?
[NK] I will let Gorry or Tom answer to this one. 

It would be interesting to test this in various different settings.

Typos:

Sec 2.1:
applications may provide additionnal services applications may provide additional services

Sec.4:
Refuse: A client could choose not to use there parameters
Refuse: A client could choose not to use these parameters

Sec. 5.1:
That being said, the recon_bytes_in_fight That being said, the recon_bytes_in_flight

[NK] Thanks for the typos - issue created on the GITHUB repo. 

Regards,
  Roland

_______________________________________________
iccrg mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/iccrg