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

Giridhar Mandyam <mandyam@qti.qualcomm.com> Mon, 04 February 2019 05:34 UTC

Return-Path: <mandyam@qti.qualcomm.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 95DE0130E09; Sun, 3 Feb 2019 21:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 qJNWYeUD4Tay; Sun, 3 Feb 2019 21:34:31 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F711294FA; Sun, 3 Feb 2019 21:34:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1549258471; x=1580794471; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZbHftOrMhphQZdHBoB9DHaiCe/KioVgJdnFLxC8T4do=; b=fjTQ6qf4Q1DaewfcsP8YUg6/tJWPy+XR5A+MDgBUeTl1LBX1794hzW7R fcKU/hXwzzVKyDITVz0/z81RbryiA0m5IM53PwrAxGRQHbJnnRdKZdTmZ NEwKOmDiOdKLcUM2cid3mEKyFO+AMWNf4KCFzFNHwd1SNl8K30aWJ+MMk k=;
X-IronPort-AV: E=Sophos; i="5.56,559,1539673200"; d="scan'208,217"; a="26310326"
Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-01.qualcomm.com with ESMTP; 03 Feb 2019 21:34:30 -0800
Received: from nasanexm01c.na.qualcomm.com ([10.85.0.83]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 03 Feb 2019 21:34:30 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01C.na.qualcomm.com (10.85.0.83) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 3 Feb 2019 21:34:29 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Sun, 3 Feb 2019 21:34:29 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Meral Shirazipour <meral.shirazipour@ericsson.com>, "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: AdS6AXpmB06Lq5qJQ9mEFCKG02iH2gCSO5ng
Date: Mon, 4 Feb 2019 05:34:28 +0000
Message-ID: <0a8ee63d79c94929b6964df1b3c15e1b@NASANEXM01C.na.qualcomm.com>
References: <BN8PR15MB2802BD6D363951E396F0961F9A920@BN8PR15MB2802.namprd15.prod.outlook.com>
In-Reply-To: <BN8PR15MB2802BD6D363951E396F0961F9A920@BN8PR15MB2802.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [199.106.107.6]
Content-Type: multipart/alternative; boundary="_000_0a8ee63d79c94929b6964df1b3c15e1bNASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/CRKxVYfZwCXHKP2PZUpIkTf8VXc>
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: Mon, 04 Feb 2019 05:34:33 -0000

>-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>;
Sent: Thursday, January 31, 2019 11:50 PM
To: draft-ietf-payload-flexible-fec-scheme.all@ietf.org; 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>