Gorry,
At 16:55 15/05/2014, go...@erg.abdn.ac.uk wrote:
Great, I look forward to comments on the actual text. I agree the front
part needs more structure and more topics called out. i started adding
that in -04 and would be pleased to add a few more subsections if we get
agreement.
I'll wait until I see comments before looking at updating the text with Fred.
Gorry
> 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.
>
That would seem OK to call-out, at least to me.
My concern is that it's wrong to introduce a doc with a description
of a problem that we're not addressing in the body of the doc (even
tho collapse is an important problem, AQM doesn't address it, so why
is it even relevant at all?). E.g. we could also add world hunger to
the introduction, but it wouldn't be relevant.
> 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!
>
OK - as long as we get agreement from the various AQM proposals, some
methods rely heavily on flow isolation to achieve their wanted behaviour.
Indeed, my point about fairness is different from my point about
collapse (which just isn't even relevant). Fairness isn't strictly
relevant to AQM, but flow isolation is used to complement AQMs. And
flow isolation (which the doc calls 'scheduling') can't be done
without affecting fairness.
So 2.1 concludes:
" In short, scheduling algorithms and queue management should be seen
as complementary, not as replacements for each other.
"
This is a conclusion that should be reflected in the recommendations
and conclusions. I.e. if they are complements, they need to be
separable, not integrated. Because scheduling requires policy and AQM
doesn't. So operators don't want to have to face the dilemma of
needing the AQM part, but not being able to have it because they
don't want the policy implicit in the scheduling part.
This is critical for fq_codel, because apparently CoDel alone is not
recommended (which I would agree with). This means that we really
need fq_X, where X is something that can be recommended either alone
or with fq.
>
> 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.
>
Hmmm... that will be interesting - suggest a para or two please?
I'll try - but I'm having to write an ETSI doc at the mo (which is
why I'm preferring to get distracted by AQM :)
> 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,
yes, agree completely should be added as a subsection in section 2 - This
was overlooked.
> * 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,
Comment on bullet 3 in Sect 2.
> * large-packet lock-out problems weren't mentioned, only flow-level
> lock-out.
>
OK - suggest a line or two of text please:-)
Will do.
> Perhaps as a result, there's no recommendation on avoiding
> synchronisation (e.g. using randomness).
>
There should be.
> 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.
Cheers
Bob
>
>
> 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
>
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
