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

I support the DISCUSS of my esteemed co-AD from Urbana.

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.

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

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

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