I still don't support wglc. a) Nit: "Network Working Group"?
b) I have given up on using the term "AQM" to describe anything other than Active Queue "Length" Management algorithms. What I wrote about "SQM" is mostly outside the scope of the AQM guidelines document, but it's here: http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management but I can live with the broad definition as used in this document. c) I also don't just mean "fair or flow queuing" when I say packet scheduling, we've identified an elephant in the room as is actually rate limiting (tbf, htb), or hybrid rate limiting/scheduling (hfsc), or powerboost style rate limiting/expansion.... Moving on: d) "The traditional technique for managing the queue length in a network device is to set a maximum length (in terms of packets)" - well, bytes is common on many devices like dlsams and cmts and modems... substitute: packets or bytes e) " 2. Provide a lower-delay interactive service" I tend to regard dns traffic also as rather significant and telnet is rather obsolete. ssh. f) "3. Non-TCP-friendly Transport Protocols" There's also the problem of DDOS attacks. g) "Another topic requiring consideration is the appropriate granularity of a "flow" when considering a queue management method. There are a few "natural" answers: 1) a transport (e.g. TCP or UDP) flow (source address/port, destination address/port, Differentiated Services Code Point - DSCP); 2) a source/destination host pair (IP addresses, DSCP); 3) a given source host or a given destination host. We suggest that the source/destination host pair gives the most appropriate granularity in many circumstances. " I don't suggest the last, as I have no data that backs it up. and my request to include a 5 tuple address/port destination address/port and protocol isn't in here, although the MF classifier is mentioned later on in section 4.4. Elsewhere (in webrtc) there is an assumption that the 5 tuple is addr/port daddr/dport protocol. I don't actually think doing a 5 tuple including the dscp rather than the protocol is a very good idea given the amount of misclassified flows I see transiting site boundries. I do think moving out dscp flows into their own queues and then 5 tupling with protocol is not a bad idea. As for the final recomendations: h) " 4. AQM algorithms SHOULD respond to measured congestion, not application profiles." I'm not sure if this precludes active classification and optimization measures? http://www.smallnetbuilder.com/lanwan/lanwan-features/32297-does-qualcomms-streamboost-really-work " Not all applications transmit packets of the same size. Although applications may be characterized by particular profiles of packet size this should not be used as the basis for AQM (see next section)." >From a packet scheduling perspective I strongly support using some differentiation based on packet size at low bandwidths. 300 bytes works well. for AQM, don't care, just care about latency no matter if it comes from a pps problem or a packet size problem. I didn't mind pie's increasing probability of a drop based on packet size (Which so far as I know is still in cablemodem pie, and: it helps on competing voip traffic) i) 4.5 might want to also mention more modern protocols like uTP and QUIC " In 2013, an obvious example of further research is the need to consider the use of Map/Reduce applications in data centers; do we need to extend our taxonomy of TCP/SCTP sessions to include not only "mice" and "elephants", but "lemmings". "Lemmings" are flash crowds of "mice" that the network inadvertently try to signal to as if they were elephant flows, resulting in head of line blocking in data center applications." I like to talk about ANTS. Can suggest some language if you want. On Wed, Apr 9, 2014 at 8:35 AM, Wesley Eddy <[email protected]> wrote: > We didn't receive any comments yet on the updated recommendations > draft, which we were trying to have a working group last call on > per Richard's email to the list on 3/5. > > Since we think people might not have noticed the last call, we're > re-announcing it. > > In the next two weeks, please review this document: > > https://datatracker.ietf.org/doc/draft-ietf-aqm-recommenda > tion/ > > and relay any comments, questions, corrections, words of support, > etc. to this AQM mailing list. > > Thanks for your help in finishing this document! > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
