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

[Gorry Fairhurst <[e-mail]>]

I think we do need to be quite careful here!

Filling a pipe with a flow could be a goal for some cases, although I 
don't think it is typical, if we consider the higher capacity paths. 
Multiple flows per bottleneck are often more important, and then we have 
the usual CC questions about RTT distribution, randomness of flow start, 
etc.

For startup, it's also really important to think about the arrival of 
new flows into an already congested pipe. I like to start with two very 
specific questions:

* What happens in the first actual path RTT of time? - Anything sent 
before feedback from the remote endpoint can lead to congestion 
collapse, because the sender does not know the situation. So a stupid 
method that says "last time I sent at X Mbps" so this time I will do 
also, inevitably ends in collapse. Initial entry into the pipe has to be 
conservative. We seem to agree that 1 packet/RTT is a safe starting 
point. IW=10 revises this to, "if IW=10 worked last time, you can try 
again" - conversely if it did not, you should not.

* After one RTT, did *everything* that was sent make it through? i.e., 
was the path as expected? Then, and only then, a sender may have reason 
to be optimistic that you are not already observing congestion collapse. 
That means the sender can *then* probe for capacity and retreat from 
congestion. How you do that depends...

Without surprise, TCP does both of these, in it's syn exchange and CC.

I think QUIC currently is a poor citizen with respect to avoiding 
congestion collapse (It has an initial RTO of 100s of ms, while sending 
a large initial segment and aggresively using IW=10) - perhaps because 
it assumes well-provisioned broadband? Anyhow this isn't nice if you are 
stuck for capacity, and we need to think about that initial RTT of data, 
before we think about CC.

Gorry

On 23/04/2020 09:07, Lars Eggert wrote:
> 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