Subject: [tsvwg] How AQM Guidance might be misinterpreted

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jan 2014 15:15:14 +0000

Fred, Gorry,

In case you've tuned out of the thread below, it's worth reading the 
(very short) section on ECN in 3GPP TS 36.300 to understand how RFCs 
could be misinterpreted (link in email below).

In this case, it's unclear but they seem to be assuming that there 
could be a special ECN marking behaviour on control signalling. It's 
ambiguous whether the 3GPP spec below intends to mean that ECN 
marking of a stream of packets is either all-on or all-off, rather 
than signalled by frequency/probability of marking.

It's perhaps another example to be brought out in the AQM Guidance, 
probably under:
"4.5. AQM algorithms SHOULD NOT be dependent on specific transport 
protocol behaviours"
which currenty has only one example: "don't assume TCP".

Bob

>Date: Thu, 23 Jan 2014 14:51:25 +0000
>To: Ingemar Johansson S <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN 
>to  L2 or tunnel protocols?
>Cc: "[email-masked]" <[email-masked]>, 
>"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>
>Ingemar, inline...
>
>At 06:36 22/01/2014, Ingemar Johansson S wrote:
>>Hi
>>
>>Please find answers inline
>>
>>/Ingemar
>>
>> > -----Original Message-----
>> > From: Bob Briscoe [mailto:[email-masked]]
>> > Sent: den 21 januari 2014 23:50
>> > To: Ingemar Johansson S; [email-masked]
>> > Cc: [email-masked]; [email-masked]
>> > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2
>> > or tunnel protocols?
>> >
>> > Ingemar,

[snip]

>> > 3) 3GPP TS 36.300 is ambiguous whether ECN marking is applied to 
>> all packets
>> > to "indicate congestion", or whether it is applied with a frequency or
>> > probability that depends on an AQM (it doesn't mention AQM, altho
>> > obviously it refers to RFC3168 that is based on AQM). Do you know whether
>> > it was meant to imply use of AQM?
>>Yes, it is very ambiguous, I advocate for a frequency or 
>>probability as it makes most sense, but this is not specified at 
>>all. The ECN marking can imply the use of AQM but that is again not 
>>specified. In short, much of the actual implementation is vendor specific.
>
>OK. In general vendor-specific is good, and congestion control can 
>be robust to different behaviours.
>
>Our draft states that algorithm guidance is outside its scope, but...
>
>One of the purposes of the IETF's AQM guidance is to set bounds on 
>how much variety is feasible without losing interworking. There's a 
>message in 3GPP TS 36.300 on how the IETF's RFCs could be 
>(mis)interpreted, if we don't make them clear.
>
>Bob
>
>> > At 20:29 21/01/2014, Ingemar Johansson S wrote:
>> > >Hi
>> > >
>> > >Please note that ECN over LTE radio access is already standardized in
>> > >3GPP TS 36.300 (see 11.6 in
>> > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zip )
>> > >
>> > >/Ingemar

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 23 Jan 2014 15:55:55 +0000

On Jan 23, 2014, at 7:15 AM, Bob Briscoe <[email-masked]> wrote:

> Fred, Gorry,
> 
> In case you've tuned out of the thread below, it's worth reading the (very short) section on ECN in 3GPP TS 36.300 to understand how RFCs could be misinterpreted (link in email below).
> 
> In this case, it's unclear but they seem to be assuming that there could be a special ECN marking behaviour on control signalling. It's ambiguous whether the 3GPP spec below intends to mean that ECN marking of a stream of packets is either all-on or all-off, rather than signalled by frequency/probability of marking.
> 
> It's perhaps another example to be brought out in the AQM Guidance, probably under:
> "4.5. AQM algorithms SHOULD NOT be dependent on specific transport protocol behaviours"

That seems reasonable. I'm not sure, though, what specific change you're suggesting. Is it the addition of an example, or rewording of the recommendation? Can you give us a specific proposed change?

>> Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to  L2 or tunnel protocols?
>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> 
>> Ingemar, inline...
>> 
>>> > 3) 3GPP TS 36.300 is ambiguous whether ECN marking is applied to all packets
>>> Yes, it is very ambiguous, I advocate for a frequency or probability as it makes most sense, but this is not specified at all. The ECN marking can imply the use of AQM but that is again not specified. In short, much of the actual implementation is vendor specific.
>> 
>> OK. In general vendor-specific is good, and congestion control can be robust to different behaviours.
>> 
>> One of the purposes of the IETF's AQM guidance is to set bounds on how much variety is feasible without losing interworking. There's a message in 3GPP TS 36.300 on how the IETF's RFCs could be (mis)interpreted, if we don't make them clear.
>> 
>> Bob
>> 

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies