[AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)

Martin Duke via Datatracker <noreply@ietf.org> Mon, 10 May 2021 21:30 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0E3A2BC6; Mon, 10 May 2021 14:30:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <162068222166.24279.17528511733896002331@ietfa.amsl.com>
Date: Mon, 10 May 2021 14:30:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/dO_bHTMzTlkliRvG4ucdv0GhHkM>
Subject: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2021 21:30:23 -0000

Martin Duke has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


- It is not completely clear to me what the actions in the case of congestion
are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So
what is the hiearchy here. My guess is:

Step 1. Senders MUST go from 300ms to 2 seconds
Step 2. Senders SHOULD (further?) limit the number of characters sent
Step 3. Senders SHOULD go from 2 seconds to 5 seconds
Step 4. Senders SHOULD exclude nodes from the session

Is this correct?

- Assuming it is correct, I don't understand the motivation behind the
congestion considerations in Section 8.

The first and third paragraphs make perfect sense to me. But if the total
traffic to a receiver, regardless of the number of senders, remains limited to
1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of
500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more
conservative, but I would like to understand your reasoning.

No need to reply to the comments below:

- In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then
say "Integrity SHALL be considered..." I think you mean confidentiality?
Integrity means the data hasn't been altered by an attacker.

- It would be helpful to clarify in this draft that the CPS limit applies only
to new, not redundant, text, assuming that is in fact the case.