Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #4

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 4 Jun 2013 22:17:17 +0000

On May 14, 2013, at 6:55 AM, grenville armitage <[email-masked]> wrote:

> 
> 
> On 05/07/2013 23:37, John Leslie wrote:
>> Fred Baker (fred) <[email-masked]> wrote:
>>> On May 6, 2013, at 7:25 AM, Michael Welzl <[email-masked]> wrote:
>>> 
>>>> ...sounds as if it would be the most normal thing in the world for an
>>>> AQM algorithm to make a decision based on the transport protocol,
>>>> which I think it shouldn't...
>>> 
>>> I certainly agree that we should not be making transport-specific
>>> modifications...
>>> My point in this, if you can think of a better way to phrase it, is
>>> that the AQM algorithm someone implements needs to demonstrably work
>>> with the transports and applications it will be affecting.
>> 
>>    Hearing no differing suggestions, those words seem appropriate. Thus
>> Section 4.4 might become:
>> "
>> " 4.4. Active Queue Management algorithms deployed SHOULD be effective on
>> "      all common Internet traffic
>> "
>> " Active Queue Management algorithms typically are verified to work with
>> " TCP [RFC0793] and a limited number of applications of it. This no
>> " longer represents a sufficient selection of actual traffic. We have
>> " significant use of UDP [RFC0768] in voice and video services, as well
>> " as SCTP [RFC4960] and DCCP [RFC4340]. Hence, Active Queue Management
>> " algorithms should demonstrably work with other transports as well as
>> " TCP, and with a wide variety of applications.
> 
> I see a difference between the scope of Fred's "...demonstrably
> work with the transports and applications it will be affecting"
> and the scope of the section heading ("...be effective on all
> common Internet traffic") or even "..as well as TCP, and with
> a wide variety of applications."
> 
> I certainly agree that an AQM algorithm ought not necessarily
> be  transport-layer aware. But the wording above could lead to
> a situation where acceptance of a future AQM scheme is derailed
> because it doesn't "work" with some (yet to be defined) "wide
> variety of applications".
> 
> I prefer the wiggle room allowed by "..the transports and
> applications it will be affecting" rather than "...all common
> Internet traffic".

I'll accept the change of language. I need to post an updated version for the IETF meeting, and am working on that with Srinivasan Keshav.

My biggest concern in the text is, as you say, it can't be limited to TCP. It has to work with two RFCs at a minimum:

https://tools.ietf.org/html/rfc3168
3168 The Addition of Explicit Congestion Notification (ECN) to IP. K.
     Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT=170966
     bytes) (Obsoletes RFC2481) (Updates RFC2003, RFC2474, RFC2401,
     RFC0793) (Updated by RFC4301, RFC6040) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6679
6679 Explicit Congestion Notification (ECN) for RTP over UDP. M.
     Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg.
     August 2012. (Format: TXT=148560 bytes) (Status: PROPOSED STANDARD)

> cheers,
> gja
> 
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

	• Make things as simple as possible, but not simpler.
Albert Einstein