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

Gunnar Hellström <> Mon, 17 May 2021 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AA633A4535; Mon, 17 May 2021 14:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UenGAetHW9ju; Mon, 17 May 2021 14:15:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 337D13A453A; Mon, 17 May 2021 14:15:39 -0700 (PDT)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 5902620199; Mon, 17 May 2021 23:15:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1621286136; bh=2pUAAGFRFzA8aPPOnNpIqlb93V/6pgaGzxnzow3gL4o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xv9BxyrFYldlzCh0/wqL27po79w/jTSTS5NIHeXZeacUifY0S4Vj+W3lWwUlAFNMF ibZBqnEboUPDX7Vy4aY3QU0qkImSRaJVmtHDusQeY/49te+ullvJXDqF01j6hmlThe Q2Rk5pYqyunGZotTEmYmkUAkDfxw/e/CB8oNkXms=
To: Martin Duke <>, The IESG <>
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Mon, 17 May 2021 23:15:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 May 2021 21:15:46 -0000


Thanks for the review,

Please see my responses inline.

Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker:
> Martin Duke has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection
> 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.

[GH] First, I should clarify that the values are per source in the 
communication to one receiver.
You are right that it is not very logical to require an increase to a 
fixed time of 2 seconds. It does not help much, and the third action is 
anyway according to RFC 4103 an increase to an interval between 0.5 and 
5 seconds.

Therefore, I suggest to replace the second sentence of section 8, so 
that the section begins:

"The congestion considerations and recommended actions from [RFC4103]  
are also valid in multiparty situations.

The time values SHALL then be applied per source of text sent to a 

> 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.
[GH] Right, I meant "confidentiality". Modified.
> - 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.
[GH] Thanks, yes. I propose to insert the following sentence after the 
first sentence in section 3.22: "The actual rate is calculated without 
regard to any redundant text transmission and is in the multiparty case 
evaluated for all sources contributing to transmission to a receiver."

[GH] I will submit version -18 with the changes indicated above, 
together with edits because of Lars Eggert's nit findings, but am 
prepared to do further changes if needed on the congestion consideration 



> _______________________________________________
> Audio/Video Transport Core Maintenance

Gunnar Hellström