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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 24 April 2017 08:28 UTC

Return-Path: <sergio.garcia.murillo@gmail.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 095E7129B20 for <rtcweb@ietfa.amsl.com>; Mon, 24 Apr 2017 01:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, T_KAM_HTML_FONT_INVALID=0.01] 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 xU0l2x_A1Kbc for <rtcweb@ietfa.amsl.com>; Mon, 24 Apr 2017 01:28:01 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 AFC30129B18 for <rtcweb@ietf.org>; Mon, 24 Apr 2017 01:27:58 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id w50so63683072wrc.0 for <rtcweb@ietf.org>; Mon, 24 Apr 2017 01:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=psc3R06leTebaA/EJZiHiZ77pULkWgSN9s+IS+K1vvc=; b=aFtdh9yZeArLHpJi+xNfqKqlCCZYSqP7hKnAhDBLeVJbuReqKli505Cey2/JYr3JuE ue59j3fU1MCExxdLGto85lj/y6wjb/I5F4hlFBFpee7c9MoUIB84EnBPFAnLPnt5OWy3 QgQuyhoXdjMuaHFswVMwMpL5uxwgZ5HquaeC0KPhHu+2KBJ+rxtreuTLsKaQhrIDtsij 7EPT/zRo8k+ifIz1FdKRV/ADPAmYJKPfd0QrY/1GReb7NHbZNCGjnK1CgC3Aqu84COvq bUoAfE1mEPP/7YxwMoeR9jjpOMaDeY/liLWbA+LGaQweukqFOEA2Yrr3u7KtknDjlUnL VJkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=psc3R06leTebaA/EJZiHiZ77pULkWgSN9s+IS+K1vvc=; b=MRyy+5iugDE7jOENJcV8nL8Pj133mbRlkW01Ltu103CMVnbNvy0NxlwomMVW+lMA08 kNm4ST8tTqcJwvb63ZduWWLvE97V105xD5OjMwfR99oKoKOqryb0qKy7korALKqUKB1B eiYSWYRJ+qGEwM8pNQaRBL1Ivc7Mcz5ytmSAe/4nNlyk3nk3FSirO5Nv/LGdBbFiCmr4 sy121EWVfyJnAN58czve0HQKFHSX+MDBfb005o27Q+Wo+Vzx4hTn8VuOO32b/J848anG qdS1c7MdErk579gPhOszXV9AFoeYRRcGE82gAdh+KRKUaCEcCKThFJwoLTLkxosnIbdj kPug==
X-Gm-Message-State: AN3rC/4W5kWaNQgBKuLJz1ax02lfH7/KXyJWFjCgrvBKu5gnl9Z7KoPg JOU4Sn9P97Tiyw==
X-Received: by 10.223.130.201 with SMTP id 67mr4885947wrc.106.1493022477082; Mon, 24 Apr 2017 01:27:57 -0700 (PDT)
Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id m201sm11883013wmd.15.2017.04.24.01.27.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 01:27:55 -0700 (PDT)
To: Roni Even <roni.even@huawei.com>, Justin Uberti <juberti@google.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>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <9a38ffd6-e4f6-632a-b5a3-df5ded305a2e@gmail.com>
Date: Mon, 24 Apr 2017 10:28:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7B084E@DGGEMM506-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------32FA19D4CA8559D3262240C3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/QlsH1X68tI4IzsqRbACmGTk40Q0>
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: Mon, 24 Apr 2017 08:28:05 -0000

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/draft-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.1discussing 
> 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]
> *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 
> <mailto:roni.even@huawei.com>> wrote:
>
> Hi,
> Inline
> Roni Even
>
> > -----Original Message-----
> > From: rtcweb [mailto:rtcweb-bounces@ietf.org 
> <mailto:rtcweb-bounces@ietf.org>] On Behalf Of Sergio Garcia
> > Murillo
> > Sent: יוםו 21 אפריל 2017 12:30
> > To: rtcweb@ietf.org <mailto: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 <mailto:rtcweb@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/rtcweb
>