Section, paragraph (page)
======= ========= ====
4 para 1 (p10)
The IRTF, in publishing [RFC2309], and the IETF in subsequent
discussion, has developed a set of specific recommendations regarding
the implementation and operational use of AQM procedures. This
document updates these to include
As we have a list that is immediately followed by the same list in an
expanded form, I'd suggest a few words to tell the reader what they're
going to see. I'd end the paragraph with "some seven additional
considerations, expanded upon starting in section 4.1
4, last para (p11)
However, care should be taken in concluding that one's use case
falls in that category;
Actually this would be stronger if it was the conclusion of the previous
sentence. I'd suggest the sentence start with "Therefore"
4.1, para 1 (p11)
AQM procedures are designed to minimize delay induced in the network by
queues that have filled as a result of host behavior.
It's also true hat we're trying to prevent buffer overflow, so I'd
suggest changing "delay" to "delay and buffer exhaustion", to make the
argument for AQM a stronger one.
4.2, para 5 (p12)
To be conservative transport must the latter."
I think "assume" may be missing here.
4.5, para 3
AQM algorithms SHOULD NOT target or derive implicit assumptions about
the characteristics desired by specific transports/applications.
Transports and applications need to respond to the congestion signals
provided by AQM (i.e. dropping or ECN-marking) in a timely manner
(within a few RTT at the latest).
This reads like it should be the introductory paragraph of section 4.6, so
I'd move it there.
4.6 para 3, now 4, (p 15)
A common objective is to deliver data from its source end point to
its destination in the least possible time. When speaking of TCP
performance, the terms "knee" and "cliff" area defined by [Jain94].
They respectively refer to the minimum congestion window that
maximises throughput and the maximum congestion window that avoids
loss. An application that transmits at the rate determined by this
window has the effect of maximizing the rate or throughput. For the
sender, exceeding the cliff is ineffective, as it (by definition)
induces loss; operating at a point close to the cliff has a negative
impact on other traffic and applications, triggering operator
activities, such as those discussed in [RFC6057]. Operating below
the knee reduces the throughput, since the sender fails to use
available network capacity. As a result, the behavior of any elastic
transport congestion control algorithm designed to minimise delivery
time should seek to use an effective window at or above the knee and
well below the cliff.
This is not the case where one has a congestion control mechanism, and
it's inconsistent with Jain's later works or a modern understanding
of queues. The knee is a region, between a gentle increase in latency
with increasing throughput and the cliff, or the "handle of the hockey
stick"
to use modern terminology. He was using "knee" as the first upturn, and
"cliff" as the completion of the upturn.
Speaking of TCP only, one wants to run up to the point at which one sees
congestion,
then back off, exactly what we try to do.
I'd therefor say something like
Common objectives of TCP/IP are deliver the maximum amount of data
without inducing queuing delays when packets sit in a buffer waiting
to be sent on. It is important to stay below the inflection point
(bend) in the load/delay curve, which is shaped like a hockey-
stick, "_/". Above the bend, congestion exists, delay rises without bound
and TCP starts dropping packets due to the congestion.
Approaching the bend, delay starts to rise due to congestion, caused
by packets probabalistically arriving at overlapping times. Near-
maximum throughput and low latency are both achieved quite close to the
knee, so it is desirable to send at as rapid a rate as can be done without
causing congestion.
Choice of an appropriate rate can therfore significantly impact the loss and
delay experienced not only by a flow, but by other flows that share the same
queue.
This stays away from the possibly fuzzy language and calls out the
packet drop as
something that a queue modeler will recognize as non-standard.
Finally, in 6, I'd suggest that a DOS atatck "may probably be disguised
as" rather than "may create"
unresponsive flows that may be indistinguishable from normal
unresponseive ones.
End of third day: comments, suggestions and brickbats cordially accepted!
--dave
[If anyone would prefer this as amendments to an editable format, I have
it in a doc file
at https://github.com/davecb/draft-ietf-aqm-recommendation-edits]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
