Subject: Re: [tsvwg] 3GPP references to ECN

From: Bob Briscoe <[email-masked]>
Date: Fri, 8 Apr 2016 14:19:28 +0100

Ingemar,

Cc'ing the list as agreed...

On 08/04/16 08:29, Ingemar Johansson S wrote:
>
> Hi
>
> A few comments inline below
>
> Will listen in on the TSVWG session ASAP.
>
> /Ingemar
>
> *From:*ken carlberg [mailto:[email-masked]]
> *Sent:* den 7 april 2016 21:06
> *To:* Bob Briscoe
> *Cc:* Ingemar Johansson S
> *Subject:* 3GPP references to ECN
>
> Bob
>
> I very much liked your 3GPP references slide in the TSVWG 
> presentation.  The one thing, though, that reminded me of a concern I 
> had with 3GPP’s support for ECN centers in an obscure sentence in 
> TS.29.162, end of Section 10.2.13.2 Incoming SDP offer with ECN, which 
> states:
>
> "The TrGW*_should_ *not send RTCP XR ECN summary reports.”
>
> This departs from RFC-6679, and I think the motivation stems from a 
> concern by IMS vendors that the rate of feedback would be excessive.  
> I agree that the RFC will clearly add more control traffic, but I’m 
> not in agreement that it is excessive.
>
> [IJ] I don’t have the full understanding of what happens in 3GPP, I 
> recall that there was a lot of discussion of the amount of overhead 
> that RTCP gives. But I never had any real influence in this area.
>
[BB] I can add Ken's point to the liaison, but if the 3GPP worded it the 
way it did in full knowledge of what was in the IETF RFC, and you tried 
to influence it at the time, but failed, that's a different problem from 
misunderstanding or lack of clarity between SDOs. We'll see what others 
think.

> I bring this up in your references slide, you state that the L4-7 is 
> “fully compatible with EC-in-RTP”, which it is not.
>
> Also, my understanding is that the objective of some vendors/carriers 
> was to rely on a step-like function in having the codec (eg, AMR-WB) 
> reduce its load on receipt of ECN-CE instead of relying on a more 
> elaborate congestion control algorithm.  I’m cc’ing Ingemar for a 
> sanity check (on what I wrote, versus my current state of mind :-)
>
> [IJ] Yes, I am partly guilty to this. I guess it is good enough for 
> bitrates below ~30kbps. But I am quite confident today that it won’t 
> work well at video bitrates or higher audio bitrates, that is why I 
> try to pitch the SCReAM algorithm.
>
[BB] So, are you confirming definitely that the intent was for on-off 
marking at the eNodeB (even tho it doesn't go as far as saying that, it 
sounds as if that was in the mind of the writer)?

Have you seen the problem John K has pointed out (in our slides) where 
the marking might either come from an AQM in a non-3GPP network or 
on-off marking in the 3GPP network. So all codecs have to interpret both 
a low level of random marking (as in AQM) and toggling between a 
constant 100% level of marking and 0%, even tho they both occur under 
the same conditions and they don't know where the marking is coming from.

Now that we have pointed this discrepancy out, do you think it's best 
that 3GPP adds some text to these specs to refer to (say) the recent 
IETF AQM Recommendations for the marking behaviour [RFC7567]. Does that 
create an incremental deployment problem in 3GPP?

Cheers

Bob
> cheers,
> -ken

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

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

Hi  all,

I just proposed noticed your discussion here, which could be of interest on trying DCTCP on mobile networks:

> Also, my understanding is that the objective of some vendors/carriers was to rely on a step-like function in having the codec (eg, AMR-WB) reduce its load on receipt of ECN-CE instead of relying on a more elaborate congestion control algorithm.  I’m cc’ing Ingemar for a sanity check (on what I wrote, versus my current state of mind :-)
[IJ] Yes, I am partly guilty to this. I guess it is good enough for bitrates below ~30kbps. But I am quite confident today that it won’t work well at video bitrates or higher audio bitrates, that is why I try to pitch the SCReAM algorithm.
[BB] So, are you confirming definitely that the intent was for on-off marking at the eNodeB (even tho it doesn't go as far as saying that, it sounds as if that was in the mind of the writer)?

Is this step function the right one to run a DCTCP like congestion control on it? Is it a step that is not smoothed and shallow enough? Is there equipment that implements this step, and can we do some tests using DCTCP on this?

Regards,
Koen.

From: tsvwg [mailto:[email-masked]] On Behalf Of EXT Bob Briscoe
Sent: vrijdag 8 april 2016 15:19
To: Ingemar Johansson S; [email-masked]; tsvwg IETF list
Subject: Re: [tsvwg] 3GPP references to ECN

Ingemar,

/Ingemar

From: ken carlberg [mailto:[email-masked]]
Sent: den 7 april 2016 21:06
To: Bob Briscoe
Cc: Ingemar Johansson S
Subject: 3GPP references to ECN

Bob

I very much liked your 3GPP references slide in the TSVWG presentation.  The one thing, though, that reminded me of a concern I had with 3GPP’s support for ECN centers in an obscure sentence in TS.29.162, end of Section 10.2.13.2 Incoming SDP offer with ECN, which states:

          "The TrGW should not send RTCP XR ECN summary reports.”

This departs from RFC-6679, and I think the motivation stems from a concern by IMS vendors that the rate of feedback would be excessive.  I agree that the RFC will clearly add more control traffic, but I’m not in agreement that it is excessive.
[IJ] I don’t have the full understanding of what happens in 3GPP, I recall that there was a lot of discussion of the amount of overhead that RTCP gives. But I never had any real influence in this area.
[BB] I can add Ken's point to the liaison, but if the 3GPP worded it the way it did in full knowledge of what was in the IETF RFC, and you tried to influence it at the time, but failed, that's a different problem from misunderstanding or lack of clarity between SDOs. We'll see what others think.

I bring this up in your references slide, you state that the L4-7 is “fully compatible with EC-in-RTP”, which it is not.

Also, my understanding is that the objective of some vendors/carriers was to rely on a step-like function in having the codec (eg, AMR-WB) reduce its load on receipt of ECN-CE instead of relying on a more elaborate congestion control algorithm.  I’m cc’ing Ingemar for a sanity check (on what I wrote, versus my current state of mind :-)
[IJ] Yes, I am partly guilty to this. I guess it is good enough for bitrates below ~30kbps. But I am quite confident today that it won’t work well at video bitrates or higher audio bitrates, that is why I try to pitch the SCReAM algorithm.
[BB] So, are you confirming definitely that the intent was for on-off marking at the eNodeB (even tho it doesn't go as far as saying that, it sounds as if that was in the mind of the writer)?

Have you seen the problem John K has pointed out (in our slides) where the marking might either come from an AQM in a non-3GPP network or on-off marking in the 3GPP network. So all codecs have to interpret both a low level of random marking (as in AQM) and toggling between a constant 100% level of marking and 0%, even tho they both occur under the same conditions and they don't know where the marking is coming from.

Now that we have pointed this discrepancy out, do you think it's best that 3GPP adds some text to these specs to refer to (say) the recent IETF AQM Recommendations for the marking behaviour [RFC7567]. Does that create an incremental deployment problem in 3GPP?

Cheers

Bob

cheers,

-ken

--

---

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

Hi

My comments inline

/Ingemar

From: De Schepper, Koen (Nokia - BE) [mailto:[email-masked]] 
Sent: den 8 april 2016 18:32
To: EXT Bob Briscoe; Ingemar Johansson S; [email-masked]; tsvwg IETF list
Cc: [email-masked]
Subject: Re: [tcpPrague] [tsvwg] 3GPP references to ECN

Hi  all,

[IJ] No I would  not take it that far, parts of the text in 36.300 may imply this (1st para in section 11.6), but this is actually only a discussion text. The normative text is the 2nd para. My interpretation is that ECN marking should be something according to RFC7567, problem is however that ECN is not implemented. 

[IJ] Currently I cannot answer the question, if ECN is implemented I would believe that it would be more RFC3168-ish at least initially.

Regards,

Koen.

Ingemar,

Hi

/Ingemar

Bob

 

Cheers

Bob 

cheers,

-ken