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
>