Re: [AVTCORE] Question on multi-party RTT handling (draft-ietf-avtcore-multi-party-rtt-mix-02)

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Wed, 27 May 2020 17:39 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 9F08E3A0062 for <avt@ietfa.amsl.com>; Wed, 27 May 2020 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 m9zAriXVasgO for <avt@ietfa.amsl.com>; Wed, 27 May 2020 10:39:38 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60111.outbound.protection.outlook.com [40.107.6.111]) (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 727B13A0045 for <avt@ietf.org>; Wed, 27 May 2020 10:39:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YP5nF4VvAsMwVPrUffEWo+sj3UIiUpxAEJ054iEqNpiXy1ddZlL2STIWcM+VLU6SN5UCpDMnWIEnR5m5yV4BryF5RpYUX+CGrHLiqQNd54fMG+wmSLUVExom8pnTXW+R6QEFFQIw7RLjDHPzj1/R1+/DIBDK13qK/V7KYtj3PLUmV/t51kCbjZuLPQjAYa2XmZZgtgosC6WeOGKrf1u37g9HAOjB/b9eB18bXsk0XcEQr7Ka6Ox9CD2811/RIYkyq3IAGP+/eGM9IFCRUCBJ9dpNM0iLLNkU5uWHfgv889ryveA4RMT7SquzAj9REMl6U+Tdg8RX+3QL6yH31ocbcg==
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=61QdcCnyYdWzAtZNzyD6zc9cPb6Npx88E+ervwPPeM8=; b=cgYhx4lPzNXzqgLzRDvSjZVeVpJPXzn76vjEuQTAeaJJPUnpjdeiqVIDBbg3gwz6COg2aGN8KSxCsfL/KlMFJ/8Okx7Gp5s0fPIyLf3IRn3wNuoH9AMuHzqgSaqwYSn/r7diZJfy7Gb351Uf2vVAKDdakKt81MeCZv+LsxKQm7F79ApVgoeUZV9r3RNF7LmImv/tfbzP+XEnN5Ps0PChqOGVeg1sh2Xh8J8iTzEGOXvo+k/nHeBgV0fOMq1y6M3esRYbmElwuTXClYbYCE9/wq1PaXZQ9c8C5czyr6nqN25zpzZTo8n2X9UK+rhHd/Lw3YDes5mWYATjXECxqSmNgA==
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=61QdcCnyYdWzAtZNzyD6zc9cPb6Npx88E+ervwPPeM8=; b=N1j9A67mKTP5snF9m8x9cHb+5+FkwRn+WdApFHPiTqycrR/MoLqxceH/8YQX3fFjPPydQy7/enwv/QTqpsV5KtnJ4hH1IYhanubIMwgNMTgTogj6dYUuoODVw/gjqqePeJD2HSMqE8SB/nDQ+C9PIKS2eD3xtX5DVkvinEz5p6M=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=omnitor.se;
Received: from PR3P193MB0650.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:32::13) by PR3P193MB0540.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:3b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Wed, 27 May 2020 17:39:33 +0000
Received: from PR3P193MB0650.EURP193.PROD.OUTLOOK.COM ([fe80::cc04:8066:494b:a9e2]) by PR3P193MB0650.EURP193.PROD.OUTLOOK.COM ([fe80::cc04:8066:494b:a9e2%8]) with mapi id 15.20.3045.016; Wed, 27 May 2020 17:39:33 +0000
To: avt@ietf.org
References: <SN4PR0801MB36806FF9CD2538E08E95CDCD9CB60@SN4PR0801MB3680.namprd08.prod.outlook.com> <8e29faf8-2abc-d7d2-6551-8c2fcfee9545@ghaccess.se> <MWHPR0801MB3674D15E6F2011F31323FFF69CB40@MWHPR0801MB3674.namprd08.prod.outlook.com> <ebc55345-21e4-67e0-5161-70bb8941599c@ghaccess.se> <MWHPR0801MB3674E1617DF2EB5ABA1E438B9CB40@MWHPR0801MB3674.namprd08.prod.outlook.com> <aa86310e-5a98-3276-ee60-c6ec4c377c66@ghaccess.se> <MWHPR0801MB3674B270CB72EEB98D3F9A099CB00@MWHPR0801MB3674.namprd08.prod.outlook.com> <31c75ef2-f75c-8300-aa24-e5bd526c8e28@ghaccess.se> <MWHPR0801MB3674C03BFC430333683CA45F9CB10@MWHPR0801MB3674.namprd08.prod.outlook.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <4806bfe8-27d3-99f6-dda9-53cd6f914871@omnitor.se>
Date: Wed, 27 May 2020 19:39:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
In-Reply-To: <MWHPR0801MB3674C03BFC430333683CA45F9CB10@MWHPR0801MB3674.namprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B8911B00AE0189D8F427D999"
Content-Language: sv
X-ClientProxiedBy: HE1PR05CA0338.eurprd05.prod.outlook.com (2603:10a6:7:92::33) To PR3P193MB0650.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:32::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.2.136] (79.138.72.251) by HE1PR05CA0338.eurprd05.prod.outlook.com (2603:10a6:7:92::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17 via Frontend Transport; Wed, 27 May 2020 17:39:33 +0000
X-Originating-IP: [79.138.72.251]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: edf4abf3-6926-4a44-f40e-08d80264eac4
X-MS-TrafficTypeDiagnostic: PR3P193MB0540:
X-Microsoft-Antispam-PRVS: <PR3P193MB0540802032719087733E7EADFBB10@PR3P193MB0540.EURP193.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 04163EF38A
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: NvlJvurpHLPX9q+mYsjeWi3YgUU6Zow3DCqQZkKTkVjbt4yxzHZIz3lIVaRkKyTSOAUOOAheEnjoYu2WdEA1vDZXgegirRDNFcWkIyzCh2iHGEx2s3RylMFVCVQUl/Rh72qzptTHDfKJS/zEhjYhg/og3UwT7nHl4g/yl04RPejPJQ8BBPLjo0KBGnIa59kf1nm9qwpDlPE1feTENFEuQVRfDQaT+WCf7bI+1TmUQlzgP+4FM2BRYl/2OR9IgFcbZ+Ls4Ex98cr1M39Vmp6d0NtIfmChexloYpE22Lqk9zoqgOmo7Qg0iy+Tsh9bZ7Zq20lUUZKelLnGtJeeF7aRgfswXM3/Y+Uu4iUShaRD8nRM5vcVvAXRVklEO5fFaTENZFKXWa0Gq0esYBVDu97TzDSpmb4NyrXyRmACLXb2GrfGp8APDtkreX3HxWLAcSeS/+4uxGgT5OgkixOagLos7A==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P193MB0650.EURP193.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(396003)(366004)(39830400003)(136003)(346002)(376002)(66574014)(166002)(6486002)(8676002)(53546011)(2616005)(956004)(31686004)(52116002)(26005)(316002)(186003)(16526019)(2906002)(16576012)(508600001)(8936002)(36756003)(31696002)(66946007)(66556008)(66476007)(5660300002)(966005)(30864003)(83380400001)(6916009)(86362001)(43740500002)(579004)(559001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: 73/4GrAIx6TwAAcdsp/fuJ8XcZhjRNNAOJjF5vsOcY6cz68OZnhs/ZxpxVNE9cE1S/w6zEgPy9ssajK60niyO4FPcDhG+/pN2lfCAQu317x8KEO818P/ATX2oNsrXo5ZuvE/7Vhypx/vTPX2XVKz3JYl+oy2d7ns5QOUGjh8iJulQQbTG/U7YkV3hTkLL9Se06pjXomOCbRaVz5m1596OvwTB5/J/n/2QXL95HEiQ+Lav0BIX0IGliRL4hwKql9nwevsZZQKA3kUJKN/buEEdmSzLQvHtctLXyqVktoS8WcKSAomEx/K7mvHyI+Ob2axJC35dcZG+2dHAS4k4aPuKNWQT1o/ABez0yBK0qqt9BE/ktSxzotOTarOWo8ajqXQezI74pVoNJiznZhstVMraahtVGU8O9uho4pZvY1wn7yqLCro0AuBN1ocZp2nzAOZl2t++79erek+bMK+c65fdG/ps1jyEE6gPgv4kaT1ZoM=
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: edf4abf3-6926-4a44-f40e-08d80264eac4
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2020 17:39:33.7072 (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: F3RbXnMcMpAgICpg076oX3aAJH6hZKLIbOe6rRrQbrEw2UessctHatT5wEXy0LODUO0JnbJTMNOvHuwf6BnujLY2VMMym3KhIHcz5rbWgI0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P193MB0540
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/KniTpWJR3ZWoaFKzBtRMtqop_l8>
Subject: Re: [AVTCORE] Question on multi-party RTT handling (draft-ietf-avtcore-multi-party-rtt-mix-02)
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: Wed, 27 May 2020 17:39:42 -0000

Hi Yong,

Den 2020-05-27 kl. 17:32, skrev Yong Xin:
>
> Hi Gunnar,
>
> Agreed, the mixer performance requirement of 5 simultaneous text 
> sources with less than 500ms delay should be sufficient. BTW, do you 
> expect to send the BCP document 
> https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-solutions-00 
> to IESG for approval around the same time (Feb/2021) as the standard 
> track document 
> https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-02?
>
The .....-solutions document has not yet gone through the procedure to 
be adopted as a working group draft. So, there is no current plan for 
its completion date.

I have included a few words about the performance requirements in next 
version of draft-ietf-avtcore-multi-party-rtt-mix 
<https://tools.ietf.org/html/draft-ietf-avtcore-multi-party-rtt-mix-02> 
now.

Are there any specific part of 
draft-hellstrom-avtcore-multi-party-rtt-solutions 
<https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-solutions-00> 
that you see value of to see published?

Regards

Gunnar

> Thanks,
>
> Yong
>
> *From:* Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
> *Sent:* Tuesday, May 26, 2020 11:01 PM
> *To:* Yong Xin <Yong.Xin@radisys.com>
> *Cc:* avt@ietf.org
> *Subject:* Re: Question on multi-party RTT handling 
> (draft-ietf-avtcore-multi-party-rtt-mix-02)
>
> Thanks Yong for feedback,
>
> We discussed performance requirements initially. I have checked the 
> requirements from regulation outside of the emergency services. There, 
> there is only a requirement to identify the source and be able to 
> switch source smoothly in an ordely way between users taking turns 
> properly.
>
> In practice I know that there will be some simultaneous typing, at 
> least for very brief indications, like "I want to say something" or 
> "that suits me". So, good switching performance without much extra 
> delay between 5 simultaneous typing users as the documented goal in 
> draft-hellstrom-avtcore-multi-party-rtt-solutions-00 seems to be a 
> safe and maybe a bit high requirement.
>
> With the intended use for emergency services, the situation is similar 
> there. I expect eager users in emergency to sometimes type longer 
> explanations while they get instructions. But instead fewer extra 
> persons jumping in with comments. So also there, switching without too 
> much extra delay between a maximum of 5 simultaneous senders seem to 
> be a safe and a bit high requirement.
>
> Regards
>
> Gunnar
>
> Den 2020-05-26 kl. 19:12, skrev Yong Xin:
>
>     Thanks Gunnar for the clarification and suggested change in next
>     revision – they all look good to me
>
>     Regards,
>
>     Yong
>
>     *From:* Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
>     <mailto:gunnar.hellstrom@ghaccess.se>
>     *Sent:* Saturday, May 23, 2020 6:24 AM
>     *To:* Yong Xin <Yong.Xin@radisys.com> <mailto:Yong.Xin@radisys.com>
>     *Cc:* avt@ietf.org <mailto:avt@ietf.org>
>     *Subject:* Re: Question on multi-party RTT handling
>     (draft-ietf-avtcore-multi-party-rtt-mix-02)
>
>
>     	
>
>     The e-mail below is from an external source. Please do not open
>     attachments or click links from an unknown or suspicious origin.
>
>     Hi Yong, please see inline,
>
>     Den 2020-05-23 kl. 01:31, skrev Yong Xin:
>
>             Thanks for the quick response. The latest spec does
>             address my concern. I have some follow-up questions:
>
>               * The new payload format “text/rex” can be used with or
>                 without redundancy. When redundancy is used, mixer has
>                 to use the same redundancy level when transmitting
>                 texts from multiple sources. If the different party in
>                 the same conference has negotiated a different
>                 redundancy level, the mixer has to pick the lowest
>                 level to use, right?
>
>         No. There are two sides of this answer:
>
>         The mixer should do separate mixing for each recipient, using
>         the redundancy level agreed with each recipient. This is also
>         because the users do not want to see their own transmitted
>         text being received from the mixer. The own text is displayed
>         locally by the endpoints. If the recipient does not support
>         "text/rex", the mixer also need to do the mixing for
>         multi-party unaware endpoints using the "text/red" format 
>         described in section 13.2.
>
>         */[YX] Understood, the text mixer is providing N-1 mixing,
>         similar to audio mixing, so the user never receive their own
>         transmitted text from the mixer./*
>
>     */[GH] /*Yes. I see I have that specified for the multi-party
>     unaware mixing in 13.2.2 by this sentence: "Text received from a
>     participant SHOULD NOT be included in transmission to that
>     participant." I suggest I include a similar sentence in 13.1 for
>     the multi-party aware case.
>
>         And the mixer must recover from loss in reception from each
>         source and create a queue of clean text from each source
>         before composing the packets for transmission. The mixer
>         cannot just resend received packet contents with redundancy,
>         because the recovery mechanism requires the sequence number
>         gaps for loss detection, and the mixer must create its own
>         sequence number series in the transmission.
>
>         */[YX] I agree what you said here. I think I’m little confused
>         when reading the following paragraph in section 3 of the spec.
>         Let me put an example, there’s a 3-party conference and all
>         participants (A, B, C) are conference-aware RTT terminals and
>         support text/rex packet format. User A, B, C negotiates
>         different redundancy level 2, 3, 1 respectively. When mixer
>         transmitting text (source from B & C) to user A, what is the
>         number of redundant generations should be used by the mixer in
>         the transmitted packet? Is it 2 or 1? /*
>
>     [GH] It is 1. I see my wording is confusing. I suggest to improve
>     the yellow sentence fron the paragraph below to read: "/ItSHOULD
>     be set to the minimum of the number declared by the two parties in
>     the SDP exchange."/
>
>     It can be discussed if the minimum of what the parties declared is
>     the best choice. It is quite common that SDP parameters declare
>     what the party wants to receive. In this case the number can be
>     decided by the party knowing the network conditions in the
>     network, or it can know it has decoding limitations and does not
>     want to receive more than a specific number of generations in the
>     packets. It may also have coding limitations, so that it cannot
>     create more generations than itself can receive. That made me
>     think that the resulting number of generations sent should be the
>     minimum of what the two parties in each connection declared. I can
>     change that to say that "It SHOULD be set to what the other party
>     declared". What is actually used in the stream is found by
>     dividing the number of data header entries with the number of
>     members in the CSRC list.
>
>     This discussion is a bit theoretical, because the default is one
>     primary and two redundant generations, and there are rarely any
>     reason to deviate from that.
>
>         *//*
>
>         /   The number of redundant generations of T140blocks to
>         include in/
>
>         /   transmitted packets SHALL be deducted from the SDP
>         negotiation. It/
>
>         /SHOULD be set to the minimum of the number declared by the
>         receiver/
>
>         /and the transmitter//.  The same number of redundant
>         generations MUST/
>
>         /   be used for all sources in the transmissions.  The number of/
>
>         /   generations sent to a receiver SHALL be the same during
>         the whole/
>
>         /   session unless it is modified by session renegotiation./
>
>               * But in case there’s one party has negotiated
>                 “text/rex” without any redundancy level, does that
>                 mean mixer has to turn of the redundancy for this
>                 conference? Does mixer need to change the redundancy
>                 level up and down dynamically as user joins or leaves
>                 the conference? Does mixer need to send re-INVITE to
>                 re-negotiate the redundancy level with other party
>                 when such change happens?
>
>         From the logic above, the answers on these questions are: no.
>         I realize that an explanation should be inserted in the
>         beginning of section 3. "Actions at transmission by the mixer"
>         to clarify that the source for transmission from the mixer is
>         clean text in separate queues regardless of which format or
>         protocol they used in the individual receptions.
>
>
>
>         */[YX] This is related to the above question. Some
>         clarification in the spec would be helpful../*
>
>               * In section 12, I noticed the 150cps recommendation is
>                 still there and has been made as default value for the
>                 new packet format, but the transmission interval is
>                 back to 300ms (the recommended interval was 100ms in
>                 the old spec). I guess with the new packet format, it
>                 is not required to use the shorter transmission
>                 interval any more.
>
>         The transmission interval is mentioned in two paragraphs in
>         section 3. One saying that the default is 300 ms, the other
>         saying:
>
>         "For multi-party operation, it is RECOMMENDED that the mixer
>         sends a packet to each receiver as soon as text has been
>         received from a source as long as the maximum number of
>         characters per second indicated by the recipient is not
>         exceeded, and also the number of packets sent per second to a
>         recipient is kept under a specified number..  This number
>         SHALL be 10 if no other limit is applied for the application. 
>         The intention is to keep the latency introduced by the mixer low."
>
>         This is intended to create a balance between low latency and
>         protection against bursty packet loss. Even if the latency
>         requirements from real-time text users are much lower than
>         from audio and video users, a low latency is appreciated, and
>         latency of over 2 seconds end-to-end creates conversation
>         problems.  Therefore, this paragraph about when to transmit
>         will self-regulate to about 100 ms packet interval from about
>         3 simultaneous typing sources.
>
>         The 300 ms default assures that the remaining redundancy
>         transmissions will be sent even shortly after all sources have
>         stopped typing.
>
>         */[YX] So are you saying the recommended transmission interval
>         in the new spec is still 100ms, and the 300ms is actually the
>         time that covers 3 transmissions (one primary transmission
>         plus 2 redundancy transmissions, assuming redundancy level 2),
>         is my understanding correct? I guess this is better clarified
>         in the new spec. The old spec is much clear in this definition. /*
>
>     */[GH]/*The intention now is to not have a fixed interval, but
>     have it variable between 100 and 300 ms. This is in order to not
>     add delay by the mixer when it is possible to avoid it.
>
>     So, when the mixer receives a packet, it checks for each party it
>     is sending to, if it already has sent 10 packets to that party
>     during the last second. If not, it sends the just received text
>     immediately on to that party together with whatever redundant text
>     there was to be sent. If it already had sent 10 packets, then this
>     text needs to wait in queue until 300 ms has passed from the
>     latest transmission and then sent together with any other new text
>     and the redundancy. Whoops, there was a logic error in that
>     algorithm. It can allow a burst of 10 packets sent to one party
>     with very short intervals, and then three more packets during the
>     same second with 300 ms interval. That causes a risk for loss of
>     text if a short burst loss happens when the 10 packets are sent.
>     And it results in 13 packets sent when the limit was intended to
>     be 10.
>
>     So, it is likely better to say in chapter 3:
>
>
>     " A "text/rex" transmitter SHOULD send packets distributed in time
>     as long as there is something (new or  redundant T140blocks) to
>     transmit.  The maximum transmission interval SHOULD then be 300
>     ms. It is RECOMMENDED to send a packet to a receiver as soon as
>     new text  to that receiver is available, as long as the time after
>     the latest sent packet to the same receiver is more than 100 ms,
>     and also the maximum character rate to the receiver is not
>     exceeded. The intention is to keep the latency low while keeping a
>     good protection against text loss in bursty packet loss conditions."
>
>     The introduced delay for up to 16 simultaneously sending users
>     will be between 0 and 100 ms. I think it is good that a middlebox
>     like this does not introduce more latency. I hope we can have a
>     discussion if we instead get too high risk for text loss in case
>     of bursty packet loss.  With intensive participants the coverage
>     for such loss is only 200-300 ms, while at low traffic it is
>     600-900 ms.
>
>         *//*
>
>         However, this algorithm may make the protection against bursty
>         loss weaker than with a steady 300 ms interval. With between
>         17 and 32 simultaneous typing users, the latency caused by the
>         mixer will be around 300 ms and then passes both regulatory
>         and human requirements.
>
>         Now, even if it passes the requirements, 32 is a very
>         unrealistic number of simultaneous typing users. In audio
>         conferences it is only possible to perceive one source at a
>         time well. The benefit of enabling more is just for noticing
>         that someone else want to say something. Requirements for this
>         work are collected in
>         draft-hellstrom-avtcore-multi-party-rtt-solutions-00, and
>         there the performance requirements are set to be valid for up
>         to 5 simultaneously transmitting users and the delay caused by
>         the mixer to be less than 500 ms. I think we should design for
>         these figures.
>
>               * And you mentioned these characteristics provide for
>                 smooth flow of text with acceptable latency from at
>                 least 32 sources simultaneously. Since the new packet
>                 format can support up to 16 sources per packet, the
>                 text from 32 sources will have be transmitted in turn.
>                 If my calculation is correct, with 300ms transmission
>                 interval and redundancy level 2, it will take 900ms
>                 (one primary + 2 redundant) for mixer to switch from
>                 first 16 sources to next 16 sources, so the delay is
>                 about 900ms. Is this the acceptable latency in your mind?
>
>         See discussions above. Maybe regulators need to say how many
>         simultaneous users the requirements are for. I think 5 is a
>         high and good figure even if the discussion above indicates 32
>         to be possible.
>         */[YX] Yes I agree, at least for emergency type of service, I
>         don’t see a multi-party use case that requires more than 5
>         parties /*
>
>     [GH] I want to create a specification that is regarded sufficient
>     for all realistic use cases. The most commonly foreseen emergency
>     service use case has only two occsionally simultaneously
>     transmitting users.
>
>     It is hard to imagine a use case with 5 simultaneously sending
>     participants, where it would be important for a user to be able to
>     read text from one source with less than one second delay.
>
>     It does not happen for audio. As soon as two talks, the result is
>     usually not perceivable.(Except in the efforts you experience now
>     in Corona-times, with a choir of individual conference
>     participants trying to sing together.)
>
>     With video, you cannot concentrate on what more than one does. But
>     the mixer can usually present up to 9 or 16 or so with maintained
>     temporal resolution but less spatial resolution. The receiver
>     selects one to perceive.
>
>     One application that could cause many simultaneous sources of text
>     would be a conference with voice to text translations in many
>     languages for a large audience. That will require a user interface
>     at the receiving end that shows one selected text stream and hides
>     everything else. I imagine that there are other mechanisms for
>     that already. It cannot be the application we design for, but I
>     dont mind if it will be possible.
>
>     This reasoning tells again that a goal of 5 simultaneous text
>     sources with less than 500 ms delay is high but maybe realistic in
>     some situation, and our solution that provides for 16 simultaneous
>     transmitting users and 0-100 ms delay meets the requirement well.
>     I do not think we will need to mention the 32 simultaneously
>     transmitting users still meeting the requirements.
>
>     I will adjust the performance chapter and the introduction for this.
>
>         [GH] Thanks.
>
>     -- 
>
>     Gunnar Hellström
>
>     GHAccess
>
>     gunnar.hellstrom@ghaccess.se  <mailto:gunnar.hellstrom@ghaccess.se>
>
> -- 
> Gunnar Hellström
> GHAccess
> gunnar.hellstrom@ghaccess.se  <mailto:gunnar.hellstrom@ghaccess.se>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 

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

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