Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox
"David Benham (dbenham)" <dbenham@cisco.com> Tue, 31 March 2015 23:34 UTC
Return-Path: <dbenham@cisco.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 C66441A1BCF for <avt@ietfa.amsl.com>; Tue, 31 Mar 2015 16:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3zSFccNf-5_K for <avt@ietfa.amsl.com>; Tue, 31 Mar 2015 16:34:22 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A0F1A1BC3 for <avt@ietf.org>; Tue, 31 Mar 2015 16:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14054; q=dns/txt; s=iport; t=1427844861; x=1429054461; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9YMe00npKew/A+4pXAw2qvCCCpt99TGtrljFhFhVpRY=; b=aRJc2cmUUXu4xErNrsyx7i0KnaoEdc79xw91fqP4CiWsA9RP1To5dkDS dpaaFJdf+2UJNsjLBK/oX5qgDAgZE4PKOPwUly+L8wNhcjq6FaLJrGibU OZ3w8ZMz0jPDjGcrovYX+/AqPWDq42I4okLsKFiozxtYMlggbyfN1a/ti Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AUBQC/LhtV/5JdJa1TCYMGUlwFxXcKhXMCgThMAQEBAQEBfYQUAQEBAwEBAQELGRMrAxYJBAEIEQMBAgsUCSIMCxQJCQEEARIIiB8IDc4YAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEiyWEHQMlAj6DEYEWBYYdikWLEoMyiHSGeCKDbm+BAiQefwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="408571946"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 31 Mar 2015 23:34:02 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2VNY2vH030833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 23:34:02 GMT
Received: from xmb-aln-x10.cisco.com ([169.254.5.207]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 18:34:02 -0500
From: "David Benham (dbenham)" <dbenham@cisco.com>
To: "avt@ietf.org" <avt@ietf.org>, "magnus.westerlund@ericsson.com" <magnus.westerlund@ericsson.com>
Thread-Topic: [AVTCORE] Slight rewording on Selective Forwarding Middlebox
Thread-Index: AdBsCxy+Fre/zLymRlO5R+yaMGsSiA==
Date: Tue, 31 Mar 2015 23:34:01 +0000
Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC56B95112F@xmb-aln-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.35.132.26]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/OX9AliYWIae0dZdQQSmbbvIiGoU>
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: Tue, 31 Mar 2015 23:34:24 -0000
Magnus Thanks for taking on the SFM section wording changes so quickly! Looks good and strikes an appropriate balance between clarifying the SSRC projection options and minimizing the text's changes given it is so near closing the last call. David Benham dbenham@cisco.com Director, Media & Standards Office of CTO, Collaboration Technology Group Cisco Systems ======================================================== Date: Tue, 31 Mar 2015 10:46:35 +0200 From: Magnus Westerlund <magnus.westerlund@ericsson.com> To: <avt@ietf.org> Subject: Re: [AVTCORE] Slight rewording on Selective Forwarding Middlebox Message-ID: <551A5EEB.3080200@ericsson.com> Content-Type: text/plain; charset="windows-1252" 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 ---------------------------------------------------------------------- > Date: Mon, 30 Mar 2015 13:14:09 +0200 > From: Magnus Westerlund <magnus.westerlund@ericsson.com> > To: IETF AVTCore WG <avt@ietf.org> > Subject: [AVTCORE] Slight rewording on Selective Forwarding Middlebox > Message-ID: <55193001.9070009@ericsson.com> > Content-Type: text/plain; charset="utf-8" > > WG, > > Based on last weeks discussion with David Benham, I have attempted to > write the SFM section more neutral in regards to if one must have > independent SSRC spaces or not. Please review if you think this is > better or if you have further suggestion on changes needed. > > Cheers > > Magnus > > > 3.7. Selective Forwarding Middlebox > > Another method for handling media in the RTP mixer is to "project", > or make available, all potential RTP sources (SSRCs) into a per- > endpoint, independent RTP session. The middlebox can select which of > the potential sources that are currently actively transmitting media > will be sent to each of the endpoints. This is similar to the media > switching Mixer but has some important differences in RTP details. > > > +-A---------+ +-Middlebox-----------------+ > | +-RTP1----| |-RTP1------+ +-----+ | > | | +-Video-| |-Video---+ | | | | > | | | AV1|------------>|---------+-+------>| | | > | | | |<------------|BV1 <----+-+-------| S | | > | | | |<------------|CV1 <----+-+-------| W | | > | | | |<------------|DV1 <----+-+-------| I | | > | | | |<------------|EV1 <----+-+-------| T | | > | | | |<------------|FV1 <----+-+-------| C | | > | | +-------| |---------+ | | H | | > | +---------| |-----------+ | | | > +-----------+ | | M | | > | | A | | > +-B---------+ | | T | | > | +-RTP2----| |-RTP2------+ | R | | > | | +-Video-| |-Video---+ | | I | | > | | | BV1|------------>|---------+-+------>| X | | > | | | |<------------|AV1 <----+-+-------| | | > | | | |<------------|CV1 <----+-+-------| | | > | | | | : : : |: : : : : : : : :| | | > | | | |<------------|FV1 <----+-+-------| | | > | | +-------| |---------+ | | | | > | +---------| |-----------+ | | | > +-----------+ | | | | > : : : : > : : : : > +-F---------+ | | | | > | +-RTP6----| |-RTP6------+ | | | > | | +-Video-| |-Video---+ | | | | > | | | FV1|------------>|---------+-+------>| | | > | | | |<------------|AV1 <----+-+-------| | | > | | | | : : : |: : : : : : : : :| | | > | | | |<------------|EV1 <----+-+-------| | | > | | +-------| |---------+ | | | | > | +---------| |-----------+ +-----+ | > +-----------+ +---------------------------+ > > Figure 17: Selective Forwarding Middlebox > > In the six endpoint conference depicted above in (Figure 17) one can > see that endpoint A is aware of five incoming SSRCs, BV1-FV1. If > this middlebox intends to have a similar behavior as in Section 3.6.2 > where the mixer provides the endpoints with the two latest speaking > endpoints, then only two out of these five SSRCs need concurrently > transmit media to A. As the middlebox selects the source in the > different RTP sessions that transmit media to the endpoints, each RTP > stream requires rewriting of certain RTP header fields when being > projected from one session into another. In particular, the sequence > number needs to be consecutively incremented based on the packet > actually being transmitted in each RTP session. Therefore, the RTP > sequence number offset will change each time a source is turned on in > a RTP session. The timestamp (possibly offset) stays the same. > > The RTP sessions can be considered independent, the SSRC numbers used > can also be handled independently, thereby bypassing the requirement > for SSRC collision detection and avoidance. This will require tools > such as remapping tables between the RTP sessions.However, using > independent RTP sessions are not required, the switching behavior is > possible to perform also with a common SSRC space. However, in this > case collision detection and handling becomes a different problem. > Therefore, it is up to the implementation to use a single common SSRC > space or separate ones. > > Using separate SSRC spaces have some implications. For example, the > RTP stream that is being sent by endpoint B to the middlebox (BV1) > may use an SSRC value of 12345678. When that RTP stream is sent to > endpoint F by the middlebox, it can use any SSRC value, e.g. > 87654321. As a result, each endpoint may have a different view of > the application usage of a particular SSRC. Any RTP level identity > information, such as SDES items also needs to update the SSRC > referenced, if the included SDES items are intended to be global. > Thus the application must not use SSRC as references to RTP streams > when communicating with other peers directly. This also affects loop > detection which will fail to work, as there is no common namespace > and identities across the different legs in the communication session > on RTP level. Instead this responsibility falls onto higher layers. > > The middlebox is also responsible to receive any RTCP codec control > requests coming from an endpoint, and decide if it can act on the > request locally or needs to translate the request into the RTP > session/transport leg that contains the media source. Both endpoints > and the middlebox need to implement conference related codec control > functionalities to provide a good experience. Commonly used are Full > Intra Request to request from the media source to provide switching > points between the sources, and Temporary Maximum Media Bit-rate > Request (TMMBR) to enable the middlebox to aggregate congestion > control responses towards the media source so to enable it to adjust > its bit-rate (obviously only in case the limitation is not in the > source to middlebox link). > > The selective forwarding middlebox has been introduced in recently > developed videoconferencing systems in conjunction with, and to > capitalize on, scalable video coding as well as simulcasting. An > example of scalable video coding is Annex G of H.264, but other > codecs, including H.264 AVC and VP8 also exhibit scalability, albeit > only in the temporal dimension. In both scalable coding and > simulcast cases the video signal is represented by a set of two or > more bitstreams, providing a corresponding number of distinct > fidelity points. The middlebox selects which parts of a scalable > bitstream (or which bitstream, in the case of simulcasting) to > forward to each of the receiving endpoints. The decision may be > driven by a number of factors, such as available bit rate, desired > layout, etc. Contrary to transcoding MCUs, these "Selective > Forwarding Units" (SFUs) have extremely low delay, and provide > features that are typically associated with high-end systems > (personalized layout, error localization) without any signal > processing at the middlebox. They are also capable of scaling to a > large number of concurrent users, and--due to their very low delay-- > can also be cascaded. > > This version of the middlebox also puts different requirements on the > endpoint when it comes to decoder instances and handling of the RTP > streams providing media. As each projected SSRC can, at any time, > provide media, the endpoint either needs to be able to handle as many > decoder instances as the middlebox received, or have efficient > switching of decoder contexts in a more limited set of actual decoder > instances to cope with the switches. The application also gets more > responsibility to update how the media provided is to be presented to > the user. > > 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 is 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 have to use other mechanism > to make clear the streams current purpose. > > > > -- > > 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 > ---------------------------------------------------------------------- > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > > ------------------------------ > > End of avt Digest, Vol 131, Issue 30 > ************************************
- [AVTCORE] Slight rewording on Selective Forwardin… Magnus Westerlund
- Re: [AVTCORE] Slight rewording on Selective Forwa… Magnus Westerlund
- Re: [AVTCORE] Slight rewording on Selective Forwa… Magnus Westerlund
- Re: [AVTCORE] Slight rewording on Selective Forwa… Bernard Aboba
- Re: [AVTCORE] Slight rewording on Selective Forwa… Roni Even
- Re: [AVTCORE] Slight rewording on Selective Forwa… David Benham (dbenham)
- Re: [AVTCORE] Slight rewording on Selective Forwa… Magnus Westerlund
- Re: [AVTCORE] Slight rewording on Selective Forwa… Magnus Westerlund