IETF Logo Mail Archive

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

zhangyunfei <zhangyunfei@chinamobile.com> Mon, 16 July 2012 06:10 UTC

Return-Path: <zhangyunfei@chinamobile.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 EA78221F85A3 for <ppsp@ietfa.amsl.com>; Sun, 15 Jul 2012 23:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.556
X-Spam-Level:
X-Spam-Status: No, score=-96.556 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
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 MeW-3WMv3WkT for <ppsp@ietfa.amsl.com>; Sun, 15 Jul 2012 23:10:40 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17821F856F for <ppsp@ietf.org>; Sun, 15 Jul 2012 23:10:37 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id C4C97E732; Mon, 16 Jul 2012 14:11:21 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id A271CE72E; Mon, 16 Jul 2012 14:11:21 +0800 (CST)
Received: from zyf-PC ([10.2.52.214]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071614111912-12449 ; Mon, 16 Jul 2012 14:11:19 +0800
Date: Mon, 16 Jul 2012 14:11:15 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: Wesley Eddy <wes@mti-systems.com>, "arno@cs.vu.nl" <arno@cs.vu.nl>
References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl>, <4FFDACBF.3080908@mti-systems.com>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012071614111568687511@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-16 14:11:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-16 14:11:20, Serialize complete at 2012-07-16 14:11:20
Content-Type: multipart/alternative; boundary="----=_001_NextPart052745570380_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19042.004
X-TM-AS-Result: No--19.299-7.0-31-10
X-imss-scan-details: No--19.299-7.0-31-10;No--19.299-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
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: zhangyunfei <zhangyunfei@chinamobile.com>
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 06:10:41 -0000

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.

BR
Yunfei



zhangyunfei

From: Wesley Eddy
Date: 2012-07-12 00:41
To: arno
CC: ppsp
Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt
On 7/11/2012 3:21 AM, Arno Bakker wrote:
> Good that you mention transports, AFAIK that still needs to be
> discussed. Candidates are:
> 
> * UDP with congestion control (e.g. LEDBAT)


I'm wondering if LEDBAT is the right choice, given that its
design is to let itself get drowned out.  LEDBAT made sense
for BitTorrent streams running in the background, but I don't
think it makes as much sense for live-streaming.

It seems that TFRC might be more appropriate to me.

-- 
Wes Eddy
MTI Systems
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

v2.23.0 | Report a Bug | By Email