Wes,
Thx. In case I don't get time to read, then type, I'll shoot my mouth
off anyway...
Sorry this is a bit rushed and dismissive. That's not my intention -
I'm v supportive of the recommendations that have now been carefully
and nicely worded. I will give more detailed comments, but these are the MSBs.
1) My main concern: The two halves of the document seemed nearly
unrelated (at least in draft-03 and it looks like draft-04 hasn't
changed this). The first half (Sections 1,2,&3) framed the problem as
primarily about preventing congestion collapse and preventing
flow-unfairness, while the recommendations (section 4) were about
AQM. The irony of this sentence is deliberate.
I had few concerns about the recommendations text (section 4), which
we've all been focusing on, including me. But I hadn't realised the
introductory text was so out of kilter with the recommendations.
Sections 1,2 and 3 seemed to focus on problems that I wouldn't even
address with AQM (from a quick scan it looks like these sections
haven't changed in this respect for draft-04):
a) Congestion collapse: An AQM cannot prevent congestion collapse -
that is the job of congestion control and, failing that, of policing.
Even isolation (e.g. flow separation) doesn't prevent congestion
collapse, because collapse is caused by the load from new flow
arrivals exceeding the ability of the system to serve and clear load
from existing flows, most likely because many existing flows are not
sufficiently responsive to congestion, so retransmissions dominate
over goodput (even if each unresponsive flow is in an isolated silo).
Flow separation doesn't help when the problem is too many flows.
b) Flow fairness (or user-fairness etc): this is a policy issue that
needs to be built in a modular way, for optional addition to AQM.
Therefore an AQM must also work well without fairness mechanisms.
This conclusion was actually reached in the early sections, but it's
not carried forward into the recommendations in section 4.
If the conclusion is that AQM isn't intended to solve these two
problems, we need to clearly say so. Most people who need to read
this will be confused, so we shouldn't confuse them further!
2) There's no statement of scope.
Can we really make all these recommendations irrespective of whether
we're talking about high stat-mux core links, low stat-mux access
links, low-stat-mux data centre links, or host buffers? Are there
different recommendations for edge links (on trust boundaries) vs
interior links? Does AQM apply at L2 as well as L3 (of course it
does)? Which recommendations are different for each layer? Does AQM
apply for middleboxes (firewalls, NATs etc) as much as for switches
and routers? If not why not (only need AQM if there can be queuing -
perhaps due to processor overload)?
To illustrate the problem, our goal should be AQM in every buffer.
But we really don't need and shouldn't have policing or isolation in
every buffer.
4) Because sections 1,2,3 focused heavily on the above two problems
(collapse and fairness) that can't really be addressed by AQM, these
sections also gave insufficient attention to problems that AQM does
address (and should address), E.g.:
* synchronisation and lock-out were both described as vaguely the
same problem,
* synchronisation wasn't explained,
* lock-out wasn't explained but it was said to be vaguely to do with
synchronisation and solving it would help low capacity bursty flows,
* large-packet lock-out problems weren't mentioned, only flow-level lock-out.
Perhaps as a result, there's no recommendation on avoiding
synchronisation (e.g. using randomness).
5) I said these are the MSB's only, but allow me one nit about the Intro:
" there is currently no consensus solution to controlling the
congestion caused by such aggressive flows; significant research and
engineering will be required before any solution will be available.
It is imperative that this work be energetically pursued, to ensure
the future stability of the Internet.
"
The draft could at least mention congestion policing and ConEx RFCs
coming out of the IETF right now (e.g. RFC6789 and
draft-ietf-conex-abstract-mech, which is with the IESG).
I promise I'll do a proper detailed review of the new text ASAP.
Bob
At 13:13 15/05/2014, Wesley Eddy wrote:
On 5/15/2014 5:09 AM, Bob Briscoe wrote:
> Wes,
>
> I assume you also want comments on the new version. Is there a deadline
> for comments?
Absolutely, yes. There's no "deadline" at the moment, but it would
be good to get any out sooner rather than later, especially if they're
likely to need more discussion or are asking for major changes.
> I prepared comments on the previous version, but didn't get the time to
> type them up. So I want to try to remedy this with the new version (that
> I haven't read yet).
The diffs aren't huge, so many of your comments on the previous
revision might still be valid.
--
Wes Eddy
MTI Systems
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
