Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt

Arno Bakker <arno@cs.vu.nl> Mon, 16 July 2012 07:22 UTC

Return-Path: <a.bakker@vu.nl>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862A321F8549 for <ppsp@ietfa.amsl.com>; Mon, 16 Jul 2012 00:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x80fw2jP+kQS for <ppsp@ietfa.amsl.com>; Mon, 16 Jul 2012 00:22:32 -0700 (PDT)
Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5441821F8551 for <ppsp@ietf.org>; Mon, 16 Jul 2012 00:22:32 -0700 (PDT)
Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 16 Jul 2012 09:23:13 +0200
Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 16 Jul 2012 09:23:14 +0200
Message-ID: <5003C171.1050606@cs.vu.nl>
Date: Mon, 16 Jul 2012 09:23:29 +0200
From: Arno Bakker <arno@cs.vu.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: zhangyunfei <zhangyunfei@chinamobile.com>
References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl>, <4FFDACBF.3080908@mti-systems.com> <2012071614111568687511@chinamobile.com>
In-Reply-To: <2012071614111568687511@chinamobile.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [130.37.238.20]
Cc: ppsp <ppsp@ietf.org>
Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: arno@cs.vu.nl
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 07:22:33 -0000

On 16/07/2012 08:11, zhangyunfei wrote:
> Same impression as Wes. To the best of my knowledge, LEDBAT is designed 
> to be for "lower priority" apps, who is mainly running on top of TCP (at 
> least UDP and TCP are co-functioning and can switch each other). It 
> seems ppsp apps are neither"lower priority"apps when competing with 
> other traffics nor requiring both UDP and TCP running and switching.
> So a UDP+cc(needn't considering the TCP effect) solutions seems appropriate.
> 

Hi

I think LEDBAT is useful for seeding (VOD) peers. Once they have
downloaded the content they should ideally contribute back to the P2P
network, but without causing disturbance for their user.

It can also be useful in networks which currently have overcapacity. In
that case, downloading at higher than the bitrate is effective use of
resources (a megabit/s not used is a megabit/s lost), but the
faster-than-required download should not infere with other activities of
the user. I.e. LEDBAT should limit it when required, whilst not dropping
the speed below approx. bitrate.

Riccardo knows more about this, so perhap he can comment.

CU,
    Arno