[rmcat] AD review of draft-ietf-rmcat-sbd-09

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Fri, 02 February 2018 16:04 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1814712D961 for <rmcat@ietfa.amsl.com>; Fri, 2 Feb 2018 08:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ea5ju3ueHnmD for <rmcat@ietfa.amsl.com>; Fri, 2 Feb 2018 08:04:18 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C08D12711B for <rmcat@ietf.org>; Fri, 2 Feb 2018 08:04:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=WgvvzzqF15jyU2yPRhB7nw8avKW9pbJqBoCTjAIaMm57ypVm41MFo0EzDsyW3ZfdTq6t59cZz7m95/ESSRG4osdRX8wWq9fKW0PF5DzoPl75yH1+M809LpAH8GRqR/6YJL+7CAeko55okIP7/6axD+rSsmzAT3wcSv48m576kvo=; h=Received:Received:From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 29726 invoked from network); 2 Feb 2018 17:04:15 +0100
Received: from i577bce83.versanet.de (HELO ? ( by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 17:04:15 +0100
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <227D2FC6-A331-4311-A8BF-E783B9F0B8EB@kuehlewind.net>
Date: Fri, 2 Feb 2018 17:04:14 +0100
Cc: "rmcat WG (rmcat@ietf.org)" <rmcat@ietf.org>
To: draft-ietf-rmcat-sbd.all@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
X-PPP-Message-ID: <20180202160415.29721.31583@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/CRP0VjkRgXQT4OyjGhws9DUWwfw>
Subject: [rmcat] AD review of draft-ietf-rmcat-sbd-09
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 16:04:20 -0000

Hi authors, hi chairs,

many thanks for this very well written document as well as a good write-up from the shepherd!

Before I start the IETF LC call I have two small questions:

1) Normative references:

I wonder if draft-ietf-rmcat-coupled-cc should be a normative reference, especially as it is mentioned in the abstract, but also because it probably helps to at least read section 4 (architecture) of draft-ietf-rmcat-coupled-cc.

Further this sentence seems to make avtcore-cc-feedback-message should also be a normative reference:
"Timing information described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD.“
I don’t think we want to wait for avtcore-cc-feedback-message for publication, therefor I would recommend to say something about the resolution used in avtcore-cc-feedback-message, e.g.
„Frequent timing information in millisecond resolution as described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD.“

2) I can't remember if this was discussed in the group but actually I believe it was not: this document could also be an informational document, as it is just one example algorithm but there are no dependencies on this scheme otherwise. I also don’t think is makes too much sense to think about this proposed algorithm as an experiment; if you want to change the algorithm or use a different one just do it; this is just a documentation of one proposal. I also assume that there is actually not much interest in the group to publish an updated version of this algorithm as proposed standard, as such why not informational from the beginning…?

If the authors and the group are uncertain about this point, I’m okay to start IETF LC as exp and see if we can get further feedback there or from the IESG; „downgrading“ to information can easily be done with any additional actions at any time.

It would be great if you could reply (or update) by early next week as I would like to start the IETF LC latest by Wednesday (or I need to move the draft to the telechat two weeks later on March 8).

Find further below other comments that came to my mind while reading the doc. None of these are critical to proceed the document and may or may not be address at any point in the process.


Other review comments:

1) As normative language is very sparsely use in this document and when used not really that much necessary, I would recommend to instead not used normative language at all, which mean use only lower case words and removed the respective preamble text in sec 2.

2) Question on the 2. scenario in section 3 (receiver-side). This says that the receiver H3 can calculate stats for SBD for H1 and H2, however H1 and H2 cannot implement coupled congestion control, thus congestion control would also need to be implemented at the receiver H3, right? Maybe worth mentioning...

3) In section 3.2.1, I’d say that the following part could be removed as it goes a bit beyond the scope of the document, and also seems actually unnecessary to me: if you have a way to request a set of metrics and the other end tells you with metrics it can send, you have to chose your SBD algorithm based on that information anyway without actually being at all restricted to one specific scheme.

"* A protocol identifier (SBD=01). This is to future proof the message exchange so that potential advances in SBD technology can be easily deployed. All following initialization elements relate to the mechanism outlined in this document which will have the identifier SBD=01.“

4) RMCAT is mentioned 3 times on the doc but never really introduced. Maybe make the following change: 
sec 3.1.3: s/SBD in RMCAT/the SBD algorithm described in this document./
sec 3.3.1: s/SBD in the RMCAT context/use of SBD with Coupled congestion control for RTP media [draft-ietf-rmcat-coupled-cc]/
sec 6: s/RMCAT congestion control algorithms/RTP Media Congestion Avoidance Techniques (RMCAT) algorithms/ 
   or: s/RMCAT congestion control algorithms/congestion control algorithm as developed in the RTP Media Congestion Avoidance Techniques (RMCAT) working group/

5) Use of the terms one way delay, OWD, or e.g way delay samples (OWD) is inconsistent in section 3.2.1 and 3.2.2

6) Just to double-check: sec 3.2.1, 3.2.2, and 3.2.3 use M while 3.2.4 and 3.2.5 use N. Is that correct? To be honest I actually still did not fully understand yet why and N and M are needed.

7) Sec 5.1:
"Timing information described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD."
"Timing information described by
   [I-D.ietf-avtcore-cc-feedback-message] should be sufficient for the
   sender to calculate relative OWD of an Internet path.“
Or would those information be also sufficient for e.g. a data center scenario?

8) Probably the security consideration section should also point to the security considerations of draft-ietf-rmcat-coupled-cc.