From nobody Wed Nov 15 07:09:49 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10E112949B for ; Wed, 15 Nov 2017 07:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 tc12_2FuZDPO for ; Wed, 15 Nov 2017 07:09:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8948912944E for ; Wed, 15 Nov 2017 07:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=810; q=dns/txt; s=iport; t=1510758586; x=1511968186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hPfcgqzQKfYhMqpZsCCaG4uy+cJ4CGgBijFuefN6k+Q=; b=cKJx5LljBc2/+PxR9l2xA1h3Gu4HvoI25endw52Q5NiUafNNAlAjPgD5 owpJdYo4DQp1KPxLp1ZOuxHEqN5AMtrelqRe+VATelE35aG6NmRYFZqXO S2c/2mzISsDG+KMDj04qEwbGeVwAxU0bamzyUNpOTyAQJO98MTS8lsnVb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAADsVwxa/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2gVIujhePHo43iiOCEQqFOwKFDj8YAQEBAQEBAQEBax0LhR8?= =?us-ascii?q?GOj8QAgE+EDIlAgQOiimqUYsTAQEBAQEBAQEBAQEBAQEBAQEBAR+DNIIHgVWBa?= =?us-ascii?q?Y46BaI3AoFyiWKJMIcBjEOWAQIRGQGBOAEfOIF0ehWDLoRei3aBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,399,1505779200"; d="scan'208";a="314786077" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 15:09:45 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAFF9jTd004355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 15:09:45 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 09:09:45 -0600 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Wed, 15 Nov 2017 09:09:45 -0600 From: "Mo Zanaty (mzanaty)" To: "payload@ietf.org" CC: Ben Campbell , Roni Even , "Ali C. Begen" , Varun Singh , "mandyam@qti.qualcomm.com" Thread-Topic: Status of draft-ietf-payload-flexible-fec-scheme Thread-Index: AQHTXg7as+JhS09aBEu331hPu8k2oqMVnGMA Date: Wed, 15 Nov 2017 15:09:44 +0000 Message-ID: References: <41E9B92E-3BD1-4430-A084-F4037E80D969@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD8367C8@DGGEMM506-MBX.china.huawei.com> <18EA9B00-8992-449C-92E7-22F20C68AFC7@nostrum.com> <6E58094ECC8D8344914996DAD28F1CCD8370D4@DGGEMM506-MBX.china.huawei.com> <159843F8-C920-424D-AF94-438A36164F0E@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.66.255.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F7073C90942134692D0CE5E684D2720@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [payload] Status of draft-ietf-payload-flexible-fec-scheme X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 15:09:48 -0000 The authors believe there are no open issues remaining in the current version of the draft. The final issue related to PERC was resolved in version -05. (The default order of FEC and SRTP operations follows RFC 3711, which specifies FEC then SRTP at senders and the reverse at receivers.) Some further updates may be required in the packet construction and reconstruction procedures in sections 6.2 and 6.3 to provide clear and accurate details of the procedures to encode and decode the packet formats in section 4, which contains the bulk of normative text. The authors plan to carefully review and scrub 6.2/6.3, and request other reviewers (especially early implementers) to assist as well. We think WGLC can proceed in parallel with this review and cleanup. Thanks, Mo (for the authors) From nobody Thu Nov 16 18:35:24 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326A5126CB6; Thu, 16 Nov 2017 18:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 m03ZyICyeBQy; Thu, 16 Nov 2017 18:35:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 67580126B71; Thu, 16 Nov 2017 18:35:16 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4184A2DE3A1E6; Fri, 17 Nov 2017 02:35:14 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Nov 2017 02:35:15 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 10:35:14 +0800 From: Roni Even To: "payload@ietf.org" CC: "rtcweb@ietf.org" Thread-Topic: WGLC on RTP Payload Format for Flexible Forward Error Correction Thread-Index: AdNfS7qfdexsNmKuR5uCq/QxumH+GA== Date: Fri, 17 Nov 2017 02:35:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.64] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:35:18 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to start a three week WGLC on RTP Payload Format for Flexible = Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05. The WGLC will end on November 7th Mo has posted some clarifications to the payload WG mailing list payload m= ailing list archives Please send comments to the payload mailing list. THe double posting is to notify RTCweb WG that the WGLC has started since = this document is needed for RTCweb Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to start a three week WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.

The WGLC will end on November 7th

 

Mo has posted some clarifications to the payload WG = mailing list  payload mailing list archives

 

Please send comments to the payload mailing list.

THe double posting is to  notify RTCweb WG that the WGLC has started since this document is ne= eded for RTCweb

 =

 =

Roni Even

Payload WG co-chair=

 =

 

--_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_-- From nobody Sun Nov 19 01:07:28 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1C126CB6 for ; Sun, 19 Nov 2017 01:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 8z3h9I7_94o2 for ; Sun, 19 Nov 2017 01:07:26 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B4A126BF0 for ; Sun, 19 Nov 2017 01:07:25 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id k18so545094wre.1 for ; Sun, 19 Nov 2017 01:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P5NfXQpqDz2qARYU/1GLFfHUEa/Te4IKY473axZyd3Y=; b=eoTe6y2lwILxbw3aAtSPXCWEIG1smNu8bOqpf4rZrbUjHEjfclg2p33qdY2L/CdUss L2AUYXnbdKqBUTWP1L17fHmXO/IY5uRfN/RHa+HGeARYeecRIzaU/w0tx26N+GFKzfP9 D2zYjFBMO5hc9gfxxut3lhzAUBU5vihSNU0zKDF7i4FIATL9hMrD62dArbMDNRjStb/K ZK8fWgCcW3rQHqXSVsQcrgigH0z48oOwOpR7zYqCIupnSRsxwSPf0qVNckNgQtRU1jUz 76OrHzRRtxM0N2e/jyu0rcpuBmaa2x4Rw9ze9KHRduDZV9jicoaI/2w55jCKNiNMUL0k CPFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P5NfXQpqDz2qARYU/1GLFfHUEa/Te4IKY473axZyd3Y=; b=TFWT1r0CdVJfaobJWOq9MLYKQ7q+j2nUharroTFfheEDZuzYVLffstYWtGDCIs5RIk 7olf3L3nI6uGEANH6yCRDjCPS77YeeBM/Z4pYgaGfBVMflBTAphAqy+XyNEm8v2Ewoeb sN4g+9MOFKv83ysbORCiYnTBg0HO1AHU33DjuP+3q8k0g4kz9CPmYeyyj+vL0EreIG9O qKlh7lLXsPkUzsf8k7TIvgXvH19KjyoeXnXF1I5ROsP4noJUuP5w7fwHc/rCNWlpdZrh whmOiMhlk4vtQn27Q74DclEIwf/zW80pF7cNuL9Yv2UwRVoN3jkG5dDZWhV0a5zNooIj ap8A== X-Gm-Message-State: AJaThX4dtiEU6Au9wbZv6ImnCibpEibE/u2INpbWHkBypPx6gp3QmFX6 0A4LSziWSc7zt1dJz8hn9O1e2EgUslc= X-Google-Smtp-Source: AGs4zMbj03+h4+fDREZOyjzUnf3Tss05GBNdDgi7MFibsEkwp5NFnTWtvEDiiLgxFnpjimvq+L8lZw== X-Received: by 10.223.164.22 with SMTP id d22mr9418142wra.232.1511082444120; Sun, 19 Nov 2017 01:07:24 -0800 (PST) Received: from [192.168.1.171] ([85.105.47.236]) by smtp.gmail.com with ESMTPSA id p15sm2581129wre.24.2017.11.19.01.07.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 01:07:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: "Ali C. Begen" In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Date: Sun, 19 Nov 2017 12:07:20 +0300 Cc: "payload@ietf.org" , "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4A105783-051C-469E-8080-ED438E8DB803@networked.media> References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 09:07:27 -0000 Obviously the deadline for the WGLC is Dec. 7th. -acbegen > On Nov 17, 2017, at 5:35 AM, Roni Even wrote: >=20 > Hi, > I would like to start a three week WGLC on RTP Payload Format for = Flexible Forward Error Correction in = draft-ietf-payload-flexible-fec-scheme-05. > The WGLC will end on November 7th > =20 > Mo has posted some clarifications to the payload WG mailing list = payload mailing list archives > =20 > Please send comments to the payload mailing list.=20 > THe double posting is to notify RTCweb WG that the WGLC has started = since this document is needed for RTCweb > =20 > =20 > Roni Even > Payload WG co-chair > =20 > =20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Nov 21 13:22:43 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B85129BD8; Tue, 21 Nov 2017 13:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DQS9a2_26yKU; Tue, 21 Nov 2017 13:22:39 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1868129BD5; Tue, 21 Nov 2017 13:22:38 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id q18so9262850uaa.0; Tue, 21 Nov 2017 13:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nEAm2z8CVUKDt2y6s5DibbJUVUhnJG9bOQu1SbTe8bs=; b=R2TRuaxHrHktVdetzPPc3lkJIdrXpH1GqGP/KrfJG/JP23skf5R8g9sakU7Y9X7HFS ftlLFuuXMNZnoktc3kor73+pX5EaNpWF2N2m5Xwfxmyufa9aWJBi7NCVqqOuIonEO0Mx NWNBnHmNFQmbP0er6CmMRdE/AbySA3LGtVRDMS80wVD8QP12iwLTs3Dnbm2vFyePM4dj qg66YIWuVv3v01cTASpdIx3TU89SAN8gjqWtFj35Fw4hRxBtF0jpsKCA1Xc2UT4/Sld+ qa0jixrlT2jnymud5lgwiXgiRyPnDvJKjy4hR4nbIgqsUudK7H01UiUB27v+Q2wYsvaC tNsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nEAm2z8CVUKDt2y6s5DibbJUVUhnJG9bOQu1SbTe8bs=; b=O5GBWuY2NUz7zAnnUdEoXY6fYytw3TvJHwCp4Pi8GMcv4xjvhWB2Auj3vtw+Cxz+Le puYHvSWMZjBcvzHpZbWa6vCMrLnp0lk+LOxJrrvmfigzbDpdrs8yiFoIDyE1RQGVwHSl f3CRTi8jGlBxwJxZ24aXh65rWBrWGwloTg6UpxAmq4UT9jroEVHwLMDh+refVJLE6VEK +H3OgvnwGx0Es61F+fRM0w6znDUygdZZw10iCofcKTClgjEt2hjN2umF2RoJ9ElyZ4mN 50plI+ukbX2HcbmR4Lhd0BGmxGHoGBFpSowiUXI7P3gOf8pdcQyV1AF6dh9DwCR/x5In cKlQ== X-Gm-Message-State: AJaThX54APSDkXWbZWsf6ZFoVHLxnjxy1wWvJ06A77YgEAVle0Ma3fCL 5DTyh0jlacY059e94flbF31ffMy/GvPbp4Y35yo= X-Google-Smtp-Source: AGs4zMbMgARCWBVlEIhKlO/jKmoLRaDMWpDI8Gwqoj2fXALfU08yOhxz/CgYzY8bRP+C1LeOL3nFN3utmHlLChHftNw= X-Received: by 10.159.60.98 with SMTP id w34mr15789272uah.27.1511299357103; Tue, 21 Nov 2017 13:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.130 with HTTP; Tue, 21 Nov 2017 13:22:36 -0800 (PST) In-Reply-To: <4A105783-051C-469E-8080-ED438E8DB803@networked.media> References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> <4A105783-051C-469E-8080-ED438E8DB803@networked.media> From: Stephen Botzko Date: Tue, 21 Nov 2017 16:22:36 -0500 Message-ID: To: "Ali C. Begen" Cc: Roni Even , "rtcweb@ietf.org" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="f40304364382545bbe055e84cd7b" Archived-At: Subject: Re: [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 21:22:43 -0000 --f40304364382545bbe055e84cd7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed it, but I don't think it is ready for publication yet. My commends follow. BR Stephen >>> Abstract >>> Overall, the purpose is to reconstruct RTP source packets that were lost in transmission, using the source and repair packets that were received. I expected that to be stated somewhere in the abstract and introduction. >>> These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols. >>> This is of course the usual FEC jargon. But it isn=E2=80=99t clear if the symbols in this draft are bits, bytes, or the full source packets payloads. Overall, the draft generally uses the phrase =E2=80=9Csource packet=E2=80= =9D and =E2=80=9Crepair packet=E2=80=9D. =E2=80=9Crepair symbols=E2=80=9D shows up= in section 4.2, and there it seems to mean bits or bytes. The draft needs to clarify this, as the many implementers won=E2=80=99t have any real knowledge of FEC. I suggest removing references to =E2=80=9Csymbols=E2=80=9D, as the XOR cons= truction and repair mechanisms really don=E2=80=99t need to talk about =E2=80=9Csymb= ols=E2=80=9D. Also, =E2=80=9CFEC packets=E2=80=9D appears to be the same thing as =E2=80= =9Crepair packets=E2=80=9D. It would be better to use one term for both. Repair packets might be clearer (though they reconstruct lost packets, and don't actually repair them). >>> These repair symbols are sent in a repair flow separate from the source flo= w >>> The word =E2=80=9Cflow=E2=80=9D appears 19 times in the document with no ex= planation on what exactly is meant. I believe it simply means that the source and repair packets use different SSRCs (or different payload types?), but this is not as clear as it might be. FWIW, I realize that =E2=80=9Cflow=E2=80=9D is also used extensively in RFC= 6363. But RFC6363 defines flows in terms of transport identifier (such as standard 5 tuple), and that definition doesn=E2=80=99t apply here, since source and repair flows can use the same 5 tuple. >>> Moreover, alternate FEC codes may be used with the payload formats presente= d. >>> Does this mean that the FEC codes might not be XOR? If so, the document doesn=E2=80=99t say anything about how that is done (and the repair generat= ion and recovery methods in the draft are specific to XOR). So if means what is meant, the sentence should probably be removed. If it doesn=E2=80=99t mean that, then what does it mean? Section 1.1 >>> Note that the source and repair packets belong to different source and repair flows, and the sender must provide a way for the receivers to demultiplex them, even in the case they are sent in the same 5-tuple (i.e., same source/destination address/port with UDP). >>> The =E2=80=9Cdifferent source and repair flows=E2=80=9D aspect of the note = is repetitive, since it is also stated in step 3 immediately above this paragraph. =E2=80= =9CEven in the case=E2=80=9D is understated, =E2=80=9Cespecially in the case=E2=80= =9D is closer to the truth of it. It might be simpler to just say that source and repair packets MUST use different SSRCs (or different payload types?), and delete this sentence. >>> The repair packets may be sent proactively or on-demand. >>> How are they sent on demand? I don=E2=80=99t see any methods for requestin= g repair packets. Either procedures should be defined/referenced or the sentence deleted. >>> In this document, we refer to the time that spans a FEC block, which consists of the source packets and the corresponding repair packets, as the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in a FEC block, to allow all the repair packets to arrive. >>> Not sure if the intent is SHOULD wait or should wait. More importantly, the FEC patterns in the draft are all defined to have a fixed number of packets. The =E2=80=9Ctime that spans an FEC block=E2=80= =9D is not constant, especially for variable-rate video. The receiver has no idea how long that repair window time might be for a *specific *FEC block. At some point the receiver decides it=E2=80=99s time to deliver the source = packets =E2=80=93 either because (a) It is receiving source packets with no break in sequence number, so there is no need to wait for repair (b) It has received enough repair packets to recover the missing source packets (c) It has received all the repair packets, and they aren=E2=80=99t suf= ficient to recover the missing source packets (d) It is choosing not to wait any longer. Case (d) might be reached because it is starting to receive packets in the next FEC block, or it might be reached because of a real-time constraint The wording in the above paragraph doesn=E2=80=99t cover these cases very w= ell. And the FEC decoder doesn=E2=80=99t always need to wait for all the repair = packets to be received before it can begin the repair process. It=E2=80=99s probably more useful to point out that using flexflec does add= delay, and it needs to be clear that the repair window (in time units) is nominal. Or maybe specify the repair window in packets? >>> Suppose that we have a group of D x L source packets that have sequence numbers starting from 1 running to D x L, and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as 1-D non-interleaved FEC protection >>> I think the document would be clearer if this was in new section =E2=80=93 = preceded by a short into saying how flexspec provides non-interleaved (row), interleaved (column), and hybrid row+column (2-D) FEC patterns. This is a key concept in the draft, and should be more prominent. I think there should also be four use-case sections. Separate sections for row and column, and the retransmission mode (=E2=80=9CR=E2=80=9D bit) shoul= d probably have a short section too. >>> *1.1.3 **. Overhead Computation* >>> Overhead isn=E2=80=99t used much in the document, and I am not sure this pa= rticular definition adds much value. It might be better phrased as =E2=80=9CFEC Ove= rhead Considerations=E2=80=9D, since the overhead fractions really don=E2=80=99t = have much practical use, especially when the source packets are of unequal size. >>> 3.1 . Definitions >>> FEC Block, and repair window should be defined here (neither are defined in RFC6363). Parity Codes are not defined in RFC6363 either, and probably should be defined here. 1-D non-interleaved, 1-D interleaved, 2-D protection perhaps should be defined. It might be cleaner to define source block here, since the RFC6363 definition doesn=E2=80=99t precisely apply (because its definition of ADU f= low depends on 5-tuple). In general there are very few definitions in RFC6363 that are used in flexfec, so if it were my draft I=E2=80=99d just redefine them explicitly h= ere. >>> 3.2 . Notations >>> I=E2=80=99m not sure that bitmask needs to be here, though the text is ok. 4.1 . Source Packets >>> The source packets MUST contain the information that identifies the source block and the position within the source block occupied by the packet. >>> This is a meaningless MUST, since the source RTP packet is simply sent without modification. The sequence number and SSRC are used to map the packets onto the repair packets. Overall, paragraph 4.1 is confusing, because it gives the impression that something else needs to be done, and then says that there isn=E2=80=99t. P= lus, it is supposed =E2=80=9Cdefine the format of the source packet=E2=80=9D - whi= ch it doesn=E2=80=99t do. I think it=E2=80=99s better just to say earlier in the document that the so= urce packets can be any RTP packets, and leave it at that. Perhaps tie that statement to the use of systematic codes. Then focus on defining the repair packet format, which is the heart of the draft. The advantages of not modifying the source packets is better placed somewhere else in the document =E2=80=93 perhaps in section 1.1, when the F= EC encoder and Decoders are introduced. 4.2 . Repair Packets >>> o Marker (M) Bit: This bit is not used for this payload type, and SHALL be set to 0 >>> And ignored by receivers? >>> Note that this document registers new payload formats for the repair packets (Refer to Section 5 for details). According to [RFC3550 ], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type, and hence, will discard the repair packet. >>> This probably should be said somewhere, but I think it=E2=80=99s better mov= ed somewhere other than the repair packet format description. I believe this also requires that the CSRCs in the repair RTP header be set to the SSRCs of the source packets. That isn=E2=80=99t stated, but is impl= ied by the structure in table 10. >>> The format of the FEC header is shown in Figure 10. The FEC header consists of the following fields: >>> No. This is the first of four? possible formats, depending on R,F,M, and N, shown in figures 10-15. M is ambiguous - appears as M and M (columns). Some fields are really repair symbols (P,X,C,M, PT Recovery, Length Recovery, recovery), and are meaningless on their own. This rather important detail doesn=E2=80=99t show up until you get to 6.2. Figure 15 also affects figure 9, since the unspecified =E2=80=9CRepair symb= ols=E2=80=9D in figure 9 are replaced by the =E2=80=9Cretransmission payload=E2=80=9D In fi= gure 15. The contents of that =E2=80=9Cretransmission payload=E2=80=9D are not specified= anywhere in the draft. This whole section is a confusing mess, and needs to be restructured. I guess one approach is to change 6.2 to =E2=80=9CRepair symbol construction= =E2=80=9D, and explicitly refer to it for all fields in the FEC header that are XORed. One way or another, you need to separate out the fields that specify the FEC parameters from the embedded repair symbols mixed into the structure. >>> o The CSRC_i (32 bits) field describes the SSRC of the packets protected by this particular FEC packet. If a FEC packet contains protects multiple SSRCs (indicated by the CSRC Count > 1), there will be multiple blocks of data containing the SN base and Mask fields. >>> Does this mean that a repair flow can protect multiple RTP sources? If so, this should be clearly stated earlier. There might be other implications of supporting this (do all the sources need to have the same CNAME???) >>> If M>0, N=3D0, is Row FEC, and no column FEC will follow Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. If M>0, N=3D1, is Row FEC, and column FEC will follow. Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. and more to come If M>0, N>1, indicates column FEC of every M packet in a group of N packets starting at SN base. Hence, FEC =3D SN+(Mx0), SN+(Mx1), ... , SN+(MxN). Figure 14: Interpreting the M and N field values >>> First, this is not a figure. Second, the names are not consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d described above. The names need to be consistent. FWIW, these names are a bit more intuitive to me. >>> Note that the parsing of this packet is different. >>> =E2=80=9Cthis=E2=80=9D is indefinite. In general you should name the four(= ?) header types, I think that will make things simpler. >>> Figure 15: Protocol format for Retransmission >>> This is mis-titled. It also isn=E2=80=99t clear. The figure shows the alt= ernative FEC header format, but I believe the intent is that the retransmission payload replaces the =E2=80=9Crepair symbols=E2=80=9D shown in figure 9. T= hat isn=E2=80=99t obvious from the organization. >>> It should be noted that a mask-based approach (similar to the ones specified in [RFC2733 ] and [RFC510= 9 ]) may not be very efficient to indicate which source packets in the current source block are associated with a given repair packet. In particular, for the applications that would like to use large source block sizes, the size of the mask that is required to describe the source-repair packet associations may be prohibitively large. The 8-bit fields proposed in [SMPTE2022-1 ] indicate a systematized approach. Instead the approach in this document uses the 8-bit fields to indicate packet offsets protected by the FEC packet. The approach in [SMPTE2022-1 ] is inherently more efficient for regular patterns, it does not provide flexibility to represent other protection patterns (e.g., staircase). >>> I have no idea why this note is here. I=E2=80=99d delete it. There's no p= oint in talking about all the roads not taken. >>> 5 . Payload Format Parameters >>> If no specific FEC code is specified in the subtype, then the FEC code defaults to the parity code defined in this specification. >>> Since there is no syntax to specify the FEC code, a receiver has no way to know for certain that the parity code is being used. I *guess* that the statement in 5.2.1 *might* cover this >>> =E2=80=9CThere are no optional format parameters defined for this payload. Any unknown option in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, it can be deleted from the answer. >>> For SDP at least, any FEC code in the offer would be deleted by an existing receiver, so if parity is mandatory-to-implement you=E2=80=99d get interoperability at least. But why not just specify the FEC code parameter (with Parity as a choice) now? >>> 6.2 . Repair Packet Construction The RTP header of a repair packet is formed based on the guidelines given in Section 4.2 . >>> Since 4.2 is a mess, it=E2=80=99s not surprising that 6.2 is also. The FEC header length isn=E2=80=99t limited to 28 octets in the retransmiss= ion case (which is conveniently skipped in 6.2) It would be good to specify what=E2=80=99s in the skipped bits in the heade= r, rather than making people figure it out. (=E2=80=9CV-2=E2=80=9D and Sequenc= e Number) Also phrases like =E2=80=9CThe next 4 bits of the FEC bit string are writte= n into the CC recovery field in the FEC header=E2=80=9D should be written as like =E2=80=9CThe next 4 bits of the FEC bit string are XORed into the CC recovery field in the FEC header=E2=80=9D BTW, I don=E2=80=99t think the =E2=80=9CFEC bit string=E2=80=9D nomenclatur= e is all that useful, given that you end up specifying the XOR field by field anyway. >>> The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. If the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. >>> This presumably defines what is placed into the =E2=80=9Crepair symbols=E2= =80=9D back in figure 9. But it doesn=E2=80=99t say that. I believe this is incomplete. It doesn=E2=80=99t say how to handle extensi= on headers. It isn=E2=80=99t clear whether padding octets are XORed (RFC 3550= says the padding octets =E2=80=9Care not part of the payload=E2=80=9D). SRTP MKI= and authentication tag would also be recovered (which is not possible in the current draft). >>> 6.3.2 . Recovering the RTP Header This procedure recovers the header of an RTP packet up to (and including) the SSRC field. >>> But it doesn=E2=80=99t recover the full header, and that should be more cle= arly stated, FWIW, =E2=80=9Cif the repair symbols=E2=80=9D were defined as runn= ing from the first byte after the SSRC to the end of the source RTP packet, then the full RTP packet would be recovered =E2=80=93 including SRTP MKI and authent= ication tag, which cannot be recovered now. >>> 6.3.3 . Recovering the RTP Payload 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. *Note that the information of the* * first 8 octets are protected by the FEC header* >>> As is the SSRC, though in a different way. >>> 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header. 3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. Note that the FEC header may be 12, 16, 32 octets depending on the length of the bitmask. 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2 . >>> This is close to the algorithm I suggested above (starting the =E2=80=9CRep= air symbols=E2=80=9D in figure 9 from the first octet after the SSRC). That=E2=80=99s good, but it isn=E2=80=99t consistent with the text in 6.2 (= =E2=80=9CThe repair packet payload consists of the bits that are generated by applying the XOR operation on the *payloads of the source RTP packets)*. So the text as written fails to recover (or fails to generate the repair packet correctly, depending on how you look at it). Also, any RTP padding, SRTP MKI + authentication tag in the repair packets themselves shouldn=E2=80=99t be included in the XOR. RTP Padding, RTP MKI and the authentication tag lengths that are part of the source packets do need to be taken into account when computing Y. I'm not sure the current FEC header handles that well. This section uses "FEC Bit String" to mean something different than it meant earlier in the document. Note the repair algorithms could include authentication of input packets and recovered source packets. >>> 8 . Congestion Control Considerations >>> I=E2=80=99d remove the reference to[I-D.singh-rmcat-adaptive-fec ]. >>> However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13 ][Nagy14]. >>> What does this sentence mean? The draft doesn=E2=80=99t talk about using F= EC for either bandwidth estimation or capacity probing. I suggest deleting it. >>> 9 . Security Considerations >>> Since the sender of the repair packets might not be the sender of the source packets, there is an obvious threat of injection of bogus repair packets. Authentication can be helpful in mitigating that threat. Such authentication (if possible) should be done an any packets that are used in the recovery process, and also on the reconstructed output packets. One could strengthen this into "MUST not" normative language if one wished. NITS Overall, the document frequently uses first person plural (Suppose we have, If we apply, We generate, We refer, We assume, =E2=80=A6). I think the au= thors should consider rephrasing those sentences. Section 1 >>> Situations where adaptivitiy of FEC parameters is desired, the endpoint can use the in-band mechanism, whereas when the FEC parameters are fixed, the endpoint may prefer to negotiate them out-of-band. >>> The sentence uses incorrect grammar. I suggest The in-band mechanism is advantageous when the endpoint is adapting the FEC parameters; the out-of-band mechanism may be preferable when the FEC parameters are fixed. Section 1.1 >>> In a nutshell, >>> Informal English =E2=80=93 I suggest rephrasing. >>> Section 8 However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13 ][Nagy14]. >>> Probing? On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen wrote: > Obviously the deadline for the WGLC is Dec. 7th. > > -acbegen > > > On Nov 17, 2017, at 5:35 AM, Roni Even wrote: > > > > Hi, > > I would like to start a three week WGLC on RTP Payload Format for > Flexible Forward Error Correction in draft-ietf-payload-flexible- > fec-scheme-05. > > The WGLC will end on November 7th > > > > Mo has posted some clarifications to the payload WG mailing list > payload mailing list archives > > > > Please send comments to the payload mailing list. > > THe double posting is to notify RTCweb WG that the WGLC has started > since this document is needed for RTCweb > > > > > > Roni Even > > Payload WG co-chair > > > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --f40304364382545bbe055e84cd7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed it, but I don't think it is ready for = publication yet.

My commends follow.

BR
Stephen=C2=A0

=C2=A0

>>>
Abstract
>>><=
/pre>
Overall, the purpose is to reconstruct RTP source packets that wer=
e lost in transmission, using the source and repair packets that were recei=
ved.=C2=A0 I expected that to be stated somewhere in the abstract and intro=
duction. 
=C2=A0<=
/span>
>>>=C2=A0
These parity codes are syste=
matic codes, where a number of repair
=C2=A0=C2=A0 symbols are generated from a set of sourc=
e symbols.
>&g=
t;>=C2=A0
This is of course the usual FEC jargon.=C2=A0 Bu=
t it isn=E2=80=99t clear if the symbols in this draft are bits, bytes, or t=
he full source packets payloads.=C2=A0 
Overall, the draft ge=
nerally uses the phrase =E2=80=9Csource packet=E2=80=9D and =E2=80=9Crepair=
 packet=E2=80=9D.  =E2=80=9Crepair symbols=E2=80=9D shows up in sect=
ion 4.2, and there it seems to mean bits or bytes.=C2=A0 The draft needs to=
 clarify this, as the many implementers won=E2=80=99t have any real knowled=
ge of FEC.
=C2=A0
I sug=
gest removing references to =E2=80=9Csymbols=E2=80=9D, as the XOR construct=
ion and repair mechanisms really don=E2=80=99t need to talk about =E2=80=9C=
symbols=E2=80=9D.
=C2=A0
Also, =E2=80=9CFEC packets=E2=80=9D appears to be the same thing as=
 =E2=80=9Crepair packets=E2=80=9D.=C2=A0 It would be better to use one term=
 for both.=C2=A0 Repair packets might be clearer (though they reconstruct l=
ost packets, and don't actually repair them).
=


>>>=C2=A0 
These repair symbols are=
 sent in a repair flow separate from the source flow
>>> 



The word=
 =E2=80=9Cflow=E2=80=9D appears 19 times in the document with no
explanation on what exactly is meant.=C2=A0 I
believe it simply means that the source and repair packets use different SS=
RCs
(or different payload types?), but this is not as clear as it might be.=C2=
=A0 



>>>=C2=A0



Moreover, alternate FEC codes may be used =
with the payload formats presented.



>>>=C2=A0



Does this mean that the FEC codes might not be XOR?=
=C2=A0 If so, the document doesn=E2=80=99t say anything
about how that is done (and the repair generation and recovery methods in t=
he
draft are specific to XOR).=C2=A0 So if means
what is meant, the sentence should probably be removed.



If it doesn=E2=80=99t mean that, then what does it m=
ean?



=C2=A0



Section 1.1



>>>=C2=A0



=C2=A0=C2=A0 Note that the source and repa=
ir packets belong to different source
=C2=A0=C2=A0 and repair flows, and the sender must pro=
vide a way for the receivers
=C2=A0=C2=A0 to demultiplex them, even in the case they are sen=
t in the same
=C2=
=A0=C2=A0 5-tuple (i.e., same source/destination address/port with UDP). 



>>>=C2=A0



The =E2=80=9Cdifferent source and repair flows=E2=80=
=9D aspect of the note
is repetitive, since it is also stated in step 3 immediately above this
paragraph.=C2=A0 =E2=80=9CEven in the case=E2=80=9D is
understated, =E2=80=9Cespecially in the case=E2=80=9D is closer to the trut=
h of it.=C2=A0 It might be simpler to just say that source
and repair packets MUST use different SSRCs =C2=A0(or different payload typ=
es?), and delete this
sentence.



=C2=A0



=
>>>=C2=A0



The repair packets may be sent proactively=
 or on-demand.



=
>>>=C2=A0



How are they sent on demand?=C2=A0
I don=E2=80=99t see any methods for requesting repair packets.=C2=A0 Either=
 procedures should be defined/referenced
or the sentence deleted.



>>>=C2=A0



In this document, we refer to the time tha=
t
=C2=A0=C2=A0 sp=
ans a FEC block, which consists of the source packets and the<=
/span>
=C2=A0=C2=A0 corresponding rep=
air packets, as the repair window.=C2=A0 At the receiver
=C2=A0=C2=A0 side, the FEC decoder =
should wait at least for the duration of the
=
=C2=A0=C2=A0 repair window after getting the fi=
rst packet in a FEC block, to allow
=C2=A0=C2=A0 all the repair packets to arrive.



>>>=C2=A0



Not sure if the intent is SHOULD wait or should wait=
.



More importantly, the FEC patterns in the draft are =
all
defined to have a fixed number of packets.=C2=A0
The =E2=80=9Ctime that spans an FEC block=E2=80=9D is not constant, especia=
lly for
variable-rate video.=C2=A0 The receiver has no
idea how long that repair window time might be for a specific FEC block.



At some point the receiver decides it=E2=80=99s time=
 to deliver the
source packets =E2=80=93 either because 



(a)=C2=A0=C2=A0=C2=A0
It is receiving source packets with no break in
sequence number, so there is no need to wait for repair



(b)=C2=A0=C2=A0=C2=A0
It has received enough repair packets to recover
the missing source packets



(c)=C2=A0=C2=A0=C2=A0=C2=A0
It has received all the repair packets, and they
aren=E2=80=99t sufficient to recover the missing source packets



(d)=C2=A0=C2=A0=C2=A0
It is choosing not to wait any longer.



=C2=A0



Case (d) might be reached bec=
ause it is
starting to receive packets in the next FEC block, or it might be reached
because of a real-time constraint



=C2=A0



The wording in the above paragraph doesn=E2=80=99t c=
over these cases
very well.=C2=A0 And the FEC decoder doesn=E2=80=99t
always need to wait for all the repair packets to be received before it can
begin the repair process.



It=E2=80=99s probably more useful to point out that =
using flexflec
does add delay, and it needs to be clear that the repair window (in time un=
its)
is nominal.=C2=A0 Or maybe specify the repair window in packets?=C2=A0
<=
br>


>>>=C2=A0



Suppose that we have a group of D x L sour=
ce packets that have
=C2=A0=C2=A0 sequence numbers starting from 1 running to D x L, and a r=
epair
=C2=A0=C2=
=A0 packet is generated by applying the XOR operation to every L
=C2=A0=C2=A0 consecutive pa=
ckets as sketched in Figure 3.=C2=A0 This process is
=C2=A0=C2=A0 referred to as 1-D non-int=
erleaved FEC protection



>>>=C2=A0



I think the document would be clearer if this was in=
 new
section =E2=80=93 preceded by a short into saying how flexspec provides non=
-interleaved
(row), interleaved (column), and hybrid row+column (2-D) FEC patterns.=C2=
=A0 This is a key concept in the draft, and
should be more prominent.=C2=A0 



I think there should also be four use-case sections.=
=C2=A0 Separate sections for row and column,
and the retransmission mode (=E2=80=9CR=E2=80=9D bit) should probably have =
a short section too.



>>>=C2=A0
1.1.3.=C2=A0=
 Overhead Computation
>&g=
t;>=C2=A0




Overhead isn=E2=80=99t used much in the document, an=
d I am not sure
this particular definition adds much value.=C2=A0
It might be better phrased as =E2=80=9CFEC Overhead Considerations=E2=80=9D=
, since the
overhead fractions really don=E2=80=99t have much practical use, especially=
 when the
source packets are of unequal size.



=C2=A0



>>>=C2=A0


3.1.=C2=A0
Definitions



>>>=C2=A0



FEC Block, and repair window should be defined here =
(neither
are defined in RFC6363).=C2=A0 Parity Codes
are not defined in RFC6363 either, and probably should be defined here.




1-D non-interleaved, =
1-D interleaved, 2-D protection perhaps
should be defined.




It might be cleaner t=
o define source block here, since the
RFC6363 definition doesn=E2=80=99t precisely apply (because its definition =
of ADU flow
depends on 5-tuple).=C2=A0 




In general there are =
very few definitions in RFC6363 that
are used in flexfec, so if it were my draft I=E2=80=99d just redefine them =
explicitly
here.



>>>=C2=A0



3.2.=
=C2=A0
Notations



>>>=C2=A0



I=E2=80=99m not sure that bitmask needs to be here, =
though the text is ok.



=C2=A0



=C2=A0



4.1.=C2=A0 Sour=
ce Packets



>>>=C2=A0



=C2=A0=C2=A0 The source packets MUST conta=
in the information that identifies the
=C2=A0=C2=A0 source block and the position within the=
 source block occupied by the
=C2=A0=C2=A0 packet.=C2=A0 



>>>=C2=A0



This is a meaningless MUST, since the source RTP pac=
ket is
simply sent without modification.=C2=A0 The
sequence number and SSRC are used to map the packets onto the repair
packets.=C2=A0=C2=A0
Overall, paragraph 4.1 is
confusing, because it gives the impression that something else needs to be
done, and then says that there isn=E2=80=99t.=C2=A0
Plus, it is supposed =E2=80=9Cdefine the format of the source packet=E2=80=
=9D - =C2=A0which it doesn=E2=80=99t do.=C2=A0 




I think it=E2=80=99s =
better just to say earlier in the document that
the source packets can be any RTP packets, and leave it at that.=C2=A0 Perh=
aps tie that statement to the use of
systematic codes.=C2=A0 Then focus on defining
the repair packet format, which is the heart of the draft.




The advantages of not=
 modifying the source packets is better
placed somewhere else in the document =E2=80=93 perhaps in section 1.1, whe=
n the FEC
encoder and Decoders are introduced.



=C2=A0



4.2.=
=C2=A0
Repair Packets



=C2=A0



>>>=C2=A0
=C2=A0=C2=A0 o=C2=A0 Marker (M) Bit: Thi=
s bit is not used for this payload type, and
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHALL be set to =
0



>>>=C2=A0



And ignored by receivers?



>>>=C2=A0
Note that this document
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
gisters new payload formats for the repair packets (Refer to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Section 5 for details).=C2=A0 According to [RFC3550], an RTP receiver
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 that cannot recognize a payload type must discard it.=C2=A0 This
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 provides backward compatibility.=C2=A0 If a non-FEC-capable re=
ceiver
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 receives a repair packet, it will not recognize the p=
ayload type,
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 and hence, will discard the repair packet.



>>>=C2=A0



This probably should be said somewhere, but I think =
it=E2=80=99s
better moved somewhere other than the repair packet format description.



=C2=A0



I believe this also requires that the CSRCs in the r=
epair
RTP header be set to the SSRCs of the source packets.=C2=A0 That isn=E2=80=
=99t stated, but is implied by the
structure in table 10.




>>>=C2=
=A0
The format of the FEC header=
 is shown in Figure 10.
The FEC header consists of the following fields:=




>>>=C2=A0



No.=C2=A0 This is the first
of four? possible formats, depending on R,F,M, and N, shown in figures 10-1=
5.=C2=A0 M is ambiguous - appears as M and M
(columns).=C2=A0 Some fields are really repair
symbols (P,X,C,M, PT Recovery, Length Recovery, recovery), and are meaningl=
ess
on their own.=C2=A0 This rather important
detail doesn=E2=80=99t show up until you get to 6.2.




Figure 15 also affect=
s figure 9, since the unspecified
=E2=80=9CRepair symbols=E2=80=9D in figure 9 are replaced by the =E2=80=9Cr=
etransmission payload=E2=80=9D In
figure 15.=C2=A0 The contents of that
=E2=80=9Cretransmission payload=E2=80=9D are not specified anywhere in the =
draft.




This whole section is=
 a confusing mess, and needs to be
restructured.=C2=A0 I guess one approach is to
change 6.2 to =E2=80=9CRepair symbol construction=E2=80=9D, and explicitly =
refer to it for all
fields in the FEC header that are XORed.=C2=A0
One way or another, you need to separate out the fields that specify the
FEC parameters from the embedded repair symbols mixed into the structure.



=C2=A0



>>>=C2=A0



=C2=A0=C2=A0 o=C2=A0 The CSRC_i (32 bits) =
field describes the SSRC of the packets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protected by this par=
ticular FEC packet.=C2=A0 If a FEC packet contains
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protects m=
ultiple SSRCs (indicated by the CSRC Count > 1), there
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wil=
l be multiple blocks of data containing the SN base and Mask
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
fields.



>>>=C2=A0



Does this mean that a repair flow can protect multip=
le RTP
sources?=C2=A0 If so, this should be clearly
stated earlier.=C2=A0 There might be other
implications of supporting this (do all the sources need to have the same
CNAME???)




>>>=C2=
=A0



If M>0, N=3D0,=C2=A0 is Row FEC, and no=
 column FEC will follow
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M.
=C2=A0
<=
pre>=C2=A0=C2=A0 If M>0, N=3D1,=C2=A0 is Row=
 FEC, and column FEC will follow.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN, SN+1, SN+2, ... =
, SN+(M-1), SN+M.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and mor=
e to come
=C2=A0<=
/span>
=C2=A0=C2=A0 If M>0, N>1=
,=C2=A0 indicates column FEC of every M packet
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in a =
group of N packets starting at SN base.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN+(Mx0), SN+(=
Mx1), ... , SN+(MxN).
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figure 14: Interpreting the M and N field=
 values



>>>=C2=A0



First, this is not a figure. Second, the names are n=
ot
consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d described
above.=C2=A0 The names need to be
consistent.=C2=A0 FWIW, these names are a bit
more intuitive to me.



=C2=A0



>>>=C2=A0



Note that the parsing of this packet is di=
fferent. 



>>>=C2=A0



=E2=80=9Cthis=E2=80=9D is indefinite.=C2=A0
In general you should name the four(?) header types, I think that will
make things simpler.=C2=A0 



=C2=A0



>>>=C2=A0



Figure 15: Protocol format for Retransmiss=
ion



>>>=C2=A0



This is mis-titled.=C2=A0
It also isn=E2=80=99t clear.=C2=A0 The figure
shows the alternative FEC header format, but I believe the intent is that t=
he
retransmission payload replaces the =E2=80=9Crepair symbols=E2=80=9D shown =
in figure 9.=C2=A0 That isn=E2=80=99t obvious from the organization.=C2=A0=
=C2=A0 




>>>=C2=
=A0



=
=C2=A0=C2=A0 It should be noted that a
mask-based approach (similar to the ones



=
=C2=A0=C2=A0 specified in [RFC2733]
and [RFC5109])
may not be very efficient to



=
=C2=A0=C2=A0 indicate which source
packets in the current source block are



=
=C2=A0=C2=A0 associated with a given
repair packet.=C2=A0 In particular, for the



=
=C2=A0=C2=A0 applications that would
like to use large source block sizes, the



=
=C2=A0=C2=A0 size of the mask that is
required to describe the source-repair



=
=C2=A0=C2=A0 packet associations may
be prohibitively large.=C2=A0 The 8-bit fields



=
=C2=A0=C2=A0 proposed in [SMPTE2022-1]
indicate a systematized approach.=C2=A0
Instead



=
=C2=A0=C2=A0 the approach in this
document uses the 8-bit fields to indicate



=
=C2=A0=C2=A0 packet offsets protected
by the FEC packet.=C2=A0 The approach in



=
=C2=A0=C2=A0 [SMPTE2022-1]
is inherently more efficient for regular patterns, it


=
=C2=A0=C2=A0 does not provide
flexibility to represent other protection patterns



=
=C2=A0=C2=A0 (e.g., staircase).



>>>=C2=A0



I have no idea why this note is here.=C2=A0 I=E2=80=
=99d delete it.=C2=A0 There's no point in talking about all the roads n=
ot taken.





>>>=C2=A0



5.=C2=A0=
 Payload
Format Parameters



>>>=C2=A0



If no specific FEC code is specified=

=C2=A0=C2=A0 in the su=
btype, then the FEC code defaults to the parity code defined
=C2=A0=C2=A0 in this specificat=
ion.



>>>=C2=A0



Since th=
ere is no syntax to specify the FEC code, a receiver has no way to know for=
 certain that the parity code is being used.=C2=A0 I guess that the =
statement in 5.2.1 might cover this 
<=
span>=C2=A0
>>>=C2=A0
=E2=
=80=9CThere are no optional format parameters d=
efined for this payload.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any unknown option in the offer MUST=
 be ignored and deleted from
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the answer.=C2=A0 If FEC is not =
desired by the receiver, it can be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 deleted from the answer.
>>>=
=C2=A0
For SDP at least, any FEC code in the offer wou=
ld be deleted by an existing receiver, so if parity is mandatory-to-impleme=
nt you=E2=80=99d get interoperability at least.=C2=A0 But why not just spec=
ify the FEC code parameter (with Parity as a choice) now?=

=C2=A0
>>>=C2=A0





6.2.=C2=A0 Repair Packet Construction








=C2=A0=C2=A0 The=
 RTP header of a repair packet is formed based on the guidelines
=C2=A0=C2=A0 given in Section 4.2.
>>>=C2=A0



Since 4.2 is a mess, it=E2=80=99s not surprising tha=
t 6.2 is also.



The FEC header length isn=E2=80=99t limited to 28 oc=
tets in the
retransmission case (which is conveniently skipped in 6.2)



It would be good to specify what=E2=80=99s in the sk=
ipped bits in
the header, rather than making people figure it out. (=E2=80=9CV-2=E2=80=9D=
 and Sequence
Number)



Also phr=
ases like =E2=80=9CThe next 4 bits of the FEC b=
it string are written into the CC recovery field in the FEC header=E2=80=9D=
 should be written as like =E2=80=9CThe =
next 4 bits of the FEC bit string are XORed into the CC recovery field in t=
he FEC header=E2=80=9D



=C2=A0



BTW, I don=E2=80=99t think the =E2=80=9CFEC bit stri=
ng=E2=80=9D nomenclature is all
that useful, given that you end up specifying the XOR field by field anyway=
.



=C2=A0



>>>=C2=A0



=C2=A0=C2=A0 The repair packet payload con=
sists of the bits that are generated by
=C2=A0=C2=A0 applying the XOR operation on the paylo=
ads of the source RTP packets.
=C2=A0=C2=A0 If the payload lengths of the source packets are=
 not equal, each
=
=C2=A0=C2=A0 shorter packet MUST be padded to the length of the longest pac=
ket by
=C2=A0=C2=
=A0 adding octet 0's at the end.



>>>=C2=A0



This presumably defines what is placed into the =E2=
=80=9Crepair
symbols=E2=80=9D back in figure 9.=C2=A0 But it
doesn=E2=80=99t say that.



I believe this is incomplete.=C2=A0 It doesn=E2=80=
=99t say how to handle extension
headers.=C2=A0 It isn=E2=80=99t clear whether padding
octets are XORed (RFC 3550 says the padding octets =E2=80=9Care not part of=
 the
payload=E2=80=9D). SRTP MKI and authentication tag would also be recovered =
(which is
not possible in the current draft).



=C2=A0



>>>=C2=A0



6.3.2=
.=C2=A0 Recovering the RTP Header



This procedure recovers the header of an R=
TP packet up to (and
=C2=A0=C2=A0 including) the SSRC field.



=C2=A0



>>>=C2=A0



But it doesn=E2=80=99t recover the full header, and =
that should be
more clearly stated,=C2=A0 FWIW, =E2=80=9Cif the
repair symbols=E2=80=9D were defined as running from the first byte after t=
he SSRC to
the end of the source RTP packet, then the full RTP packet would be recover=
ed =E2=80=93
including SRTP MKI and authentication tag, which cannot be recovered now.



=C2=A0



>>>=C2=A0



6.3.3=
.=C2=A0 Recovering the RTP
Payload



=C2=A0



=C2=A0=C2=A0 2.=C2=A0 For each of the sour=
ce packets that are successfully received in
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T, compute=
 the bit string from the Y octets of data starting with=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 the 13th octet of the packet.=C2=A0 If any of the bit strings=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 generated from the source packets has a length shorter than Y,
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 pad them to that length.=C2=A0 The padding of octet 0 MU=
ST be added at
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the end of the bit string.=C2=A0 Note that the information of the
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first 8=
 octets are protected by the FEC header



>>>=C2=A0



As is the SSRC, though in a different way.



>>>=C2=A0



=
=C2=A0=C2=A0 2.=C2=A0 For each of the source packets that are
successfully received in



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T, compute the bit
string from the Y octets of data starting with



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the 13th octet of the
packet.=C2=A0 If any of the bit strings



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from the
source packets has a length shorter than Y,



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pad them to that
length.=C2=A0 The padding of octet 0 MUST be
added at



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the end of the bit
string.=C2=A0 Note that the information of the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first 8 octets are
protected by the FEC header.



=
=C2=A0



=
=C2=A0=C2=A0 3.=C2=A0 For the repair packet in T, compute the FEC
bit string from the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 repair packet
payload, i.e., the Y octets of data following the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FEC header.=C2=A0 Note that the FE=
C header may be 12, 16, 32
octets



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 depending on the
length of the bitmask.



=
=C2=A0



=
=C2=A0



=
=C2=A0=C2=A0 4.=C2=A0 Calculate the recovered bit string as the XOR
of the bit strings



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from all
source packets in T and the FEC bit string



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from the
repair packet in T.



=
=C2=A0



=
=C2=A0=C2=A0 5.=C2=A0 Append the recovered bit string (Y octets) to
the new packet



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated in =
Section
6.3.2.



>>>=C2=A0



This is close to the algor=
ithm I suggested above (starting the =E2=80=9CRepair symbols=E2=80=9D in fi=
gure 9 from the first octet after the SSRC).=C2=A0 
That=E2=80=99s good, but it isn=E2=80=
=99t consistent with the text in 6.2 (=E2=80=9C=
The repair packet payload consists of the bits that are generated by applyi=
ng the XOR operation on the payloads of the source RTP packets).=C2=A0 
So the text as written fails to recover (or=
 fails to generate the repair packet correctly, depending on how you look a=
t it).
Also, any RTP padding, SRTP MKI + authenticatio=
n tag in the repair packets themselves shouldn=E2=80=99t be included in the=
 XOR.  
RTP Padding, RTP MKI and the authentication ta=
g lengths that are part of the source packets do need to be taken into acco=
unt when computing Y.  I'm not sure the current FEC header handles that=
 well.

Th=
is section uses "FEC Bit String" to mean something different than=
 it meant earlier in the document.

Note the repair algorithms could include =
authentication of input packets and recovered source packets.=





>>>=C2=A0



.=C2=A0 Congestion Control Considerations



=C2=A0



>>>=C2=A0



I=E2=80=99d remove the reference to[I-D.singh-rmcat-adaptive-fec].<=
/span>



=C2=A0



>>>=C2=A0



However, it MAY still continue to use FEC =
if considered for bandwidth
=C2=A0=C2=A0 estimation instead of speculatively probe for addit=
ional capacity
=
=C2=A0=C2=A0 [Holmer13][Nagy14].



>>>=C2=A0



What does this sentence mean?=C2=A0 The draft doesn=
=E2=80=99t talk about using FEC for
either bandwidth estimation or capacity probing.=C2=A0 I suggest deleting i=
t.



=C2=A0



>>>=C2=A0



.=C2=A0 Security
Considerations



>>>=C2=A0





Since the sender of the repair packets might not be the sender of the sourc=
e
packets, there is an obvious threat of injection of bogus repair packets.=
=C2=A0 Authentication can be helpful in mitigating
that threat.=C2=A0=C2=A0
Such authentication (if
possible) should be done an any packets that are used in the recovery proce=
ss,
and also on the reconstructed output packets.

One could strengthen this into &qu=
ot;MUST not" normative language if one wished.



=C2=A0




NITS



Overall, the document frequently uses first person p=
lural
(Suppose we have, If we apply, We generate,=C2=A0 We refer, We assume, =E2=
=80=A6).=C2=A0 I think
the authors should consider rephrasing those sentences.



=C2=A0=C2=A0



=C2=A0



Section 1



=
>>>=C2=A0



=
Situations where adaptivitiy



=
=C2=A0=C2=A0 of FEC parameters is
desired, the endpoint can use the in-band



=
=C2=A0=C2=A0 mechanism, whereas when
the FEC parameters are fixed, the endpoint



=
=C2=A0=C2=A0 may prefer to negotiate
them out-of-band.



>>>=C2=A0



The sentence uses incorrect grammar.=C2=A0 I suggest=




The in-band mechanism is advantageous when the endpo=
int is
adapting the FEC parameters; the out-of-band mechanism may be preferable wh=
en
the FEC parameters are fixed.



=C2=A0



Section 1.1



>>>=C2=A0



In a nutshell,



>>>=C2=A0



Informal English =E2=80=93 I suggest rephrasing.



=C2=A0



>>>=C2=A0



Section 8



However, it MAY still continue to use FEC =
if considered for bandwidth
=C2=A0=C2=A0 estimation instead of speculatively probe for addit=
ional capacity
=
=C2=A0=C2=A0 [Holmer13][Nagy14].



>>>=C2=A0



Probing?



=C2=A0



=C2=A0



=C2=A0



=C2=A0

On Sun, Nov 19, 2017 at 4:07 AM, A= li C. Begen <ali.begen@networked.media> wrote:
Obviously the deadline for the WGLC is Dec. 7t= h.

-acbegen

> On Nov 17, 2017, at 5:35 AM, Roni Even <roni.even@huawei.com> wrote:
>
> Hi,
> I would like to start a three week WGLC on RTP Payload Format for Flex= ible Forward Error Correction in draft-ietf-payload-flexible-fec-schem= e-05.
> The WGLC will end on November 7th
>
> Mo has posted some clarifications to the payload WG mailing list=C2=A0= payload mailing list archives
>
> Please send comments to the payload mailing list.
> THe double posting is to=C2=A0 notify RTCweb WG that the WGLC has star= ted since this document is needed for RTCweb
>
>
> Roni Even
> Payload WG co-chair
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload=

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= br>

--f40304364382545bbe055e84cd7b-- From nobody Tue Nov 28 10:44:03 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692B126557 for ; Tue, 28 Nov 2017 10:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001] autolearn=no 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 VJACU7tMhtWd for ; Tue, 28 Nov 2017 10:44:00 -0800 (PST) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 36E62126CE8 for ; Tue, 28 Nov 2017 10:43:59 -0800 (PST) Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id EC201B44D77; Tue, 28 Nov 2017 13:43:58 -0500 (EST) From: "Victor Demjanenko, Ph.D." To: "'Roni Even'" , "'Ali C. Begen'" , Date: Tue, 28 Nov 2017 13:43:48 -0500 Message-ID: <05c001d36878$d4079fb0$7c16df10$@demjanenko@vocal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C1_01D3684E.EB3197B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdNoeNOgTQQ8/FbdR2eGp84HJPQB6A== Content-Language: en-us Archived-At: Subject: [payload] Draft document draft-demjanenko-payload-tsvcis-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 18:44:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05C1_01D3684E.EB3197B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Roni, Ali, I was wondering when the next meeting would be for possible discussion of our draft RTP payload format for the TSVCIS speech codec? This is not a well known (yet) speech codec. It is related to MELPe as it uses MELPe 2400 bps as its base codec. It supplements the base codec with additional LSP coefficients and functions as a variable rate audio codec. Our suggested payload format is compatible with the MELPe encoding of RFC 8130. So this draft serves as a companion document to cover the TSVCIS as a variable rate audio codec. What would you need from us to advance this work (obviously first to an IETF draft and then to an RFC)? Victor ------=_NextPart_000_05C1_01D3684E.EB3197B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni, = Ali,

 

I was wondering when the next meeting would be for = possible discussion of our draft RTP payload format for the TSVCIS = speech codec?  This is not a well known (yet) speech codec.  = It is related to MELPe as it uses MELPe 2400 bps as its base = codec.  It supplements the base codec with additional LSP = coefficients and functions as a variable rate audio codec.  Our = suggested payload format is compatible with the MELPe encoding of RFC = 8130.  So this draft serves as a companion document to cover the = TSVCIS as a variable rate audio codec.

 

What would = you need from us to advance this work (obviously first to an IETF draft = and then to an RFC)?

 

Victor

------=_NextPart_000_05C1_01D3684E.EB3197B0-- From nobody Tue Nov 28 10:48:44 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15C128B44 for ; Tue, 28 Nov 2017 10:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.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 iOViQmYDfbma for ; Tue, 28 Nov 2017 10:48:40 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335BD126557 for ; Tue, 28 Nov 2017 10:48:40 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id 63so1192458qke.0 for ; Tue, 28 Nov 2017 10:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=foxty594iMRNc1mBlBQgKlHU9SqlowU5GF+g2tkuGGM=; b=hqMFeT5ZaVzr9nxibjPQ+9i0eLNARRZ7+FTdC6TvYZ0RHTfyrMkTUWG/RXFOS3Pl0b rbej4v/LcFQxc9tl9LSCrX3VW6JoNbX/0faASLITvgLh6gtB4Mprne7dZC3QMZ2F1Xm3 MtJPJfZipAQpt2pNrNNwrYCDbSiT5sk+lDDLTx22QtpeD3az7v1Xzk2OeTOyrPp1jJ+e GGjcqbJeVY8v5kyOqw+iPMqX9Wy2lt213iTkZvjjyecPxDw+BQ64LVEimhUdXthVnbbo CEh9VxcFAocrpnIc2m/HYCgdvdKZjHyR6vQcMIDjVVNRurWwBDLPzcHJXVbTYnkgm9WG m6kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=foxty594iMRNc1mBlBQgKlHU9SqlowU5GF+g2tkuGGM=; b=Jy7J6wo3wD4HPcTJaliWqv2uV96+fosVMj0utziqHqHGQjGr83ooVb7FNUNOQbuTQ3 MCc0vPurKJNcNNDivwTkb3TW4b2YvnMZ+xrcdrqdtPAp1U4APPj8lb6vuxjmCw1a12Fo ThqLcVkjpPr4BcBs++MjFGvNzwNlG65qy+CpgSAx7u71wSJdR0Ky52XRA85DSD2Ydspw S84OFTWDYU0WODzW6otOwPvxraFwtjSALqxCKguuD5QNt6wg0da+G0HJmllCuNDwgIzz YdDBKWbyxpf0K2ZuGPP3h4+LBFTRs1eXJAJqXCve2r4AqIY8yl7iJXLAQfEV62GwxPju VAvw== X-Gm-Message-State: AJaThX7OcgTbo4isIUqQ4uGTHvcyrWsZfdlgYbVn3/YEHg4HUfM8VRWt OZ2y0u/oYXk4dHDj1wtPB2VrNgQjTeZk4w== X-Google-Smtp-Source: AGs4zMb19dUTeORvoMP5QXJYVZDuLUHMKxuSxqhOZCjxRD/2+2oIFviZpintUBnBWnqPX7gP68RAtQ== X-Received: by 10.55.182.129 with SMTP id g123mr171447qkf.243.1511894919331; Tue, 28 Nov 2017 10:48:39 -0800 (PST) Received: from [10.36.103.17] (cet-nat.comcastcntr.pa.bo.comcast.net. [68.87.42.110]) by smtp.gmail.com with ESMTPSA id q191sm22047106qke.54.2017.11.28.10.48.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 10:48:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: "Ali C. Begen" In-Reply-To: <5a1dae6f.c54c370a.8690.6c5dSMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 28 Nov 2017 13:48:36 -0500 Cc: Roni Even , payload@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5a1dae6f.c54c370a.8690.6c5dSMTPIN_ADDED_BROKEN@mx.google.com> To: "Victor Demjanenko, Ph.D." X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [payload] Draft document draft-demjanenko-payload-tsvcis-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 18:48:42 -0000 Hi Victor Writing a draft and sending a pointer to the list is always the first = step. And as we get closer to the next meeting, we can decide whether we = need some face time or not. -acbegen > On Nov 28, 2017, at 1:43 PM, Victor Demjanenko, Ph.D. = wrote: >=20 > Hi Roni, Ali, > =20 > I was wondering when the next meeting would be for possible discussion = of our draft RTP payload format for the TSVCIS speech codec? This is = not a well known (yet) speech codec. It is related to MELPe as it uses = MELPe 2400 bps as its base codec. It supplements the base codec with = additional LSP coefficients and functions as a variable rate audio = codec. Our suggested payload format is compatible with the MELPe = encoding of RFC 8130. So this draft serves as a companion document to = cover the TSVCIS as a variable rate audio codec. > =20 > What would you need from us to advance this work (obviously first to = an IETF draft and then to an RFC)? > =20 > Victor From nobody Wed Nov 29 04:37:49 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DCB124319 for ; Wed, 29 Nov 2017 04:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 iBmXBQ9fSbJ6 for ; Wed, 29 Nov 2017 04:37:45 -0800 (PST) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 A9DBD120725 for ; Wed, 29 Nov 2017 04:37:45 -0800 (PST) Received: from [192.168.11.26] (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 9260CB43A2C; Wed, 29 Nov 2017 07:37:44 -0500 (EST) To: "Ali C. Begen" , "Victor Demjanenko, Ph.D." Cc: payload@ietf.org, roni.even@huawei.com References: <5a1dae6f.c54c370a.8690.6c5dSMTPIN_ADDED_BROKEN@mx.google.com> From: "Dave Satterlee (Vocal)" Organization: Vocal Technologies Message-ID: <82bc92ab-f14e-428c-eb31-b3a215fbb523@vocal.com> Date: Wed, 29 Nov 2017 07:37:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B603AF427103F335232EDD5D" Content-Language: en-US Archived-At: Subject: Re: [payload] Draft document draft-demjanenko-payload-tsvcis-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:37:47 -0000 This is a multi-part message in MIME format. --------------B603AF427103F335232EDD5D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Ali, We submitted in October, but didn't hit the list.  Please have a look. https://datatracker.ietf.org/doc/draft-demjanenko-payload-tsvcis/ Regards, Dave Satterlee On 11/28/2017 1:48 PM, Ali C. Begen wrote: > Hi Victor > > Writing a draft and sending a pointer to the list is always the first step. And as we get closer to the next meeting, we can decide whether we need some face time or not. > > -acbegen > > > On Nov 28, 2017, at 1:43 PM, Victor Demjanenko, Ph.D. wrote: > > > > Hi Roni, Ali, > > > > I was wondering when the next meeting would be for possible discussion of our draft RTP payload format for the TSVCIS speech codec? This is not a well known (yet) speech codec. It is related to MELPe as it uses MELPe 2400 bps as its base codec. It supplements the base codec with additional LSP coefficients and functions as a variable rate audio codec. Our suggested payload format is compatible with the MELPe encoding of RFC 8130. So this draft serves as a companion document to cover the TSVCIS as a variable rate audio codec. > > > > What would you need from us to advance this work (obviously first to an IETF draft and then to an RFC)? > > > > Victor > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > --------------B603AF427103F335232EDD5D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks Ali,

We submitted in October, but didn't hit the list.  Please have a look.


https://datatracker.ietf.org/doc/draft-demjanenko-payload-tsvcis/

Regards,
Dave Satterlee


On 11/28/2017 1:48 PM, Ali C. Begen wrote:
Hi Victor

Writing a draft and sending a pointer to the list is always the first step. And as we get closer to the next meeting, we can decide whether we need some face time or not.

-acbegen

> On Nov 28, 2017, at 1:43 PM, Victor Demjanenko, Ph.D. <victor.demjanenko@vocal.com> wrote:
> 
> Hi Roni, Ali,
>  
> I was wondering when the next meeting would be for possible discussion of our draft RTP payload format for the TSVCIS speech codec?  This is not a well known (yet) speech codec.  It is related to MELPe as it uses MELPe 2400 bps as its base codec.  It supplements the base codec with additional LSP coefficients and functions as a variable rate audio codec.  Our suggested payload format is compatible with the MELPe encoding of RFC 8130.  So this draft serves as a companion document to cover the TSVCIS as a variable rate audio codec.
>  
> What would you need from us to advance this work (obviously first to an IETF draft and then to an RFC)?
>  
> Victor

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

---
This email has been checked for viruses by AVG.
http://www.avg.com


--------------B603AF427103F335232EDD5D-- From nobody Wed Nov 29 04:44:12 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B0127286 for ; Wed, 29 Nov 2017 04:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 EDttASYXo6Vg for ; Wed, 29 Nov 2017 04:43:58 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 83159120725 for ; Wed, 29 Nov 2017 04:43:58 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A7627A7CED99C for ; Wed, 29 Nov 2017 12:43:54 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 12:43:55 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 20:43:51 +0800 From: Roni Even To: "payload@ietf.org" Thread-Topic: New document - RTP Payload Format for TSVCIS Codec - pleasew review Thread-Index: AdNpD1R5n0/GIbJSSRKysPUlTAdYNw== Date: Wed, 29 Nov 2017 12:43:51 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD847BAC@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD847BACDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [payload] New document - RTP Payload Format for TSVCIS Codec - pleasew review X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 12:44:00 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD847BACDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have a new RTP payload format in https://tools.ietf.org/id/draft-demjane= nko-payload-tsvcis-00.txt "This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters for enhancing voice quality. TSVCIS augmented speech data is processed = in conjunction with its temporal matched MELP 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail." Please review so that we can ask for adopting this document as a WG documen= t Thanks Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD847BACDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have a new RTP payload format in https://tools.ietf.org/id/draft-demjanenko-payload-tsvcis-00.txt <= /o:p>

 

“This document des= cribes the RTP payload format for the Tactical

   Secure Voic= e Cryptographic Interoperability Specification (TSVCIS)

   speech code= r.  TSVCIS is a scalable narrowband voice coder supporting<= /span>

   varying enc= oder data rates and fallbacks.  It is implemented as an

   augmentatio= n to the Mixed Excitation Linear Prediction Enhanced

   (MELPe) spe= ech coder by conveying additional speech coder parameters=

   for enhanci= ng voice quality.  TSVCIS augmented speech data is processed in conjun= ction with its temporal matched MELP 2400 speech

   data. = The RTP packetization of TSVCIS and MELPe speech coder data is<= /span>

   described i= n detail.”

 =

Please review so that we= can ask for adopting this document as a WG document

Thanks=

Roni Even  Payload = WG co-chair

 

--_000_6E58094ECC8D8344914996DAD28F1CCD847BACDGGEMM506MBXchina_-- From nobody Wed Nov 29 07:09:21 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEDB126CF6 for ; Wed, 29 Nov 2017 07:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no 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 bHICpW1ObnTx for ; Wed, 29 Nov 2017 07:09:19 -0800 (PST) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48080124B18 for ; Wed, 29 Nov 2017 07:09:19 -0800 (PST) Received: by mail-it0-f49.google.com with SMTP id t1so4341047ite.5 for ; Wed, 29 Nov 2017 07:09:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=Q832FWjhLvXFrYoTxrv7uA9KOVB7uwmu4GnRAF4b66g=; b=lMispAAM7anxA4xRlIbguaB5hgIK6hFiHAzajIOC3m8uXkU5ihA89aLzQL2tFgA6dn 31E1QR2gLjlYo4A7LEssarL0Z19onXCxGYKJ8jLxx/HUF3al5Rf7Vf8rqOZv6w87Gxno fzyv5ZnxilhWN57TJ7D0uSaVSb78ec1hoRDa0foGgij5ken2Esg4ti2CICDl0vui7Mi+ atFReyQPotTonp0nwShMvHKuAv+rWRvX/Q6e3Kb8GRg8s8JgrTd0j6/HG0mwzwnIm7LY dNauysL8Gy7brudrTUj+rsVCZQsHJ/69Djq19B+egjt8yuth5Ak57zVNJVlhLUvNWtRb i0Hg== X-Gm-Message-State: AJaThX5kUYOrnNTekzhVICvZZZZvWpq2mXnKWCqU90gp0TXsc5T7oMX6 0iRlOsDyC/uOg16AcqORqsw3PjV1Uwp5kw== X-Google-Smtp-Source: AGs4zMZ6zqto2r+59feyarZbqWe3fthemwZVqRnKtGWFV82BXryEWJ0/w6Jm9McQlIh5I1ziXZV/2Q== X-Received: by 10.36.10.73 with SMTP id 70mr7714362itw.145.1511968158211; Wed, 29 Nov 2017 07:09:18 -0800 (PST) Received: from [172.26.41.114] ([104.129.196.205]) by smtp.gmail.com with ESMTPSA id a29sm1113842itj.8.2017.11.29.07.09.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 07:09:17 -0800 (PST) From: Ali C. Begen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <72255918-B619-4B45-B35B-F5F4DC80C1A6@networked.media> Date: Wed, 29 Nov 2017 07:09:16 -0800 Cc: payload@ietf.org To: draft-ietf-payload-rtp-vc2hq@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [payload] Shepherd's review for draft-ietf-payload-rtp-vc2hq-03 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:09:20 -0000 James, Here is my chair review for your vc2hq draft. Please submit a revision = addressing the comments and then I will ship it to the AD. -acbegen 1) IDnits: There are a few minor issues reported by the IDnits tool. = Please address them. Also =E2=80=9CAbbreviated Title=E2=80=9D should = reflect this draft=E2=80=99s purpose. 2) The use of capitalization is a bit mixed. The RFC editor will likely = fix these, but words like =E2=80=9Cparse info=E2=80=9D, =E2=80=9Csequence=E2= =80=9D, etc. are sometimes capitalized but not always. Would be good to = be consistent. 3) Section 4: s/Time Stamp/Timestamp (in multiple figures) 4) Section 4.1 s/MUST holds/MUST hold 5) Section 4.2 s/sendt/sent Says: Picture header: If the receiver does not receive a transform parameters = packet for a picture then it MAY assume that the parameters are unchanged since the last picture, or MAY discard the picture. Well what if the parameters actually change in the last picture (say pic = 4) but that picture (pic 4) is lost, and the following picture (pic 5) = does not have the parameters. Would the receiver incorrectly assume the = same parameters from pic3 or earlier for pic 5? If the parameters have = changed, how big a problem would it be? What if the Slice Prefix Bytes value or the slice size scalar value is = larger than 16 bits as the smpte spec allows? What if a slice does not fit in a single RTP packet? The draft says the = packet must not contain any partial slices. Can=E2=80=99t there be = slices bigger than a few thousand bytes? 6) Section 5 If we are really talking about Gbps traffic, I am guessing this will be = mostly used in a closed environment in a production network. And maybe = in that case the network is already provisioned to carry such a high = traffic and congestion control may not be needed. I think the draft = should a bit more about this. especially if the vc2 stream to be used on = the Internet, then serious congestion control warnings need to apply. At = this point the section is pretty weak and I am pretty sure this will be = raised by the IESG. 7) Section 6.2 Could you provide a bit more details and one or two examples? See some = of the recent drafts for examples. 8) References: RFC3711, RFC4585 and RFC5124 should be normative IMO. -acbegen= From brian@sip-communicator.org Wed Nov 29 12:18:23 2017 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE11F126C83 for ; Wed, 29 Nov 2017 12:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sip-communicator-org.20150623.gappssmtp.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 2B4HCu0NXqtB for ; Wed, 29 Nov 2017 12:18:21 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7B81241F3 for ; Wed, 29 Nov 2017 12:18:21 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id f20so5343818lfe.3 for ; Wed, 29 Nov 2017 12:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sip-communicator-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=H9SvhxFHtOBQOUU4VjTcG/ZyQun1+VrjSUA/bzHHgk8=; b=pYsN9XXbdJdYgVQFS6O48+fTpelqd1PUa2NkdwVRW8ojLZcC+kol/KBT/DixeWyU8B b6KArUfw6YnxYyAv+0/kcJxVlkV6H4OiumhnuIgaRaGDMYPMv2UHBMxz/zPN6FE9oSIa hYc+PePAs0PPro0xdDeBKVppvPqgiP0YGaBzbAYhgUpAwLNw87Lx56G1JWfG/FHBnNUt /45tv1xDUwCnAfgqgRQZjPjNLpUuzTVLI35bsakKvre9m14DRn5NlOd6FVXJbNjjHR7I uHhCbBm1KNhZCyK2eptmyQ3D5Asnflp+rv6MBThiciKka/zVIas4pcqAwSGHjnB/tQHK YYJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=H9SvhxFHtOBQOUU4VjTcG/ZyQun1+VrjSUA/bzHHgk8=; b=QVloFH79jyzWPYrBZC2APWkHNCY0fkG/Wi4pUd0sY+X5O4cVsqFwSp24lkLMf4MmXX AjW33Zzbs5TYR3shwJoe/hHwJJqqXgbZWwTTU2pXTKjFEoO7DODZJDW4GFiVtH4Gy7cE ukVFfF2jHkV7DR2CPGgdHNRpyFkuW2V0475sq5r3LLcwBhXNObnzUHeM6FmK33LWbmLm vmwuJkkjAG/QN2X6/IOh8OaH3L7iqzp3eNo2ZW+0OEafmD5df2wE02elyDEbe/hLoE9a w4lLZVesIuSiWRdaSzmg+aXDjmBx/+vWpz5LL9hOR+OvkEf3Lh9ycc1SQsFuaUdxShCm RkdQ== X-Gm-Message-State: AJaThX5ZV9CDLknN3lOFvh/UkxQgyZR7ddL3wIcmIvxSsTB/T8GokUv5 9hBYrrsNdt4B4h4yvzhgSK0icwTcHRxeiwqASUhH X-Google-Smtp-Source: AGs4zMY+ZcCc9bEMPhUVY7grTgFmTzAAGuQxdACvmlsk6KkhxH/D926DJ7+nf+EHY/R1DQ8cdrP8fz9dPXm8+rpZghI= X-Received: by 10.25.203.17 with SMTP id b17mr1563646lfg.5.1511986699470; Wed, 29 Nov 2017 12:18:19 -0800 (PST) MIME-Version: 1.0 Sender: brian@sip-communicator.org Received: by 10.46.85.85 with HTTP; Wed, 29 Nov 2017 12:18:18 -0800 (PST) From: Brian Baldino Date: Wed, 29 Nov 2017 12:18:18 -0800 X-Google-Sender-Auth: HhE28IodUt0CSSWF0IKjOlnSBQU Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a078020a15b055f24d666" Archived-At: X-Mailman-Approved-At: Wed, 29 Nov 2017 21:59:02 -0800 Subject: [payload] FlexFEC draft feedback X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 20:26:58 -0000 --94eb2c1a078020a15b055f24d666 Content-Type: text/plain; charset="UTF-8" I've been implementing flexfec on the jitsi videobridge (starting with just the receive side for now) and came across a couple things. Also Boris Grozev has compiled some notes from his readings of the draft; I've tried to summarize all our thoughts here: 1) It would be nice if the draft mentioned that the header extensions of the FEC packets are totally independent of the media's header extensions, and that one can add extensions to FEC packets without having any effect on the recovery. 2) It would be nice if the draft explicitly stated that RTP header extensions (and anything in the header beyond the 12 byte fixed header, really) is protected as part of the payload. 3) I don't think it's explicitly mentioned that the first bit of the mask represents a delta value of '0' (and, therefore, a '1' in that bit means that the base sequence number itself is protected), it would be nice to call this out [in Section 6.3.1.2 maybe?] 4) In some of the diagrams there is a typo making it look like the 'P' field is 2 bits instead of 1 (Figures 10, 12, 13, and 15) 4) From an implementation perspective, I found the extraction of the mask to be a bit of a pain due to having to extract the k bits and shift the actual mask to get the offsets. I wondered if there was a reason not to move the second k bit next to the first to make them consecutive, followed by a consecutive mask. I thought of two ways this might be done: a) Put a 2 bit k field at the start of the mask. There are multiple ways to define an encoding for those 2 bits to represent a 14, 46 or 110 mask. This has the downside of making the first mask 1 bit smaller (14 bits vs 15) but does allow for encoding a 4th mask length, if so desired. b) Put a variable (either 1 or 2) bit k field at the start of the mask. Similar to the current scheme, if the first bit was a '1' it would mean it was only a 15 bit mask and the second bit would not be used to represent the mask size, If the first bit was a '0', then the next bit will also be used to determine the mask size. I.e.: 1 -> 15 bit mask (only one bit spent) 01 -> 46 bit mask 00 -> 110 bit mask -brian --94eb2c1a078020a15b055f24d666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been implementing flexfec on the jitsi videobridg= e (starting with just the receive side for now) and came across a couple th= ings.=C2=A0 Also Boris Grozev has compiled some notes from his readings of = the draft; I've tried to summarize all our thoughts here:

=
1) It would be nice if the draft mentioned that the header exten= sions of the FEC packets are totally independent of the media's header = extensions, and that one can add extensions to FEC packets without having a= ny effect on the recovery.

2) It would be nice if = the draft explicitly stated that RTP header extensions (and anything in the= header beyond the 12 byte fixed header, really) is protected as part of th= e payload.

3) I don't think it's explicitl= y mentioned that the first bit of the mask represents a delta value of '= ;0' (and, therefore, a '1' in that bit means that the base sequ= ence number itself is protected), it would be nice to call this out [in Sec= tion 6.3.1.2 maybe?]

4) In some of the diagrams th= ere is a typo making it look like the 'P' field is 2 bits instead o= f 1 (Figures 10, 12, 13, and 15)

4) From an implem= entation perspective, I found the extraction of the mask to be a bit of a p= ain due to having to extract the k bits and shift the actual mask to get th= e offsets.=C2=A0 I wondered if there was a reason not to move the second k = bit next to the first to make them consecutive, followed by a consecutive m= ask.=C2=A0 I thought of two ways this might be done:

a) Put a 2 bit k field at the start of the mask.=C2=A0 There are m= ultiple ways to define an encoding for those 2 bits to represent a 14, 46 o= r 110 mask.=C2=A0 This has the downside of making the first mask 1 bit smal= ler (14 bits vs 15) but does allow for encoding a 4th mask length, if so de= sired.

b) Put a variable (either 1 or 2) bit k fie= ld at the start of the mask.=C2=A0 Similar to the current scheme, if the fi= rst bit was a '1' it would mean it was only a 15 bit mask and the s= econd bit would not be used to represent the mask size,=C2=A0 If the first = bit was a '0', then the next bit will also be used to determine the= mask size. I.e.:
1 -> 15 bit mask (only one bit spent)
<= div>01 -> 46 bit mask
00 -> 110 bit mask

-brian
--94eb2c1a078020a15b055f24d666--