Re: [rtcweb] Non-media data service consensus and requirements

Dzonatas Sol <> Wed, 29 June 2011 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26A189E800D for <>; Wed, 29 Jun 2011 07:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.058
X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s5XfPOoChjFM for <>; Wed, 29 Jun 2011 07:28:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 22B4A9E800B for <>; Wed, 29 Jun 2011 07:28:14 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1090780pvh.31 for <>; Wed, 29 Jun 2011 07:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=op4X44A+WWOlry3dcygWF1p4qtoZ3/FF7PhZH311uUU=; b=uI4ZYSrUOBi18emHSfDI78k1b0rmgNYGrUHXi6YP+IyfveyeezOs7O3xcW8QBh9hup XWEyJ7Al4dAIb22ISh0Kdk9FiYgxmj0xu9B2GkmEnE1oWyIaJ/uThDbBCkOhsfsbyzZn G5dFzfm8Y0gpS6a6vBvh5wma21qadLR0x90N8=
Received: by with SMTP id h8mr1213381pbj.159.1309357693612; Wed, 29 Jun 2011 07:28:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id m7sm930547pbk.86.2011. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 07:28:11 -0700 (PDT)
Message-ID: <>
Date: Wed, 29 Jun 2011 07:27:36 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Non-media data service consensus and requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2011 14:28:17 -0000

On 06/29/2011 12:39 AM, Magnus Westerlund wrote:
> Hi,
> As an individual.
> On 2011-06-28 21:45, Jonathan Rosenberg wrote:
>> Here are some thoughts on additional use cases:
>> * information on congestion and receiver side environment for purposes
>> of improved sender rate adaptation
> I believe it is important that we have congestion control for the point
> to point flows for both RTP and non-media data that are implemented and
> enforced in the browser. This is a pure security and personal hygien
> question. A rouge application should not be able to consume completely
> unproportional bit-rates between two peers and be able to starve out
> applications sharing the bottleneck.

I would suggest instead of "for purposes of improved sender rate 
adaption" to "for purposes of manifold adaption", yet that may confuse 
people that relate usage outside such interface topology.

> Having said that there can clearly be need for application level signals
> for changing behavior and adopting to what bit-rate or delay
> characteristics that are available. Especially if you have star or other
> multi-hop topologies in the application interconnections. For RTP we
> already propose some such signals like TMMBR [RFC5104] in our RTP for
> RTCWEB document.

I couldn't find the link off-hand, yet there exists successful non-stop 
busy intersection simulations. The downfall with those simulations 
happens when they assume every vehicle is signal aware. Such simulations 
do not include trains or multi-trailers. This relates, however, in 
multi-hop when viewed from intersection to intersection. One may want to 
demand multi-hop to relieve traffic congestion, which may involve 
disconnection from star-topologies. What star-topologies want is how to 
keep-alive the physical tether (simulated or not) through such temporal 
disconnection. Each star-topology has one centralized physical tether no 
matter how they divide the coverage (cellular). Besides credit systems 
for that temporary digital-divide (gap), the best use-case I have seen 
for such physical tether is games that require centralized physic 
simulation to avoid cheaters (or train wrecks). The law of conservation 
is the alternative for less-than-best credit conversion (since the size 
of each bit is unknown to the observer) while disconnected. ;)

--- ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant