Return-Path: 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 831901A0140 for ; Tue, 31 Mar 2015 09:42:26 -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 d4P6tLAxC1Yf for ; Tue, 31 Mar 2015 09:42:24 -0700 (PDT) Received: from BLU004-OMC3S16.hotmail.com (blu004-omc3s16.hotmail.com [65.55.116.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9F31A00B0 for ; Tue, 31 Mar 2015 09:42:23 -0700 (PDT) Received: from BLU181-W93 ([65.55.116.72]) by BLU004-OMC3S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 09:42:22 -0700 X-TMN: [7F7rDaGv3zWDXIXFmtVLpu59m6+QrxTU] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bafd61e0-7f95-486f-a675-6a39bc0ed2dc_" From: Bernard Aboba To: Magnus Westerlund , "avt@ietf.org" Date: Tue, 31 Mar 2015 09:42:21 -0700 Importance: Normal In-Reply-To: <551A5EEB.3080200@ericsson.com> References: <55193001.9070009@ericsson.com> <55193770.3000102@ericsson.com>,<551A5EEB.3080200@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2015 16:42:22.0924 (UTC) FILETIME=[A97728C0:01D06BD1] Archived-At: Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:42:26 -0000 --_bafd61e0-7f95-486f-a675-6a39bc0ed2dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that devices using the term selective forwarding middlebox = or Selective Forwarding Unit (SFU) can operate in more than one topology. = =20 For example=2C instead of allowing SSRCs present in the session to be visib= le=2C some SFUs allocate their own SSRCs and thus operate more like a mixer= .=20 Also=2C a selective forwarding middlebox is not necessarily required to hav= e a large number of decoder instances (although many do). As an example=2C= an SFU utilizing the "frame marking" extension discussed in AVTEXT at IETF= 92 would presumably not require decoder instances for any codec=2C and in = the case of private media=2C would be able to decode the payload since the = keys would not be available.=20 Also=2C it is possible for a device to act as both an SFU and switching mix= er=2C so these are not orthogonal dimensions.=20 > Date: Tue=2C 31 Mar 2015 10:46:35 +0200 > From: magnus.westerlund@ericsson.com > To: avt@ietf.org > Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox >=20 > WG=2C >=20 > Here is an update of the last two paragraphs taking care of some nits > and a rewording of the very last sentence. Thanks for Dan Wing for feedba= ck. >=20 > Note that this topology could potentially be seen as a media > translator which include an on/off logic as part of its media > translation. The topology has the property that all SSRCs present in > the session are visible to an endpoint. It also has mixer aspects=2C > as the streams it provides are not basically translated version=2C but > instead they have conceptual property assigned to them and can be > both turned on/off as well as being fully or partially delivered. > Thus this topology appears to be some hybrid between the translator > and mixer model. >=20 > The differences between selective forwarding middlebox and a > switching mixer (Section 3.6.2) are minor=2C and they share most > properties. The above requirement on having a large number of > decoding instances or requiring efficient switching of decoder > contexts=2C are one point of difference. The other is how the > identification is performed=2C where the Mixer uses CSRC to provide > information on what is included in a particular RTP stream that > represent a particular concept. Selective forwarding gets the source > information through the SSRC=2C and instead uses other mechanisms to > indicate the streams intended usage=2C if needed. >=20 > I intended to submit an updated draft on Thursday if no objections are ma= de. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services=2C Media and Network features=2C Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm=2C Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt = --_bafd61e0-7f95-486f-a675-6a39bc0ed2dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The problem is that devices usin= g the term  =3Bselective forwarding middlebox or Selective Forwarding U= nit (SFU) can operate in more than one topology.  =3B

For example=2C instead of allowing SSRCs present in the session to be vis= ible=2C some SFUs allocate their own SSRCs and thus operate more like a mix= er. =3B

Also=2C a selective forwarding middleb= ox is not necessarily required to have a large number of decoder instances = (although many do).  =3BAs an example=2C an SFU utilizing the "frame ma= rking" extension discussed in AVTEXT at IETF 92 would presumably not requir= e decoder instances for any codec=2C and in the case of private media=2C wo= uld be able to decode the payload since the keys would not be available.&nb= sp=3B

Also=2C it is possible for a device to act a= s both an SFU and switching mixer=2C so these are not orthogonal dimensions= . =3B



>=3B Date: Tue= =2C 31 Mar 2015 10:46:35 +0200
>=3B From: magnus.westerlund@ericsson.c= om
>=3B To: avt@ietf.org
>=3B Subject: Re: [AVTCORE] Slight rewor= ding on Selective Forwarding Middlebox
>=3B
>=3B WG=2C
>=3B=
>=3B Here is an update of the last two paragraphs taking care of som= e nits
>=3B and a rewording of the very last sentence. Thanks for Dan = Wing for feedback.
>=3B
>=3B Note that this topology could po= tentially be seen as a media
>=3B translator which include an on/of= f logic as part of its media
>=3B translation. The topology has th= e property that all SSRCs present in
>=3B the session are visible t= o an endpoint. It also has mixer aspects=2C
>=3B as the streams it= provides are not basically translated version=2C but
>=3B instead = they have conceptual property assigned to them and can be
>=3B both= turned on/off as well as being fully or partially delivered.
>=3B = Thus this topology appears to be some hybrid between the translator
>= =3B and mixer model.
>=3B
>=3B The differences between sel= ective forwarding middlebox and a
>=3B switching mixer (Section 3.6= .2) are minor=2C and they share most
>=3B properties. The above re= quirement on having a large number of
>=3B decoding instances or re= quiring efficient switching of decoder
>=3B contexts=2C are one poi= nt of difference. The other is how the
>=3B identification is perf= ormed=2C where the Mixer uses CSRC to provide
>=3B information on w= hat is included in a particular RTP stream that
>=3B represent a pa= rticular concept. Selective forwarding gets the source
>=3B inform= ation through the SSRC=2C and instead uses other mechanisms to
>=3B = indicate the streams intended usage=2C if needed.
>=3B
>=3B I i= ntended to submit an updated draft on Thursday if no objections are made.>=3B
>=3B Cheers
>=3B
>=3B Magnus Westerlund
>=3B=
>=3B ---------------------------------------------------------------= -------
>=3B Services=2C Media and Network features=2C Ericsson Resear= ch EAB/TXM
>=3B ------------------------------------------------------= ----------------
>=3B Ericsson AB | Phone +46 10 7148= 287
>=3B F=E4r=F6gatan 6 | Mobile +46 73 0949079
&g= t=3B SE-164 80 Stockholm=2C Sweden | mailto: magnus.westerlund@ericsson.com=
>=3B ----------------------------------------------------------------= ------
>=3B
>=3B _______________________________________________=
>=3B Audio/Video Transport Core Maintenance
>=3B avt@ietf.org>=3B https://www.ietf.org/mailman/listinfo/avt
= = --_bafd61e0-7f95-486f-a675-6a39bc0ed2dc_--