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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail