IETF Logo Mail Archive

Re: [avtext] draft-ietf-avtext-framemarking and FEC

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Thu, 09 March 2017 19:06 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10BE12945A; Thu, 9 Mar 2017 11:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9FPB0YAF0hZC; Thu, 9 Mar 2017 11:06:09 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997CD129452; Thu, 9 Mar 2017 11:06:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5347; q=dns/txt; s=iport; t=1489086369; x=1490295969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pr8hvkNYc3zHiUszYJEV8zS5npFQV6B0R9q3kIWwZ2A=; b=lyZpejkLY1F/GxdtFXIp7yiVlcgGe4vTitQjXKMkHhXMFs7+hesmAOxG vDBMiGfqynZs80BHLI1htlgPUvNR+8bS2e0SzwANlly0AhgfzJ+VDKQyr X1d9i473d9NhS+kEKJ7/hrP/daVoQNGZBaTL9EOjCQrz8XCvrbMJ9jBvl s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CGAQC9psFY/4MNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgm5jgWsHg1mKDJFPhiOBaod+hS2CDoYiAoIxPxgBAgEBAQEBAQFrKIUVAQEBAQMEHARVEAIBCAQNAwECKAQDIQkIFAkIAgQBDQWJaAMVsRIMgiWHNg2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRvglGCI4Jngl4Fm386AY4MhCuBe48liESCEIhqAR84gQNWFYcTdYkegQ0BAQE
X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208,217";a="395679676"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2017 19:06:08 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29J68BQ018189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 19:06:08 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 13:06:08 -0600
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 13:06:08 -0600
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, Emil Ivov <eivov@atlassian.com>, Boris Grozev <bgrozev@atlassian.com>
Thread-Topic: [avtext] draft-ietf-avtext-framemarking and FEC
Thread-Index: AQHSmQg1frQLKhEX+0Sxuj+szvmizA==
Date: Thu, 09 Mar 2017 19:06:07 +0000
Message-ID: <D4E70BF4.6AB64%mzanaty@cisco.com>
References: <CAOW+2dsGd1mO5YVdRKhMGH7Vg+gPw15JDmFB8y+jscYq4Y0h+w@mail.gmail.com>
In-Reply-To: <CAOW+2dsGd1mO5YVdRKhMGH7Vg+gPw15JDmFB8y+jscYq4Y0h+w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.238.74]
Content-Type: multipart/alternative; boundary="_000_D4E70BF46AB64mzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/f_XLmQ6LX4Lczd1vsKbFrdnH0dw>
Cc: "avtext@ietf.org" <avtext@ietf.org>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [avtext] draft-ietf-avtext-framemarking and FEC
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avtext/>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Mar 2017 19:06:10 -0000

Hi Bernard,

Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH but don't think this has been discussed. Adding Emil and Boris as they plan to submit/present a PERC draft related to this (RTX).

Frame marking was intended for Source RTP Streams not Redundancy RTP Streams [RFC 7656]. I will update the draft to reflect this. If E2E encrypted redundancy streams need some type of marking, I would recommend a separate marking mechanism rather than overloading or extending the current video frame marking draft.

Thanks,
Mo

From: avtext <avtext-bounces@ietf.org<mailto:avtext-bounces@ietf.org>> on behalf of Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>>
Date: Wednesday, March 1, 2017 at 3:10 PM
To: "avtext@ietf.org<mailto:avtext@ietf.org>" <avtext@ietf.org<mailto:avtext@ietf.org>>
Subject: [avtext] draft-ietf-avtext-framemarking and FEC

So far, discussion on framemarking has focused on conveying information about video frames useful to an SFU.

In video forwarding scenarios, forward error correction can be used to protect one or more layers.

Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not end-to-end.  For example, FEC is consumed and re-generated by the SFU which receives video frames and repairs via the received FEC if it can.The SFU decides which video frames to forward (such as by using info in the frame marking header), and will regenerate an FEC stream corresponding to the forwarded stream.

My question is whether hop-by-hop robustness is expected to continue with PERC so that the payloads of FEC packets would be available to the SFU, or whether FEC payload would also be encrypted so that FEC would be end-to-end.

If FEC becomes end-to-end, do those packets also need to be marked?

v2.23.0 | Report a Bug | By Email