I'm forwarding this with Bob's permission, as a response to the edits he requested in WGLC. I shall incorporate changes in the revision we are now preparing (-07).
Gorry > > At 14:37 23/07/2014, [email protected] wrote: >>Thanks for the careful read. These are all OK. I'll add them to rev -07 >>within a week or so. >> >>I'd like to take these as proposed resolutions to the WGLC comments. With >>this in mind, can I copy this email to the list Bob? >> >>Gorry >> >> > Gorry, Fred, >> > >> > Thank you v much for the new intro. You've done a great job. >> > Now that it's not tied to the structure of 2309, it is much much >> > easier to understand. >> > >> > Below are nitty things I've noticed in the new introductory sections >> > (up to section 3). Nothing controversial. I haven't cc'd to list, so >> > you can choose to ignore these (given WG last call has passed), but >> > you'll probably want to fix them - I've suggested text in each case. >> > >> > 1. Intro >> > s/for a variety traffic of traffic/ >> > /for a variety of traffic/ >> > >> > s/ In the current Internet and low latency/ >> > / In the current Internet low latency/ >> > >> > Section 1.1 >> > "congestion signals (i.e., marked or dropped packets) " >> > The concept of ECN marking has not been introduced yet. How about: >> > "congestion signals (i.e., packets that are dropped or >> > marked with explicit congestion notification [RFC3168]) >> > >> > Section 2. >> > s/ The solution to the full-queues problem is for network >> > devices to drop packets before a queue becomes full,/ >> > /The solution to the full-queues problem is for network >> > devices to drop or ECN-mark packets before a queue becomes full,/ >> > >> > s/By dropping packets before buffers overflow, >> > AQM allows network devices to control when and how many packets to >> > drop./ >> > /By dropping or ECN-marking packets before buffers overflow, >> > AQM allows network devices to control when and how many packets to >> > drop./ >> > >> > Section 2.1 >> > " AQM >> > mechanisms need to control the overall queue sizes, to ensure that >> > arriving bursts can be accommodated without dropping packets. AQM >> > should also be used to control the queue size for each individual >> > flow or class, >> > " >> > s/AQM mechanisms need to control the overall/ >> > /AQM mechanisms might need to control the overall/ >> > >> > Rationale: >> > This implies AQM is needed for the overall queue, and for each >> > individual class. Is the former actually known to be true? If not, I >> > don't believe this should be stated with such certainty. >> > >>Fred are you OK with this? >> >> > Section 3. >> > " It is convenient to divide flows into three classes: (1) TCP >> Friendly >> > flows, (2) unresponsive flows, i.e., flows that do not slow down >> when >> > congestion occurs, and (3) flows that are responsive but are not >> TCP- >> > friendly. >> > " >> > The names of the 3 categories and their later definitions could be >> > understood by the reader as points on the spectrum, not the regions >> > between the points. >> > The subsequent section headings need to be disambiguated too. >> > >> > "congestive collapse [RFC2309]." >> > You're referring to an RFC that you are obsoleting! >> > >> > s/congestion control in the application [RFC5405]./ >> > /congestion control in the application [RFC5405], [RFC6679]. >> > >> > s/granugranularity/ >> > /granularity/ >> > >> > I'd like to suggest an item 5) for the list of granularities: >> > 5) a class per site (enterprise or residential). >> > We never use a granularity lower than this as a carrier, other than >> > in the home gateway. >> > >>I'd also be Ok with this. >> >> > But this last one is probably beyond a nit, so you can ignore it at >> this >> > stage. >> > >> > >> > That's it. HTH >> > >> > >> > >> > Bob >> > >>Gorry >> >> > At 10:58 02/07/2014, Gorry Fairhurst wrote: >> >>To keep things clear, we published a new revision of the AQM >> >>recommendations (-06) after the conference call for which Richard sent >> >> notes. >> >> >> >>Our hope is that this provides a firm basis for any further >> >>discussion. The editors are asking the group to read this and note any >> >> errors. >> >> >> >>There remains some on-going discussion about whether this now should >> >>move RFC2309 to Historic, or not. This issue needs to be resolved >> >>before we finalize the introduction. Let's hope we can conclude this >> >> soon. >> >> >> >>Best wishes, >> >> >> >>Gorry >> >> >> >> >> >> >> >>On 01/07/2014 10:15, [email protected] wrote: >> >>> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>>directories. >> >>> This draft is a work item of the Active Queue Management and >> >>> Packet Scheduling Working Group of the IETF. >> >>> >> >>> Title : IETF Recommendations Regarding Active >> >>> Queue Management >> >>> Authors : Fred Baker >> >>> Godred Fairhurst >> >>> Filename : draft-ietf-aqm-recommendation-06.txt >> >>> Pages : 27 >> >>> Date : 2014-07-01 >> >>> >> >>>Abstract: >> >>> This memo presents recommendations to the Internet community >> >>> concerning measures to improve and preserve Internet >> performance. >> >>> It >> >>> presents a strong recommendation for testing, standardization, >> and >> >>> widespread deployment of active queue management (AQM) in >> network >> >>> devices, to improve the performance of today's Internet. It >> also >> >>> urges a concerted effort of research, measurement, and ultimate >> >>> deployment of AQM mechanisms to protect the Internet from flows >> >>> that >> >>> are not sufficiently responsive to congestion notification. >> >>> >> >>> The note largely repeats the recommendations of RFC 2309, >> updated >> >>> after fifteen years of experience and new research. >> >>> >> >>> >> >>>The IETF datatracker status page for this draft is: >> >>>https://datatracker.ietf.org/doc/draft-ietf-aqm-recommendation/ >> >>> >> >>>There's also a htmlized version available at: >> >>>http://tools.ietf.org/html/draft-ietf-aqm-recommendation-06 >> >>> >> >>>A diff from the previous version is available at: >> >>>http://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-recommendation-06 >> >>> >> >>> >> >>>Please note that it may take a couple of minutes from the time of >> >>> submission >> >>>until the htmlized version and diff are available at tools.ietf.org. >> >>> >> >>>Internet-Drafts are also available by anonymous FTP at: >> >>>ftp://ftp.ietf.org/internet-drafts/ >> >>> >> >>>_______________________________________________ >> >>>aqm mailing list >> >>>[email protected] >> >>>https://www.ietf.org/mailman/listinfo/aqm >> >> >> >>_______________________________________________ >> >>aqm mailing list >> >>[email protected] >> >>https://www.ietf.org/mailman/listinfo/aqm >> > >> > ________________________________________________________________ >> > Bob Briscoe, BT >> > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
