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

[Kuhn Nicolas <[e-mail]>]

Hi, 

Following your comments, we have updated the draft with (amongst various changes) a more accurate description of the last_bdp and a security discussion. 
https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/ 
Do not hesitate to share your views with us. 

Merry Christmas, 

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
>