Re: [payload] Updates on FLEX FEC (ver -19)

Bernard Aboba <bernard.aboba@gmail.com> Tue, 02 April 2019 17:55 UTC

Return-Path: <bernard.aboba@gmail.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 C92A7120172 for <payload@ietfa.amsl.com>; Tue, 2 Apr 2019 10:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 DQl2jSFrrN9O for <payload@ietfa.amsl.com>; Tue, 2 Apr 2019 10:54:58 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 05C45120182 for <payload@ietf.org>; Tue, 2 Apr 2019 10:54:58 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id d5so4676062uan.6 for <payload@ietf.org>; Tue, 02 Apr 2019 10:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VutlxtZGNcoiIJYssbuyfojjpfpjPPAfJKRIJs9npeA=; b=muF889fuJAhZuIZzHjfzQ8h0/csp9ZcsU0GNm2VJOsH6AB6B0MTI1z9t7jVSWSfGRb EswPrh7OooV5sS44MiUCeQG5k8KL9iesT88hnkjhqfrGDnTxgkNf1Bw+g5ZPOHJqdak4 QdQiBOyN66PDGaR/LoPPyNxp/4WThWGniKhFR6gpKwWUC0tQST6BAtJjkAX3elKwQYH0 wUdWMZ/JidSfHpFAKrACh5x8PbgET/g6PYNffLhflkuE0UvolRcucKd69RGwXJvOtP9Q AvQk7Xndy1bpVr+75xVsLWXQOPPsXxrZXoVQA1Ko250aJcvzbyqLKnpOBslvihERswmC vttA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VutlxtZGNcoiIJYssbuyfojjpfpjPPAfJKRIJs9npeA=; b=HlYIiQ34kqmASmP26GBBcrsqkzTAad2SFKAO1HQUWV/Vi7wlq9Q+Ay646DAtk5bMVf YzZA/0+pI0U390tLTKX+MBBQzSurw+mLtMyWaKVyjEZDNP6GGesUup3UuYzWPorDw5TA M4A2S4Nep8Z/Z69P9GWdH5pNHntWkdgobmpbVHgARRcyWyXlL3oJVJ1m0kNF0AhFPnLD m1me2n0d/58UV5HqlNuxCS2zLCqU9LNE8a6PlO/dLrlk+BMNlQzed/J7Z9wAZla6hs5c RZl2pFOF8EuyNCci0b4qSUD9m1olEkGvToIiG32aH0FbAuDPWykA0cZS3cttqpZRib3o D1fQ==
X-Gm-Message-State: APjAAAWlMLhYexxHDTiMFXbgDoX704yDhUhKWtAzV4BrPiK3a/BH1NCw thUCYjICy6AhNrCfa55qLH/UcSMAgCfawBF5JLM=
X-Google-Smtp-Source: APXvYqy+poNem0gsKm8oU2AicBfYgbRP4HHPf3SJ9psbqrOwug8P/KDPFbRxrKktvo7WIeIJwqHnJtJEGLZ759vxt8o=
X-Received: by 2002:ab0:70d4:: with SMTP id r20mr36402427ual.67.1554227696658; Tue, 02 Apr 2019 10:54:56 -0700 (PDT)
MIME-Version: 1.0
References: <5e948e46153445c892dc661085d21073@NASANEXM01C.na.qualcomm.com> <CAA4McztCnsm+coMH6B=9_UHFfX+sdWmuXR6veXuKUxjPaGjytw@mail.gmail.com>
In-Reply-To: <CAA4McztCnsm+coMH6B=9_UHFfX+sdWmuXR6veXuKUxjPaGjytw@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 02 Apr 2019 13:54:45 -0400
Message-ID: <CAOW+2dsydVC38-K_z+HUtxu6r4KmC6xMp1E5CP3XjErx0+q6Ng@mail.gmail.com>
To: "Ali C. Begen" <ali.begen@networked.media>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "payload@ietf.org" <payload@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c26eda05858fd53a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/U1jLdf7Iw50AqrcfW9Ib6qGghyI>
Subject: Re: [payload] Updates on FLEX FEC (ver -19)
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: Tue, 02 Apr 2019 17:55:02 -0000

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>
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>
> 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
>> https://www.ietf.org/mailman/listinfo/payload
>>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>