Re: [tcpPrague] TCP Prague progress and ideas

["De Schepper, Koen (Nokia - BE)" <[e-mail]>]

Hi Ingemar,

I think the marking pattern during slow start depends on quite some factors. First DualQ has currently 2 modes of marking for L4S flows:
- if there are L4S only flows, hitting a queue size step-on/off marker
- L4S competing with Classic, where a smooth probability is applied by the classic AQM (for example PI2).

I see 2 options to continue here:

a.       Accepting the 2 modes network behavior, and make TCP-Prague support both

b.      Making the network behavior equal in both modes

Some ideas in case a:

-          A mix of marks and non-marks identifies Classic mode, trains of marks the L4S mode.

-          In Classic mode, we expect (currently) 2 marks per rtt on average, we could go to a slower increase after one mark per RTT, go back to faster increase if we get an RTTs no mark, stop slow start when 2 or 3 marks per RTT are received.

-          We could limit going back to faster increase only if we didn't exit slow start, or use the exponential increase after X non-marked RTTs all the time?

-          In L4S mode, a train indicates that threshold is hit, but maybe not the link capacity. Pacing and inspecting the timing of ACKs could help to estimate the available capacity.

Ideas on case b:

-          The step function could be replaced with a virtual queue and maybe doing excess marking. Excess marking will at least give a non-on/off signal before the link speed is reached indicating the amount of excess traffic in the queue (optionally followed by a train when the real queue gets hit as well). There are also other possibilities.

-          Keeping TCP-Prague RTT dependent only for the acceleration, but RTT INdependent for the final target convergence throughput (only depend on P measured over your RTT) could also help to find better mechanisms (as marking probability is not depending on the RTTs of other flows (at least not in the long run)).

I also think that we have to define another behavior for the congestion avoidance. We need to get fast up to speed if BW gets available, this can't be done with linear increase (1/W increases per non marked ack). Also making its rate RTT independent will have its impact on increase/decrease mechanism. This might also reduce the dependence on a good slow start estimate?

Koen.




From: tcpPrague [mailto:[e-mail]] On Behalf Of Ingemar Johansson S
Sent: maandag 19 september 2016 11:14
To: '[e-mail]'
Cc: marcelo bagnulo braun; Praveen Balasubramanian; Ingemar Johansson S; Bob Briscoe ([e-mail]); De Schepper, Koen (Nokia - BE)
Subject: [tcpPrague] TCP Prague progress and ideas

Hi

I have started to simulate DualQ/L4S and DCTCP and try to get an understanding of the flaws with DCTCP.
One (obvious) issue I see is that slowstart can exit too quickly. I tried with a dirty hack to just ignore the 1st few ECE and that solved the issue in one experiment setup but more brain exercise is needed here I guess.
Do you have any initial ideas and thoughts on how to improve an evolved DCTCP --> TCP Prague.

/Ingemar
==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com

The secret of getting ahead is getting started
                   Mark Twain
==================================