Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Giridhar Mandyam <mandyam@qti.qualcomm.com> Mon, 07 January 2019 18:38 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 2C2CB12785F; Mon, 7 Jan 2019 10:38:47 -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 q0idBgmxhvOk; Mon, 7 Jan 2019 10:38:44 -0800 (PST)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F3B1277D2; Mon, 7 Jan 2019 10:38:44 -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=1546886324; x=1578422324; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Tfw2qfjSdRvZDZTyYXUzapxL3yXXNAG9qrty9KtXLZs=; b=Svg5qqORHfpAHW2E3tjvQfbhCqXZIGa293PoJCezQ4Y2h9/3bMMP51ts 4v3ovh4WDsOlLocaklt4JD7F2OmG8E3lLVQQ/XTO9IGnj0DezUcgdz6+J RWARBpkYW7QEs+7uBszX3dP8CL6m24brJ8k9ID3YvTzzyrZIj0PrDQaNg I=;
X-IronPort-AV: E=Sophos; i="5.56,451,1539673200"; d="scan'208,217"; a="23558736"
Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-02.qualcomm.com with ESMTP; 07 Jan 2019 10:38:43 -0800
Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 07 Jan 2019 10:38:43 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 7 Jan 2019 10:38:43 -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; Mon, 7 Jan 2019 10:38:43 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>, "payload@ietf.org" <payload@ietf.org>, Ben Campbell <ben@nostrum.com>
Thread-Topic: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes
Thread-Index: AdSjpbyCoL1+LHhrRfypJF1xMdVwaQC1k/xAAA76OrA=
Date: Mon, 07 Jan 2019 18:38:42 +0000
Message-ID: <32426087082648efb5dedb901d9c1fb9@NASANEXM01C.na.qualcomm.com>
References: <c98b67a013d94d1d9fe62504153b83b6@NASANEXM01C.na.qualcomm.com> <DB7PR07MB4988ED389E5D133A6806E6B895890@DB7PR07MB4988.eurprd07.prod.outlook.com> <6E58094ECC8D8344914996DAD28F1CCD18C99631@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18C99631@dggemm526-mbx.china.huawei.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_32426087082648efb5dedb901d9c1fb9NASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/iV6QNbrOXXNZW57tPPwyxCltYsE>
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes
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: Mon, 07 Jan 2019 18:38:47 -0000

Hi All,

I am in favor of making the change Magnus recommended below.  My apologies - I did not consider all use cases when responding to the AD review.  I will submit a revision next week (with this change and any other requested changes), assuming there are no objections.

-Giri

From: Roni Even (A) <roni.even@huawei.com>
Sent: Monday, January 7, 2019 3:31 AM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam <mandyam@qti.qualcomm.com>; draft-ietf-payload-flexible-fec-scheme.all@ietf.org; payload@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: RE: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes


CAUTION: This email originated from outside of the organization.
Hi Magnus,
This also what I thought specially the case of multiple sources.
Roni Even as Individual

From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Monday, January 07, 2019 12:26 PM
To: Giridhar Mandyam; draft-ietf-payload-flexible-fec-scheme.all@ietf.org<mailto:draft-ietf-payload-flexible-fec-scheme.all@ietf.org>; payload@ietf.org<mailto:payload@ietf.org>; Ben Campbell
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Hi,

In regard to the below.

On 2019-01-03 21:50, Giridhar Mandyam wrote:

There are a couple of substantive changes based on AD review (versus version -13) of which the group should be aware:


  1.  Sec. 4.2.1.  Under the description of the SSRC field, the following requirement was previously a SHOULD:  ""The repair streams' SSRC's CNAME MUST be identical to the CNAME of the source RTP stream(s) that this repair stream protects."



There was actually a reason for this SHOULD. That should likely have been written out explicitly. In case of a RTP middlebox adding FEC to one or more streams it forwards towards to a downstream receiver or other middlebox then it can't use the CNAME of the source stream if there are multiple ones from different sources. Secondly, even if it forwards only from one, that SSRC sending the FEC stream probably shouldn't be required to give the impression that it is the source entity doing this. In some cases RTP middleboxes are considering doing this on behalf of the original source, but not always.

Thus, I am opposed to make this change. I rather add an exception statement after the SHOULD.

The repair streams' SSRC's CNAME SHOULD be identical to the CNAME of the source RTP stream(s) that this repair stream protects. An FEC stream that protects multiple source RTP streams with different CNAMEs uses the CNAME associated with entity generating the FEC stream or the CNAME of the entity on whose behalf it perform the protection operation.



Cheers



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>

----------------------------------------------------------------------