Subject: [tcpPrague] BoF comments

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 7 Apr 2016 13:24:23 +0000

I am quite positive to the 'Ultra-Low Queuing Delay for All' ideas. I have
not fully grasped the AQM ideas but nonetheless.

Direct question (which I missed) : On SCReAM and making a dualQ solution to
it. Yes, should be doable as SCReAM already  steals ideas from TCP. This
work of course depends on whether SCReAM flies. 

The challenges are both technical and political.
Technical : 4G/5G (also raised at the mic by somebody).The goal to reach low
latency even at high load levels is a bit at odds against the need to have
enough bits to transmit, given that the transport block sizes can change a
lot. The rapid change in resource allocation is also a challenge as
transport protocols at the endpoints are not fast enough to track these, the
effect of this is that the queuing delay will spike even though it is
targeted to a low level. There could be solutions to this but these
solutions cannot be devised within a IETF framework, rather it needs to be
handled with in the SDOs that deal with the MAC layer functions (if subject
to standardization at all).

Political : The challenge today is to sell ECN, even though ECN is
standardized in TS36.300 I still eagerly  wait to see it happen. Still
despite this, any work around this that involves 3GPP radio needs to somehow
be driven in 3GPP as well.

That said : Given that one can get some traction around ECN in general I
don't see any dramatic issues with distinguishing between ECT(0) and ECT(1)

/Ingemar
==================================
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
[email-masked]
www.ericsson.com

           This report, by it´s very length, 
 defends itself against the risk of being read
                        Winston Churchill
==================================

---

From: Michael Welzl <[email-masked]>
Date: Thu, 7 Apr 2016 10:37:42 -0300

Hi Ingemar, all,

> On 7. apr. 2016, at 10.24, Ingemar Johansson S <[email-masked]> wrote:
> 

I’m not sure we’d even need to tweak SCReAM or any other delay-based mechanism when we’re discussing using instantaneous queue marking with ECN?
Scalable TCP should give you low latency and a smooth rate, what else can you wish for?
(except maybe it shouldn’t be “TCP” per se for RMCAT’s purposes, you neither need nor want 100% reliability there).

> be driven in 3GPP as well.

Towards ECN deployment, I believe that a simple easy-to-install solution that shows people that ECN can have benefits is a good first step:
draft-khademi-alternativebackoff-ecn-03
http://heim.ifi.uio.no/michawe/research/publications/CAIA-TR-150710A.pdf

In short, this simply tweaks the sender to react differently in response to an ECN signal than in response to packet loss (recognizing that a CE-mark was probably produced by a smaller-than-BDP queue). The result is that you can have short queues without losing throughput. The point of this is to be simple: it doesn’t change the ECN definition, the AQM behavior, the receiver behavior - just the sender-side congestion control.

> don't see any dramatic issues with distinguishing between ECT(0) and ECT(1)

… and the proposal I mentioned above uses ECT(0), which is why it wouldn’t get in the way of the better “grand solution” here (Scalable TCP + Dual Queue + Accurate ECN feedback), yet could help convince people that ECN is good.

Cheers,
Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 7 Apr 2016 10:29:36 -0700

> to standardization at all).
Could you provide more details or pointers on that. Thanks.

> _______________________________________________
> tcpPrague mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpprague
>

---

From: "De Schepper, Koen (Nokia - BE)" <[email-masked]>
Date: Fri, 8 Apr 2016 13:46:05 +0000

Hi Michael, Ingemar,

> -----Original Message-----
> From: EXT Michael Welzl [mailto:[email-masked]]
> Sent: donderdag 7 april 2016 15:38
> To: Ingemar Johansson S
> Cc: [email-masked]; Bob Briscoe ([email-masked]); De Schepper,
> Koen (Nokia - BE)
> Subject: Re: [tcpPrague] BoF comments
> 
> Hi Ingemar, all,
> 
> 
> > On 7. apr. 2016, at 10.24, Ingemar Johansson S
> I’m not sure we’d even need to tweak SCReAM or any other delay-based
> mechanism when we’re discussing using instantaneous queue marking with
> ECN?
> (except maybe it shouldn’t be “TCP” per se for RMCAT’s purposes, you
> neither need nor want 100% reliability there).

It has been a while that I had a look at the RMCAT congestion controls, but I think they are good candidates to explore the L4S capabilities. As far as I understood they also respond to latency, so as long as the latency is not increased, they can respond scalable and preferably RTT independent to the marking. If latency is increasing, they can assume a classic ECN-marker is in place (that does not know the difference between ect(0) and ect(1)), and respond more drastically, like they would respond to drop. But most probably they will respond already early to the latency, avoiding high ECN marking probabilities under high RTTs?

For testing purposes, you could run a SCReAM or NADA flow on an immediate (DCTCP configured RED with ECN and shallow step) AQM.

> > targeted to a low level.

You could do the tests using DCTCP on a varying throughput link, configured with an immediate shallow threshold ECN AQM to get an idea of its capabilities, compared to what is typically configured today with Cubic and CTCP. I forgot to mention that we also plan to do these tests, but it would be good to see independent results and discussions on the limitations (range of RTTs where we can use L4S), and improvements we can do on DCTCP to better support L4S.  

The good thing is that all building blocks are currently available to test (use in confined partition) L4Sv0.1 (DCTCP, step-ECN-RED).

You need DualQ only if you want to test L4S and Classic competing flows.

> > There could be solutions to this but these

Isn't Ect(1) L4S marking (DCTCP configured RED) very simple to implement/configure in the bottleneck (access) queues?
If you can show drastic latency advantages (even with slightly bigger "small" queues) with a fast responding congestion control, wouldn't that help?

Note currently DCTCP responds fast downwards, but not yet fast upwards. This is one of the needed improvements.

Regards,
Koen.

> Towards ECN deployment, I believe that a simple easy-to-install solution
> that shows people that ECN can have benefits is a good first step:
> In short, this simply tweaks the sender to react differently in response
> to an ECN signal than in response to packet loss (recognizing that a CE-
> mark was probably produced by a smaller-than-BDP queue). The result is
> that you can have short queues without losing throughput. The point of
> this is to be simple: it doesn’t change the ECN definition, the AQM
> behavior, the receiver behavior - just the sender-side congestion
> control.
> 
> 
> … and the proposal I mentioned above uses ECT(0), which is why it
> wouldn’t get in the way of the better “grand solution” here (Scalable
> TCP + Dual Queue + Accurate ECN feedback), yet could help convince
> people that ECN is good.
> 
> Cheers,
> Michael

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 8 Apr 2016 19:19:23 +0000

Hi Yuchung

I elaborate a bit on the resource allocation issue in the CC for 4G and 5G draft (section 2.3).  Cannot currently give any details or pointers to possible solutions as I don't know of any sofar however. 

Regards
/Ingemar

> From: Yuchung Cheng [mailto:[email-masked]]
> Sent: den 7 april 2016 19:30
> To: Ingemar Johansson S
> Cc: [email-masked]; Bob Briscoe ([email-masked]);
> [email-masked]
> > I am quite positive to the 'Ultra-Low Queuing Delay for All' ideas. I
> > have not fully grasped the AQM ideas but nonetheless.
> >
> > Direct question (which I missed) : On SCReAM and making a dualQ
> > solution to it. Yes, should be doable as SCReAM already  steals ideas
> > from TCP. This work of course depends on whether SCReAM flies.
> >
> > Technical : 4G/5G (also raised at the mic by somebody).The goal to
> > reach low latency even at high load levels is a bit at odds against
> > the need to have enough bits to transmit, given that the transport
> > block sizes can change a lot. The rapid change in resource allocation
> > is also a challenge as transport protocols at the endpoints are not
> > fast enough to track these, the effect of this is that the queuing
> > delay will spike even though it is targeted to a low level. There
> > could be solutions to this but these solutions cannot be devised
> > within a IETF framework, rather it needs to be handled with in the
> > SDOs that deal with the MAC layer functions (if subject to standardization
> at all).
> > despite this, any work around this that involves 3GPP radio needs to
> > somehow be driven in 3GPP as well.
> >
> > That said : Given that one can get some traction around ECN in general
> > I don't see any dramatic issues with distinguishing between ECT(0) and
> > ECT(1)
> >
> > /Ingemar
> >            This report, by it´s very length,  defends itself against
> > the risk of being read
> >                         Winston Churchill

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Apr 2016 07:23:49 +0000

Hi

Koen , Michael + others
See comments inline [IJ]

/Ingemar

> From: De Schepper, Koen (Nokia - BE)
> [mailto:[email-masked]]
> Sent: den 8 april 2016 15:46
> To: EXT Michael Welzl; Ingemar Johansson S
> Cc: [email-masked]; Bob Briscoe ([email-masked])
> Subject: RE: [tcpPrague] BoF comments
> 
> Hi Michael, Ingemar,
> 
> 
> 
> > Cc: [email-masked]; Bob Briscoe ([email-masked]); De
> > Schepper, Koen (Nokia - BE)
> > have
> > solution to
> It has been a while that I had a look at the RMCAT congestion controls, but I
> think they are good candidates to explore the L4S capabilities. As far as I
> understood they also respond to latency, so as long as the latency is not
> increased, they can respond scalable and preferably RTT independent to the
> marking. If latency is increasing, they can assume a classic ECN-marker is in
> place (that does not know the difference between ect(0) and ect(1)), and
> respond more drastically, like they would respond to drop. But most
> probably they will respond already early to the latency, avoiding high ECN
> marking probabilities under high RTTs?
> 
> For testing purposes, you could run a SCReAM or NADA flow on an
> immediate (DCTCP configured RED with ECN and shallow step) AQM.

[IJ] You may want to take a look at section A.5 in (https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-03) The Q-bit semantics is much inspired by DCTCP, the intention is here to force down the bitrate of a stream that is suspected to take a too large share of a common bottleneck. It is quite easy to add a similar DCTCP like congestion window modification function, what has so far prevented more experiments with ECN (and L4S) is that it is a lack of (well documented) support for ECN in UDP sockets. 
ECN in general has been tried out in our system simulators, the results are however poorly documented, with traditional RFC3168 style ECN marking it does not good much of an improvement in latency as SCReAM already tries to keep latency low as is, the benefit instead comes with less packet drops and that is a yuuuge benefit for Video as retransmissions then become more rare. Also complicated cases with competing TCP traffic are also more efficiently solved with ECN support.

> > reach low
> > > latency even at high load levels is a bit at odds against the need
> > > to
> > have
> > > effect of this is that the queuing delay will spike even though it
> > > is targeted to a low level.
> 
> You could do the tests using DCTCP on a varying throughput link, configured
> with an immediate shallow threshold ECN AQM to get an idea of its
> capabilities, compared to what is typically configured today with Cubic and
> CTCP. I forgot to mention that we also plan to do these tests, but it would be
> good to see independent results and discussions on the limitations (range of
> RTTs where we can use L4S), and improvements we can do on DCTCP to
> better support L4S.
> 
> The good thing is that all building blocks are currently available to test (use in
> confined partition) L4Sv0.1 (DCTCP, step-ECN-RED).
> 
> > > There could be solutions to this but these solutions cannot be
> > > devised within a IETF framework, rather it needs
> > to be
> > > standardized in TS36.300 I still eagerly  wait to see it happen.
> > > Still despite this, any work around this that involves 3GPP radio
> > > needs to
> > somehow
> Isn't Ect(1) L4S marking (DCTCP configured RED) very simple to
> implement/configure in the bottleneck (access) queues?
> If you can show drastic latency advantages (even with slightly bigger "small"
> queues) with a fast responding congestion control, wouldn't that help?
> 
> > Towards ECN deployment, I believe that a simple easy-to-install
> > solution that shows people that ECN can have benefits is a good first step:
> > In short, this simply tweaks the sender to react differently in
> > response to an ECN signal than in response to packet loss (recognizing
> > that a CE- mark was probably produced by a smaller-than-BDP queue).
> > The result is that you can have short queues without losing
> > throughput. The point of this is to be simple: it doesn’t change the
> > ECN definition, the AQM behavior, the receiver behavior - just the
> > sender-side congestion control.
> >
> >
> > I

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Apr 2016 07:35:46 +0000

Hi

As regards to draft-khademi-alternativebackoff-ecn-03 , please note that the SCReAM draft already recommends different back off settings for loss and ECN-CE. With that said, I have not had time to evaluate ECN fully.

/Ingemar

> From: Michael Welzl [mailto:[email-masked]]
> Sent: den 7 april 2016 15:38
> To: Ingemar Johansson S
> Towards ECN deployment, I believe that a simple easy-to-install solution that
> shows people that ECN can have benefits is a good first step:
> In short, this simply tweaks the sender to react differently in response to an
> ECN signal than in response to packet loss (recognizing that a CE-mark was
> probably produced by a smaller-than-BDP queue). The result is that you can
> have short queues without losing throughput. The point of this is to be
> simple: it doesn’t change the ECN definition, the AQM behavior, the receiver
> behavior - just the sender-side congestion control.
> 
> 
> … and the proposal I mentioned above uses ECT(0), which is why it wouldn’t
> get in the way of the better “grand solution” here (Scalable TCP + Dual
> Queue + Accurate ECN feedback), yet could help convince people that ECN is
> good.
> 
> Cheers,
> Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 11 Apr 2016 09:47:45 +0200

Thanks - this is great! I hadn't seen this in the draft - I just checked and saw that it was added in the last version.

Cheers,
Michael

> On 11 Apr 2016, at 09:35, Ingemar Johansson S <[email-masked]> wrote:
> 
> Hi
>