IETF Logo Mail Archive

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

Riccardo Petrocco <r.petrocco@gmail.com> Mon, 16 July 2012 13:47 UTC

Return-Path: <r.petrocco@gmail.com>
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 4070921F8858 for <ppsp@ietfa.amsl.com>; Mon, 16 Jul 2012 06:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWaJYNFebciB for <ppsp@ietfa.amsl.com>; Mon, 16 Jul 2012 06:47:53 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 807C521F8855 for <ppsp@ietf.org>; Mon, 16 Jul 2012 06:47:53 -0700 (PDT)
Received: by yhq56 with SMTP id 56so5662657yhq.31 for <ppsp@ietf.org>; Mon, 16 Jul 2012 06:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.50.46.231 with SMTP id y7mr5183884igm.21.1342446512853; Mon, 16 Jul 2012 06:48:32 -0700 (PDT)
Received: by 10.64.20.168 with HTTP; Mon, 16 Jul 2012 06:48:32 -0700 (PDT)
In-Reply-To: <5003C171.1050606@cs.vu.nl>
References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl> <4FFDACBF.3080908@mti-systems.com> <2012071614111568687511@chinamobile.com> <5003C171.1050606@cs.vu.nl>
Date: Mon, 16 Jul 2012 15:48:32 +0200
Message-ID: <CAN6E5EeS407N_rDG8nyEr+RBAkg2vroCFSPzNm_nazi_OgOsRw@mail.gmail.com>
From: Riccardo Petrocco <r.petrocco@gmail.com>
To: arno@cs.vu.nl
Content-Type: multipart/alternative; boundary="14dae9340be787513004c4f2af57"
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
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 13:47:54 -0000

Hi,

As Arno explained in the previous mail, LEDBAT was chosen to increase the
on-line
time of seeders.
The main problem with any P2P systems is the supply of bandwidth. With an
oversupplied
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
candidate.
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.


BR,
Riccardo

2012/7/16 Arno Bakker <arno@cs.vu.nl>

> 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
> ppsp@ietf.org
> https://www.ietf.org/mailman/listinfo/ppsp
>

v2.23.0 | Report a Bug | By Email