Re: [rtcweb] H.264 SVC and BUNDLE

Harald Alvestrand <harald@alvestrand.no> Thu, 30 August 2012 20:19 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5361A21F84C2 for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 13:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.367
X-Spam-Level:
X-Spam-Status: No, score=-110.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AoEiFbAixeR for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 13:19:14 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8349C21F8495 for <rtcweb@ietf.org>; Thu, 30 Aug 2012 13:19:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DC3239E2BE for <rtcweb@ietf.org>; Thu, 30 Aug 2012 22:18:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdza4PMjjXWV for <rtcweb@ietf.org>; Thu, 30 Aug 2012 22:18:42 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id EF0A539E170 for <rtcweb@ietf.org>; Thu, 30 Aug 2012 22:18:41 +0200 (CEST)
Message-ID: <503FCAA1.5080500@alvestrand.no>
Date: Thu, 30 Aug 2012 22:18:41 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <503E0B63.3020708@ericsson.com>, <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se> <035101cd8636$3b654160$b22fc420$@com> <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H.264 SVC and BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 20:19:15 -0000

My assumption has always been that if you were operating on a network 
that could only apply diffserv to separate 5-tuples, you would allocate 
the SSRCs comprising a multilayer encoding to different 5-tuples.

If you were operating on a network that preserved DSCP values, or on one 
that did stateful resource reservation based on SSRC values, you would 
be able to use the same 5-tuple, if desirable.

This choice seems to be a choice that the application writer should take 
before deciding whether or not to use BUNDLE, so it's a little hard to 
see what the relationship to BUNDLE is.

One size does not fit all. Sometimes bundling is not what people want to do.

On 08/30/2012 10:07 PM, Ejzak, Richard P (Richard) wrote:
> Dan Wing wrote:
>> The general multiplexing of layers onto the same 5-tuple is a problem,
>> *if* we want the layers to have different DSCP values.  This is because
>> we cannot successfully and reliably set different DSCP values for packets
>> belonging to a 5-tuple over the Internet -- too many things rewrite
>> the DSCP field (to a different value) or simply clear the DSCP field.
>> This makes it impossible to restore the per-packet DSCP values later
>> (e.g., using RSVP, or using any other better/stronger/faster signaling
>> method).  If, however, each 5-tuple has its own DSCP value then that
>> DSCP value could be restored.
> Dan,
> You make a claim that is not necessarily true.  If packets within a 5-tuple have different DSCP values that are then erased by the network, why would it be "impossible" to restore those values later?  Within the context of multiplexing of RTP streams, each RTP stream within a 5-tuple would of necessity need to still use a single DSCP value.  If signaling can be used to inform a node of some means of identifying each RTP stream then the original DSCP markings could be restored.
>
> While I agree that it would be easier to assign the same DSCP value to all packets in a 5-tuple, it would still be "possible" to filter on, for example, the SSRC value used for each stream (in addition to the 5-tuple) to reassign the original DSCP value (or a mapped value with appropriate meaning in the target network) for each stream.
>
> Richard
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb