Subject: Re: [iccrg] Maybe skipping Prague...

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 9 May 2017 01:45:11 +0000

Hi Koen , Hi Bob

I have read the slides of L4S TCP-Prague in IETF98. The discussion of scalable CC is very attractive.
However I have a little trouble with the equations in the slides. For example : r = 2 / p.RTT and one of its conclusions: Current DCTCP- 2 marks per RTT
Is there any reference of the equations to better understand them? 
And Whether the DCTCP can mark more than 2 packets based on the network condition, in my understanding?

sorry to ask this if it has been discussed or explained in the meeting, but I really want to make the whole idea clear. 
thanks!

Best Regards,

Xuesong

>-----Original Message-----
>From: iccrg [mailto:[email-masked]] On Behalf Of Bob Briscoe
>Sent: Wednesday, April 19, 2017 6:41 PM
>To: Michael Welzl
>Cc: [email-masked]
>Subject: Re: [iccrg] Maybe skipping Prague...
>
>Michael,
>
>We (Koen De Schepper and I) are about to post a tech report to the iccrg list,
>which identifies 6 tensions between the scaling requirements for a CC, and
>proposes solutions to most of them and compromises between others. This is in
>the context of the "TCP Prague requirements".
>
>Initially, the scope of the report is confined to scaling the steady-state, but some
>of the criteria are intended to help the dynamics to scale.
>We are using a tech report format, rather than an internet-draft, purely so the
>equations are more easily readable, and so we can include plots, figures, etc.
>It's only simple algebra - no differential equations.
>
>If there's no iccrg meeting, I guess we could arrange a meeting specifically
>about TCP Prague. However, reaching consensus on the compromises seems
>like the main "pre-standards" role of the ICCRG, so we were hoping to get
>discussion going on the list, then to try to reach consensus in a f2f iccrg meeting.
>The downside of a TCP-Prague-specific meeting might be "selection bias" in the
>consensus, because only people who agree with the premis on which TCP
>Prague is based will tend to turn up.
>
>It would have been nice to do this in Prague, given this is about "TCP Prague" :)
>
>
>
>Bob
>
>PS. Sorry we hadn't already flagged that these ideas for the next ICCRG
>mtg were in our heads.
>
>
>On 19/04/17 08:19, Michael Welzl wrote:
>> Hi all,
>>
>> We chairs are thinking of maybe not having an ICCRG meeting in Prague.
>> If you dearly wish to have a session, e.g. because you were planning to present
>or discuss something, please do send us a note ASAP; if we get enough such
>notes, there will be a meeting.
>>
>> Cheers,
>> Michael
>>
>> _______________________________________________
>> iccrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/iccrg
>
>--
>________________________________________________________________
>Bob Briscoe                               http://bobbriscoe.net/
>
>_______________________________________________
>iccrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/iccrg

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 May 2017 00:03:52 +0100

Xuesong,

On 09/05/17 02:45, Gengxuesong (Geng Xuesong) wrote:
> However I have a little trouble with the equations in the slides. For example : r = 2 / p.RTT
See https://riteproject.eu/dctth/#papers

In particular, appendix A of this one has the answers to your questions:
/*PI^2 : A Linearized AQM for both Classic and Scalable TCP*/ 
<https://riteproject.files.wordpress.com/2015/10/pi2_conext.pdf>,
Specifically, eqn (11).
     W = 2/p
where W is the congestion window and p is the ECN marking probability.
You can get the packet rate, r, from this, cos
     r= W/R
      = 2/(Rp)
where R is the RTT.

The above paper is about a Coupled Single Queue. There is another paper 
there about the Coupled Dual Queue but it's rather outdated (“`Data 
Centre to the Home’: Ultra-Low Latency for All” ). I'll send you a copy 
of a more up to date one offlist (under submission).

more...

> and one of its conclusions: Current DCTCP- 2 marks per RTT
2 packets per RTT is the steady state. During dynamics you can get much 
more marking, or none.

The nice thing about constant marks per RTT in steady state is that if 
you lose the signal for a round trip or two, you know you can start 
probing for more capacity. Whereas with non-scalable congestion controls 
it takes too long.

For instance, altho Cubic is better than Reno, at 100Mb/s with R=20ms, 
each Cubic saw-tooth is 250 round trips long (5s). So your algo has to 
wait a few hundred round trips and probably longer before it knows it 
can start pushing upwards faster to find increased available capacity.

And unlike a scalable control, this recovery time increases as you go 
faster. For instance, with Cubic you get x2 recovery time for x8 flow 
rate. So at 800Mb/s, recovery time is 500 round trips, an so on.

See also slides 5 & 7 of the presentation about the L4S identifier in 
Seoul (IETF-97, Nov 2016)
https://www.ietf.org/proceedings/97/slides/slides-97-tsvwg-sessb-43-l4s-ecn-modificataions-00.pdf

> sorry to ask this if it has been discussed or explained in the meeting, but I really want to make the whole idea clear.
No problem. It's expected that people keep joining the conversation all 
the time.

I plan to "beacon out" an L4S status update shortly, for exactly that 
reason.

Bob

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 10 May 2017 02:20:23 +0000

Thanks Bob! That is really nice.
Another small question : I notice that you have mentioned:" The nice thing about constant marks per RTT in steady state is that if you lose the signal for a round trip or two, you know you can start probing for more capacity.", but I haven't found the relative description in DCTCP paper(https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/dctcp-sigcomm2010.pdf). Is it an optional function of DCTCP or a possible modification of it?

Best Regards,

Xuesong

From: Bob Briscoe [mailto:[email-masked]]
Sent: Wednesday, May 10, 2017 7:04 AM
To: Gengxuesong (Geng Xuesong); De Schepper, Koen (Nokia - BE/Antwerp)
Cc: [email-masked]
Subject: Re: [iccrg] Maybe skipping Prague...

Xuesong,

Hi Koen , Hi Bob

In particular, appendix A of this one has the answers to your questions:
PI2: A Linearized AQM for both Classic and Scalable TCP<https://riteproject.files.wordpress.com/2015/10/pi2_conext.pdf>,
Specifically, eqn (11).
    W = 2/p
where W is the congestion window and p is the ECN marking probability.
You can get the packet rate, r, from this, cos
    r= W/R
     = 2/(Rp)
where R is the RTT.

The above paper is about a Coupled Single Queue. There is another paper there about the Coupled Dual Queue but it's rather outdated ("`Data Centre to the Home': Ultra-Low Latency for All" ). I'll send you a copy of a more up to date one offlist (under submission).

more...

And Whether the DCTCP can mark more than 2 packets based on the network condition, in my understanding?
2 packets per RTT is the steady state. During dynamics you can get much more marking, or none.

The nice thing about constant marks per RTT in steady state is that if you lose the signal for a round trip or two, you know you can start probing for more capacity. Whereas with non-scalable congestion controls it takes too long.

For instance, altho Cubic is better than Reno, at 100Mb/s with R=20ms, each Cubic saw-tooth is 250 round trips long (5s). So your algo has to wait a few hundred round trips and probably longer before it knows it can start pushing upwards faster to find increased available capacity.

And unlike a scalable control, this recovery time increases as you go faster. For instance, with Cubic you get x2 recovery time for x8 flow rate. So at 800Mb/s, recovery time is 500 round trips, an so on.

See also slides 5 & 7 of the presentation about the L4S identifier in Seoul (IETF-97, Nov 2016)
https://www.ietf.org/proceedings/97/slides/slides-97-tsvwg-sessb-43-l4s-ecn-modificataions-00.pdf

sorry to ask this if it has been discussed or explained in the meeting, but I really want to make the whole idea clear.
No problem. It's expected that people keep joining the conversation all the time.

I plan to "beacon out" an L4S status update shortly, for exactly that reason.

Bob

thanks!

Best Regards,

Xuesong

-----Original Message-----

To: Michael Welzl

Cc: [email-masked]<mailto:[email-masked]>

Michael,

Bob

mtg were in our heads.

Hi all,

Cheers,

Michael

iccrg mailing list

[email-masked]<mailto:[email-masked]>

--

iccrg mailing list

[email-masked]<mailto:[email-masked]>

iccrg mailing list

[email-masked]<mailto:[email-masked]>

--

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 10 May 2017 10:00:42 +0000

Hi Xuesong,

This is indeed one of the possible performance improvement for DCTCP. We described a set of required safety improvements and optional performance improvements as the "TCP-Prague" requirements, now moved to appendix A of the draft-ietf-tsvwg-ecn-l4s-id. The performance improvements became possible because of the more frequent and scalable L4S signal.

Regards,
Koen.

From: Gengxuesong (Geng Xuesong) [mailto:[email-masked]]
Sent: woensdag 10 mei 2017 4:20
To: Bob Briscoe <[email-masked]>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: RE: [iccrg] Maybe skipping Prague...

Best Regards,

Xuesong

Xuesong,

Hi Koen , Hi Bob

more...

Bob

thanks!

Best Regards,

Xuesong

-----Original Message-----

To: Michael Welzl

Michael,

Bob

mtg were in our heads.

Hi all,

Cheers,

Michael

iccrg mailing list

--

iccrg mailing list

iccrg mailing list

--

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 10 May 2017 11:32:00 +0000

Hi

The proposed ECN handling at lower layers in the 5G NR standard (see link below) is intended to make it possible to make it possible to deploy efficient implementations of L4S.

L4S is of particular interest in 5G as we foresee that throughput can change quite considerably with 5G access technology.
http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.zip

/Ingemar

From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: den 10 maj 2017 12:01
To: Gengxuesong (Geng Xuesong) <[email-masked]>; Bob Briscoe <[email-masked]>
Cc: [email-masked]
Subject: Re: [iccrg] Maybe skipping Prague...

Hi Xuesong,

Regards,
Koen.

To: Bob Briscoe <[email-masked]<mailto:[email-masked]>>; De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>

Best Regards,

Xuesong

Xuesong,

Hi Koen , Hi Bob

more...

Bob

thanks!

Best Regards,

Xuesong

-----Original Message-----

To: Michael Welzl

Michael,

Bob

mtg were in our heads.

Hi all,

Cheers,

Michael

iccrg mailing list

--

iccrg mailing list

iccrg mailing list

--

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 May 2017 15:53:15 +0100

Ingemar,

Thanks for this. The proposal to do ECN-marking at the RLC layer is 
important.

I've sent you a marked up corrected copy offlist, cos the ECN deployment 
statements are misleading.

Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest 
OSs, 5% on previous).
On mobile-connected devices, Apple enables ECN solely for 3 carriers: 
T-Mobile, Three, Telstra

See video of conference: Networking for the Modern Internet 
<https://developer.apple.com/videos/play/wwdc2016/714/> (video requires 
Safari, or you can look it up in the iOS WWDC app 
<https://itunes.apple.com/us/app/wwdc/id640199958?mt=8>).

Cheers

Bob

On 10/05/17 12:32, Ingemar Johansson S wrote:
>
> Hi
>
> The proposed ECN handling at lower layers in the 5G NR standard (see 
> link below) is intended to make it possible to make it possible to 
> deploy efficient implementations of L4S.
>
> L4S is of particular interest in 5G as we foresee that throughput can 
> change quite considerably with 5G access technology.
>
> *From:*De Schepper, Koen (Nokia - BE/Antwerp) 
> [mailto:[email-masked]]
> *Sent:* den 10 maj 2017 12:01
> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>; Bob Briscoe 
> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [iccrg] Maybe skipping Prague...
>
> Hi Xuesong,
>
> This is indeed one of the possible performance improvement for DCTCP. 
> We described a set of required safety improvements and optional 
> performance improvements as the “TCP-Prague” requirements, now moved 
> to appendix A of the draft-ietf-tsvwg-ecn-l4s-id. The performance 
> improvements became possible because of the more frequent and scalable 
> L4S signal.
>
> Regards,
>
> Koen.
>
> *From:*Gengxuesong (Geng Xuesong) [mailto:[email-masked]]
> *Sent:* woensdag 10 mei 2017 4:20
> *To:* Bob Briscoe <[email-masked] <mailto:[email-masked]>>; 
> De Schepper, Koen (Nokia - BE/Antwerp) 
> <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [iccrg] Maybe skipping Prague...
>
> Another small question : I notice that you have mentioned:”The nice 
> thing about constant marks per RTT in steady state is that if you lose 
> the signal for a round trip or two, you know you can start probing for 
> more capacity.”, but I haven’t found the relative description in DCTCP 
> paper(https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/dctcp-sigcomm2010.pdf). 
> Is it an optional function of DCTCP or a possible modification of it?
>
> Best Regards,
>
> Xuesong
>
> *From:*Bob Briscoe [mailto:[email-masked]]
> *Sent:* Wednesday, May 10, 2017 7:04 AM
> *To:* Gengxuesong (Geng Xuesong); De Schepper, Koen (Nokia - BE/Antwerp)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [iccrg] Maybe skipping Prague...
>
> Xuesong,
>
> */PI^2 : A Linearized AQM for both Classic and Scalable TCP/* 
> The above paper is about a Coupled Single Queue. There is another 
> paper there about the Coupled Dual Queue but it's rather outdated 
> (“`Data Centre to the Home’: Ultra-Low Latency for All” ). I'll send 
> you a copy of a more up to date one offlist (under submission).
>
> more...
>
> probing for more capacity. Whereas with non-scalable congestion 
> controls it takes too long.
>
> sorry to ask this if it has been discussed or explained in the 
> meeting, but I really want to make the whole idea clear.
>
>     Cc: [email-masked] <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 11 May 2017 01:26:52 +0000

Hi Koen,

Thank you!  I think I can get the point now, and I am looking forward to your further work.

Best Regards,

Xuesong
From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: Wednesday, May 10, 2017 6:01 PM
To: Gengxuesong (Geng Xuesong); Bob Briscoe
Cc: [email-masked]
Subject: RE: [iccrg] Maybe skipping Prague...

Hi Xuesong,

Regards,
Koen.

Best Regards,

Xuesong

Xuesong,

Hi Koen , Hi Bob

more...

Bob

thanks!

Best Regards,

Xuesong

-----Original Message-----

To: Michael Welzl

Michael,

Bob

mtg were in our heads.

Hi all,

Cheers,

Michael

iccrg mailing list

--

iccrg mailing list

iccrg mailing list

--