Re: [AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
James Hamlin <james.hamlin@purple.us> Sat, 14 March 2020 00:45 UTC
Return-Path: <james.hamlin@purple.us>
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 CBCC43A1399 for <avt@ietfa.amsl.com>; Fri, 13 Mar 2020 17:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tfXFBkMZsJzg for <avt@ietfa.amsl.com>; Fri, 13 Mar 2020 17:45:41 -0700 (PDT)
Received: from outbound-ip1b.ess.barracuda.com (outbound-ip1b.ess.barracuda.com [209.222.82.183]) (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 782EA3A1391 for <avtcore@ietf.org>; Fri, 13 Mar 2020 17:45:38 -0700 (PDT)
Received: from smtp.purple.us (unknown [208.17.91.144]) by mx9.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sat, 14 Mar 2020 00:45:31 +0000
Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 13 Mar 2020 17:45:22 -0700
Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Fri, 13 Mar 2020 17:45:22 -0700
From: James Hamlin <james.hamlin@purple.us>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, "avtcore@ietf.org" <avtcore@ietf.org>
Thread-Topic: Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
Thread-Index: AQHV+VZLdm2KNJW0Uky65QSHZFmrt6hHBKLk
Date: Sat, 14 Mar 2020 00:45:22 +0000
Message-ID: <1584146721401.88908@purple.us>
References: <158300358958.4740.11384667574242789327@ietfa.amsl.com>, <910582c0-dcb5-eea4-2075-eef6085750f4@omnitor.se>
In-Reply-To: <910582c0-dcb5-eea4-2075-eef6085750f4@omnitor.se>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.0.10.15]
Content-Type: multipart/alternative; boundary="_000_158414672140188908purpleus_"
MIME-Version: 1.0
X-BESS-ID: 1584146714-893017-23709-6396-2
X-BESS-VER: 2019.1_20200313.2046
X-BESS-Apparent-Source-IP: 208.17.91.144
X-BESS-Outbound-Spam-Score: 0.20
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.222867 [from cloudscan15-45.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.20 BSF_SC0_SA953 META: Custom Rule BSF_SC0_SA953 0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.20 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_SC0_SA953, BSF_BESS_OUTBOUND
X-BESS-BRTS-Status: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/s6WxxbV4kOZ1ZYHhSd0BmjQMOMA>
Subject: Re: [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: Sat, 14 Mar 2020 00:45:44 -0000
Hi Gunnar I've also been thinking through the possibility of a sender switching source without clearing all redundant generations first. Clearly, a sender that did this today would cause problems for existing receivers. But checking timestamps at the receiver should fix this. Consider three senders 1, 2 and 3 which send text "ABC", "MNO" and "XYZ". The block below shows this text being sent taking round-robin turns with the participants. seq 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 part 1 2 3 1 2 3 1 2 3 1 2 3 1 2 3 - R2 A M X B N Y C O Z R1 A M X B N Y C O Z P A M X B N Y C O Z If sequence 06 is lost and the receiver sees sequence 07 then it may assume that the lost packet was for participant 1 and use the redundant character "B". This would lead to character "B" being duplicated in the output for participant 1. But it is possible for a receiver to get the correct result; the timestamp for the redundant text in packet 07 will not be higher than the most recent timestamp previously received and so shouldn't be used. The redundant text in the following packet 08 has no applicable redundant text, but the timestamp of the R1 in packet 09 will be greater than the most recent received and so is usable. The advantage of this approach is that the format of the packet doesn't change. The current arrangement where all the text in a packet is for one participant is preserved. Tracking the timestamp adds some implementation effort but I think it's minimal. It does also mean the mixer needs to synchronize timestamps across the media sources but it is in a position to do so. Best regards James [X][X] [X]James Hamlin Contractor Purple, a Division of ZP Better Together, LLC purplevrs.com The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ________________________________ From: Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sent: 13 March 2020 16:41 To: avtcore@ietf.org; James Hamlin Subject: Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt 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<mailto: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<mailto: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<mailto:gunnar.hellstrom@omnitor.se> +46 708 204 288
- [AVTCORE] Source switching performance in draft-h… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… James Hamlin
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… James Hamlin
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… James Hamlin
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… James Hamlin
- Re: [AVTCORE] Source switching performance in dra… James Hamlin
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström
- Re: [AVTCORE] Source switching performance in dra… Gunnar Hellström