Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

Justin Uberti <juberti@google.com> Wed, 05 July 2017 02:45 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E4D127977 for <rtcweb@ietfa.amsl.com>; Tue, 4 Jul 2017 19:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RbP6s0nrM15D for <rtcweb@ietfa.amsl.com>; Tue, 4 Jul 2017 19:45:42 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 5D7471243FE for <rtcweb@ietf.org>; Tue, 4 Jul 2017 19:45:42 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id v202so107348388itb.0 for <rtcweb@ietf.org>; Tue, 04 Jul 2017 19:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nUYl2+SyNxFO1YIXQSOu9rIQ/Rx8ryJefwE0fsn1HWo=; b=lzzS01G90r5NC7n/tiLFKnXLjO/WbMDtQyYxmDhjBRgMqlQVf2uDrV1SkPg1ZTiZXE /zQUaLiVviuqBvjJ458zHD0Fixxl62bfF/Z2UQ6vKuvMd/yM0icXbZN4hxyAmqi0J64Q LPlHxvH2IiX5bG9PEyP4NRJQ8zDDsFakygcB/WAqiIrGJvWN+XcYrNST8CWvhvPJkwxm RO0JXvDtb4/Dg6pUbkwMMDduty0aCfEP2ezGqy8A24aQz9DvNUZ4A/aA4Qha2Ss2q/3Z pPsEX8tW64THwsF/MrRG06X9sR0Av9stLC2npa1iInJ2Rj96YkSSlcF9G1vLvc59rrW3 7g0Q==
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=nUYl2+SyNxFO1YIXQSOu9rIQ/Rx8ryJefwE0fsn1HWo=; b=kx0Ztd4rGdjacmmiJsKar7l684Hh3lrHTK9DYtgRXgn4GDt9UQu8zalXeC2WpFr99o wuGD458kEfxFVlgGIsB7qamPQv5QMyktbMpJAGWndqP9RSNpehXW5opumXTHc60arcws 5D2ZQe7kSKBZEULuvk0bcsW62cIjKwdjU10pZ4xexI5/siROgnvSfZacOPl9guPA9VOS pXm9Xt9ob4yj3JnppC40qxwdS4qfHK5ibpRwcylGoDNeezYsgklt54p6pgOU1TqslHGb 6GF9OJ47OCYv0lxfExJoSl0IP+UbHBbJ6trx04ElJTu0YCFXltL1ZoUUPrg6QpDnogG/ kWkw==
X-Gm-Message-State: AIVw1115xeyvVJQvRDXjQ5RtsLt2n458HK1yNtqtvQ2pTOr6OzfUE8kr I/DE3sSU8DJk/5+B45ESjZqWeSoZissf
X-Received: by 10.36.33.210 with SMTP id e201mr15710372ita.112.1499222741540; Tue, 04 Jul 2017 19:45:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.18.149 with HTTP; Tue, 4 Jul 2017 19:45:20 -0700 (PDT)
In-Reply-To: <CAOJ7v-2gu2aE4FqWcb4=DoRPZ30h33E6rFTjGLAiEbLz2hJ+nQ@mail.gmail.com>
References: <1ddd77ef-da4a-1a89-e538-aa20742c11a4@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B0714@DGGEMM506-MBX.china.huawei.com> <CAOJ7v-3yukU+SLcbAiR1TYqeu54nV+8V-h9hUgFc5JRMRzgx=w@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B084E@DGGEMM506-MBX.china.huawei.com> <9a38ffd6-e4f6-632a-b5a3-df5ded305a2e@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B08CD@DGGEMM506-MBX.china.huawei.com> <3a83f119-34a0-a9dc-da07-d63f1e912851@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7B090B@DGGEMM506-MBX.china.huawei.com> <CAOJ7v-2gu2aE4FqWcb4=DoRPZ30h33E6rFTjGLAiEbLz2hJ+nQ@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 4 Jul 2017 19:45:20 -0700
Message-ID: <CAOJ7v-37=bdiG3gBJxdk2M9k11gtmK6xtY+Zq_OeK9mn4TDmUA@mail.gmail.com>
To: Roni Even <roni.even@huawei.com>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="001a11474a72f360a8055388fe41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/XAxTKlAMV9phgTKF_bZj8MpfHwI>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 02:45:45 -0000

This is now addressed in the latest version of the draft -
https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06, Section 3.

On Mon, Apr 24, 2017 at 11:31 AM, Justin Uberti <juberti@google.com>; wrote:

> Agree - the differences in protection that you mention are what I was
> planning to discuss in the new text.
>
> On Mon, Apr 24, 2017 at 2:59 AM, Roni Even <roni.even@huawei.com>; wrote:
>
>> Hi Sergio,
>>
>> I understand your distinction between FEC (ulpfec) and  RED with regards
>> to the RTP header. Still, the RTP header extensions have their own
>> redundancy recommendations so they less less problem for packet loss.
>>
>> Maybe it will be good in section 3 to add a section that mention that FEC
>> will protect the whole RTP packet while RED and in-band fec will only
>> protect the RTP payload.
>>
>>
>>
>>
>>
>> Roni
>>
>>
>>
>> *From:* Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com]
>> *Sent:* יום ב 24 אפריל 2017 12:09
>> *To:* Roni Even; Justin Uberti
>> *Cc:* rtcweb@ietf.org
>> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>>
>>
>>
>> AFAIK, FEC (at least ulpfec) protects the full packet, including header
>> extensions. When we are addressing the usage of RED vs FEC for audio we
>> should note the difference in behavior  and it's possible consequences.
>>
>> Best regards
>> Sergio
>>
>> On 24/04/2017 11:04, Roni Even wrote:
>>
>> Hi Sergio,
>>
>> What I said that the redundancy of RTP header extensions in not a FEC
>> issue. FEC addresses the payload and not the RTP header.  RTP header
>> extensions are discussed in the RFC5285-bis draft and each new RTP header
>> extension must address the issue of loss since RTP over UDP is unreliable.
>>
>> I am not sure we need any text in rtcweb-fec about RTP header
>> extensions.  General RTP usage in RTCweb is in the RTCweb RTP usage and
>> this is where general redundancy of RTP is discussed, and as a general RTP
>> usage it points at redundancy for payload and for RTP header extensions
>> reference RFC5285 (rfc5285-bis will obsolete it and have a section about
>> transmission consideration.
>>
>>
>>
>> In this rtcweb-fec document audio/red is a payload; it is not an RTP
>> packet for which you need to address the RTP header redundancy.
>>
>>
>>
>> Roni Even
>>
>>
>>
>> *From:* Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com
>> <sergio.garcia.murillo@gmail.com>]
>> *Sent:* יום ב 24 אפריל 2017 11:28
>> *To:* Roni Even; Justin Uberti
>> *Cc:* rtcweb@ietf.org
>> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>>
>>
>>
>> Hi Roni,
>>
>> Not following you. Neither RFC 5265 nor RFC 5265-bis references
>> red/audio, also webrtc-rtp-usage references the fec draft when speaking
>> about redundancy.
>>
>> Also, please note that I am not proposing to change current RED behavior
>> or its usage within webrtc, just proposing to add a "warning" note to make
>> it implicit what is the current situation: When using rtp red for audio,
>> only payload is protected, and rtp headers are not, which is almost
>> harmless currently but could cause some issues in the future if not taken
>> into consideration when using new rtp header extensions.
>>
>> Best regards
>> Sergio
>>
>> On 24/04/2017 7:43, Roni Even wrote:
>>
>> Hi Justin,
>>
>> I am not sure that this is something to discuss here, RTP header
>> extensions are discussed in https://tools.ietf.org/html/dr
>> aft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 soon to be
>> replaced  by the rfc5285-bis draft.
>>
>> The bis draft has a section about transmission considerations see
>> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-
>> 09#section-4.1.1 discussing reliability of RTP header extension delivery
>> by sending them in multiple RTP packets.
>>
>>
>>
>> If you still want to say something you can probably add to section 1 “
>> Web Real-Time Communication (WebRTC) Media Transport and Use of RTP are
>> discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26”
>>
>>
>>
>> Roni
>>
>>
>>
>>
>>
>> *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>]
>> *Sent:* יום א 23 אפריל 2017 21:48
>> *To:* Roni Even
>> *Cc:* Sergio Garcia Murillo; rtcweb@ietf.org
>> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <roni.even@huawei.com>; wrote:
>>
>> Hi,
>> Inline
>> Roni Even
>>
>> > -----Original Message-----
>> > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio
>> Garcia
>> > Murillo
>> > Sent: יום ו 21 אפריל 2017 12:30
>> > To: rtcweb@ietf.org; Justin Uberti
>> > Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>> >
>> > Hi all, Justin,
>> >
>> > I have been reviewing current FEC draft and I have a couple of comments:
>> >
>> > 1. Usage of RED and in band FEC and header extensions in Sections 3.2,
>> > 3.3 and 4
>> >
>> > I think it would be worth noting that neither red/audio nor in-band fec
>> allows
>> > to recover RTP header extensions from previous packets. The impact of
>> > loosing the header extensions will be dependent of its meaning as, for
>> > example, this would cause minor problems to SFUs as client to mixer
>> audio
>> > level info of previous packets will be lost, but could make it unusable
>> for
>> > PERC (as it is currently defined) as it requires the OHB header
>> extension.
>>
>>
>> [Roni Even] This is not a FEC problem but general RTP header extensions
>> reliability discussed in RFC5285 and RC5285-bis draft and in the specific
>> RTP header extension.
>>
>>
>>
>> Roni, what would you suggest we say in this document?
>>
>>
>>
>> >
>> > 2. Adaptive use of FEC for bandwidth probing (section 8)
>> >
>> > I think it would be a good addition to recommend FEC usage for bandwidth
>> > proving instead of other alternatives like RTX or padding only packets.
>> >
>> > Best regards
>> >
>> > Sergio
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > rtcweb@ietf.org
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>>
>>
>>
>
>