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

Bernard Aboba <bernard.aboba@gmail.com> Wed, 01 March 2017 20:10 UTC

Return-Path: <bernard.aboba@gmail.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 6679C1296C1 for <avtext@ietfa.amsl.com>; Wed, 1 Mar 2017 12:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 PmBqqE3pXv-5 for <avtext@ietfa.amsl.com>; Wed, 1 Mar 2017 12:10:56 -0800 (PST)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 AA1271296E3 for <avtext@ietf.org>; Wed, 1 Mar 2017 12:10:53 -0800 (PST)
Received: by mail-ua0-x236.google.com with SMTP id q7so20904301uaf.2 for <avtext@ietf.org>; Wed, 01 Mar 2017 12:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uZis2famrRSnGbI0bdDOUlpZyGw/TXpM2/T+860ITI4=; b=qg2nmQX51EfBIRzRJH4MAKkFrvAuFPSxeojuICGCIb8D+XcifaQjZvAeVbElluSqJ1 CJAQoTz+Qw7YMnqkTXWfRA8insmgJr7xesQoFtPfaHSKaRNL5tBa4OfhB8zmwNGk80If B4l3LPN0Wbm0ccr0AwCvVBDhkZSOB98S+TJr750YJX4T8+4iTS5vzAqdzDTrjT40aOcf h+khIPxG7ZWbydEiSPYG0T+XAfHQI3aV8dLUA9BzSqhwATYgu/kcPZYZIPYjvwAb4nkl pjo1kWvUW2I2NisIpxQmMf8H9R10DjGyfoXS8J1QMc13gDrNr34+z9cPA3MCosl+lGHA j1nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uZis2famrRSnGbI0bdDOUlpZyGw/TXpM2/T+860ITI4=; b=LUo2nluZ69XhB/NTjsOflU+IHAm9XAeEYlM478Tcwhv+DuejlBiDaU1m8WavZ8jCxE /jmTY9jZ0UWgb0Zbf92yJzjBiHgXIQ9+nAP5EkQrkIy+nDa5TSrnLuG7iYtkFa10joWC LyKa4V1eHv9ZeAMtjUbY5V+5cROI/cQKWGMNoWeqQ2n0FmHiXr5edjcE+E9oYyoDjhHr +Raxn2r0cpalrEbJegX6U01PKiPv5RwG22y6BaDnhTSGt3g3UBW+rzRTojIJvfFIw5tF 3dwVgnWPFzGpS4HYrWsarbfAZedacjd5PNMs4i9FhsXu2njLQAsqABAWdwNv4dnzLpK7 X7JQ==
X-Gm-Message-State: AMke39notWz4sBgWpP3ZF/Cd559aryBGq3KdD0PTF2Gdupg0BBPG0RWnWOBIrbSXgInPwfoyZG4asNsCtOg/XA==
X-Received: by 10.159.36.10 with SMTP id 10mr5290236uaq.124.1488399051986; Wed, 01 Mar 2017 12:10:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Wed, 1 Mar 2017 12:10:31 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 01 Mar 2017 12:10:31 -0800
Message-ID: <CAOW+2dsGd1mO5YVdRKhMGH7Vg+gPw15JDmFB8y+jscYq4Y0h+w@mail.gmail.com>
To: avtext@ietf.org
Content-Type: multipart/alternative; boundary="001a113df684c721660549b0e893"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/TENBAZHiEnYAKjEQkckcntmC7JY>
Subject: [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: Wed, 01 Mar 2017 20:10:59 -0000

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?