[AVTCORE] Review of draft-ietf-avtcore-multi-party-rtt-mix

Brian Rosen <br@brianrosen.net> Mon, 02 November 2020 21:23 UTC

Return-Path: <br@brianrosen.net>
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 2E5603A15EC for <avt@ietfa.amsl.com>; Mon, 2 Nov 2020 13:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 yQ1xPyxFTvFK for <avt@ietfa.amsl.com>; Mon, 2 Nov 2020 13:23:26 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DF03A15F0 for <avtcore@ietf.org>; Mon, 2 Nov 2020 13:22:21 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id 63so6824729qva.7 for <avtcore@ietf.org>; Mon, 02 Nov 2020 13:22:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Q60VNKW2JTnEDyzC+xJeigeBrJ6IHeD9ksRGzlrSo/Q=; b=ZqKbz3cc1eAuS7bVT43KoGYGa+g/VPTMekx6AxWxsfegfPqaddq4HBxVlQZ1NV8gNQ 4V0KYgpLcswKwvRpn5ZrLpqEYzPonKlVBmDK6RlTvYrtkJ3ttAC4/WbdLtMPtmt/2knI l5oIiuva+gmpFM+/t0mpAzNEKQE8amGeLfOkx+1B+W9y4I5z/rdmGni9Klf0qLkYDbdv 8uojJOoljRzPb1WwpFpC132U+NpEZ1Xu9LCLabGs7+L22Rcolu5f7A0An4Gma4G69rW6 KmxzDiEWEef2RAiYxrtWgtOK9JWcRfVBKolKDvTOs8AJu4c7TwOxV9N6Os0FOEtGyU7o L6YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Q60VNKW2JTnEDyzC+xJeigeBrJ6IHeD9ksRGzlrSo/Q=; b=V6HmHc0/aCwXZy2svg2q5iZbVlD3CGkGVNa7ZqSUGbHpxlw9tvIY/zJquvXQEjmFmD PqRQ6jUPC+6YpPgVmymnnF2enMZu8W/pUJvTCQF+L+PDhxuNCQizClpSuys/0OdV1IXE zPYNjFEEJCz+I6PrsKweXGwm+f2z9GHle0UVQsoLkaDl8ZD+Z/aIVGLiUkH7UAnh9M9u zwHnTaP8aTv8DwN7UFEUptOpL5hAg/u/dnHWNNR2tpQRtqRQ9c4EFatf0SWyLMsh5rsF cYuuvN3+ah2ALc1mbEaN27AAALXxCbFXjMdcDvgq/5oyF1Sa7PSvYUsYnorkY2HURMak UcBg==
X-Gm-Message-State: AOAM530VupU8wQxjE4Bn2GarFjnlAzH05zNfkU5O0MVUcKKEx6lF/dpU /NRo+9c6JzDhp029utgiQnazwpMnuyE5FXm/
X-Google-Smtp-Source: ABdhPJzReSrFgmGL54VTNf+JW53b8mja6XbYymVa2diqFErV2GGlf8wS1fbPr/8Bh8t2r93mU9uiNA==
X-Received: by 2002:a0c:b908:: with SMTP id u8mr14423035qvf.27.1604352140133; Mon, 02 Nov 2020 13:22:20 -0800 (PST)
Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id x191sm8389981qkb.53.2020.11.02.13.22.19 for <avtcore@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 13:22:19 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Message-Id: <7F3C955A-4231-44B1-A15D-CCF26E4F6217@brianrosen.net>
Date: Mon, 2 Nov 2020 16:22:18 -0500
To: avtcore@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/H_GYDhCF_k3QTm49aH5lIgh_Few>
Subject: [AVTCORE] Review of draft-ietf-avtcore-multi-party-rtt-mix
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, 02 Nov 2020 21:23:36 -0000

I have reviewed -multi-party-mix-09 and have the following comments:

1. Section 1 Introduction provides the solution, in detail.  I think it would be better to have a high level description of the problem, and then introduce the solution in a subsequent section.  I would also like to see a little text on what “mixing” for rtt means.

2. In the Selected solution and considered alternatives section, the first alternative (One RTP stream per source in same RTP session), please make it clearer that the clients have to support this, not just the mixer, and that’s the issue.  

3. I don’t really understand the text at the end of that section where it describes when multiple typers send text simultaneously.  ISTM that RTT behaves just like voice in that turn taking is often jumbled when more than one user responds to the previous user.  It takes time to recognize it, and for agreement on who has the “floor”.

4.  Need a better heading for “Specified Solutions”.  Actually, I wonder if you could delete this whole section, and add a definition for “multiparty aware” and “multiparty unaware” in 1.2.  Some of this text might move to 3 and 4.2, but that’s okay

5. If you did remove Section 2, you could rename Section 3 to Procedures for Multi-party aware mixing

6. The first two paragraphs of 3.1 are O/A text.  The last 3 aren’t - they are how parties act after O/A

7. In 3.3, it says “As soon as a participant is known to participate in a session and being available for text reception, a Unicode BOM character SHALL be sent to it according to the procedures in this section.”  I think it is unclear who sends this to whom.  I believe based on the text in 3.8, that the participant sends BOM to the mixer, because it says “and deletion of 'BOM' characters from each participant”.  Does the participant send it to the mixer?  Does the mixer send it to the new participant?  To existing participants?

8. I don’t remember why you have to send the redundant text before switching sources.  You might want to explain why in 3.11.  It’s obvious you would like to do Particpant 1, initial, Participant 2, initial, Participant 1, redundant 1, Participant 2 redundant 2, Participant 1, redundant 2, Participant 2, redundant 2.

9. Might want to add text before 3.18.1 that says why you want to send CSRC length 0.

10. Typo “evenso” in 3.19

11. Not sure I understand what “a negotiation between security and no security SHOULD be applied. ” (3.20) is supposed to mean. 

12. Showing examples of SHA-1 may be realistic, but not desirable.

13. Possible discussion of malicious participants in Security Considerations.  Not much can be done, other than require secure signaling and media (so authentication can be relied upon).