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

Dzonatas Sol <dzonatas@gmail.com> Wed, 29 June 2011 14:28 UTC

Return-Path: <dzonatas@gmail.com>
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 26A189E800D for <rtcweb@ietfa.amsl.com>; Wed, 29 Jun 2011 07:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.058
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5XfPOoChjFM for <rtcweb@ietfa.amsl.com>; Wed, 29 Jun 2011 07:28:14 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22B4A9E800B for <rtcweb@ietf.org>; Wed, 29 Jun 2011 07:28:14 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1090780pvh.31 for <rtcweb@ietf.org>; Wed, 29 Jun 2011 07:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.68.35.136 with SMTP id h8mr1213381pbj.159.1309357693612; Wed, 29 Jun 2011 07:28:13 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id m7sm930547pbk.86.2011.06.29.07.28.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 07:28:11 -0700 (PDT)
Message-ID: <4E0B3658.1080706@gmail.com>
Date: Wed, 29 Jun 2011 07:27:36 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E0832FE.7010401@ericsson.com> <4E0A2F70.9040305@jdrosen.net> <4E0AD6AD.5050705@ericsson.com>
In-Reply-To: <4E0AD6AD.5050705@ericsson.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Non-media data service consensus and requirements
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: 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. ;)

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant