[payload] Update on FLEX FEC (ver -20)
Giridhar Mandyam <mandyam@qti.qualcomm.com> Thu, 16 May 2019 23:00 UTC
Return-Path: <mandyam@qti.qualcomm.com>
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 42409120221 for <payload@ietfa.amsl.com>; Thu, 16 May 2019 16:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=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 eFlItQPW_o_5 for <payload@ietfa.amsl.com>; Thu, 16 May 2019 16:00:16 -0700 (PDT)
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 3CE4C120100 for <payload@ietf.org>; Thu, 16 May 2019 16:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1558047616; x=1589583616; h=from:to:subject:date:message-id:mime-version; bh=F/ZFvCUW5pgKmBTG59KrPGEkVHDkpi1Sb/29rWaZpuc=; b=ihkWg2FVH4H52NlulMQlh1CPQO6Szoxp1RoWFIrxSeFh5y0bVZaulDbV XvWmFPDcijo28y0OxepaW61RDWldMDVvzZDUzvUkAXgU5o4oWiyVoH1h3 6ci+2eOmDyMOAPWzluctFMM02yXtAx8jLE164wJAUs3A/wKz+YWIhpN+/ 0=;
Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-01.qualcomm.com with ESMTP; 16 May 2019 16:00:14 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,9259"; a="255766986"
Received: from nasanexm01d.na.qualcomm.com ([10.85.0.84]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 16 May 2019 16:00:14 -0700
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01D.na.qualcomm.com (10.85.0.84) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 16 May 2019 16:00:14 -0700
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; Thu, 16 May 2019 16:00:14 -0700
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Update on FLEX FEC (ver -20)
Thread-Index: AdUMOv1jYucN4ke2QaCIqhf4rzQy8w==
Date: Thu, 16 May 2019 23:00:13 +0000
Message-ID: <bb89c761fe0c4e738043689300b9e082@NASANEXM01C.na.qualcomm.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: [10.80.80.8]
Content-Type: multipart/alternative; boundary="_000_bb89c761fe0c4e738043689300b9e082NASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/H_7iJJ5CtHYZGy43XWeS8rvVcAg>
Subject: [payload] Update on FLEX FEC (ver -20)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2019 23:00:19 -0000
Hello, Please note that a new version addressing the comment below has been uploaded. Thanks, -Giri Mandyam From: Bernard Aboba <bernard.aboba@gmail.com> Sent: Tuesday, April 2, 2019 10:55 AM To: Ali C. Begen <ali.begen@networked.media> Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>; payload@ietf.org Subject: Re: [payload] Updates on FLEX FEC (ver -19) CAUTION: This email originated from outside of the organization. Here is my feedback. IMHO the new draft is an improvement, because it makes clear what is mandatory to implement (almost everything) as well as clarifying the SDP negotiation (which seemed quite unclear before). Both of these issues had been encountered in implementations and were likely to lead to interoperability problems. The clarifications do raise the bar in terms of what an implementation needs to be able to handle, but AFAICT not to an unreachable level (at least in a browser or a game console environment). In terms of specific comments: 1.1.7<https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-19#section-1.1.7>. FEC Protection with Retransmission This specification supports both forward error correction, i.e. before any loss is reported, as well as retransmission of source packets after loss is reported. The retransmission includes the RTP header of the source packet in addition to the payload. Therefore, endpoints supporting other RTP retransmission methods (see [RFC4588<https://tools.ietf.org/html/rfc4588>]) in addition to FLEX FEC MUST only use the FLEX FEC retransmission method. [BA] I would like to see this rephrased in Offer/Answer terminology. For example, "If a peer supporting both FLEX FEC and other RTP retransmission methods (see [RFC4588]) receives an Offer including both FLEX FEC and another RTP retransmission method, it MUST respond with an Answer containing only FLEX FEC." On Mon, Apr 1, 2019 at 6:57 PM Ali C. Begen <ali.begen@networked.media<mailto:ali.begen@networked.media>> wrote: Folks, please provide feedback. There are important changes in the flex fec and in a few days, the draft will be shipped to the RFC editor. Thanks. On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam <mandyam@qti.qualcomm.com<mailto:mandyam@qti.qualcomm.com>> wrote: Dear Payload WG, After offline discussion with the editors and reviewers (special thanks to Bernard Aboba), we have decided that the spec needed to be slightly modified. Version -19 contains the following changes: a) Recommendation against negotiation of RTP RTX when FLEX FEC is used. A new section 1.1.7 on the use of FLEX FEC retransmissions has been added to indicate as such. b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields). This means that the sender can send any FEC configuration (as indicated by the FEC header) as long as it stays consistent with the mandatory SDP parameters (rate and repair window). Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the primary impacted sections. We believe this will greatly simplify SDP O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC repair data on a packet-by-packet basis. - Note that L and D cannot be larger than 255, respectively. As we gain implementation experience, if we decide that 255 is not sufficient then it could be possible to extend the corresponding header fields in the future. Currently there are header values that are reserved (R=F=1 and L=D=0) that could be used to indicate the use of an extended L and D field, as an example of one way to implement extended fields for L and D. c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering errors in the abstract procedure for grouping of source packets using their RTP sequence numbers. d) Accounting for the remaining nit's in Benjamin Kaduk's last review. e) Explicitly defining "FLEX FEC" in the abstract. Please provide any feedback within 7 days of the sending of this notification. Thank you, -The Editors of FLEX FEC _______________________________________________ payload mailing list payload@ietf.org<mailto:payload@ietf.org> https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org<mailto:payload@ietf.org> https://www.ietf.org/mailman/listinfo/payload
- [payload] Update on FLEX FEC (ver -20) Giridhar Mandyam