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

Riccardo Petrocco <> Mon, 16 July 2012 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4070921F8858 for <>; Mon, 16 Jul 2012 06:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cWaJYNFebciB for <>; Mon, 16 Jul 2012 06:47:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 807C521F8855 for <>; Mon, 16 Jul 2012 06:47:53 -0700 (PDT)
Received: by yhq56 with SMTP id 56so5662657yhq.31 for <>; Mon, 16 Jul 2012 06:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EEzOBhRrm39wf/rOy+ZmUGPKFSXq3AKka2mIC+Zdn6o=; b=ZIV8Jzmw2ZnL4X91UsJvEMkZhPAdkHYpD4/Wz4Eckz5BwsGDQB5hsp8mSYHUP3A4ON DkqNuBStbv9DlJDT8fXVry+CEPNJMVmqK9P9QbDSRlTwrUzD6LeevUL0haMVymdwvp6+ Sb6pCXcLDqSIF+ZvqJ0HCqY/Ez6MMd6cjyIHkxeoNb1Qa8WtfSzXxFwy3UJDaGNwvjpf jCaQzUW6DTiVgLPUsBZvxp62wpRLVvDQLa1qzG2Rgp9KwCBfSdYVKSRg3fdVwRFh49TY O6mBG9feZD0jGWYpWXrIXwvGwHKSj7Ll+NKp2I2uKLyVHczhuddHfif7Yzzong97PfZD iZkA==
MIME-Version: 1.0
Received: by with SMTP id y7mr5183884igm.21.1342446512853; Mon, 16 Jul 2012 06:48:32 -0700 (PDT)
Received: by with HTTP; Mon, 16 Jul 2012 06:48:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Mon, 16 Jul 2012 15:48:32 +0200
Message-ID: <>
From: Riccardo Petrocco <>
Content-Type: multipart/alternative; boundary=14dae9340be787513004c4f2af57
Cc: ppsp <>
Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2012 13:47:54 -0000


As Arno explained in the previous mail, LEDBAT was chosen to increase the
time of seeders.
The main problem with any P2P systems is the supply of bandwidth. With an
swarm, there is usually no problem in delivering the stream on time. If the
users don't see
any drop in performance by keeping on seeding content they already watched,
they might
stay longer in the swarm.

Wesley is definitely right, as for live-streaming LEDBAT is not the best
I wonder if we can keep LEDBAT, as it's the ideal cc for file sharing and
VoD content, and
adjust it's queuing target delay value, to act as TCP, in case of a
live-streaming swarm.


2012/7/16 Arno Bakker <>

> 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
> _______________________________________________
> ppsp mailing list