Subject: Re: [rmcat] Publication has been requested for draft-ietf-rmcat-cc-requirements-04

From: Spencer Dawkins <[email-masked]>
Date: Tue, 10 Jun 2014 23:26:08 -0500

Dear Mirja,

On 05/12/2014 11:04 AM, Mirja Kuehlewind wrote:
> Mirja Kuehlewind has requested publication of 
> draft-ietf-rmcat-cc-requirements-04 as Informational on behalf of the 
> RMCAT working group. Please verify the document's state at 
> http://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ 

Your slug of an AD has completed his AD evaluation for this document.

I have some comments I'd like to resolve before putting this document 
out for IETF Last Call.

Almost all of my comments are editorial in nature. Only the question 
about "jitter" is likely to result in a technical discussion.

IDNITS does find a few things, like a reference in the Abstract. Please 
address those issues so no one else will see them during reviews 
(directorate reviewers run IDNITS and complain, too!).

Other than that, the document is quite clear, and I'm pleased with the 
result of RMCAT's work. Thank you and the working group for that.

Spencer

--

In this text:

Abstract

    This document attempts to describe a set of requirements that can be
                  ^^^^^^^^^^^^^^^^^^^^
By this point in the publication process, the "document describes a set 
of requirements ..."

    used to evaluate other congestion control mechanisms in order to
    figure out their fitness for this purpose, and in particular to
    provide a set of possible requirements for proposals coming out of
    the RMCAT Working Group.
    ^^^^^^^^^^^^^^^^^^^^^^^

We don't typically refer to IETF working groups (which conclude) in RFCs 
(that live forever). Perhaps "for realtime media congestion avoidance 
techniques"?

I might be looking for terminology that RMCAT simply doesn't use, but in 
this text:

1.  Introduction

    When doing real time interactive media, the requirements are
    different; one needs to provide the data continuously, within a very
    limited time window (no more than 100s of milliseconds end-to-end
    delay), the sources of data may be able to adapt the amount of data
    that needs sending within fairly wide margins, and may tolerate some
    amount of packet loss, but since the data is generated in real time,
    sending "future" data is impossible, and since it's consumed in real
    time, data delivered late is commonly useless.

It wasn't obvious whether requirements on variation of interpacket delay 
("jitter") would be included in the requirements. Is that covered 
somewhere? Or does jitter matter?

I note that your Requirements Language looks like this:

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

but there are a LOT of lowercased 2119 terms in the document. That's 
fine, but it's clearer if you could say something like "these terms are 
presented in lower case for readability".

In this text:

2.  Requirements

         C.  It should handle interface changes (WiFi to 3G data, etc)

Somewhat obscurely, 
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt doesn't 
list "WiFi" - the term of preference seems to be "WLAN" or "wireless 
LAN". I don't know, but suspect that this is because "wifi" is a 
trademark. I was pleasantly surprised that "3G" was on the well-known list.

In this text:

         F.  Similarly periodic bursty flows such as MPEG DASH
             [MPEG_DASH] or proprietary media streaming algorithms may
             compete in bursts with the algorithm, and may not be
             adaptive within a burst.  They are often layered on top of
             TCP.  The algorithm must avoid too much delay buildup during
             those bursts, and quickly recover.  Note that this traffic
             may on an access link, or may cause a shift in the location
             of the bottleneck for the duration of the burst.

I couldn't parse the final sentence. Missing word?

In this text:

    2.   The algorithm must be fair to other flows, both realtime flows
         (such as other instances of itself), and TCP flows, both long-
         lived and bursts such as the traffic generated by a typical web
         browsing session.  Note that 'fair' is a rather hard-to-define
         term.  It should be self-fair with itself, giving roughly equal
                             ^^^^^^^^^^^^^^^^^^^^^
         bandwidth to multiple flows with similar RTTs, and if possible
         to multiple flows with different RTTs.

This reads somewhat oddly, and the term "self-fair" doesn't occur again 
in the document. I'd suggest either "self-fair" or "fair with itself", 
and the second possibility is probably easier for a first-time reader.

In this text:

         A.  An algorithm may be more successful at avoiding starvation
             from short-lived TCP long-lived/saturating TCP flows.
                                 ^
I couldn't parse the sentence. I'm guessing there's a missing "than".

In this text:

    5.   It should be stable if the RTP streams are halted or
         discontinuous (VAD/DTX).

These aren't listed as well-known abbreviations, but they don't appear 
anywhere else in the document. Could you replace them with their expansions?

In this text:

         C.  Bandwidth for the feedback messages should be minimized
             (such as via RFC 5506 [RFC5506]to allow RTCP without SR/RR)

Could you replace SR/RR with their expansions? These aren't listed as 
well-known abbreviations, but they don't appear anywhere else in the 
document.

In this text:

    Algorithm designers SHOULD consider the possibility of malicious on-
    path attackers.

you might consider lower-casing the SHOULD - the document will be easier 
for readers if your RFC 2119 cases match throughout.