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

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 6 May 2013 14:00:05 +0000

Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.4? This is the question of ensuring that AQM technologies are applicable to all Internet traffic - not just TCP, but UDP, SCTP, and so on.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 May 2013 16:25:25 +0200

Hi,

First of all, I'd like to say that I agree with all the recommendations you asked about so far. I hesitated to answer as I wasn't sure if a ton of "yes I do" responses are useful?!

About this recommendation, I agree regarding what it actually recommends, but I have a comment about the wording. This bit:

"Hence, Active Queue Management algorithms that are effective with all of those transports and the applications that use them are to be preferred."

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. To me, ECN is an IP-layer signal and routers shouldn't have to investigate what's layered on it (which may go beyond just looking at the "protocol" field in case of tunnels) in order to make their decisions.

I tried to come up with a better phrasing but failed... maybe it could be an idea to just add a sentence after this one, saying something like "Such algorithms do not need to consider any information in the packet beyond its IP header."

Cheers,
Michael

On 6. mai 2013, at 16:00, Fred Baker (fred) wrote:

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 6 May 2013 14:36:23 +0000

Agree. 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Fred Baker (fred)
> Sent: Monday, May 06, 2013 9:00 AM
> To: [email-masked]
> Subject: [aqm] Question re draft-baker-aqm-recommendations
> recomendation #4
> 
> Do we generally agree with the recommendation of
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-
> 4.4? This is the question of ensuring that AQM technologies are
> applicable to all Internet traffic - not just TCP, but UDP, SCTP, and
> so on.
> 
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 6 May 2013 16:49:05 +0000

> 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. To me, ECN is an IP-layer signal and…

Thanks. I certainly agree that we should not be making transport-specific modifications; that was one thing that bothered me with cones, that it seemed to expect a different ECN encoding based on the DSCP. 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.

---

From: John Leslie <[email-masked]>
Date: Mon, 6 May 2013 15:17:25 -0400

Michael Welzl <[email-masked]> wrote:
> 
> About this recommendation, I agree regarding what it actually
> recommends, but I have a comment about the wording. This bit:
> 
> "Hence, Active Queue Management algorithms that are effective with
> all of those transports and the applications that use them are to be
> preferred."
>...

   I think some wordsmithing would help...
] 
] 4.4. Active Queue Management algorithms deployed SHOULD be effective on
] all common Internet traffic

   At the outset, do we mean to say that AQM specifications SHOULD
have, e.g., a "UDP Considerations" section? (That's one way to read
this.)

   Or do we mean that AQM SHOULD NOT be optimized for TCP?

   Or do we mean there exist some magical principles which enable
AQM designers to optimize for IP traffic we haven't thought of yet?

]  Active Queue Management algorithms often target TCP [RFC0793], as it
]  is by far the predominant transport in the Internet today.  However,
]  we have significant use of UDP [RFC0768] in voice and video services,
]  and find utility in SCTP [RFC4960] and DCCP [RFC4340].  Hence, Active
]  Queue Management algorithms that are effective with all of those
]  transports and the applications that use them are to be preferred. 

   I'm not the least bit sure that "target TCP" is the point. There's
an incredible range of traffic carried over TCP. It's typical for an
AQM proposal to be tested in terms of how a bulk-transfer TCP reacts
vs. an "interactive" web session series of "short" TCP streams. This,
IMHO, isn't "targetting" TCP, but rather comparing bulk transfer vs.
on-demand short-transfer -- where both happen to use TCP transport.
They could just as well be using SCTP or any of several other transports.

   Do we mean to say that things would be significantly better if the
tests were altered to use SCTP for some of the sessions?

   Besides, whether sessions are mixed transports or all TCP, the
congestion-control algorithms are in fact varied. Don't we mean to say
that AQM algorithms SHOULD work with a variety of congestion control
algorithms?

   If we do mean to require consideration of multiple _transports_,
what do we wish to see considered? I don't get much of a hint from
this text.

   Back to Michael:

> 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.

   That's certainly one "solution"... And I also dislike it.

> To me, ECN is an IP-layer signal and routers shouldn't have to
> investigate what's layered on it (which may go beyond just looking
> at the "protocol" field in case of tunnels) in order to make their
> decisions.

   Yes, but...

   It seems unlikely that we're going to get a fully satisfactory AQM
without separate queues for different flows. I'd like to believe the
IPv6 flow label can give us what we need, but that's optimistic...

> I tried to come up with a better phrasing but failed... maybe it
> could be an idea to just add a sentence after this one, saying
> something like "Such algorithms do not need to consider any
> information in the packet beyond its IP header."

  I think more substantial rewording is needed. I'll be happy to
suggest wording _after_ I see a better understanding of what we mean
to say here.

--
John Leslie <[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Mon, 6 May 2013 21:36:15 +0200

On May 6, 2013, at 9:17 PM, John Leslie <[email-masked]> wrote:

> IPv6 flow label can give us what we need, but that's optimistic…

Seems like a case of "more specific and more complicated" vs. "more vague but perhaps good enough" to me. I don't think that there's a reasonable way to be more specific here, but maybe I'm just missing it.

Cheers,
Michael

---

From: John Leslie <[email-masked]>
Date: Tue, 7 May 2013 09:37:24 -0400

Fred Baker (fred) <[email-masked]> wrote:
>> ...sounds as if it would be the most normal thing in the world for an
>> 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.

---

From: grenville armitage <[email-masked]>
Date: Tue, 14 May 2013 08:55:59 +1000

> " 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".

cheers,
gja

---

From: John Leslie <[email-masked]>
Date: Mon, 13 May 2013 19:48:11 -0400

grenville armitage <[email-masked]> wrote:
>>" ... Hence, Active Queue Management

   I'm not sure I understand the distinction here...

   My main thought as I wordsmithed was that there's really no way for
an AQM algorithm to know _what_ "transports and applications it will
be affecting".

> variety of applications".

   I suppose the process could be "delayed"; but "derailed" seems
unlikely. But frankly I don't see much difference between the two
wordings in that respect.

> applications it will be affecting" rather than "...all common

   To tell truth, I have no emotional attachment to my wording.

   (But perhaps this objection is to some other words??)

   Perhaps Grenville could send proposed text?

---

From: grenville armitage <[email-masked]>
Date: Wed, 15 May 2013 19:53:10 +1000

On 05/14/2013 09:48, John Leslie wrote:
	[..]
>     Perhaps Grenville could send proposed text?

A small tweak to the subsection heading and the last sentence:

  4.4. Active Queue Management algorithms deployed SHOULD be effective on
       all transports and applications they will be affecting

  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 all transports and applications
  they will be affecting.

cheers,
gja

---

From: Michael Welzl <[email-masked]>
Date: Wed, 15 May 2013 12:07:08 +0200

I like it!