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

Dan Mongrain <dan.mongrain@motorolasolutions.com> Sat, 16 May 2020 03:21 UTC

Return-Path: <prvs=24057aa5a7=dan.mongrain@motorolasolutions.com>
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 D85F73A092C for <avt@ietfa.amsl.com>; Fri, 15 May 2020 20:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=motorolasolutions.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 9Y1VZvAPZWtg for <avt@ietfa.amsl.com>; Fri, 15 May 2020 20:21:15 -0700 (PDT)
Received: from mx0b-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 5708E3A092B for <avt@ietf.org>; Fri, 15 May 2020 20:21:14 -0700 (PDT)
Received: from pps.filterd (m0074408.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04G34kRs009514 for <avt@ietf.org>; Fri, 15 May 2020 22:21:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=motorolasolutions.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS--2020-03-17; bh=Vco/PKkyNpycemUU6KlZeKFJ5FTF0YQ/2XMxuDC9HUU=; b=hXGfFEaO7G0dgl05upnJBEHsuvTr5iKzg1WYUmOVG+G44quqFlXpMjwdacps8QKp7Hkd edj4LaYqcdzQMQo5oBUInAGHOCX83cbdKe1etOYORd6ZfUWM1C9c2jfDwuXnBEwS3TeC Apz+SP2cnzxlcBKmolA4dvPGH/XPMrp8J9IXFGdD6bCpjB+48eXke+A2XOw2lMZg7M9O m5uIM6L/MC+XM3wwejABWYYxfrl4t5u5yew0yhXMlud1gFp4K3oFe9IhvxxCOC3P8v5N uCxfsw3iWop8HCEZkQb4qbhkoEyCwog4l4vUO7wV8Bc5xKi9k01a8ETzs8v7OPBhLY+w Jw==
Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) by mx0a-0019e102.pphosted.com with ESMTP id 31012mpgn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for <avt@ietf.org>; Fri, 15 May 2020 22:21:13 -0500
Received: by mail-ua1-f70.google.com with SMTP id k17so1889263uab.11 for <avt@ietf.org>; Fri, 15 May 2020 20:21:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vco/PKkyNpycemUU6KlZeKFJ5FTF0YQ/2XMxuDC9HUU=; b=hkva1Rzvp71EeFzS6pbGqB1Lr0xLYfoTxu1DrpyB2g66+KfJhu39oDOCshn9Kb0/hZ UCI93wypb/h84tjJYBejH/OcaBqY9E+RoxUUpqGc/U52eO8p5EpyqIXoRjSWNlKjNBBZ YljJGQqV7IDGNLGam42bDFCBYo0pvxTVzoLiLqSO7Q9T8eA2c4ggvROCH3n7esGkUqCn zNM5ETjCHpsoeL3r0wZ+4rxpC561tIDCEt0Fjyj1uB9sHaEsVkJo7MA/sKDZ6WFbMBZR 6wuxMO0+Rujhj6Hay1IqfrzYrDukGcTG7D7Yem6inl6OS5k7tu79d1v/vJ/sEEsAQ03p sH/A==
X-Gm-Message-State: AOAM53200bicp0MvtPMiLc+RKoehQNLMDUgaEHnZTYpYPL+P7VyNAVlo XA6Ve/tWK+7Ek/rOPpIO/Vy5nSSRYXS1M3aeBr6F/hE8JUMe3JhhcywCO87nTuQ3U6zGc+HOXDy 76ulKln0G56KzXqZELC0=
X-Received: by 2002:a67:32cb:: with SMTP id y194mr4943316vsy.114.1589599271608; Fri, 15 May 2020 20:21:11 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJx+RT8fl2uJ3mYM7yAwNr6hOSUyO4CU6o5D7SQZrg2o+OjA776+ZrCAfBwVzi/TUY9ogP906tI3kn3nCF99o7Q=
X-Received: by 2002:a67:32cb:: with SMTP id y194mr4943306vsy.114.1589599271086; Fri, 15 May 2020 20:21:11 -0700 (PDT)
MIME-Version: 1.0
References: <158895171474.17391.16816077344810423489@ietfa.amsl.com> <e462ea93-e084-5c55-1ade-521424884d41@ghaccess.se> <e6d35436-0ba4-6347-6990-46bbf5b4e5b3@ghaccess.se> <a2a1add6-7934-6371-81a0-8e3dc6735045@ghaccess.se> <C8BCBCFE-EA60-4964-A969-320265A89FA7@brianrosen.net> <06d6a0e7-8a0b-6177-ebcb-b03d3396e6cb@ghaccess.se> <0104AEDD-A7FC-4FC9-9E9E-8858D258581D@brianrosen.net>
In-Reply-To: <0104AEDD-A7FC-4FC9-9E9E-8858D258581D@brianrosen.net>
From: Dan Mongrain <dan.mongrain@motorolasolutions.com>
Date: Fri, 15 May 2020 23:20:59 -0400
Message-ID: <CAKB0ssGfCR1K+Ukgek0OLT29a6omCpc7wEjZQN_UT+PSi3icaA@mail.gmail.com>
To: Brian Rosen <br@brianrosen.net>
Cc: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>, avt@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e38d5905a5bb6bff"
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 bulkscore=0 cotscore=-2147483648 mlxlogscore=999 adultscore=0 suspectscore=1 mlxscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005160023
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/98ejFcJ-zP4EWWC4-Qp15V10YyY>
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: Sat, 16 May 2020 03:21:20 -0000

Please keep UDP-based RTT conveyance, even for conference-aware endpoints.
While I do not mind if we were to add a reliable conveyance protocol as an
option, we must keep the UDP-based option for RTT. The reason is that SBCs
out there currently treat RTT as voice traffic and allow it through. If we
were to insist that conference-aware endpoints only support a reliable
protocol then the SBCs will need to be updated in order for RTT to work.
This is not a trivial change, especially since the initial market for RTT
is Public Safety which is a small market for SBC vendors thus does not
react quickly to these types of changes.

Thanx,
Dan


*Dan Mongrain, eng.*Principal Engineer, Standards
*Motorola Solutions*

*o*: +1.819.931.2129
*m*: +1.613.558.0764
e: Dan.Mongrain@MotorolaSolutions.com
www.linkedin.com/in/DanMongrain

*[image:
https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png]*




On Fri, May 15, 2020 at 5:34 PM Brian Rosen <br@brianrosen.net> wrote:

> Ah,  two cases, multiparty aware and multi party unaware slipped my mind.
>
> I would say if we’re defining multi-party aware UAs, which is by
> definition, new code, that we’re better off with a truly reliable
> transport.  Keeping “repeat it enough times that it ought to work” doesn’t
> strike me as the best choice given implementations must change.  That was a
> hack.  It’s an okay hack, but we have the problem that this is very high
> information density per bit, so it’s quite a bit worse to lose information
> with RTT than with audio or video.  Your mind can fill in some missing
> character blanks, but not as well as it can deal with missing audio and
> video packets.
>
> Brian
>
> On May 15, 2020, at 2:29 PM, Gunnar Hellström <
> gunnar.hellstrom@ghaccess.se> wrote:
>
> Hi Brian,
> Den 2020-05-15 kl. 17:03, skrev Brian Rosen:
>
> I think we have to consider who has to do what.
>
> If we are requiring all implementations to change because of other
> multi-party issues, then I think we should us an actual reliable protocol,
> and not just a “repeat enough times that the probability it gets there is
> high enough.
>
> If we aren’t asking all implementations to change for multi-party, but
> only the mixer, then I think that we’re sticking with T.140,
>
> We’re in the latter case, right?  The point of this work is don’t change
> the endpoints, only the conference bridge.
>
> We are in both cases. And I hope you agree we should be.  And this is in
> general, not only for the transport. Both cases are there in the current
> draft draft-ietf-avtcore-multi-party-rtt-mix-01
>
> 1) A mechanism that the mixer can use when it is revealed that the
> endpoint does not support proper multi-party presentation. There are
> functional limitations, but it works reasonably well, especially for few
> parties taking turns in reasonably good order. It is specified in section
> 13.2 and is called "Multi-party mixing for multi-party unaware endpoints".
> You can check the functional limitations at the end of that section and
> tell if you agree that we also need something better.
>
> 2) A mechanism to use when both the mixer and the endpoint can handle
> fully functional multi-party presentation of text. That requires active
> action by the endpoint to place received text in areas for each
> participant, and present them in a suitable way, both providing a good
> real-time impression, an impression of approximately when in time order the
> text entries were produced, and a collection of text from each participant
> in suitable chunks, phrases, sentences or messages, with source information
> attached. The latest draft has a format for multi-party transport that
> allows up to 16 sources per packet, and can by that provide text from about
> 32 simultaneously typing participants without introducing unacceptable
> delay. Earlier versions of the draft had different and much lower
> performance.  I am glad that the new format will not be the bottleneck for
> a good RTT multi-party experience.
>
> It would have been possible to specify another transport for mechanism 2),
> but my reasoning ended up in the same as before: RTP with RFC2198-type
> redundancy, with one original and two redundant transmissions, most often
> 300 ms apart. You can see the format as 16-tuple-RFC-4103. Do you agree in
> this conclusion for case 2?
>
> Thanks,
>
> Gunnar
>
>
>
>
>
>
> Brian
>
> On May 14, 2020, at 11:01 AM, Gunnar Hellström <
> gunnar.hellstrom@ghaccess.se> wrote:
>
> 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
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwMFaQ&c=q3cDpHe1hF8lXU5EFjNM_A&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=Mh4BvC6JY0d6urYNkCGlGuI1Pgq7xekFGGo79VtP9m4&s=K1yT7vKc_oY0sbKk9iEk8eU7THJ6mwdS8Xy716izsdI&e=>
>
>
> --
> Gunnar Hellström
> GHAccessgunnar.hellstrom@ghaccess.se
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_avt&d=DwICAg&c=q3cDpHe1hF8lXU5EFjNM_A&r=n9aaU9xSQM4-mK_yF4tJzi7SeOWS3tTUWut1BhcRBI5vMR5LUWrTKzC_1DF8wC_4&m=Mh4BvC6JY0d6urYNkCGlGuI1Pgq7xekFGGo79VtP9m4&s=K1yT7vKc_oY0sbKk9iEk8eU7THJ6mwdS8Xy716izsdI&e=
>

-- 


*Your privacy is important to us. That is why we have taken appropriate 
measures to ensure the data you provide to us is kept secure. To learn more 
about how we process your personal information, how we comply with 
applicable data protection laws, and care for the security and privacy of 
your personal data, please review our Privacy Policy. If you have any 
questions related to data protection and compliance with applicable laws, 
please contact us at our Security Operations Center at 1-800-674-4357.*