Subject: [tsvwg] Benoit Claise's No Record on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 13 Oct 2016 06:12:39 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-tsvwg-rfc5405bis-18: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Before starting to read this document, a first reaction: let me stress
that this type of document should really benefit from a "changes since
RFC5405" section.

I see in the abstract:

   This document obsoletes RFC5405 and adds guidelines for multicast UDP
   usage.

I see in the intro section:

   [RFC5405] was scoped to provide guidelines for unicast applications
   only, whereas this document also provides guidelines for UDP flows
   that use IP anycast, multicast, broadcast, and applications that use
   UDP tunnels to support IP flows.

Looking at the diffs, there is certainly more than this
	https://www.ietf.org/rfcdiff/rfcdiff.pyht
	=> https://tools.ietf.org/rfc/rfc5405.txt
	=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt

Background: 
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the
related discussion on having a "changes since RFCxxxx", even for
obsolete.

=================================
Now the review.

Like Stephen, I was wondering about the QUIC involvement and awareness.

- TCP-Friendly Rate Control (TFRC) on the first occurence
- Section 3.1.1 might refer to active probing in IPPM, RFC 7679
- Section 3.1.5: Question: instead of implementing a congestion control
scheme, is this valid to limit the UDP traffic to a certain value, such
as a fraction of the outgoing link bandwidth? At least, that should be
true for the section 3.6 "controlled environment"