Re: [EToSat] New Version Notification for draft-kuhn-quic-4-sat-04.txt

[Lars Eggert <[e-mail]>]

Hi,

On 2020-4-24, at 2:26, Christian Huitema <[e-mail]> wrote:
> 1) The tests in the TCP Eval draft are largely focused on long term equilibrium. In my proposal, I am mostly looking at ramp up time from the start of the connection. Once the connection has found the initial sstresh (or equivalent), it will behave just like BBR. Is there specific guidance on the evaluation of the ramping up scenario?

what's interesting to look at is what happens if some connections using your scheme ramp up while others (yours or legacy ones) are (1) also ramping up in parallel, (2) are already in steady-state, or a mix of the two scenarios. Both in terms of what happens to the performance of those connections using your scheme, and also what happens to those that are not.

> 2) The battery of tests covers a large number of configurations. The proposal is very specifically aiming at long delay links, defined as min RTT larger than some threshold. Is there any advantage to also testing for the low delay configurations?

Can you know that you will run over a long-delay link ahead of time? If you want to limit yourself to only evaluating those scenarios (because you will use a different scheme for the other scenarios), you need to be able to tell reliably.

> 3) The draft states that the traces uses for calibrating TMIX are available at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG. I cannot find them at that location. Where should I look?

Don't know. Ask the authors?

> I also have a puzzling question regarding the purpose of the tests. The TCP Eval draft follows the classic approach that Internet stability depends on well behaved transports, and that this good behavior should be documented by a large battery of tests. I got some fairly consistent feedback last year, after worrying that free wheeling innovation in transport protocols might end up having bad consequences for the Internet. A number of distinguished colleagues lined up at the mic and explained that my fears were exaggerated, that the Internet was very robust, and that I should not worry. So, which is which? Should I worry about consequences for others, or is selfishness OK?

The *Internet* will very likely be fine these days, even if broken CC gets shipped to some fraction of the nodes. The reason being that the network topology these days (for consumer access networks) is usually such that the bottleneck link is the access hop.

You still want a working CC scheme, however, because you can DDoS your other flows sharing that same access link, i.e., from other machines/users in your own home. (BitTorrent wasn't a problem for the Internet per se, but it did kill parallel VoIP connections out of the same house pretty effectively, which is what motivated LEDBAT.)

Lars

> Of course, even assuming that selfishness is OK, I need to do additional tests to verify that the proposal still results in better performance in the presence of competing traffic, at various data rates, or in the presence of delay jitter. I already perform the tests for several data rates, and with presence or absence of packet losses -- as specified in the Etosat draft. My first priority is to add the delay jitter tests, as they have a critical impact on bandwidth measurement.
> 
> -- Christian Huitema
>