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
- Re: [rtcweb] Non-media data service consensus and… Jonathan Rosenberg
- [rtcweb] Non-media data service consensus and req… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Bernard Aboba
- Re: [rtcweb] Non-media data service consensus and… Matthew Kaufman
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Emil Ivov
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Igor Faynberg
- Re: [rtcweb] Non-media data service consensus and… Timothy B. Terriberry
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- Re: [rtcweb] Non-media data service consensus and… Magnus Westerlund
- Re: [rtcweb] Non-media data service consensus and… Manuel Simoni
- Re: [rtcweb] Non-media data service consensus and… Dzonatas Sol
- Re: [rtcweb] Non-media data service consensus and… Christopher Blizzard
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Cullen Jennings
- Re: [rtcweb] Non-media data service consensus and… Randell Jesup
- [rtcweb] Consensus Call on Non-media data service… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- Re: [rtcweb] Consensus Call on Non-media data ser… Magnus Westerlund
- Re: [rtcweb] Consensus Call on Non-media data ser… Dzonatas Sol
- [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Silvia Pfeiffer
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Ted Hardie
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Tim Panton
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Matthew Kaufman
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Magnus Westerlund
- Re: [rtcweb] realiable data service Henry Sinnreich
- Re: [rtcweb] realiable data service Justin Uberti
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Emil Ivov
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Dzonatas Sol
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Cullen Jennings
- Re: [rtcweb] realiable data service Stefan Håkansson LK
- Re: [rtcweb] realiable data service Emil Ivov
- [rtcweb] PseudoTCP implementation (Re: realiable … Harald Alvestrand
- Re: [rtcweb] realiable data service Randell Jesup
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Serge Lachapelle
- Re: [rtcweb] realiable data service Bernard Aboba
- Re: [rtcweb] realiable data service Peter Saint-Andre
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Tim Panton
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Emil Ivov
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Cullen Jennings
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Harald Alvestrand
- Re: [rtcweb] PseudoTCP implementation (Re: realia… Justin Uberti