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

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.

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?

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.

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>.

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.

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.

Looks good to me.

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;-)