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

["Bless, Roland (TM)" <[e-mail]>]

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."

So what do you consider as being "_the_ _actual_ BDP"?
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).

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

Regards,
  Roland