Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 01 April 2015 10:43 UTC

Return-Path: <magnus.westerlund@ericsson.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 789521A0049 for <avt@ietfa.amsl.com>; Wed, 1 Apr 2015 03:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 LSKK1G68yZVm for <avt@ietfa.amsl.com>; Wed, 1 Apr 2015 03:43:17 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A201A0032 for <avt@ietf.org>; Wed, 1 Apr 2015 03:43:16 -0700 (PDT)
X-AuditID: c1b4fb2d-f79a46d0000006b4-dd-551bcbc2c939
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.12.01716.2CBCB155; Wed, 1 Apr 2015 12:43:15 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Wed, 1 Apr 2015 12:43:14 +0200
Message-ID: <551BCBC0.9070901@ericsson.com>
Date: Wed, 1 Apr 2015 12:43:12 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>, "avt@ietf.org" <avt@ietf.org>
References: <55193001.9070009@ericsson.com> <55193770.3000102@ericsson.com>, <551A5EEB.3080200@ericsson.com> <BLU181-W9331685ED48AAC16F9AE4093F40@phx.gbl>
In-Reply-To: <BLU181-W9331685ED48AAC16F9AE4093F40@phx.gbl>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje7h09KhBn+7eSxe9qxkt9i/5DKz A5PH454zbB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYcewHY0G7asWD17OYGxinynUxcnJICJhI zPy8kB3CFpO4cG89WxcjF4eQwFFGiXs3f7NCOMsYJdY0T2UBqeIV0JY4vf8jK4jNIqAi8afv ECOIzSZgIXHzRyMbiC0qECzxs303E0S9oMTJmU/AekUEfCRe75nADGILC3hKbLl6GmrbTEaJ 2+8PgzVwClhJPJ/4DKyIWcBA4siiOawQtrxE89bZYHEhoCMamjpYJzAKzEKyYxaSlllIWhYw Mq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzNg1t+6+5gXP3a8RCjAAejEg9vQqd0qBBr YllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGI3n70zJ2bN+fXZo YFh2sPcDnTO+2Tz9BgHbpn7sPqeTM3WWWsm0P1o/z/3jf+798vzRI54hij/sZjY2XPT+UN57 NCuDc8HVz984smLe61yRvReUzqC45b3iwa+vSgpul/RsZ9Se7jnvTO45ldeTFPoYy40W5bw8 vm+ugXUUm2/qVqW2a3Jr1JVYijMSDbWYi4oTAXcww4cuAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/3YXTpY0jGE0YT2jIBC5xfGxtxrw>
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 <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, 01 Apr 2015 10:43:19 -0000

Hi Bernard,

On 2015-03-31 18:42, Bernard Aboba wrote:
> The problem is that devices using the term  selective forwarding
> middlebox or Selective Forwarding Unit (SFU) can operate in more than
> one topology.  
> 
> For example, instead of allowing SSRCs present in the session to be
> visible, some SFUs allocate their own SSRCs and thus operate more like a
> mixer. 

Yes but let us look at the respective behaviours, the first acting as a
RTP mixer that switches streams, thus selecting which of the incoming
streams are forwarded in a particular outgoing stream. The other end of
the spectrum is to project all incoming streams into each outgoing leg.
The later is what I intended to be covered by SFM description. If the
SSRC values are translated or not is less important.

> 
> Also, a selective forwarding middlebox is not necessarily required to
> have a large number of decoder instances (although many do).  As an
> example, an SFU utilizing the "frame marking" extension discussed in
> AVTEXT at IETF 92 would presumably not require decoder instances for any
> codec, and in the case of private media, would be able to decode the
> payload since the keys would not be available. 

I agree that the SFM likely has zero decoders, the point about decoders
is however present at the receiving endpoint. There are an issue in this
that a SFM need to know the number of simultaneous decoder the endpoint
has.

> 
> Also, it is possible for a device to act as both an SFU and switching
> mixer, so these are not orthogonal dimensions. 

Yes, I agree some outgoing SSRCs may be switched, while other are
forwarded. But, that would fall under the composite topologies. This one
actually being a really good example of such one.

What I don't get out of this discussion is if anything actually need to
change in the document.

Cheers

Magnus

> 
> 
> 
>> Date: Tue, 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
>>
>> WG,
>>
>> 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
> feedback.
>>
>> 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,
>> as the streams it provides are not basically translated version, 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.
>>
>> The differences between selective forwarding middlebox and a
>> switching mixer (Section 3.6.2) are minor, and they share most
>> properties. The above requirement on having a large number of
>> decoding instances or requiring efficient switching of decoder
>> contexts, are one point of difference. The other is how the
>> identification is performed, 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, and instead uses other mechanisms to
>> indicate the streams intended usage, if needed.
>>
>> I intended to submit an updated draft on Thursday if no objections are
> made.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB | Phone +46 10 7148287
>> Färögatan 6 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------