IETF Logo Mail Archive

Re: [p2pi] Follow-Up from Comcast Presentation

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Sat, 07 June 2008 19:23 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C1A3A6B9A; Sat, 7 Jun 2008 12:23:32 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E651A3A6B9A for <p2pi@core3.amsl.com>; Sat, 7 Jun 2008 12:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.369
X-Spam-Level:
X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGht7Ww3DxVd for <p2pi@core3.amsl.com>; Sat, 7 Jun 2008 12:23:29 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 8F6EB3A6B33 for <p2pi@ietf.org>; Sat, 7 Jun 2008 12:23:29 -0700 (PDT)
Received: from [IPv6:::1] (fruitcake [192.150.186.11]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id m57JNepf026232; Sat, 7 Jun 2008 12:23:40 -0700 (PDT)
Message-Id: <1B22E2BD-9910-477D-AF13-AC6F1B5FAD43@icsi.berkeley.edu>
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
To: John Leslie <john@jlc.net>
In-Reply-To: <20080607191509.GL8579@verdi>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Sat, 07 Jun 2008 12:23:39 -0700
References: <45AEC6EF95942140888406588E1A6602045CBA5E@PACDCEXCMB04.cable.comcast.com> <3efc39a60806061909n11a65eafnce88df7c73c30639@mail.gmail.com> <4CB75CEA-FE7E-4398-A1B3-A03DBF5063D3@icsi.berkeley.edu> <3efc39a60806070852p49f6a066y27e804fd5d4cf989@mail.gmail.com> <20080607173925.GJ8579@verdi> <484AC9EB.8060501@isi.edu> <20080607175712.GK8579@verdi> <484ACEEC.9070705@joelhalpern.com> <20080607191509.GL8579@verdi>
X-Mailer: Apple Mail (2.924)
Cc: p2pi@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [p2pi] Follow-Up from Comcast Presentation
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

There is always just "friendlier than TCP-Reno under reasonable ranges  
of latency and bandwidth" as a definition, so conventional TCP flows  
will outcompete the "scavenger" service.

Of which there are plenty of examples, including TCP-vegas, of stable  
congestion control algorithms which have this property.

So the question is not "How do you do this?" but "Why is this not  
done?".

I believe that the Linux stack, for example, allows you to switch the  
behavior of newly-created flows from Vegas to Reno with a /proc update.

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

v2.23.0 | Report a Bug | By Email