Re: [EToSat] BDP parameters draft (was: Re-chartering for extension work)

[Kuhn Nicolas <[e-mail]>]

Thank you for this feedback.
We are working on an updated version of the document. 
At least, we start a security discussion section. We also adapt the last_bdp parameter as you suggested.  
The parameters would likely to be (at least) ;
   o  last_bdp (0x000X): The BDP measured on the previous connection by
      the server.  It is an integer in unit of bytes.  Using the
      congestion_window defined in [I-D.ietf-quic-recovery], last_bdp
      can be set to congestion_window.
   o  last_rtt (0x000X): The minimum RTT measured on the previous
      connection by the server.  It is an integer in unit of
      milliseconds.  Using the min_rtt defined in
      [I-D.ietf-quic-recovery], last_rtt can be set to min_rtt.
   o  initial_max_pkt_number (0x000X): The maximum amount of packets
      that the server is allowed to send when reconnecting.  It is an
      integer in unit of packets.

Cheers, 

Nico

-----Message d'origine-----
De : Christian Huitema <[e-mail]> 
Envoyé : mercredi 18 décembre 2019 03:03
À : Kuhn Nicolas <[e-mail]>
Cc : 'Gorry (erg)' <[e-mail]>; '[e-mail]' <[e-mail]>; [e-mail]
Objet : Re: BDP parameters draft (was: [EToSat] Re-chartering for extension work)

I am looking at this draft before trying to implement it. I think I understand the spirit of the draft, but I have a couple of questions regarding how this is supposed to work.

There is probably a typo in the formulation of the BDP as "last_bdp can be set to min_rtt*congestion_window". This would give a value in bytes*seconds, when we expect bytes. Using "min_rtt*received_rate" would work, since clients can certainly measure the rate at which the server was sending data. In fact, sending both the BDP and the RTT would make sense.

By default, the number of RTT required to reach a full bandwidth BDP is log2(BDP/IWbytes). In my tests of the "250Mbps/3Mbps" scenario, the required BDP is reached in 3.6 seconds after starting with IW10.
Starting with IW160 would shave 2.4 seconds on that total, etc. We would of course need RTT evaluation and pacing, but for high BDP scenarios we need that anyhow. Learning the BDP in advance would help there.

All that sounds good, but I don't know how the client can safely estimate IW. The draft says "use the previous sender value", but I don't understand how the client learns that. I think that the client knows the previous BDP, and it also knows how long ago the measurement was made.
If the time is short, there are good chances that the new conditions are similar to the previous ones, but if the time is long there is a high risk that they are different. Let's assume that the client sends a BDP parameter with a large value. Should the server trust it? Should it initialize CWIN to a fraction of that, and chose a smaller fraction if the measurement was old? How does the server know how old the measurement was?

There is also a security aspect there. The server that blindly trusts the BDP option will blast a large number of packets. What if the client is trying to sabotage the local network? Why should the server trust the client? The security section does not cover that...

-- Christian Huitema

On 12/17/2019 7:27 AM, Kuhn Nicolas wrote:
> Hi Mark, Lars,
>
> Many meetings discussed the impacts of QUIC encryption on satellite Performance-enhancing proxy (PEP) and the benefit of exchanging additional transport parameters.
> draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension during « Quick QUIC Update » presentation.
>
> We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.
> We propose to include it in the re-chartering discussion.
>
> Regards,
> Nicolas, Emile and Gorry
>
> https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvarea-
> quick-quic-update-mark-nottingham-00.pdf
> https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05
>