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

Note: This ballot was opened for revision 09 and is now closed.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

Comment (2013-03-26 for -09)
No email
send info
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.

(Richard Barnes) No Objection

Comment (2013-03-25 for -09)
No email
send info
"""
 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.

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-03-25 for -09)
No email
send info
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).

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-03-28 for -09)
No email
send info
I support the DISCUSS of my esteemed co-AD from Urbana.

(Pete Resnick) (was Discuss) No Objection

Comment (2013-03-27 for -09)
No email
send info
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.?

(Sean Turner) (was Discuss) No Objection