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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 16 March 2020 22:12 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 842F43A124D for <avt@ietfa.amsl.com>; Mon, 16 Mar 2020 15:12:34 -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 4TdwuK4uSVWU for <avt@ietfa.amsl.com>; Mon, 16 Mar 2020 15:12:31 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150124.outbound.protection.outlook.com [40.107.15.124]) (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 0E7763A124C for <avtcore@ietf.org>; Mon, 16 Mar 2020 15:12:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a27vUsPbtSrqboRrXhebFq0lNOaC/OLrHhAgTauPHOlHLYRuZTwAQaz08DR/DlZIRO8UTHJNz/g9UFDgQMQU2x1Bi/SCPF9VYgBkDgQ5gPu/YHojS+MZmT6XDBRzIoOBAK2Mb9PTarARDniNVhZF4TBsMjUKE04wX1SvkCgm5Wk6Q8IFzkTEVqsP7RAfj4mfgPO77tK2CHoEN/h+rvxoo+3O8YfCSPZEmH6gU3Elv780lAAZryMzBRdNOc6T62QFFFbpMRISNSwfEcwCigg5EtQ8Y4Yo6MT6E2BqWgZsVWUYJlNn0Dh/cnQ8yXB+k78RpVCvFq/TLM33N+NcFmmKNg==
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=ejFHM88h4zeqnJdb43tWICOHHC4Prwuv7ThphVmblqk=; b=gTR+UjYZAXsZm5PCTWNxtN86jYe2KwR40yCn6WQ5qzNCITIVSaajP/mB+VAtoPQZ8UxGrNkXY9r3VNWKJWJcVumHhhYirxTk4ZAhUQr5rllyAZnlfXkyvyOfN8ruPz1YOT+sxhGOo0F49ZbBErbpMH+STNHXVb0nnPoJVPlJ0BultZ29YvCdpL8bZ8gwWRrU2HFcqWwK3SGJv9DVo0aUs/Ucw2zz1j7fXG8fmnSgH/9C8102EUT50x39jRrgoLxs/PHH4dBm+S4v+dgRchpoTLw9Sj5mCvanKu+iD/uKidwQ3eb7htmE9Tjt/bLqxCpJT0/1Qe5228oX2v2NSOw9Gg==
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=ejFHM88h4zeqnJdb43tWICOHHC4Prwuv7ThphVmblqk=; b=JBIgThENAGgANXf4MYPUIQZJ7T0UoSoc85ylnuJZOazBtvAWYBJ3Y/+Eh8NuceAxbVvPrFSvl9VLvGpO4pOA9BvnKD9VSnHAJMN5uAvhJUZ/KYGpSPWIOP7xGIIu3rMdnPh0hL+eCXPqtnmDTQqcWyoBN2cX9a5R9mh/FNnv8O4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
Received: from DB8P193MB0614.EURP193.PROD.OUTLOOK.COM (20.180.1.81) by DB8P193MB0533.EURP193.PROD.OUTLOOK.COM (20.180.2.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.22; Mon, 16 Mar 2020 22:12:25 +0000
Received: from DB8P193MB0614.EURP193.PROD.OUTLOOK.COM ([fe80::cc9:8735:97be:103b]) by DB8P193MB0614.EURP193.PROD.OUTLOOK.COM ([fe80::cc9:8735:97be:103b%6]) with mapi id 15.20.2814.021; Mon, 16 Mar 2020 22:12:25 +0000
To: James Hamlin <james.hamlin@purple.us>, "avtcore@ietf.org" <avtcore@ietf.org>
References: <158300358958.4740.11384667574242789327@ietfa.amsl.com> <910582c0-dcb5-eea4-2075-eef6085750f4@omnitor.se> <1584146721401.88908@purple.us> <61971f62-cff3-6fcb-1035-341e1244d255@omnitor.se> <1584360674813.99071@purple.us>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <3a8a924a-8e36-6015-dee0-5951457dd39f@omnitor.se>
Date: Mon, 16 Mar 2020 23:12:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
In-Reply-To: <1584360674813.99071@purple.us>
Content-Type: multipart/alternative; boundary="------------95325A62611476154105B61A"
Content-Language: sv
X-ClientProxiedBy: FR2P281CA0028.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::15) To DB8P193MB0614.EURP193.PROD.OUTLOOK.COM (2603:10a6:10:155::17)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.2.136] (77.53.230.59) by FR2P281CA0028.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.19 via Frontend Transport; Mon, 16 Mar 2020 22:12:23 +0000
X-Originating-IP: [77.53.230.59]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 6c527647-e15d-49a7-e20c-08d7c9f71aef
X-MS-TrafficTypeDiagnostic: DB8P193MB0533:
X-Microsoft-Antispam-PRVS: <DB8P193MB05339C11BE9EC0B6167180FCFBF90@DB8P193MB0533.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:7691;
X-Forefront-PRVS: 03449D5DD1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(376002)(366004)(39840400004)(199004)(8936002)(81166006)(81156014)(8676002)(966005)(508600001)(21615005)(19627405001)(2616005)(956004)(66574012)(316002)(16576012)(110136005)(26005)(31686004)(16526019)(186003)(53546011)(36756003)(2906002)(6486002)(52116002)(30864003)(5660300002)(31696002)(66476007)(66556008)(66946007)(86362001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8P193MB0533; H:DB8P193MB0614.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: KIS0Fqho2MIoHJOMVl3xJ9ALonSYn1vXwWXZ/7qS4BhzKLs4anN92PZIvpj0XI65uozh3MWc/xokMuyGA3RyaEWazN16PLgAHEKJoeJtBDHJamp4Z/m5NJiyHLW8dMJ6RF/VFtTjiXZ4rZhVY3xYvgmJnsKhSoD8toDp1H6RKRyKMeA/zghEdbrxM43dtReDrLQerbJgbrC/7owAk08wM1UhLkzBi8cA5RomfHKGBHP9XGtNbDSmgxRuQzEX7JjYkQ6gbAhaV5d+tRE/9aZIdSz8MIUFn6YRYvTe7aS4ldgx0f9gQttWzWDnyKm7yjq8Df+WHyyeeowNvilgnRHgwhFRJwzgvtA/tNR6ls2KeioB/ggqPjMg1wZY2QYeBKcIlf2NLo7uP2s+vmmNw4tIAH88aa5I2qovQiP6SYWkm6GP0ueJ5xr27iK+62cweq8VWs0RIozMwY/xxwhdHycT4r6pWrITW7FzzygO7elbs/TrBOFRxh2nw87KmF5oZ2mQB+XOM26NDL33G8ODf9nTGA==
X-MS-Exchange-AntiSpam-MessageData: zNU+vKrAOz1hrW+8UlGRJ1vRlPZhDeSB2T3hM7GmK3E8pY68JsIEjvv4CyU2vLRTiEbIfboM8Mf0hckPE+NuIoyTl5a+dqFDET80lWRN8NZPVLVovkHTp4p8PqRU+JFE1FgKhjTMRidgBEmmWSRaVw==
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c527647-e15d-49a7-e20c-08d7c9f71aef
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2020 22:12:25.0397 (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: hHejtpaM+gGRUP8j6+eojJGyfgo601Y8lLaRsamLDhN/0NPz1nVSNuzKnxEbyl7t9x3/VxIxrzDfmuU9bGE8wCYZYK/+jnIXyGWT//y8Qg4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P193MB0533
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/6aYHCbWys_SRbi8PfQIBxmTLt6g>
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: Mon, 16 Mar 2020 22:12:35 -0000

Hi James,


Den 2020-03-16 kl. 13:11, skrev James Hamlin:
>
> Hi Gunnar
>
>
> Many thanks for taking the time to go through this so thoroughly.
>
>
> I think we have 2 main aspects to this work:-
>
>  1. Compatibility with existing implementations
>  2. Choosing an efficient mechanism for the future
>
> For the first of these, it seems to me that the only solution is for a 
> mixer to be able to do inline participant labeling and buffering to 
> produce a presentable single text stream. Current implementations of 
> RFC4103 will simply not understand switching between participants, nor 
> will they make any visual indication of which text belongs to which 
> participant, so the mixer needs to do that.
Yes, it is possible to implement a limited functionality 
"pseudo-multi-party" text mixer for presenting multi-party rtt on a 
point-to-point rtt terminal. A procedure is included as Appendix A in 
this draft:

https://datatracker.ietf.org/doc/draft-hellstrom-mmusic-multi-party-rtt/

When the mixer has text from more than one source to transmit, it looks 
for suitable switching moments in the text from the source it is 
transmitting. When a phrase or a sentence is complete or a line 
separator issued, or even a long pause, then the mixer decides to switch 
source and inserts a line separator and a label for next in turn to get 
its text transmitted, and then the text. This method can be used but has 
its limitations. It only displays one source at a time in real-time. 
Erasure over a switch does not work. It assumes that the receiver 
accepts to use the chat-style layout in one display area etc.

Each application area should decide what to do with old terminals who do 
not support multi-party. Implement the switching method above, or 
upgrade the terminals or refuse to involve the terminals in multi-party 
sessions.




>
> For the second we have established that it's possible to: allow the 
> different redundant blocks in a packet to be for different 
> participants; or use timestamps to resolve the correct redundant text 
> to use and to have each packet associated with just one participant. I 
> can also imagine putting all text generations of each source in the 
> CSRC list in each packet which adds 12 bytes of header space per CSRC 
> (assuming 2 redundant generations); I'll write a separate mail about 
> that.
Sound interesting.
> After that, I think we have a fairly complete set of solutions to 
> choose from.

Thanks,

Gunnar


> Some other comments inline.
>
> Best regards
>
> James
>
>
>
> 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:* 14 March 2020 11:17
> *To:* James Hamlin; avtcore@ietf.org
> *Subject:* Re: Source switching performance in 
> draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
>
> Hi James,
>
> Thanks for an interesting proposal.
>
> Let us extend the information about the packet contents of your 
> example a bit:
>
>
>
> seq         01  02  03  04  05  06  07  08  09  10  11  12  13  14  15
>
> CSRC=source  1   2 3   1   2   3   1   2   3   1   2   3   1   2   3
>
> Timestamp   91  92  93  94 95  96  97  98  99 100 101 102 103 104 105
>
>
> R2 t offset  6   6   6   6 6   6   6   6   6   6   6   6   6   6   6
>
> R1 t offset  3   3   3   3 3   3   3   3   3   3   3   3   3   3   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
>
>
> Lost X   X
>
>
> (The timestamps and timestamp offsets ("t offset") are shown in 100 
> ms, in reality it will be in milliseconds)
>
>
> The SSRC of the packet is always the mixer's SSRC.
>
> The source is indicated in the CSRC-list that in this method has only 
> one member = the SSRC of the source represented in the packet.
>
> +jeh: Agreed: My mistake.
>
>
> The timestamp is created by the mixer when sending, and the timestamp 
> offsets make it possible to calculate the timestamps the redundant 
> texts had when they were transmitted as originals.
>
>
> The receiver must store essential data from a number of packets. This 
> data is the sequence number, the source (=CSRC), the Timestamp.
>
> So, let us see what happens if both packet 06 and 07 are lost.
>
> The receiver must also store for each source, the timestamps for which 
> text has been recieved (either with real contents or empty).
>
>
> In packets 1 to 5, we have received and put in display areas for 
> source 1: "AB", for source 2: "MN", for source 3: "X"
>
>
> 08 is received and the gap (07 and 06 ) is detected (07 and 06 with 
> two redundant elements in both, making a need for retrieval of 4 text 
> elements ) is remembered so we need to do the recovery analysis..  The 
> source (2) and other essential data is noted. The original timestamp 
> of R2 is calculated as Timestamp-R2 t offset = 98-6 = 92. Checking 
> back in the list of received packets we find that we got a packet with 
> timestamp 92 (and indeed, it contained text from source 2), so there 
> is no need to recover R2. Then the original timestamp of R1 is 
> calculated as Timestamp-R1 t offset = 98-3 = 95. Checking back in the 
> list of received packets we find that we got a packet with timestamp 
> 95 (and indeed, it contained text from source 2), so there is no need 
> to recover R1. The Primary text in packet 08 ("O") is retrieved and 
> put in the display area for source 2. It is noted that we have got 
> text for timestamp 98 for source 2. The gap is still 4.
>
>
> 09 is received.  The gap (4 elements ) is remembered so we need to do 
> the recovery analysis.  The source (3) and other essential data is 
> noted. The original timestamp of R2 is calculated as Timestamp-R2 t 
> offset = 99-6 = 93. Checking back in the list of received packets we 
> find that we got a packet with timestamp 93 (and indeed, it contained 
> text from source 3), so there is no need to recover R2. Then the 
> original timestamp of R1 is calculated as Timestamp-R1 t offset = 99-3 
> = 96. Checking back in the list of received packets we find that we 
> never got a packet with timestamp 96 , so we recover R1 ("Y") and 
> insert it in the display area of source 3. The Primary text in packet 
> 09 ("Z") is retrieved and put in the display area for source 3. It is 
> noted that we got text from timestamps 96 and 99 for source 3 (the gap 
> can now be reduced to 3)
>
>
>
> 10 is received.  The gap (3 ) is remembered so we need to do the 
> recovery analysis.  The source (1) and other essential data is noted. 
> The original timestamp of R2 is calculated as Timestamp-R2 t offset = 
> 100-6 = 94. Checking back in the list of received packets we find that 
> we got a packet with timestamp 94 (and indeed, it contained text from 
> source 1), so there is no need to recover R2. Then the original 
> timestamp of R1 is calculated as Timestamp-R1 t offset = 100-3 = 97. 
> Checking back in the list of received packets we find that we never 
> got a packet with timestamp 97 , so we recover R1 ("C") and insert it 
> in the display area of source 1. The Primary text in packet 10 is 
> empty so there is nothing to put in the display area for source 1. It 
> is noted that we got text from timestamps 97 and 100 for source 1 (the 
> gap can now be reduced to 2)
>
>
>
> 11 is received.  The gap (2 ) is remembered so we need to do the 
> recovery analysis.  The source (2) and other essential data is noted. 
> The original timestamp of R2 is calculated as Timestamp-R2 t offset = 
> 101-6 = 95. Checking back in the list of received packets we find that 
> we got a packet with timestamp 95 (and indeed, it contained text from 
> source 2), so there is no need to recover R2. Then the original 
> timestamp of R1 is calculated as Timestamp-R1 t offset = 101-3 = 98. 
> Checking back in the list of received packets we find that we got a 
> packet with timestamp 98 , so we do not need to recover R1. The 
> Primary text in packet 11 is empty so there is nothing to put in the 
> display area for source 2. It is noted that we got text from timestamp 
> 101 for source 2. (we did not recover anything, so the gap is still 2)
>
>
> 12 is received.  The gap (2 ) is remembered so we need to do the 
> recovery analysis.  The source (3) and other essential data is noted. 
> The original timestamp of R2 is calculated as Timestamp-R2 t offset = 
> 102-6 = 96. Checking back in the list of received packets we find that 
> we never got a packet with timestamp 96, but from packet 09 we 
> recovered R1 from timestamp 96. So we shall not recover anything from 
> R2 here. Then the original timestamp of R1 is calculated as 
> Timestamp-R1 t offset = 102-3 = 99. Checking back in the list of 
> received packets we find that we got a packet with timestamp 99, so we 
> do not need to recover R1. The Primary text in packet 12 is empty so 
> there is nothing to put in the display area for source 3. It is noted 
> that we got text for timestamp 102 for source 3 (the gap can now be 
> reduced to 1)
>
>
> 13 is received.  The gap (1 ) is remembered so we need to do the 
> recovery analysis.  The source (1) and other essential data is noted. 
> The original timestamp of R2 is calculated as Timestamp-R2 t offset = 
> 103-6 = 97. Checking back in the list of received packets we find that 
> we already recovered text for timestamp 97, so nothing is recovered 
> and nothing inserted from R2 in the display area of source 1 . Then 
> the original timestamp of R1 is calculated as Timestamp-R1 t offset = 
> 103-3 = 100. Checking back in the list of received packets we find 
> that we got a packet with timestamp 100, so we do not need to recover 
> R1. The Primary text in packet 13 is empty so there is nothing to put 
> in the display area for source 1. It is noted that we got text for 
> timestamp 103 for source 1 (the gap can now be reduced to 0)
>
>
> 14 is received.  The gap is now 0 so we do not need to do any recovery 
> analysis.   The source (2) and other essential data is noted. The 
> Primary text in packet 13 is empty so there is nothing to put in the 
> display area for source 2. It is noted that we got text for timestamp 
> 104 for source 2.
>
>
> After this, we have in the display areas:  for 1: "ABC" for 2: "MNO", 
> for 3: "XYZ", so everything is recovered.
>
>
> I am sorry, the narrative above may be hard to follow. It could 
> probably be converted to some table format if we need to do it again 
> for other cases.
>
>
> So, yes, this method also works.
>
> I see a couple of differences in characteristics between this 
> "timestamp method" and the "CSRClist method":
>
>
> 1. The recovery time from loss to recovery can with the timestamp 
> method be 200 times the number of simultaneous sending sources in 
> milliseconds. Thus with 5 sources: 1 second. With the CSRClist method, 
> it is steady 200 milliseconds. (assuming a transmission interval of 
> 100 ms and round robin mixer switching.)
>
>
> 2. The recovery capacity in packets in sequence is 2*the number of 
> simultaneous sources = 10 packets for 5 sources. With the CSRC method 
> it is 2 packets. (again assuming round robin mixer switching )
>
>
> 3. The complexity of the procedure is higher but still manageable for 
> the timestamp method.
>
> jeh: Yes. I had thought this would be simpler, but the timestamp logic 
> gets complicated.
>
>
> 4. The number of packets to store essential information about is 
> higher for the timestamp method ( I think it is 4*the number of active 
> sources). For the CSRC list method, it is 4 packets and less 
> information per packet.
>
>
> You say: "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."
>
>
> I do not see the CSRClist method as a change in packet format.
>
> jeh: Agreed: I should have said that differently: the change is that 
> the text over the redundant and primary block is no longer continuous; 
> it's for different participants.
>
>
> The mixer needs in both methods to include a CSRC -list. The 
> difference is that in the CSRClist method, the list has more members. 
> It is still within the format description of RTP. The source of the 
> redundant parts will vary in a packet, but the composition of the 
> contents of the packet for transmission from the mixer is as usual for 
> a single sender: Put what was sent next to last in the packet as R2, 
> put what was sent last as R1, and put the new text chunk as P. The 
> only addition is the rule that the CSRC list is populated with the 
> sources in the strict order.
>
>
> Summary: both methods seem possible. It will be interesting to get 
> more comments.
>
>
> Thanks,
>
>
> Gunnar
>
>
>
>
>
>
>
>
> Den 2020-03-14 kl. 01:45, skrev James Hamlin:
>> 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
>>
>>
>>
>> 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:
>>> 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
>>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> -- 
>>
>> + + + + + + + + + + + + + +
>>
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se
>> +46 708 204 288
> -- 
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46 708 204 288

-- 

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

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