Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-multi-party-rtt-mix-09.txt
Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 12 November 2020 15:20 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 568533A11D9 for <avt@ietfa.amsl.com>; Thu, 12 Nov 2020 07:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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=alum.mit.edu
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 cnwKPpDCYmpg for <avt@ietfa.amsl.com>; Thu, 12 Nov 2020 07:20:36 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2085.outbound.protection.outlook.com [40.107.94.85]) (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 9A6593A11D3 for <avt@ietf.org>; Thu, 12 Nov 2020 07:20:36 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bylcef5IJEUkzNNXh/2a9EMCrsSkeoZpljGUU529YQgALpQ0ujoiLA9ypF1NYCsNe62PrtWkfjZg4DjB4Lwrzmrgka/dHEiwCQZ2GNchNf2qRFrDNLMFxBGmIWmGHnf3Y/Hr5ENj8Ff1aYFjmPoKMYxAwsyrCqvq9BfR0NWvu1ubUmWXcdDWGNs3AZA7Rp6aLuhC+bJ4UKVcPLxdjchSHXewCLHOkBuwcXnQ5rVHwXikYQ/Xw0ArQLgoobiL8lDRHn5EvNIIUnnnK4OG3ufRKdLlt64DozEENM1CHEb3ve754e0HNnW6qBzVhzOrVjJ/LRBRwwo3m/l3kfdoi83M7w==
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=LEG5sel2ji/FGcXuVEyTkCE/zGudqevSUROgs+1vZy0=; b=Q/z1rjzImsswF/5ujU5dLlIwZiSSPwh8hp1aiRAtlkoHmFceWmlC5GhQXs8qebgK1Ph2ewfoMhsZ8rDU7yOvCBi03Z1PBTU7lSE5/D0WF009OPR7Vojlp1liWCkYB+8laTkX6O72tv8aZwwQMBnCCncwZ4dGwD9fh4aILnGl47OFVsl5dC78sGUCP+FVOT8DcTBRNOwLGx3Cz+49aHZzeWARBOewFjci2GhbbcpjRHxFfFENLxL52uPO+HmpBY7yaXntF+U4Rahbd3DsUk9+YK0T/3KIzt7tD5TjPZ6SAoI+AUUC5eAhNTO1GItkEi2tnZ/xazIqg84NsIhUK+E8gA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LEG5sel2ji/FGcXuVEyTkCE/zGudqevSUROgs+1vZy0=; b=hsXi6MCO0KPaCqfUVzjPWGhpNZrLG+ZisdokNwjrX7qbbFiuyC8mU/zSgpOXjTrIyAYVqpranIjIBKcb96oKE6oGAqOHJMHvjz+v/X+L89qT/J80F6yJIf9BHb8rcjZfa3EUvQqLnwlpSgmPvf2CpcdKaTW0+5FdbIpVl8yGDo4=
Received: from BL1PR13CA0017.namprd13.prod.outlook.com (2603:10b6:208:256::22) by CH2PR12MB3880.namprd12.prod.outlook.com (2603:10b6:610:2b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Thu, 12 Nov 2020 15:20:34 +0000
Received: from BL2NAM02FT040.eop-nam02.prod.protection.outlook.com (2603:10b6:208:256:cafe::d8) by BL1PR13CA0017.outlook.office365.com (2603:10b6:208:256::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.21 via Frontend Transport; Thu, 12 Nov 2020 15:20:34 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT040.mail.protection.outlook.com (10.152.77.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.22 via Frontend Transport; Thu, 12 Nov 2020 15:20:34 +0000
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 0ACFKWt7023521 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <avt@ietf.org>; Thu, 12 Nov 2020 10:20:33 -0500
To: avt@ietf.org
References: <1605182709686.62555@purple.us>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <39c61203-0f62-ec4b-7750-83df034bae82@alum.mit.edu>
Date: Thu, 12 Nov 2020 10:20:31 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.2
MIME-Version: 1.0
In-Reply-To: <1605182709686.62555@purple.us>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d7c1e00f-47e1-4e07-5a2c-08d8871e804e
X-MS-TrafficTypeDiagnostic: CH2PR12MB3880:
X-Microsoft-Antispam-PRVS: <CH2PR12MB388076A55E0901A883DAAF58F9E70@CH2PR12MB3880.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 0E0o7R4xe1Y1R5g3shgzAm1KJKD2ReDLHsotFpKYPrubjZKRzlvcZlPInA5Kez02wG7EcdZosiP7ZQ0Gy1w14j9IHsW3I8uwcw3qe7InkygsZcAOdUPhtoGBI4iiCLWWlrXJ8lX9I/qPW4e0UekrBlhbLh8FYjmvXgke+/ny5L15MtZqGOjRjFwZy0gwscB7QAthbqLs1CO3eVC/h4MpFB4GuvUqet71l1Zf0qyRrVGC0trtMIsotqKjP3EE3YZeYMGvfL7hhgAW2CEA2Cx9SudReLSQB5aNvyi2EkMbJq63dFlsVoSbj5540g/XAqSFLoMFsD0AG8UQQlbzzVCMMpoQZDA2EZYHf4iSD0VFGbPwElm6gmm6MJyMdRIYOF6m9yqM69sxAkvK3QQab0X19hGLAfo8DUyC26TMA5IU9uQU6Oxmhc3MfUAzNW45SXCXUztYZvzRW5JRhLb0R3OXLYXYCIUxmbKqx4hV++J9bhM3W8LSy5Cf29u8Jv5D2k27
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(346002)(396003)(39860400002)(376002)(136003)(46966005)(478600001)(82740400003)(75432002)(316002)(36906005)(53546011)(31696002)(83380400001)(7596003)(356005)(186003)(956004)(82310400003)(336012)(6916009)(47076004)(2616005)(8936002)(5660300002)(786003)(70586007)(2906002)(26005)(70206006)(31686004)(966005)(15650500001)(8676002)(86362001)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2020 15:20:34.3702 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d7c1e00f-47e1-4e07-5a2c-08d8871e804e
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT040.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3880
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/J_2G4ZVPcI1Jl_VzjC2TyNngoA4>
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-multi-party-rtt-mix-09.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: Thu, 12 Nov 2020 15:20:39 -0000
James, Comment toward the end... On 11/12/20 7:05 AM, James Hamlin wrote: > Hi Gunnar > > > I had another look at the recovery text at the end of section 3.23. I > think the statement > > "If CSRC is different before and after the gap, a gap of 4 can be > recovered if the last packet before the gap contained only R2 data" is > should read: > > "If the CSRC is different before and after the gap, a gap of 4 can be > recovered if the last packet before the gap contained primary data and > the newly received packet contains R2 data". > > I also think the condition for a 'third' CSRC to have been active in the > missing packets is more complicated than stated. > > > To avoid the document getting too complicated, it might be better just > to say that receivers should put in a missing text mark against the > mixer unless they have implemented an algorithm that > determines that loss is limited to a smaller group of participants. > > > I think the diagram below might help to visualize the conditions where > it is possible determine from sequence numbers, where loss has occurred. > WARNING: it's upside down with primary at the top and I've used the word > "step" instead of "gap" and then used "gap" to refer to the gap that > determines whether a 'third' party CSRC could have been active in > the missing packets. I've deliberately used more than 3 redundant > generations as RFC4103 doesn't set a limit. Colored blocks represent > data and white an empty or undetermined block. > > > A receiver has a newly received packet and a previously received packet, > with a lower sequence number. > > From the newly received packet one can draw a square showing the packets > that are known to have been from the second participant (in this case > the blue participant). The green arrows show data that can be > recovered and the yellow show that the two empty redundant > generations show where primary blocks must have been empty. > > From the previously received packet one can draw a square (in this case > for the red participant), showing the packets that must have been for > that participant, to run out remaining redundant generations. > > > Then, to work out if anything was lost, by any participant, try to draw > test squares with primary data in the top left, which reach to the > bottom of the diagram. It is only possible for something to be lost, if > such a square can be drawn that doesn't overlap a square with a > different participant's color. > > > So, in the diagram, one couldn't draw a 5*5 square in orange without > overlapping the blue or red so there was definitely no text from anyone > other than blue and red. > > It is possible to draw red 5*5 squares starting in the > first, or second lost packets, without overlapping the blue and so it is > possible that there was unrecoverable loss of the red > participant's text. It is also possible to draw a blue square starting > at 4th missing packet, without overlapping the red square so it is > possible that there was unrecoverable loss of the blue participant's > text. It is also possible that there were keep-alive packets meaning > that nothing was lost. It is also possible to draw a blue square > starting at the fifth missing packet but we know that primary was > empty (follow the yellow arrow). > > > > Using this mechanism, I think the algorithm for determining packet loss > markers is:- > > > let step = the difference in the start and end sequence numbers + 1; // > When no packets are missing step == 2 > let n_gen = number of generations including primary > let block = depth to last non-empty redundant block in the newly > received packet; > let p_block = n_gen - depth to first non-empty redundant block in the > previously most recently received packet; > let gap = step - block - p_block; > > > if (gap >= n_gen) then > > Insert a missing text marker against the mixer; // missing > text could have been from anyone > > else > > if (change in participant) then // CSRC is different before and > after the missing packets > > if (step - p_block > n_gen) then > > Insert a missing text marker against the second participant; > > endif > > > if (step - block > n_gen) then > > Insert a missing marker against the first participant; > > endif; > > > elseif (step >= n_gen) then > > insert a missing marker against the participant; > > endif > > endif > > As said above, it probably makes sense to keep this detail out of the > document and err on the side of caution by encouraging > implementers to mark text missing against the mixer. I agree that such detail could make the document difficult to follow. Yet it seems helpful. You might consider putting it in a non-normative annex - as a hint about how a developer might approach this problem. Thanks, Paul > I see from previous mails that you are looking at using timestamps to > assist recovery; I haven't considered that in the above. > Apologies for bringing this analysis a bit late in the day; and I > may have made mistakes - happy to be corrected. > > > 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. > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >
- Re: [AVTCORE] New Version Notification for draft-… Gunnar Hellström
- Re: [AVTCORE] New Version Notification for draft-… Dan Mongrain
- Re: [AVTCORE] New Version Notification for draft-… Brian Rosen
- Re: [AVTCORE] New Version Notification for draft-… Gunnar Hellström
- Re: [AVTCORE] New Version Notification for draft-… James Hamlin
- Re: [AVTCORE] New Version Notification for draft-… Paul Kyzivat
- Re: [AVTCORE] New Version Notification for draft-… Gunnar Hellström
- Re: [AVTCORE] New Version Notification for draft-… James Hamlin