Byte and Packet Congestion Notification
draft-ietf-tsvwg-byte-pkt-congest-12

[Ballot comment]
No objection once there's a rev that includes bobs proposed changes.

Outside of the general precept of don't implement AQM with byte drop mode with which I whole heartedly endorse;

I have concerns whether sections 3.2 and 4.2.3 constitute advice, or best practice.

4.2.3 makes no mention at all of UDP cases.

...

  Although there are no known proposals, it would also be possible and
  perfectly valid to make control packets robust against drop by
  explicitly requesting a lower drop probability using their Diffserv
  code point [RFC2474] to request a scheduling class with lower drop.

two points:

1. If you do this with a flow with a mix of control and flow packets you can helpfully introduce more reordering than normal in forwarding devices that use the dscp bits as an additional source of entropy by hashing different packets from the same flow onto links of the same cost but unequal lengths (or across linecards). (why you can safely use those bits as a source of entropy in your own network comes up in point 2)

2. it is common to to point ubiquity to reset dscp bits at administrative boundaries for sanitary purposes. because different operators treat traffic differently, because wireless operators do in fact prioritize tcp connection setup or dns queries over other parts of  flows, to ameliorate number 1 and so on. So... doesn't work on the internet is probably a bit of an issue.

the reference:

no longer exists so a stable reference needs to be found

  [DupTCP]                  Wischik, D., "Short messages", Royal
                              Society workshop on networks: modelling
                              and control , September 2007, .

http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html

Error 404

Not found - file doesn't exist or is read protected [even tried multi]

This user URL no longer exists. The user has either left UCL-CS or changed name or user-class, or the home filestore is offline.

It is cited a rational for:

  Although not brought to the IETF, a simple proposal from Wischik
  [DupTCP] suggests that the first three packets of every TCP flow
  should be routinely duplicated after a short delay.  It shows that
  this would greatly improve the chances of short flows completing
  quickly, but it would hardly increase traffic levels on the Internet,
  because Internet bytes have always been concentrated in the large
  flows.  It further shows that the performance of many typical
  applications depends on completion of long serial chains of short
  messages.  It argues that, given most of the value people get from
  the Internet is concentrated within short flows, this simple
  expedient would greatly increase the value of the best efforts
  Internet at minimal cost.

Which sounds like a not insignificant change to tcp notwithstanding that duplicate packet handling works just fine in general? I assume unless I'm misreading it, that they're referring to the first three packets after the handshake and not the handshake itself.

[Ballot discuss]
This is a DISCUSS-DISCUSS, i.e. a discussion between the IESG members.
The authors don't need to take any action at this point in time.

Clarification question: what is the connection between this draft and the AQM WG?
AQM is supposed to obsolete RFC 2309, and at the same time, this document updates RFC 2309.

I see that draft-ietf-aqm-recommendation normatively references draft-ietf-tsvwg-byte-pkt-congest
So should this document (at least section 2, the recommendations) be part of draft-ietf-aqm-recommendation?
To add to the/my confusion, the document abstract speaks about Codel and PIE, which, IIRC, are the two protocols discussed in AQM.

What will be the situation when draft-ietf-aqm-recommendation will be a RFC?
This RFC will obsolete RFC 2309, and reference (or maybe obsolete) draft-ietf-tsvwg-byte-pkt-congest, which in turn will update RFC 2309.
How do you see this working? Is this an issue? I would like to discuss this with responsible AD during the IESG telechat. Hence my DISCUSS-DISCUSS.

One proposal is that draft-ietf-aqm-recommendation copies the recommendations from draft-ietf-tsvwg-byte-pkt-congest (btw, it does that with the current version), and that it references the draft-ietf-tsvwg-byte-pkt-congest, which justifies the recommendations. An informational reference would be good enough, and would avoid some confusion... I guess.

A (cleaner) alternative is for draft-ietf-tsvwg-byte-pkt-congest to be a companion document to draft-ietf-aqm-recommendation, in the AQM WG.
Advantage: it doesn't update RFC 2309.
Drawback: some extra delay.

[Ballot comment]
No sure what "strongly deprecated" means.

      For the specific case of RED, this means that byte-mode queue
      measurement will often be appropriate although byte-mode drop is
      strongly deprecated.

[Ballot comment]
Please do address Barry's comments.

Administrivia: Sounds to me like this document should be part of BCP 41 so that all of this information is in the same place. An RFC Editor note should be added to let the RFC Editor know that.

[Ballot comment]

Just a few nits. Interesting read.

intro: the "long term goal" isn't stated, I took you to
mean "following this BCP's main recommendations" but it
could be something else too, as written.

intro: I don't get what it'd mean for TCP congestion
control to scale with packet size (or not). Seems like
an odd phrase here unless you're saying that TCP
congestion control runs into bigger and bigger issues as
packet size increases to infinity or something which
might be equally odd.

intro: is non-negligible right to describe the material
you then tell me the busy reader can safely neglect to
read? (Total nit, sorry;-)

[Ballot comment]
Two small points that you don't need to discuss with me.

---

I think the RFC Editor will have indigestion with your acronym soup.
You might want to have a go at that before they have to ask you to.

---

Appendix A

  Routers using a memory architecture based on fixed size buffers with
  borrowing may also still be prevalent in the Internet.

I don't find that statement very helpful. Of course, it is true. But a
little more science or substantiation might help.

[Ballot comment]
Outside of the general precept of don't implement AQM with byte drop mode with which I whole heartedly endorse;

I have concerns whether sections 3.2 and 4.2.3 constitute advice, or best practice.

4.2.3 makes no mention at all of UDP cases.

...

  Although there are no known proposals, it would also be possible and
  perfectly valid to make control packets robust against drop by
  explicitly requesting a lower drop probability using their Diffserv
  code point [RFC2474] to request a scheduling class with lower drop.

two points:

1. If you do this with a flow with a mix of control and flow packets you can helpfully introduce more reordering than normal in forwarding devices that use the dscp bits as an additional source of entropy by hashing different packets from the same flow onto links of the same cost but unequal lengths (or across linecards). (why you can safely use those bits as a source of entropy in your own network comes up in point 2)

2. it is common to to point ubiquity to reset dscp bits at administrative boundaries for sanitary purposes. because different operators treat traffic differently, because wireless operators do in fact prioritize tcp connection setup or dns queries over other parts of  flows, to ameliorate number 1 and so on. So... doesn't work on the internet is probably a bit of an issue.

the reference:

no longer exists so a stable reference needs to be found

  [DupTCP]                  Wischik, D., "Short messages", Royal
                              Society workshop on networks: modelling
                              and control , September 2007, .

http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html

Error 404

Not found - file doesn't exist or is read protected [even tried multi]

This user URL no longer exists. The user has either left UCL-CS or changed name or user-class, or the home filestore is offline.

It is cited a rational for:

  Although not brought to the IETF, a simple proposal from Wischik
  [DupTCP] suggests that the first three packets of every TCP flow
  should be routinely duplicated after a short delay.  It shows that
  this would greatly improve the chances of short flows completing
  quickly, but it would hardly increase traffic levels on the Internet,
  because Internet bytes have always been concentrated in the large
  flows.  It further shows that the performance of many typical
  applications depends on completion of long serial chains of short
  messages.  It argues that, given most of the value people get from
  the Internet is concentrated within short flows, this simple
  expedient would greatly increase the value of the best efforts
  Internet at minimal cost.

Which sounds like a not insignificant change to tcp notwithstanding that duplicate packet handling works just fine in general? I assume unless I'm misreading it, that they're referring to the first three packets after the handshake and not the handshake itself.

[Ballot comment]
I have a few non-blocking comments that I'd like you to consider.  The first few are more important, and please feel free to chat with me about them:

-- Section 2.1 --

  In this case, if the resource is bit-congestible, the AQM
  implementation SHOULD measure the length of the queue in bytes and,
  if the resource is packet-congestible, the implementation SHOULD
  measure the length of the queue in packets.  No other choice makes
  sense, because the number of packets waiting in the queue isn't
  relevant if the resource gets congested by bytes and vice versa.  For
  example, the length of the queue into a transmission line would be
  measured in bytes, while the length of the queue into a firewall
  would be measured in packets.

If no other choice makes sense, under what conditions might there be a reason to do otherwise (with respect to the SHOULDs)?  In other words, why are these not "MUST"?

  To avoid the pathological effects of drop tail, the AQM can then

This non-transport guy doesn't know what a "drop tail" is.  Is it worth having the document say what it is, or is it a common enough term of art that we can say "It's just me," and never mind?

  Exceptions to these recommendations MAY be necessary

This should not be a 2119 "MAY"; please make it "may" (or "might", to avoid the question).

-- Section 8 --

  o  When network equipment measures the length of a queue, if it is
      not feasible to use time it is recommended to count in bytes if
      the network resource is congested by bytes, or to count in packets
      if is congested by packets.

I find that sentence to be very hard to read.  In particular, I had trouble parsing "to use time it is recommended to count".  I suggest this, tweaked if this isn't exactly what you mean:

NEW
  o  When network equipment measures the length of a queue, if it is
      not feasible to measure the time in queue, it is recommended to
      measure the byte count if the network resource is congested by
      bytes, or to measure the packet count if it is congested by packets.
END

Or perhaps this is even clearer?:

NEW
  o  When network equipment measures the length of a queue, it is
      best to measure the time in queue.  If that is not feasible,
      it is recommended to measure the byte count (if the network
      resource is congested by bytes) or the packet count (if the
      resource is congested by packets).
END

-------------------------------

The rest of the comments are very minor, so please consider them, but there's no need to respond about them:

-- Section 1 --

  This document provides recommendations of best current practice for
  how we should correctly scale congestion control functions with
  respect to packet size for the long term.  It also recognises that
  expediency may be necessary to deal with existing widely deployed
  protocols that don't live up to the long term goal.

What does that second sentence mean?  What, exactly, may be necessary?  What widely deployed protocols are involved here?  Or is this theoretical?

-- Section 3 --

  This section is informative.  It justifies the recommendations given
  in the previous section.

May I suggest, "It further explains", rather than, "It justifies" ?

-- Section 3.1 --

  Imagine a scenario where the same bit rate of packets will contribute
  the same to bit-congestion of a link irrespective of whether it is
  sent as fewer larger packets or more smaller packets.

The antecedent of "it" is unclear, and appears to be the link.  I think you want, "...of whether the data is sent as...."  Of course, if you prefer "the data are", feel free.

-- Section 3.3 --

  However, in order to do this, the
  queuing algorithm has to make assumptions about the transport, which
  become embedded in the network.

May I suggest, "However, in order to do this, the queuing algorithm has to make assumptions about the transport, and those assumptions become embedded in the network." ?

-- Section 4 --

  The rest of this section is structured accordingly.

Srsly?  I suggest dropping that paragraph.

-- Section 4.2.4 --

In Table 2, it's not immediately clear to the eye where the row separation is in the first column.  The word "or" is the clue, but I suggest adding another blank line, or maybe a line of "-----".

I also suggest saying "Table 2 summarises", rather than "Table 2 aims to summarise"... unless you really do think it has failed.  :-)

-- Section 8 --

  o  When network equipment decides whether to drop (or mark) a packet,
      it is recommended that the size of the particular packet should
      not be taken into account

I think "should not be part of the decision" is better.

  At the transport layer the IETF should continue updating congestion
  control protocols to take account of the size of each packet that
  indicates congestion.

Does this mean "each packet that has been marked"?  Should it be said that way instead?

[Ballot comment]
I have a few non-blocking comments that I'd like you to consider.  The first few are more important, and please feel free to char with me about them:

-- Section 2.1 --

  In this case, if the resource is bit-congestible, the AQM
  implementation SHOULD measure the length of the queue in bytes and,
  if the resource is packet-congestible, the implementation SHOULD
  measure the length of the queue in packets.  No other choice makes
  sense, because the number of packets waiting in the queue isn't
  relevant if the resource gets congested by bytes and vice versa.  For
  example, the length of the queue into a transmission line would be
  measured in bytes, while the length of the queue into a firewall
  would be measured in packets.

If no other choice makes sense, under what conditions might there be a reason to do otherwise (with respect to the SHOULDs)?  In other words, why are these not "MUST"?

  To avoid the pathological effects of drop tail, the AQM can then

This non-transport guy doesn't know what a "drop tail" is.  Is it worth having the document say what it is, or is it a common enough term of art that we can say "It's just me," and never mind?

  Exceptions to these recommendations MAY be necessary

This should not be a 2119 "MAY"; please make it "may" (or "might", to avoid the question).

-- Section 8 --

  o  When network equipment measures the length of a queue, if it is
      not feasible to use time it is recommended to count in bytes if
      the network resource is congested by bytes, or to count in packets
      if is congested by packets.

I find that sentence to be very hard to read.  In particular, I had trouble parsing "to use time it is recommended to count".  I suggest this, tweaked if this isn't exactly what you mean:

NEW
  o  When network equipment measures the length of a queue, if it is
      not feasible to measure the time in queue, it is recommended to
      measure the byte count if the network resource is congested by
      bytes, or to measure the packet count if it is congested by packets.
END

Or perhaps this is even clearer?:

NEW
  o  When network equipment measures the length of a queue, it is
      best to measure the time in queue.  If that is not feasible,
      it is recommended to measure the byte count (if the network
      resource is congested by bytes) or the packet count (if the
      resource is congested by packets).
END

-------------------------------

The rest of the comments are very minor, so please consider them, but there's no need to respond about them:

-- Section 1 --

  This document provides recommendations of best current practice for
  how we should correctly scale congestion control functions with
  respect to packet size for the long term.  It also recognises that
  expediency may be necessary to deal with existing widely deployed
  protocols that don't live up to the long term goal.

What does that second sentence mean?  What, exactly, may be necessary?  What widely deployed protocols are involved here?  Or is this theoretical?

-- Section 3 --

  This section is informative.  It justifies the recommendations given
  in the previous section.

May I suggest, "It further explains", rather than, "It justifies" ?

-- Section 3.1 --

  Imagine a scenario where the same bit rate of packets will contribute
  the same to bit-congestion of a link irrespective of whether it is
  sent as fewer larger packets or more smaller packets.

The antecedent of "it" is unclear, and appears to be the link.  I think you want, "...of whether the data is sent as...."  Of course, if you prefer "the data are", feel free.

-- Section 3.3 --

  However, in order to do this, the
  queuing algorithm has to make assumptions about the transport, which
  become embedded in the network.

May I suggest, "However, in order to do this, the queuing algorithm has to make assumptions about the transport, and those assumptions become embedded in the network." ?

-- Section 4 --

  The rest of this section is structured accordingly.

Srsly?  I suggest dropping that paragraph.

-- Section 4.2.4 --

In Table 2, it's not immediately clear to the eye where the row separation is in the first column.  The word "or" is the clue, but I suggest adding another blank line, or maybe a line of "-----".

I also suggest saying "Table 2 summarises", rather than "Table 2 aims to summarise"... unless you really do think it has failed.  :-)

-- Section 8 --

  o  When network equipment decides whether to drop (or mark) a packet,
      it is recommended that the size of the particular packet should
      not be taken into account

I think "should not be part of the decision" is better.

  At the transport layer the IETF should continue updating congestion
  control protocols to take account of the size of each packet that
  indicates congestion.

Does this mean "each packet that has been marked"?  Should it be said that way instead?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-byte-pkt-congest-11, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.  IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Byte and Packet Congestion Notification) to Best Current Practice


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Byte and Packet Congestion Notification'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides recommendations of best current practice for
  dropping or marking packets using any active queue management (AQM)
  algorithm, including random early detection (RED), BLUE, pre-
  congestion notification (PCN) and newer schemes such as CoDel and
  PIE.  We give three strong recommendations: (1) packet size should be
  taken into account when transports detect and respond to congestion
  indications, (2) packet size should not be taken into account when
  network equipment creates congestion signals (marking, dropping), and
  therefore (3) in the specific case of RED, the byte-mode packet drop
  variant that drops fewer small packets should not be used.  This memo
  updates RFC 2309 to deprecate deliberate preferential treatment of
  small packets in AQM algorithms.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This document is intended as BCP. (This was discussed at IETF-81 and that
the status changed from Informational to BCP, because the draft provides
guidance to implementors and people configuring routers and hosts). The
BCP status was confirmed on the tsvwg list prior to resubmission to the
IESG, only one comment was noted requesting informational status.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document provides recommendations of best current practice for
dropping or marking packets using any active queue management (AQM)
algorithm, including random early detection (RED), BLUE, pre-
congestion notification (PCN) and newer schemes such as CoDel and
PIE. We give three strong recommendations: (1) packet size should be
taken into account when transports detect and respond to congestion
indications, (2) packet size should not be taken into account when
network equipment creates congestion signals (marking, dropping), and
therefore (3) in the specific case of RED, the byte-mode packet drop
variant that drops fewer small packets should not be used. This memo
updates RFC 2309 to deprecate deliberate preferential treatment of
small packets in AQM algorithms.

Working Group Summary

There was consensus to publish this as a WG document and agreement at
IETF-82 that the document was now complete. Since then there have been a
number of revisions to address WG feedback.

Document Quality

Annexe A summarises a survey by the original authors showing deployment of
the techniques by router vendors. The recommendations are thought to be in
line with that of IETF groups, such as TSVWG, TCPM, PCN, and are
considered good advice for use in the general Internet.

Personnel Who is the Document Shepherd? Who is the Responsible Area
Director?

I am the document shepherd, G Fairhurst.
The responsible AD is Martin Stiemerling

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document was presented at IEWTF-82 (Taipei), with a request for WGLC.

The first WGLC concluded with some discussion and suggested changes on
Friday 30th March 2012. The changes were discussed on the list, and have
been implemented in a revised draft. Major edits were applied to correct
comments after the document left the WG. Comments were received from 8
people after this document were returned to the WG. The changes were
confirmed in a WG draft, draft-ietf-tsvwg-byte-pkt-congest-11, with a
WGLC ending on 19th August 2013. This WGLC concluded with no additional
comments.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This has already completed one IESG review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-byte-pkt-congest.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The document has WG support and there is consensus to publish.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

One update is listed, RFC 2309, informational - replaced by this BCP.
It deprecates deliberate preferential treatment of small packets in AQM
algorithms.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Not applicable.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Not applicable.

The authors have applied the requested changes out of the IESG review. The amount of changes require that the WG double-checks them in a WGLC before sending the draft of the RFC editor.

[Ballot discuss]
I think Sean is on to something regarding status and the Updates metadata, but I think it's even more interesting than he indicates. 2309 was an IRTF document, which explains why it is Informational. If we have now gotten to the point that the recommendations in 2309 really are all requirements (except for the preferential treatment of small packets), doesn't that justify bringing that document into the IETF stream in addition to this one, or incorporating the recommendations of 2309 into this document? If this is only updating the research in 2309, then it is appropriate to keep this document Informational as well. But if this document deserves a "higher" status, it sounds like (at least the content of) 2309 does too. Please explain.

I'd also like to hear a bit about the status itself. BCP is usually for recommendations of policy and operational guidelines. But the things in this document sound more like protocol recommendations, and things that we'd get implementation experience with over time, not things that should instantly jump to the "done" level of a BCP. Is there a reason this isn't going for the standards track instead of BCP? It sounds like protocol to me.

Finally, if this is to be a BCP, I wonder if it should be folded into BCP 41 and not made a new BCP all by itself. I'd like to hear if you think this is part of the set of overall "Congestion Control Principles" or has some reason to stand alone. An explanation of how BCP 41 (RFC 2914), RFC 2309, and this document fit together would be quite useful.

[Ballot comment]
2.1, 2.2, and 2.3: The recommendations are all given in the form of RECOMMENDEDs, SHOULDs, and SHOULD NOTs, yet there is no indication when these choices might *not* be taken, and in fact 2.1 makes it sound like there is "no other choice". Is there a reason these are not put in the form of MUST, etc.?

[Ballot discuss]
I feel the flames at my heels, but I have to ask or maybe state what I think going on with the updates/intended status mix (likely no action required by the authors):

This document is obsoleting a particular portion of RFC 2309 and then specifying a new BCP around the new recommendation?  The rest of RFC 2309 is staying at informational?  Is there harm in publishing this without including the updates header or maybe with obsoletes 2309 instead?

[Ballot comment]
I have done a basic review of discussion and the document; I'm awaiting for a possible Gen-ART review on this document, and if one arrives, it may update may position.

[Ballot comment]
"""
Bit-congestible vs. Packet-congestible: If the load on a resource
depends on the rate at which packets arrive, it is called packet-
congestible. If the load depends on the rate at which bits arrive
it is called bit-congestible.
"""

It might be helpful to note that these are not mutually exclusive, i.e., that there are devices that have both of these properties.  For example, a queue in a buffer that drains to a route engine.  In such cases, the congestible property of the overall resource is the more constrained of the individual resources.

[Ballot comment]

Thanks for a really well written document!

- Is the discussion about Non-malicious transports on p12
really about transport protocol designers or about
implementers? Seemed more like the latter to me, but the text
reads more like the former.

- 3.2, are HTTP GETs really small these days? Many are not
(e.g. thanks to cookies and other crappy headers).  I'd also
wonder about SIP with all its headers too. That might be an
argument for your approach here too - for some protocols,
messages that are important for performance may start out nice
and small, but success and inevitable crudifying might well
make those larger over time, so preferring smaller packets in
the n/w might mean you get worse over time for exactly those
protocols where its important to not get worse over time (the
ones that succeed).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-byte-pkt-congest-09.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Byte and Packet Congestion Notification) to Best Current Practice


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Byte and Packet Congestion Notification'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document provides recommendations of best current practice for
  dropping or marking packets using active queue management (AQM) such
  as random early detection (RED) or pre-congestion notification (PCN).
  We give three strong recommendations: (1) packet size should be taken
  into account when transports read and respond to congestion
  indications, (2) packet size should not be taken into account when
  network equipment creates congestion signals (marking, dropping), and
  therefore (3) the byte-mode packet drop variant of the RED AQM
  algorithm that drops fewer small packets should not be used.  This
  memo updates RFC 2309 to deprecate deliberate preferential treatment
  of small packets in AQM algorithms.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?
This document is intended as BCP. (This was discussed at IETF-81 and that
the status changed from Informational to BCP, because the draft provides
guidance to implementors and people configuring routers and hosts).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
  This document provides recommendations of best current practice for
  dropping or marking packets using active queue management (AQM) such
  as random early detection (RED) or pre-congestion notification (PCN).
  We give three strong recommendations: (1) packet size should be taken
  into account when transports read and respond to congestion
  indications, (2) packet size should not be taken into account when
  network equipment creates congestion signals (marking, dropping), and
  therefore (3) the byte-mode packet drop variant of the RED AQM
  algorithm that drops fewer small packets should not be used.  This
  memo updates RFC 2309 to deprecate deliberate preferential treatment
  of small packets in AQM algorithms.

Working Group Summary
There was consensus to publish this as a WG document and agreement at
IETF-82 that the document was now complete. Since then there have been a
number of revisions to address WG feedback.

Document Quality

Annexe A summarises a survey by the original authors showing deployment of
the techniques by router vendors. The recommendations are thought to be in
line with that of IETF groups, such as TSVWG, TCPM, PCN, and are
considered good advice for use in the general Internet.

Personnel Who is the Document Shepherd? Who is the Responsible Area
Director?
I am the document shepherd, G Fairhurst.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The document was presented at IEWTF-82 (Taipei), with a request for WGLC.
WGLC concluded with some discussion and suggested changes on Friday 30th
March 2012. The changes were discussed on the list, and have been
implemented in a revised draft.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No - the original (individual) draft had a lot of background material,
much of this has been condensed or removed, resulting in a shorter
document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-byte-pkt-congest.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
The document has WG support and there is consensus to publish.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Some people commented on the size of the document.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
No.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Not applicable.

(13) Have all references within this document been identified as
either normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.
No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
One update is listed, RFC 2309, informational - replaced by this BCP.
It deprecates deliberate preferential treatment of small packets in AQM
algorithms.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Not applicable.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.