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

[Christian Huitema <[e-mail]>]

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 
>