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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 17 May 2021 21:15 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA633A4535; Mon, 17 May 2021 14:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UenGAetHW9ju; Mon, 17 May 2021 14:15:40 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337D13A453A; Mon, 17 May 2021 14:15:39 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (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: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 5902620199; Mon, 17 May 2021 23:15:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; 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 <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org
References: <162068222166.24279.17528511733896002331@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <f53fe33d-2794-0203-1749-2833ff017953@ghaccess.se>
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: <162068222166.24279.17528511733896002331@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/4Qdc2T04j9OOawaieAT9yx9ekJM>
Subject: Re: [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
Precedence: list
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, 17 May 2021 21:15:46 -0000

Martin,

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:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - 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 
receiver."


>
> 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 
wording.


Thanks,

Gunnar

>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se