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

[Lars Eggert <[e-mail]>]

I was asking, because it’s pretty simple to come up with a scheme that does ok for a given static and otherwise empty pipe.

The tricky part is how things behave if there is other traffic, which is why in CC research there is a bunch of standard scenarios that are evaluated (dumbbell, parking lot, etc.)

-- 
Sent from a mobile device; please excuse typos.

> On Apr 23, 2020, at 08:35, Christian Huitema <[e-mail]> wrote:
> 
> I don't. I could probably do a parallel flow test, but I don't have the TCP simulation ready. Basically, I have been starting with the test cases in the quic4sat draft.
> 
> In theory, parallel flows are easier, not harder, because each flow has a smaller BDP than if it were alone. But fairness is much harder to achieve with long delay links. In TCP fairness is a statistical property, measured over some time. But in our cases the whole transfer is over in a half dozen RTT, and that does not leave much time for the statistics to play out. If we do desire fairness, my suggestion would be appropriate AQM in front of the satellite link.
> 
> -- Christian Huitema 
> 
>> On Apr 22, 2020, at 10:09 PM, Lars Eggert <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> do you have measurements with multiple parallel flows and/or competing TCP traffic?
>> 
>> Thanks,
>> Lars
>> 
>> -- 
>> Sent from a mobile device; please excuse typos.
>> 
>>>> On Apr 23, 2020, at 06:05, Christian Huitema <[e-mail]> wrote:
>>> 
>>> Something related: I have been working for some time on how to
>>> accelerate the "startup" phase of a QUIC connection over satellite. The
>>> main changes in Picoquic are:
>>> 
>>> 1) If the measured RTT is large, scale up the initial Window. We
>>> discussed this in Singapore.
>>> 
>>> 2) Tweak the pacing algorithm so Picoquic can send data bursts
>>> (moderately sized)
>>> 
>>> 3) Implement a peak bandwidth measurement by looking at acknowledgements
>>> over time, and noticing peaks when data bursts are acknowledged
>>> 
>>> 4) During start-up, increase the congestion window if it is smaller than
>>> 1/2 peak-bandwidth times RTT.
>>> 
>>> With that, the test of sending 100MB on a 250/3 Mbps link completes in
>>> 5.2 second, of which 1.2 seconds are the connection set up RTT and one
>>> RTT to request and ack the file. That means the actual transfer lasts 4
>>> seconds, average rate of 200 Mbps, 80% of the capacity.
>>> 
>>> Details on how the experiment progressed at
>>> https://huitema.wordpress.com/2020/04/21/faster-slow-start-for-satellite-links/.
>>> 
>>> -- Christian Huitema
>>> 
>>>>> On 3/6/2020 7:53 AM, Kuhn Nicolas wrote:
>>>> Hi,
>>>> 
>>>> We have just pushed an updated version of the "QUIC 4 SAT" document. 
>>>> The main difference with the previous version is that we have proposed baseline values for the regression test for the performance of QUIC on SATCOM systems. 
>>>> 
>>>> We plan a side-meeting during IETF107 where we will present the rationale behind these numbers and recent experiments on QUIC over SATCOM systems.
>>>>  Monday 23rd 
>>>>  8:30 am 
>>>>  Room: Regency E
>>>> 
>>>> If you are interested by remote participation, please join the ETOSAT mailing list where we will share conf call details. 
>>>> In the meantime, do not hesitate if you have comments on this version of the document. 
>>>> 
>>>> Cheers, 
>>>> 
>>>> Nico - on the behalf of the authors 
>>>> 
>>>> -----Message d'origine-----
>>>> De : [e-mail] <[e-mail]> 
>>>> Envoyé : vendredi 6 mars 2020 16:43
>>>> À : Gorry Fairhurst <[e-mail]>; Kuhn Nicolas <[e-mail]>; John Border <[e-mail]>; Godred Fairhurst <[e-mail]>; Stephan Emile <[e-mail]>; Emile Stephan <[e-mail]>
>>>> Objet : New Version Notification for draft-kuhn-quic-4-sat-04.txt
>>>> 
>>>> 
>>>> A new version of I-D, draft-kuhn-quic-4-sat-04.txt has been successfully submitted by Nicolas Kuhn and posted to the IETF repository.
>>>> 
>>>> Name:        draft-kuhn-quic-4-sat
>>>> Revision:    04
>>>> Title:        QUIC for SATCOM
>>>> Document date:    2020-03-06
>>>> Group:        Individual Submission
>>>> Pages:        13
>>>> URL:            https://www.ietf.org/internet-drafts/draft-kuhn-quic-4-sat-04.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-kuhn-quic-4-sat/
>>>> Htmlized:       https://tools.ietf.org/html/draft-kuhn-quic-4-sat-04
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-kuhn-quic-4-sat
>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-kuhn-quic-4-sat-04
>>>> 
>>>> Abstract:
>>>> QUIC has been designed for use across Internet paths.  Initial
>>>> designs of QUIC have focussed on common deployment scenarios for web
>>>> traffic and have not focussed on the performance when using a path
>>>> with a large Bandwidth-Delay Product (BDP).  A path can combine
>>>> satellites network segment together with a wide variety of other
>>>> network technologies (Ethernet, cable modems, WiFi, cellular, radio
>>>> links, etc): this complicates the characteristics of the end-to-end
>>>> path.  One example of such a scenario occurs when a satellite
>>>> communication (SATCOM) system is used to provide all or a part of the
>>>> end-to-end path.  If this is not addressed, the end-to-end quality of
>>>> experience can be degraded.
>>>> 
>>>> This memo identifies the characteristics of a SATCOM link that impact
>>>> the operation of the QUIC transport protocol.  It proposes regression
>>>> tests to evaluate QUIC over SATCOM links.  It discusses how to ensure
>>>> acceptable protocol performance.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>>>> 
>>>> The IETF Secretariat
>>>> 
>>>> 
>>>> _______________________________________________
>>>> EToSat mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/etosat
>>> 
>>> _______________________________________________
>>> EToSat mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/etosat
>> 
>