Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text" -Brian's #24

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sat, 05 December 2020 11:08 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 7A14C3A1143 for <avt@ietfa.amsl.com>; Sat, 5 Dec 2020 03:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 lTeAvw9WYf_W for <avt@ietfa.amsl.com>; Sat, 5 Dec 2020 03:08:56 -0800 (PST)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1543A0E0A for <avt@ietf.org>; Sat, 5 Dec 2020 03:08:53 -0800 (PST)
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 2BFD22014C; Sat, 5 Dec 2020 12:08:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1607166529; bh=rh5BUcFGetMrgw8ZK00HberT+w2KeXDSbhFu3nikM0U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ySvReylNoviLCGGNRTzwK727jcy/3OCR/T+6BhJ4nX1KYL+I8t3ELf0ArkcqKE3GE l6asG19cpDtuh/gN5I9TpeJXptiZ/O5hh3zAPbTQeo/gz12lbpPyUVf4/FcQxoU1JC rYBhs0MvIwfOYIbp76+S5v0fvlStOyUvH4EAswVg=
To: Brian Rosen <br@brianrosen.net>, Bernard Aboba <bernard.aboba@gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
References: <CAOW+2duJwBizifn94qcRfpZ6cqRjRVyueyoofox0AWjkcJm02g@mail.gmail.com> <68866CAE-C81B-4C23-9DB5-CA8B57C1E3DC@brianrosen.net>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <77ceeb8a-2a76-f1b0-b835-ff3bafa67375@ghaccess.se>
Date: Sat, 05 Dec 2020 12:08:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <68866CAE-C81B-4C23-9DB5-CA8B57C1E3DC@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------E1FFE43B6DEC2471D4C0B4C3"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/YrTB0KJkbaN08eEwVdVE7xlqnBk>
Subject: Re: [AVTCORE] WG Last Call: "RTP-mixer formatting of multi-party Real-time text" -Brian's #24
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: Sat, 05 Dec 2020 11:09:00 -0000

Brian, thanks for review and comments,

I start with responding #24.

Den 2020-12-04 kl. 18:27, skrev Brian Rosen:
> I have reviewed 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11 
> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-11>
>
> Although there are quite a few comments below, only the last one is 
> possibly a normative change.
....
>
> 24. (The only possibly normative change) 4.2.5 says the mixer should 
> send primary data from one source per packet.  Why is that?  The mixer 
> is creating a single stream that contains all the display for the 
> mixed participants.  ISTM there is nothing gained by this restriction, 
> and it means lots of extra packets.
[GH] There are a few but not so strong reasons for this restriction.

a) Use of CSRC: The same section (4.2.5) says that the CSRC should 
indicate the source of the primary. This makes it possible to implement 
a pseudo-multi-party awareness by the endpoint, e.g. color-marking text 
from different sources. Having multiple sources and multiple CSRC-list 
members would destroy that possibility. This is a weak argument, because 
if you bother to implement anything regarding multi-party RTT in an 
endpoint, it should be the full multi-party awareness.

b) We are using RFC 2198 redundancy, and RFC 2198 has a reminder about 
the use of CSRC in its section 4, leading to a conclusion to use only 
one source per packet.

c) If there is unrecoverable loss of text, it causes most confusion if 
it happens at a source switch. A correctly placed mark for possible text 
loss will then help the reader to get less confusion. If we separate the 
logical ending of one participant's entry in one packet, and the 
beginning of text from next participant, with its label, in another 
packet, it is less likely that the source switch gets completely 
invisible if unrecoverable loss appears than if the switch was embedded 
within one packet. Quite often the source switch will be caused by one 
participant ending its entry by a Line Separator that will be included 
in the packet. Next packet will then start with the label of next 
participant. Completely losing just one of these and getting it replaced 
by a mark for possible loss will still make it possible for the reader 
to understand that a source switch happened.

d) You say that it causes "lots of extra packets". But I cannot see 
that. The restriction only causes an extra packet when simultaneous 
typing has occurred. That is quite rare. And when it occurs, a source 
switch only happens when the current transmitting source has indicated a 
suitable place for source switch; a comma, an end of sentence, a new 
line or a pause. That causes the source switches to be at least seconds 
apart. Only short expressions while one party is typing like "yes" or 
"no" or "wow" or an emoji will cause more rapid source switching, and 
will still not cause many extra packets.

Conclusion: My reasons for having the restriction are weak, and I see 
your reason for deleting it to be weak. I suggest to keep it, but I am 
willing to accept another decision.

Thanks,

Gunnar

>
>
> Brian
>
>
>> On Nov 25, 2020, at 5:16 PM, Bernard Aboba <bernard.aboba@gmail.com 
>> <mailto:bernard.aboba@gmail.com>> wrote:
>>
>> This is an announcement of WG last call on "RTP-mixer formatting of 
>> multi-party Real-time text"
>>
>> The document is available for inspection here:
>> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix 
>> <https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix>
>>
>> WG Last Call will end on December 9, 2020.
>>
>> In response, please state one of the following:
>>
>> * I support advancing the document to Proposed Standard
>> * I object to advancement to Proposed Standard, due to Issues 
>> described below <Issue description or link>.
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org <mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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