Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Thu, 14 May 2020 15:02 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 D8FEF3A0AB3 for <avt@ietfa.amsl.com>; Thu, 14 May 2020 08:02:02 -0700 (PDT)
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, 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 X51sVy8fwiMX for <avt@ietfa.amsl.com>; Thu, 14 May 2020 08:01:59 -0700 (PDT)
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 EBBA93A0AF5 for <avt@ietf.org>; Thu, 14 May 2020 08:01:58 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id C715D202B4 for <avt@ietf.org>; Thu, 14 May 2020 17:01:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589468516; bh=1hWO8Z/Wx/s4YIIrhV2+zI5ZUNfzyXQBab3FFCkKj6E=; h=Subject:From:To:References:Date:In-Reply-To:From; b=KLvYBHRzjFIyI/kyt6wy6vuaqS67yXtaB4bv/VOusOIpq1jRmwf1DrpPHVX5EBlSI BKFmLawKdSsS6Hy/wEn+saDg20u2IQTkEAzw3Yoeqv5iXqYxDT0BqWO41C/ndoBsLo PQRIqbIFGJf4lYlzVURax7MHCovCCAp3w07hO5LE=
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
To: avt@ietf.org
References: <158895171474.17391.16816077344810423489@ietfa.amsl.com> <e462ea93-e084-5c55-1ade-521424884d41@ghaccess.se> <e6d35436-0ba4-6347-6990-46bbf5b4e5b3@ghaccess.se>
Message-ID: <a2a1add6-7934-6371-81a0-8e3dc6735045@ghaccess.se>
Date: Thu, 14 May 2020 17:01:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <e6d35436-0ba4-6347-6990-46bbf5b4e5b3@ghaccess.se>
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/61Esb1xuHC3e4UXVeDFlbIQySzc>
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport
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: Thu, 14 May 2020 15:02:03 -0000

I have concluded that only two of the discussed transports are realistic.

Comments below

Den 2020-05-11 kl. 12:22, skrev Gunnar Hellström:
> In a recent e-mail, I listed 9 issues to act on in 
> draft-ietf-avtcore-multi-party-rtt-mix-00
>
> I want to deal with them one by one or in small groups. Here is number 1:
>
> 1. Consider rapidly if there is any more reliable transport that is 
> feasible to move to.
>> (e.g. Comedia RFC 4145 and RFC 4572, or the recently approved WebRTC 
>> t140 data channel draft-ietf-mmusic-t140-data-channel-usage, or use 
>> of SAVPF with NAK and retransmission RFC 4588) 
>
> It may look strange with this issue after many months as an individual 
> draft. But I want to touch it anyway before we move on in one fixed 
> direction.
>
> T.140 and its RTP transport (RFC 2793 - later RFC 4103) were created 
> 1998 - 2000 as the third real-time medium for human conversations 
> beside voice and video. The idea was to give equal opportunities to 
> persons wanting to communicate by text as the ones who use voice or 
> video. That means real-time transmission while text is created and 
> accepting some rare dropouts just as we do with voice and video. 
> However, users are nowadays used to text messaging where it is 
> customary to accept a delay and get the text complete in most cases, 
> rather than to have loss. That user experience might be expected from 
> real-time text as well. I do not have any strong user indications that 
> this is the case, it is just my own thinking.
>
> The reason to bring this up now, is that we seem to need to introduce 
> the multi-party mixed format at least as a new text media subtype, 
> text/rex instead of text/red. Then we are anyway introducing signaling 
> complexity of similar kind that another transport will do.
>
> Are any of the initially mentioned more reliable transports realistic 
> and easily implemented in the target implementation environments: NG 
> emergency services, 3GPP IMS MTSI, IETF RUM, and plain SIP multimedia? 
> Or are there any other not mentioned?
>
> When considering this, we should have in mind that the proposed 
> transport should be with security so that we do not need to introduce 
> more options to negotiate between.
>
> And we shall also keep in mind that NAT traversal needs to be 
> supported as well as multi-party-signaling through the SIP central 
> conferencing model RFC 4353.
>
> Another complexity is that current regulation requires RFC 4103 and it 
> would be best that the finaly specified multi-party solution can be 
> perceived as an extension to RFC 4103.
>
> What can be said about the options?
>
>  1. Comedia RFC 4145 and RFC 4572. Makes use of TLS for transport, so 
> it is secured. Should use RFC 6544 ICE for TCP for NAT traversal. 
> Requires specification of how to arrange the streams and code the 
> sources in the multi-party environment. I do not know how well these 
> RFCs are supported in the target environments. Seems to increase 
> complexity.
--Increases complexity - not selected
>
> 2. draft-ietf-mmusic-t140-usage-data-channel. Has security, NAT 
> traversal and possibility to code multi-party source. Has good 
> opportunity for being supported in endpoint devices, because all of 
> them are expected to support WebRTC. Maybe less supported in 
> traditional SIP bridges.
--A realistic solution. The base is already approved and is for a 
popular environment. Multi-party is briefly mentioned but should 
probably be a bit further specified. Should however not be the only 
solution. The RTP based solution is also needed.
>
> 3. SAVPF with NACK and RFC 4588 retransmission. I assume this can be 
> combined with OSRTP RFC 8643 for security negotiation. When the 
> immediate or early feedback option can be used, this method can likely 
> be used without redundancy to achieve a reliability enhancement. That 
> will not work well over networks with high latency. Further study 
> needed if redundancy or FEC is needed as complement for high latency 
> networks. Easy to achieve up to 5 simultaneously sending users.
--Increases complexity - not selected
>
> 4. (Not mentioned in the introduction above) Use RFC 4103 plus one of 
> the RTP based methods for multi-party source indication but just 
> increase redundancy to one original and three (instead of two) 
> redundant generations. Can easily be done if reliability increase is 
> really a concern. Has low overhead. Easily applicable to OSRTP 
> security, SIP conferencing model and ICE NAT traversal.
--Easily done by local recommendations if 3 generations redundancy 
(including the original) would not be felt sufficient somewhere.
>
>
> 5. Accept reliability that is quite good as it is with RTP with one 
> original and two redundant generations in the RFC 2198 - style ( with 
> one of the additional methods discussed for increasing switching 
> performance)
>
--Realistic and regarded sufficient. By move to a mixer method allowing 
300 ms transmission interval, the protection against burtsy packet loss 
is quite good. Continue on this track.


The conclusion is reflected in version -01 of the draft, just published.

Regards

Gunnar


> Comments please so we can take a rapid decision and move on with one 
> solution.
>
> Regards
>
>
> Gunnar
>
>
>
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se