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 protected]>
From: Bob Briscoe <[email protected]>
Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN
to L2 or tunnel protocols?
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]" <[email protected]>
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 protected]]
> Sent: den 21 januari 2014 23:50
> To: Ingemar Johansson S; [email protected]
> Cc: [email protected]; [email protected]
> 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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
