I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.
The Last Call notes that comments should be sent by today. I do note that a
new -03 version was posted 10-12. That version seems to have updated only the
references and abstract. I reviewed the -03 version.
This draft draft-ietf-aqm-fq-implementation-03 is a discussion of types of
queuing algorithms and queue management algorithms and implementation
possibilities. Besides the categorization and discussion, I think a major
contribution is the statement in the conclusion:
There is value in implementing and coupling the operation of both
queuing algorithms and queue management algorithms, and there is
definitely interesting research in this area, but specifications,
measurements, and comparisons should decouple the different
algorithms and their contributions to system behavior.
Looking at the draft history, it has seen little change since the -00 version.
The wg seems to have been blessed with consensus early.
I see no security concerns from such a discussion and categorization.
The security considerations section says:
This memo adds no new security issues; it observes on implementation
strategies for Diffserv implementation.
I believe that.
I had wondered if the discussion of algorithm types would consider if there
were any denial of service opportunities with the algorithm types or
implementation strategies. I can’t say that I see any myself - any deliberate
attempt to exploit a queuing algorithm or queue management algorithm would
require complete knowledge of the implementation and competing flow
characteristics, so I’m not concerned or surprised to see no discussion here.
I did not consult the other AQM wg drafts or RFCs referenced, but I do not
believe that affects my review.
Nits:
section 2.2.2 page 6:
If the system is intended to maintain a
byte rate, there will be memory between searches of the excess
previously dequeued.
I am not sure what this means -- “there will be memory”?? “excess previously
dequeued”??
section 2.2.4 page 9
per-round quantum and incremental quantum - these are the same, right? if so,
could that be made clear?
The weakness of a WRR approach - WWR is not defined anywhere. Maybe a typo for
DRR?
section 3 page 10:
host transports interpret drops as signals - I presume you mean host transport
protocols [or protocol implementations]. Do transport protocols other than TCP
use drops as signals? If not, why not just say TCP. I don’t think that a drop
of a UDP packet sends a signal, for example. But I expect there could be other
such transport protocols, as my knowledge of anything but TCP/UDP and some SCTP
is scant.
It is useful to think of the effects of queuing as a signal as well.
The receiver sends acknowledgements as data is received, so the
arrival of acknowledgements at the sender paces the sender at
approximately the average rate it is able to achieve through the
network.
speaking of UDP - I don’t think you can make this statement about UDP. Can you?
section 3.1 page 11 (and 3.2 page 11 and 3.3 page 12)
o Ack Clocking, pacing the sender to send at approximately the rate
it can deliver data to the receiver, and
“it” here is the queue, or maybe the network path, not the sender. right?
because the sender does not deliver data, it transmits data. by usual grammar
rules “it” would be the sender.
—Sandy
signature.asc
Description: Message signed with OpenPGP using GPGMail