Re: [Gen-art] Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16

Meral Shirazipour <meral.shirazipour@ericsson.com> Tue, 05 February 2019 02:08 UTC

Return-Path: <meral.shirazipour@ericsson.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED02130F6C for <gen-art@ietfa.amsl.com>; Mon, 4 Feb 2019 18:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.852
X-Spam-Level:
X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZdsszkmX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=JVJ0djEd
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 0hq63ft3_wHs for <gen-art@ietfa.amsl.com>; Mon, 4 Feb 2019 18:08:57 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 48A6A130F66 for <gen-art@ietf.org>; Mon, 4 Feb 2019 18:08:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549332534; x=1551924534; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pwaR4K3+txCqCvIZuhpBpNMNTqgCMZDPU64Ygxf4/+c=; b=ZdsszkmX88HNfmzep3t/16b06n0TUXa5XhUR68PRSydooFX9Ek9odqm2FIU0isS8 eyokXZ1wUogzV8FwEX+TUzeeAw207viNP6H1ajWh4paBw1myJwBROgXSdqQOOm7M 4ICU7Z0BVsL0XQHNDOYd29Dud4QSPf06r6MXGYmsSMU=;
X-AuditID: c1b4fb2d-d9dff7000000062f-57-5c58f036e1eb
Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.5C.01583.630F85C5; Tue, 5 Feb 2019 03:08:54 +0100 (CET)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Feb 2019 03:08:53 +0100
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Feb 2019 03:08:53 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pwaR4K3+txCqCvIZuhpBpNMNTqgCMZDPU64Ygxf4/+c=; b=JVJ0djEdwjhJcwUC+CmhHYn3f+7W+ehhuVb0drXeO8pZ/ZqXQ9VmscqIS1YDYEt/WjfgDev5fTMwBmPCjEfaFLXG6a9zUkQIyx2aYHFPsS1uBTkJYXPqFr7iT39khplgut+oo8USXcI0KC7BwmgXEK3dURI1ZdbWrHvOexBpk0g=
Received: from BN8PR15MB2802.namprd15.prod.outlook.com (20.179.140.76) by BN8PR15MB2881.namprd15.prod.outlook.com (20.178.219.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.20; Tue, 5 Feb 2019 02:08:51 +0000
Received: from BN8PR15MB2802.namprd15.prod.outlook.com ([fe80::1ced:3d45:4e9d:f653]) by BN8PR15MB2802.namprd15.prod.outlook.com ([fe80::1ced:3d45:4e9d:f653%2]) with mapi id 15.20.1580.019; Tue, 5 Feb 2019 02:08:51 +0000
From: Meral Shirazipour <meral.shirazipour@ericsson.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Varun Singh <varun@callstats.io>
CC: "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16
Thread-Index: AdS6AXpmB06Lq5qJQ9mEFCKG02iH2gCSO5ngACUu1IAAAE47AAAF1Zug
Date: Tue, 5 Feb 2019 02:08:51 +0000
Message-ID: <BN8PR15MB2802A55FBE188DB536E49EE49A6E0@BN8PR15MB2802.namprd15.prod.outlook.com>
References: <BN8PR15MB2802BD6D363951E396F0961F9A920@BN8PR15MB2802.namprd15.prod.outlook.com> <0a8ee63d79c94929b6964df1b3c15e1b@NASANEXM01C.na.qualcomm.com> <CACHXSv5JFthqPwRVL38ybq_FimkaEw2wxv-MVQ_Bf6TmuQB2=Q@mail.gmail.com> <dbd9a340132847e492897a50ddc9b9f4@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <dbd9a340132847e492897a50ddc9b9f4@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=meral.shirazipour@ericsson.com;
x-originating-ip: [208.82.99.177]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN8PR15MB2881; 6:qalIaHtkvLwIsyq/gyaiN6ZGw4K3S9U1HROWdGJqJnnNbznkucwaBd5TV/vBF2MYMLxGGf8IUL/GA8yiuaDzVYidE2kvrw7z130vPi4bHF+QI1vatuZ+Xk/8S0oa34GHqfr49AwmfVb8D4SqDLbHOVMvuXf23Fc5eqtKNOvJZv/hro83UBFzmmh5ttV3VFCPlzqmQf9awnsnzJ1TRaejZPjbfmxeyQPVt+z2nHGdj5449e0H4bBMf0hENfMiKOcmDywheEIOvSZz4X9riwYEqLr0GBJfz9szCq0hxQOPnH6PSuNqZWIOC7NPJd/OaTiH8KrVThYPQvduQIZGk7k99KTYUdJhaROrOTRkFtWo07loHc20ul5Hx8/1hqv6DgRjozQu/p1lA9pBlVQEkcyEGDNVX1Wya3aPtzxhTNUQyX2uoAyF8kQGkwCKmr6oM5d0N0iZvGbQ3HVv60hkFzeGog==; 5:tZAsqoRtDQzgsCigr1D4oTGQYhkp27u7o1Q2QEfMMELA3PKVtP7XTJTTU/IVs2jySqcMpc07t8uV0wzccefo+zAPEGDHhl4DaAkfpo083WHYDLExrZP7exiARnwBzavbo0zR/fIAGmtqRZKOXdbrEWH5F8ws4HkvxkjxNTyxblwRHRi3O603Dw4QTd8hGtcXWJziwB+YGKAfaLEhOl9+rQ==; 7:Y4OYSfAK/8zTocC+wbI81Ypx+/LenSP7WmUrvB8EztiRmVHLPzEjlO8E/UOreu07Bs7rwwPLX1FBRJho5m9X+eCiqli11ehuEzzKcZW6Qa9yGqCagUMvD00PPq8DVJPfUtDcun8KnC9JSDgA2yyYsA==
x-ms-office365-filtering-correlation-id: b601f4d0-6299-4ce0-b0fb-08d68b0edf6c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN8PR15MB2881;
x-ms-traffictypediagnostic: BN8PR15MB2881:
x-microsoft-antispam-prvs: <BN8PR15MB2881B8EC000661AC250485CA9A6E0@BN8PR15MB2881.namprd15.prod.outlook.com>
x-forefront-prvs: 0939529DE2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(136003)(39860400002)(366004)(189003)(199004)(74316002)(71200400001)(26005)(14454004)(71190400001)(7696005)(105586002)(256004)(966005)(316002)(102836004)(76176011)(68736007)(2906002)(106356001)(6306002)(6506007)(110136005)(53546011)(54896002)(93886005)(25786009)(9686003)(236005)(33656002)(54906003)(4326008)(8936002)(6246003)(44832011)(53386004)(99286004)(81156014)(446003)(8676002)(81166006)(476003)(6436002)(97736004)(486006)(7736002)(186003)(11346002)(606006)(229853002)(53936002)(9326002)(55016002)(478600001)(790700001)(86362001)(6116002)(66066001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB2881; H:BN8PR15MB2802.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ti8qOxtYyspgCpipiv0u8asDi1Qs30yZbm5dsnNXxH9df165jwZBppEEDk4FlanECHxLAmCcw914eXFeYJiSdOsOxp+GLK1O2O7aSDWbn2D5BilSDwC6QKG2f70dzikhnsNzgZjuCDXQqt1WVUo1ncc+60yrzMLjCGDz9vcTJi/ha/BNGe6OREfZBVtevl/tPctSfmb6/FIK/ndTVhYg0FOv0uPKpO1kml7eFexf92S6beFKd/OnEFwXc7tcubRU4sBeMf/eqH1WQStYbQXiDCISa6OHUDLJw9/eLQo7BysDgaWoELStbuHTNQymYkdB29LelNiyKELaRBmlI3Z7uRN/T/CL4yN2/AwGPQoMKtEzbEI5KqEgpABxnLkbxee3PKFDTiuA/3UZx2WsPEdTGzUcBounsytHi5I5WWsDdjo=
Content-Type: multipart/alternative; boundary="_000_BN8PR15MB2802A55FBE188DB536E49EE49A6E0BN8PR15MB2802namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b601f4d0-6299-4ce0-b0fb-08d68b0edf6c
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 02:08:51.2368 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB2881
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO/fe7V6Hg+PS/OWjckQP8dFDcn9UFEGIFgglmEi12kXFZ/ea pBmM1HKaaGbi1nzkE6YxEsl35sjEQIJMSYNK1EQjHC0z06xtZ4H/fc/3+/n9zu93OByt6JX4 cElpmbyQpk5RSmWMPrZTCD5ijY0/oJv2Us2Pl0hV44s2RrX0axKplu8PSE8wEcaRUjqisXGV iqh/+AVF03Gyoxo+JSmLF0KPX5YlLnY/pzPa19CNkSojrUWzP1ARcuMAh8FG55DUoRX4JYLh fE0Rktn1MoIPtYUScmigwJq/4KQYXEZDye90EpRT8Ng446KmEQyUDjMOSopV0Lk2L3FoT3wO Cp7O0Q6IxgYE86Y8Z6ut+Dw0G3QMgWLA9lnrKjgNaxMvELluN6x2P3NqOY6H8sJHFBm2iYKP 2miHdsNRcMc86uyJ8DZYed3mZGjsDVOztRRZFENj3xuaaC9YmNmQEF4Nxet9DPEDwNq+7mL8 4W1tMXIMDfg2C3f/PGBJcBaml+5JSTCJoHCjyPWUgWCesbiqk6FSa3Z19YOu7kGKFBRIwVTZ RpMVeGh5UoDKUJBh07REp8OErY41OLf2gBH9LGNAnN3fD+aeUIIEQEXxNEv0PigwVrOb/TrE mpCXyItiasKhwyG8kHRVFNPTQtL4zHZk/1KDHWvBXaj160kLwhxSustblmLjFRJ1lpidakHA 0UpPefKg3ZJr1Nk5vJB+SbiewosW5MsxSm/5usIjXoET1Jl8Ms9n8ML/lOLcfLTIoI/UX2lf 2KnxH0nMwR7Vn46pNK9++iX2oYBuy60zewzv9WO54TUtFdb6ceYUO7HjWnJQjG0qhNINZTW1 vKuKbG3Y3hHn31+OTNa8GnoudzEM6eXudZ1jNrSlOdx3ONi3t193UblCXWBTV3Plf7+PUl57 v92M2uVP9YzbPJWMmKg+GEgLovofsUuTFk4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/G915EgA_8lFbgkuy5NwhMl2MTqQ>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Feb 2019 02:08:59 -0000

Hi,
  Even better, thanks.

Best,
Meral

From: Giridhar Mandyam <mandyam@qti.qualcomm.com>;
Sent: Monday, February 4, 2019 3:22 PM
To: Varun Singh <varun@callstats.io>;
Cc: Meral Shirazipour <meral.shirazipour@ericsson.com>;; draft-ietf-payload-flexible-fec-scheme.all@ietf.org; gen-art@ietf.org
Subject: RE: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16

Hi Merai,

Slight revision follows.  I assume it is still OK.


“… an application should avoid sending/receiving FEC repair streams if it knows that sending/receiving those FEC repair streams would not help at all in recovering the missing packets.  Examples of where FEC would not be beneficial are:  (1) if the successful recovery rate as determined by RTCP feedback is low (see RFC 5725 and RFC 7509),  and (2) the application has a smaller latency requirement than the repair window adopted by the FEC configuration based on the expected burst loss duration and the target FEC overhead.  It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted  dynamically based on the packet loss rate and burst loss length observed by the applications."
-Giri

From: Varun Singh <varun@callstats.io<mailto:varun@callstats.io>>
Sent: Monday, February 4, 2019 3:13 PM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>>
Cc: Meral Shirazipour <meral.shirazipour@ericsson.com<mailto:meral.shirazipour@ericsson.com>>; draft-ietf-payload-flexible-fec-scheme.all@ietf.org<mailto:draft-ietf-payload-flexible-fec-scheme.all@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>
Subject: Re: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16


CAUTION: This email originated from outside of the organization.
Hi Giri,

Both post-repair loss metrics should be referenced, one provides run-length perpacket feedback and the other provides loss and repair counters. Webrtc-stats reports on the latter and can already be used to toggle FEC in webrtc applications.

On Mon, 4 Feb 2019 at 0.34, Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>> wrote:
>-Section 8, "an application should avoid sending/receiving FEC repair streams if it knows that sending/receiving those FEC repair streams would not help at all in recovering the missing packets. It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted dynamically based on the packet loss rate and burst loss length observed by the applications."

>How would the application know that sending/receiving those FEC repair streams would not help at all? any rule of thumb to add here?

The editors propose that the above text be revised as follows:


“… an application should avoid sending/receiving FEC repair streams if it knows that sending/receiving those FEC repair streams would not help at all in recovering the missing packets.  Examples of where FEC would not be beneficial are:  (1) if the successful recovery rate as determined by RTCP feedback is low (see RFC 5725),  and (2) the application has a smaller latency requirement than the repair window adopted by the FEC configuration based on the expected burst loss duration and the target FEC overhead.  It is RECOMMENDED that the amount and type (row, column, or both) of FEC protection is adjusted  dynamically based on the packet loss rate and burst loss length observed by the applications."

Please let us know if this is acceptable.

Thanks,

-Giri Mandyam

From: Meral Shirazipour <meral.shirazipour@ericsson.com<mailto:meral.shirazipour@ericsson.com>>
Sent: Thursday, January 31, 2019 11:50 PM
To: draft-ietf-payload-flexible-fec-scheme.all@ietf.org<mailto:draft-ietf-payload-flexible-fec-scheme.all@ietf.org>; gen-art@ietf.org<mailto:gen-art@ietf.org>
Subject: Gen-ART Last Call review of draft-ietf-payload-flexible-fec-scheme-16


CAUTION: This email originated from outside of the organization.
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.

Document: draft-ietf-payload-flexible-fec-scheme-16

Reviewer: Meral Shirazipour
Review Date: 2019-01-31
IETF LC End Date: 2019-02-01
IESG Telechat date: NA


Summary: This draft is ready to be published as Standards Track RFC .
Major issues:

Minor issues:

Nits/editorial comments:
-Section 1.1.1 Title "One-Dimensionsal "--->"One-Dimensional"

-[Page 14] 3.2.  , "signficant"--->"significant"

-[Page 16], 4.2.1.  , "pakcets"--->"packets"

-[Page 35], 6.3.1.  , "reciever"--->"receiver"

-[Page 35], 6.3.1.1.  , "signficant"--->"significant"

-[Page 43], 7., "several Sesssion "--->"several Session "

-Section 8, "an application should avoid
   sending/receiving FEC repair streams if it knows that sending/
   receiving those FEC repair streams would not help at all in
   recovering the missing packets. It is RECOMMENDED that the amount
   and type (row, column, or both) of FEC protection is adjusted
   dynamically based on the packet loss rate and burst loss length
   observed by the applications."

How would the application know that sending/receiving those FEC repair streams would not help at all? any rule of thumb to add here?


Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com<http://www.ericsson.com>
--
Founder, CEO, callstats.io<http://callstats.io>
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/<http://www.callstats.io/jobs/>