[ppsp] PPSP notes in IETF 84

zhangyunfei <zhangyunfei@chinamobile.com> Mon, 20 August 2012 01:56 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B56E221F864A for <ppsp@ietfa.amsl.com>; Sun, 19 Aug 2012 18:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.19
X-Spam-Status: No, score=-97.19 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id okPpqmVDvdwI for <ppsp@ietfa.amsl.com>; Sun, 19 Aug 2012 18:56:29 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0C6AD21F8644 for <ppsp@ietf.org>; Sun, 19 Aug 2012 18:56:29 -0700 (PDT)
Received: from imss.chinamobile.com (localhost []) by localhost.chinamobile.com (Postfix) with ESMTP id 2BF83E51D; Mon, 20 Aug 2012 09:56:23 +0800 (CST)
Received: from mail.chinamobile.com (unknown []) by imss.chinamobile.com (Postfix) with ESMTP id 12E7DE51B; Mon, 20 Aug 2012 09:56:23 +0800 (CST)
Received: from zyf-PC ([]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012082009562141-6976 ; Mon, 20 Aug 2012 09:56:21 +0800
Date: Mon, 20 Aug 2012 09:56:18 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: ppsp <ppsp@ietf.org>
X-Priority: 3 (Normal)
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <2012082009561839584722@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-20 09:56:21, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-20 09:56:22, Serialize complete at 2012-08-20 09:56:22
Content-Type: multipart/alternative; boundary="----=_001_NextPart881756283404_=----"
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--35.159-7.0-31-10
X-imss-scan-details: No--35.159-7.0-31-10;No--35.159-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Subject: [ppsp] PPSP notes in IETF 84
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, 20 Aug 2012 01:56:30 -0000

Hi folks,
    The following is an initial version of PPSP notes in IETF 84. Thanks Martin for taking the notes. Please feel free to send emails to Stefano and me if you have any modification or update on the notes. Thanks.

Yunfei and Stefano

ppsp session at IETF-84

Note taker: Martin Stiemerling (martin.stiemerling@neclab.eu)

     PPSP Agenda #IETF 84 
Georgia A,WEDNESDAY, August 1, 2012

09:00 Agenda bashing (Chairs, 5 minutes)
09:05 Status of the WG (Chairs, 5 minutes)
09:10 Peer Protocol (Johan Pouwelse, 40 minutes)
Fabio: Question about previous slide (Example PPSP).
Does the 'hints' make the protocol a pull protocol?
Johan: Is it hybrid?
Fabio: Push protocol would either send the data/tokwn right away to B. Want to sent chunk and does if ok. Token means, A sends token to B. gonna send chunk right away.  B will respond with a chunk.
Pull based, B tells A, when you have time, send a chunk you are hinting to. 
Johanr: call it not HINT but Request.
(further discussion are taken taken offline.)
Fabio: important to support pull/push, and hybrid.
Martin: please limit presentation to protocol not your implementation
Johan: Overly ads, will back up
Yunfei: ledbat congestion control?
Wes: ledbat isn't necessary good for streaming, as you need a certain rate. not really good. Spec should say: must do something, if ledbat ...  
replace ledbat over the long run in the spec, but ledbat the only thing we have right now.
Johan: showing congestion control box on block diagram. could be replaced. streaming related, upload peer side, can we measure on upload side ledbat friendlyness.... 
Fabio: the other day was the talk about problems that ledbat can occur.
should look for potential issues with ledbat. generic congestion control? We need to think about it.
Johan: We or someone else?
Fabio: need to think about question.
Wes: If you do ledbat, need machinery to compute one way delay. Fine with the system as it is. spec 'must do something, should do ledbat'.
There is a BOF tomorrow on RMCAT. Whatever is coming out of that, might be new mechanisms...
Stefano: Lack of energy, at this point just go ahead with the document. if anything has something to say, just move on. 
Johan: Policy is, if no one opposing, just go ahead.
Yunfei: Question about #43 auth scheme wrt overhead? Need to sign every chunk?
Johan: block of chunks or single chunk? Not sure avout excat state of this is?
Fabio: Clarifyin question: overhead of computing or bandwidth?
Yunfei: both
Fabio: Regardless of what overhead is, signing all options is good. latency advantage. 
Yunfei: Good news, people will asking questions, if ppsp is on your mobile devices. People general think contributing to other peers will consume more power, compared to client/server mode.
Martin: Any other implementation? (no one with another implementation is in the room)
Stefano: Good to have already one!
Stefano: Since you (Johan) have an implementaiton, it would be good to document it in an implementation report.  
Johan: Good to have somebody else to have an implementation.
Johan: have done simulation and measuremnts in the wild.
Martin: Livestreaming at the next IETF?
Johan: Was done in large scale with pplive, etc. Would need more resources to make it.
Stefano: How to operate this proto in private environments. 
(scribe did miss what was said)
Stefano: analog to routing protocol. would helped there experiencing description,  details you missed or you worked out.
James: only suggestion to make, we should pay attention to managment of the protocol. Know how to treat things if something goes wrong.
Johan: (missed what he said)
Fabio: How many lines of code is an implementation roughly. 
Johan: roughly 10,000 lines of code or less. 

09:50 Tracker Protocol (Yingjie, 30 minutes)
Martin: Why is the peer's IP address put in the tracker protocol
Yingjie: To know whether the peer is behind NAT or not
Martin: Send back the IP address of the peer as seen in the tracker. Peer can find out on his own if behind NAT.
Yunfei: Can you elaborate on the peer ID?
Yingjie: (missed what he said)
Yunfei: Didnot see the unique requirement for peer ID?
Yingjie: PeerId is used to identify a peer, if it is not globally unqe, typcally unique in local tracker. 
Yunfei: use public IP plux X to generate globally unique
Stefano: Issue in many protocols, relying on IP is not enough. Could be reused partially to create unqieu ID. Use different fields that make a unique ID, IP address can be part of the game.
Yunfei: do you need the port information?
Yingjie: there should be port information, do remember this.

Johan: commenting also on the mailing list. binary implementation of this?
to better support mobile devices? opinions?
Yingjie: still not clear about question?
Johan: xml encoding, needs a parser. big tracker will require computation power with xml. lightweight udp tracker protocol
James: xml could be expensive
Yingjie: long discissoin on the list. conclusion was to go for text based.
Wes: no http, doesn't solve the problem. http header do not add anything to it. just send the messages, independet of xml, json, whatever.
Stefano: separation of base and extended is good, want feedback.
Martin: about split ok, but overall quality needs to be improved
Fabio: agress with said before. need no http, lighter encoding. if argument for http, would be good to hear it. same for xml, json. base functionality is fine. work on encoding issue and this as base functionality is fine. 
Stefan: are we ok with the functionality? if we consider the func, is it mature enough? Raised hand (majority). If people are fine with functions raise hand (some). WG is fine functionality wise.
Stefano: How about encodind?
4 expressing concerns
Encoding as proposed is ok: 3
Stefano: decision not clear yet.
Stefano: same policy, no feedback is good feedback. cannot wait for years. 

10:20 Tracker Protocol Extension  (Rachel,15 minutes)
Fabio: trying to understand the Registration message. message does fewer things than the base version
Rachel: is different. (scribe didn't understood the rest)
Fabio: may be I am missing something. there is a connect message in the base protocol. what is the diff between connect and the registration message? 
Rachel: Biggst differecne is that that it has registration meaning. will take it offline.
Ning: it is called enhanced, it is not more complex, more optional functionality as compared to base draft. register does not execute additional things.

Stefano: result of split. if anybody has issues speak up right now. 
Let's give the entire working group in the mailing list to see what is the feedback. 
Stefano: some reads some questions from webex
Arno: security section of peer protocol?
rui: peer id discussion on the mic. what is the best options?
Stefano: (scribe missed a part) 
Yunfei: any further comments or questions.

End of session at 10:52 local time.