On Jan 23, 2014, at 7:15 AM, Bob Briscoe <[email protected]> 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" > which currenty has only one example: "don't assume TCP". 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? > 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 ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
