Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 11 March 2015 22:01 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F791A87EF for <avt@ietfa.amsl.com>; Wed, 11 Mar 2015 15:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 GiarqQtKCU-s for <avt@ietfa.amsl.com>; Wed, 11 Mar 2015 15:01:31 -0700 (PDT)
Received: from BLU004-OMC3S23.hotmail.com (blu004-omc3s23.hotmail.com [65.55.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D7F1A889F for <avt@ietf.org>; Wed, 11 Mar 2015 15:01:31 -0700 (PDT)
Received: from BLU181-W35 ([65.55.116.72]) by BLU004-OMC3S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 11 Mar 2015 15:01:30 -0700
X-TMN: [xuIbXFh3sJceU5lLtswYFwm2S4CAxz+d]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU181-W353020E36BA50D30F0468F93190@phx.gbl>
Content-Type: multipart/alternative; boundary="_9fa60eb7-62af-49b5-9ce0-6c93439a7b61_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Paul E. Jones" <paulej@packetizer.com>, IETF AVTCore WG <avt@ietf.org>
Date: Wed, 11 Mar 2015 15:01:30 -0700
Importance: Normal
In-Reply-To: <5500473F.1060205@ericsson.com>
References: <em4eb65589-a3ce-4cff-b297-6ae7b038c083@sydney>, <5500473F.1060205@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Mar 2015 22:01:30.0824 (UTC) FILETIME=[EE3DD480:01D05C46]
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/r-0E5gAGqp4wuTR0ieC-TY4nAGE>
Subject: Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 22:01:36 -0000

Magnus said: 
> Well, the switching operation appears to have been implemented in
> several different ways. I see the motivation for the different methods
> applied. Thus, I see an issue with having this work restrict how the
> middlebox work.

[BA] Preventing a MANE/SFU from modifying the SSRC or sequence number field is not a minor restriction - it will break the majority of existing MANE/SFU implementations, and there are no good workarounds. 
AFAIK, the vast majority of existing MANE/SFU implementations modify the SSRC field and implementations supporting SRST modify the sequence number field when dropping an SVC layer.  
Also, SSRC field modification is not just for MANE/SFU implementations that support scalable video coding; there are also simulcast implementations that do this (I believe that the Hangouts SFU is one of them). 
To my mind, a problem this fundamental indicates that there is insufficient understanding of how MANE/SFU implementations operate today.