[AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 13 March 2020 16:41 UTC

Return-Path: <gunnar.hellstrom@omnitor.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 8D9B13A0F10 for <avt@ietfa.amsl.com>; Fri, 13 Mar 2020 09:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=omnitorab.onmicrosoft.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 NHQJLRDfisme for <avt@ietfa.amsl.com>; Fri, 13 Mar 2020 09:41:46 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130127.outbound.protection.outlook.com [40.107.13.127]) (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 7C8423A0EEB for <avtcore@ietf.org>; Fri, 13 Mar 2020 09:41:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cVs92Ue/YRTQCPzQbPrwGdiSNu/DleEf7ZyGdmxv1jP/eW/c8/lhofF0jZhy+goag+YhU6V6gPHgiA3mhv1neLlk2LFU6du4Ff08PThE2vNsaMQu+hMrx3FR6C1ccC9957DijU25F8acVomXGe8VHeDAmU3t5wGeoUTz+uQitQ7DOfVU32l8aLXrilN7xLC9f2WZXw9J4wBS0MunDZdYk1lAkTS8Yw+Qy2OSYGn9Ip8daIkfOh7p+EGo/h3qF5shi2PXTZKnKpr7yycdrngMJ95DgmGV9yW1PeK0uFCdJhiJFDXWRuBi+iNbzsucuc3rZnFDbRg9yigMEgou3EtxlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=WEoloQB69PQ/NYtw3XNE2iEXpGlSLz7aLdlXvDB0FMc=; b=cPcPFQr1Hsgz08TgQdJ333zCM2LgV17KyOlunoO36mwB1xCc5cXrHZvrzNQtjoSgOM7uGi/GFxc7r7Nfjo2Z4i2csbjvXp/6JLnlEPSKv2Z/JQoN0FZnVJYULwXHUrMyH9WSisO5OH3pCb+28AezpCBzzJCE9g/AbI74sbw5nNUTVNBd8qzkS9gzuoe5t2LtpnKV0pXlIF111Lq9ulKZSI+j1d65nYcdNkan/zd0/gKLFWi9X1XC0a9cTCIITI45FLotsYLNare5XdEM7MKUJyhXkYx++wl2w3uIu3doeyrzF+6Ddoj0KH0UARA7s077JfUfBVWPRhNuxH5UsJgZ0w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=WEoloQB69PQ/NYtw3XNE2iEXpGlSLz7aLdlXvDB0FMc=; b=E+Ifu6ESvxXOLmlprcNn+IAs923JQFkhT/3uOg7NSjbeW1m+65JMCO66JB0r4nYnppvkso81yFohM6UmJmQjkGsD2XlqnMwJuY0eWmWrVasaBw7Wi/zWfxHhtVGHWA8HyKnKxsbQedNRfJ8IQSm1ojD2ow/rUibXRVivRTk98xo=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
Received: from AM0P193MB0721.EURP193.PROD.OUTLOOK.COM (10.186.188.206) by AM0P193MB0626.EURP193.PROD.OUTLOOK.COM (10.141.211.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Fri, 13 Mar 2020 16:41:41 +0000
Received: from AM0P193MB0721.EURP193.PROD.OUTLOOK.COM ([fe80::d850:e7bb:c87c:3a3e]) by AM0P193MB0721.EURP193.PROD.OUTLOOK.COM ([fe80::d850:e7bb:c87c:3a3e%7]) with mapi id 15.20.2814.018; Fri, 13 Mar 2020 16:41:41 +0000
To: avtcore@ietf.org, James Hamlin <james.hamlin@purple.us>
References: <158300358958.4740.11384667574242789327@ietfa.amsl.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <910582c0-dcb5-eea4-2075-eef6085750f4@omnitor.se>
Date: Fri, 13 Mar 2020 17:41:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <158300358958.4740.11384667574242789327@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------1595DE9728B6303B952E0652"
Content-Language: sv
X-ClientProxiedBy: ZR0P278CA0005.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::15) To AM0P193MB0721.EURP193.PROD.OUTLOOK.COM (2603:10a6:20b:163::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.2.136] (77.53.230.59) by ZR0P278CA0005.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:16::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.18 via Frontend Transport; Fri, 13 Mar 2020 16:41:40 +0000
X-Originating-IP: [77.53.230.59]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 95f769d3-63ff-438d-2fc8-08d7c76d6827
X-MS-TrafficTypeDiagnostic: AM0P193MB0626:
X-Microsoft-Antispam-PRVS: <AM0P193MB06266968961818FECA3434B5FBFA0@AM0P193MB0626.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 034119E4F6
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39840400004)(136003)(346002)(376002)(199004)(8936002)(6916009)(66946007)(30864003)(6666004)(186003)(16526019)(26005)(5660300002)(956004)(8676002)(66476007)(2616005)(81156014)(81166006)(66556008)(316002)(36756003)(2906002)(52116002)(86362001)(16576012)(508600001)(21615005)(6486002)(66574012)(31696002)(966005)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0P193MB0626; H:AM0P193MB0721.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
Received-SPF: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lim49S9P49Zi1ExGXR2yn95ahRAauHAsONqvXb4dXdrij9zXNVjrWqGnZTsdMsJqEPKjF6gg4dmYn+Bo3MXXT3D87VVBvTM0sn9WEh0Y+au38t5T9sXchtBtu25fmPNaVHsv6KjnCcmbC6WM9wqVPdRUWMFhym2CH5E27riqAHGU2GjVfcz7kvHd9MOH5lelbY4Zyb/kAKFfZtQ25bceU4+rLfjDcSWbUd1anmGFaW210D2rgM0TOjZpl5+HWlL8Pbo/+by5nvJraBGZeCvlrxh64Vd5DP+KqtA2ycbQAUcoDxmRxPi880lOiLRSSpTVl045SXESxUUgBwLfec3rbik0Imfhe05mEFyfikSMuwggy+Y/dyleZmoymKCFMNCaq7pg4L78rjxGfLAYSJJVhumCoFhdUkEwhERxrHUicYFwoALHcSBihPtORlEzTqT2OBZO2EgUABePKXmP6hbE0p78e3xCegTbeX9ZsvIHf3lZ4d1VsbR/0mhp2t/bH6MKBm6rFlUcoJMAA8UCVcxruA==
X-MS-Exchange-AntiSpam-MessageData: tlKSWi/ALaK4OArT/rViQU0S13L53FiROEMvO/gObSGn2Y1sWc29xCSs71i1yx0hUYVat7JZTX3LmrTFddx2Oj/o5G4qkBNQEUKPfSbD43z0AJfej3dV+Fy6ZaXYI2XM8DMNi+/kv6ZCjncNEkrxMw==
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 95f769d3-63ff-438d-2fc8-08d7c76d6827
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2020 16:41:41.1136 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vYTpeW4yB7Nomeas6aALxk+pw001RQ6BqSnkstjBNIEzN4fcqeK/pr/oyaslfBwEUSyubO/VzMkIh2YAv214MqHTr7l/CfjDmRHG66Kq4uo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P193MB0626
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/vgNoagMh5NRf1zy5UmZvZo9GhYk>
Subject: [AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
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: Fri, 13 Mar 2020 16:41:51 -0000

Hi,

I want to follow-up on the good discussion on source switching 
performance a couple of days ago, under the subject "[AVTCORE] Improved 
RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding"

*Two parts in the performance increase solution.*
Two actions are proposed in draft-hellstrom-avtcore-multi-party-rtt-source:
a) Reduce the packet transmission interval from 300 to 100 ms.
b) Use a strict relation between members in the CSRC list and the parts 
of the payload that is original text and first generation redundancy and 
second generation redundancy so that the mixer can switch source for 
every new packet and the sources of text recovered from redundancy can 
be assessed by the receiver.

I think it is worth while to move forward with the complete improvement 
a) and b) proposed in the draft. It will cause less complexity, lower 
delays and lower risk for stalling in case of many participants entering 
new text simultaneously.

Here is my reasoning:

I have the following view of the achievable performance improvements for 
different cases:

1. With the original source switching with RFC 4103 and an RTP-mixer 
using 300 ms transmission interval and not allowing a mix of sources in 
one packet, there can be one source switching per second by the mixer 
with an introduced delay of up to one second.


2. By just reducing the transmission interval from 300 to 100 ms, it 
will be possible to have three source switches per second with an 
introduced delay of up to one second. (with just two parties sending 
text simultaneously, the delay will be maximum 300 ms. )

3. And by applying the proposal from the multi-party-rtt-source draft 
with the CSRC-list as a source list for the redundancy, and also using 
100 ms transmission interval, there can be switching between five source 
per second with an introduced delay of max 500 ms. With just two parties 
typing simultaneously, the delay will be a maximum of 100 ms.

The delays are extreme values from when all sources start to type 
simultaneously.  It was agreed that at least the improvement from the 
reduced transmission interval is needed.

Case 1 and 2 are a bit complex for the mixer to implement. From the 
moment it has text queued for transmission from another source B than 
the one currently transmitted A, then the mixer needs to stop adding new 
text from A to the packets, but still send two more packets with the 
agreed transmission interval, progressing the latest transmitted 
original text to first generation redundancy and then again one more 
packet with the text as second level redundancy. Not until that is done, 
the mixer is allowed to start taking text from the transmission queue 
from B to transmit. This is the background of the 1 s vs 300 ms delays 
in case 1 and 2.

In case 3, there is much less complexity. When there is something from B 
in queue for transmission, the mixer can decide to insert that in next 
packet and add the redundancy from earlier transmissions from A, because 
their sources are included in the CSRC list in the same packet.

Therefore I want to move on with the complete solution in case 3.

-----------------------------------

*Influence on the multi-party capability negotiation:*
There is an installed park of RTT implementations without multi-party 
awareness. The receiver need to take active part in planning the 
multi-party RTT presentation. Therefore a capability negotiation is 
needed. A simple sdp attribute a=rtt-mix without value is proposed in 
the draft.

It is important to let this attribute mean capability of the complete 
solution case 3).  If there is a temptation to have different levels of 
implementation, some only implementing the shorter transmission interval 
(2) and some implementing the complete solution (3), then threre will be 
a need for two different attributes, or one attribute with a list of 
parameter values for the two cases. That would complicate the evaluation 
of the negotiation. Therefore I would prefer that the attribute can mean 
capability to use the complete mixing solution (3).

Regards

Gunnar


Den 2020-02-29 kl. 20:13, skrev internet-drafts@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : Indicating source of multi-party Real-time text
>          Author          : Gunnar Hellstrom
> 	Filename        : draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
> 	Pages           : 13
> 	Date            : 2020-02-29
>
> Abstract:
>     Real-time text mixers need to identify the source of each transmitted
>     text chunk so that it can be presented in suitable grouping with
>     other text from the same source.  An enhancement for RFC 4103 real-
>     time text is provided, suitable for a centralized conference model
>     that enables source identification, for use by text mixers and
>     conference-enabled participants.  The mechanism builds on use of the
>     CSRC list in the RTP packet.  A capability exchange is specified so
>     that it can be verified that a participant can handle the multi-party
>     coded real-time text stream.  The capability is indicated by an sdp
>     media attribute "rtt-mix".
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-source/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-source-01
> https://datatracker.ietf.org/doc/html/draft-hellstrom-avtcore-multi-party-rtt-source-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-hellstrom-avtcore-multi-party-rtt-source-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288