Re: [tcpPrague] TCP Prague progress and ideas

"De Schepper, Koen (Nokia - BE)" <> Tue, 20 September 2016 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CBA612B83F for <>; Tue, 20 Sep 2016 08:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.42
X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f2Vfxfv5Is-a for <>; Tue, 20 Sep 2016 08:30:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A88B312B9B6 for <>; Tue, 20 Sep 2016 08:14:07 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 7F695F602D331; Tue, 20 Sep 2016 15:14:02 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u8KFE4dl003351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Sep 2016 15:14:05 GMT
Received: from ( []) by (GMO) with ESMTP id u8KFE1Dm024874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Sep 2016 17:14:04 +0200
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 17:14:02 +0200
From: "De Schepper, Koen (Nokia - BE)" <>
To: Ingemar Johansson S <>, "''" <>
Thread-Topic: TCP Prague progress and ideas
Thread-Index: AdISViNPIZ62s6OiQfCJKrGKXkpj2QANUpzw
Date: Tue, 20 Sep 2016 15:14:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: nl-BE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BF6B00CC65FD2D45A326E74492B2C19FB774E69AFR711WXCHMBA05z_"
MIME-Version: 1.0
Archived-At: <>
Cc: marcelo bagnulo braun <>, Praveen Balasubramanian <>, "Bob Briscoe (" <>
Subject: Re: [tcpPrague] TCP Prague progress and ideas
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Sep 2016 15:30:23 -0000

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?


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


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 Johansson  M.Sc.
Master Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289<>

The secret of getting ahead is getting started
                   Mark Twain