Subject: Re: [ppsp] WG item adoption confirmation

From: "Roni Even" <[email-masked]>
Date: Mon, 4 Apr 2011 10:22:02 +0300

Hi,

I support adopting this document to address the august 2011 mile stone

Thanks

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
zhangyunfei
Sent: Tuesday, March 29, 2011 10:22 AM
To: Cullen Jennings; [email-masked]
Cc: Martin Stiemerling
Subject: [ppsp] WG item adoption confirmation

Hi all,

   As discussed in yesterday's meeting, we will likely adopt
draft-gu-ppsp-tracker-protocol as a new WG item. Please post on the mailing
list if you have any objections on this before Apr. 10th. 

    If there are no objections by Apr. 10th 2011, the draft above will be
accepted as WG document fulfilling the “tracker protocol”
deliverable.Thanks.

BR

Yunfei

  _____  

zhangyunfei

2011-03-29

  _____  

发件人： Cullen Jennings

发送时间： 2011-03-28 17:27:23

收件人： [email-masked]

抄送： 

主题： [ppsp] Notes from PPSP meeting IETF80

A  few  notes  I  took  from  the  meeting

First,  thank  you  to  Christian  Schmidt  for  taking  minutes  and
Martin  Stiemerling  for  jabber  scribing.

We  need  to  prioritize  the  use  cases  and  decide  what  we  will  work
on  first.  

draft-ietf-ppsp-problem-statement  is  getting  close  to  WGLC  

We  will  likely  adopt  draft-gu-ppsp-tracker-protocol  as  a  WG  item

Were  about  60  people  in  room  

 

_______________________________________________

ppsp  mailing  list

[email-masked]

https://www.ietf.org/mailman/listinfo/ppsp

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 5 Apr 2011 14:57:29 +0000

Dear all,

I have serious doubts about whether the working group has read the draft and is fine with the impending adoption as WG item. 

Basically, only Roni has expressed feedback to this. 

I would suggest that the WG reads the draft and gives feedback until April 10th if the draft is **ok** to be accepted as WG item or if it is **not ok**. 

Not sending any email to the list (i.e., pure silence) would read in my opinion as "we just do not care" and not as accept as WG item. Don't care doesn't seem to be a good option...

Thanks,

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: zhangyunfei [mailto:[email-masked]]
> Subject: WG item adoption confirmation
> 
> Hi all,
>    As discussed in yesterday's meeting, we will likely adopt draft-gu-
> ppsp-tracker-protocol as a new WG item. Please post on the mailing list
> if you have any objections on this before Apr. 10th.
>     If there are no objections by Apr. 10th 2011, the draft above will
> be accepted as WG document fulfilling the “tracker protocol”
> deliverable.Thanks.
> 
> BR
> Yunfei
> 
> 
> 
> ________________________________
> 
> zhangyunfei
> 2011-03-29
> ________________________________
> 
> 发件人： Cullen Jennings
> We  need  to  prioritize  the  use  cases  and  decide  what  we  will
> work  on  first.
>

---

From: Ning Zong <[email-masked]>
Date: Thu, 07 Apr 2011 19:26:32 +0800

Hi,

I read the draft and support to adopt it as a starting point for "Tracker
Protocol" deliverable. I'd also like to contribute to it by keeping it align
with requirement draft.

BR,
Ning Zong

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Martin
Stiemerling
发送时间: 2011年4月5日 22:57
收件人: zhangyunfei; Cullen Jennings; [email-masked]
主题: Re: [ppsp] WG item adoption confirmation

Dear all,

I have serious doubts about whether the working group has read the draft and
is fine with the impending adoption as WG item. 

I would suggest that the WG reads the draft and gives feedback until April
10th if the draft is **ok** to be accepted as WG item or if it is **not
ok**. 

Not sending any email to the list (i.e., pure silence) would read in my
opinion as "we just do not care" and not as accept as WG item. Don't care
doesn't seem to be a good option...

Thanks,

  Martin

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014

---

From: Ping Pan <[email-masked]>
Date: Thu, 7 Apr 2011 05:43:21 -0700

Curious: which encoding will it be? Binary or HTTP?

If binary is not a part of the protocol, why is it taking over 1/3 of the
document as appendix?

If HTTP, it may be helpful if it can provide the same level of details as
illustrated in  Alto protocol design.

Also, from the survey, it shows that there are many existing tracker
protocols. How did we reach the conclusion of using HTTP?

Thanks!

- Ping

2011/4/5 Martin Stiemerling <[email-masked]>

> Dear all,
>
> I have serious doubts about whether the working group has read the draft
> and is fine with the impending adoption as WG item.
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 7 Apr 2011 13:58:47 -0400

Hi,

I have read the draft, draft-gu-ppsp-tracker-protocol, and have the following comments:

1) In section 1 (Intro), there is the statement " At present, this draft attempts to
   allow for both a BitTorrent style offline and real-time streaming protocol, but may
   currently be biased a bit toward the offline approach, since the decision of the WG
   is to use BitTorrent as a reference."

   I don't think this is accurate.  I do not see anywhere in the charter, problem 
   Statement or requirements where this type of assumption is made.  Can the authors
   please explain why they say this?  And also explain the impacts to the draft if
   this statement is proved to be wrong?

2) How are the Trackers discovered?  In section 4.2.1 (Bootstrapping) it simply says
   that "Tracker discovery is out of scope of this specification".  I think we need
   to be a bit more prescriptive then this.

3) I think we need to have a separate "Security Considerations" section in the document
   as is usually found in most drafts.  At the present time, there are security related
   points spread throughout the document and I found it hard to deduce the overall
   security approach.

I am OK to adopt the draft as a WG document after my comments are addressed.

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ning Zong
Sent: Thursday, April 07, 2011 7:27 AM
To: 'Martin Stiemerling'; 'zhangyunfei'; 'Cullen Jennings'; [email-masked]
Subject: [ppsp] 答复: WG item adoption confirmation

Hi,

BR,
Ning Zong

-----邮件原件-----

Dear all,

Thanks,

  Martin

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 8 Apr 2011 14:21:42 +0800

Hi Ping,
   I remember that in last IETF and after the meeting(in the mailing list), the author had a poll to ask for the WG's attitude on the encoding. It seemed that most favored of http based encoding.
   Personally at a first sight the binary encoding is more efficient in mobile environment. But just as I mentioned in this IETF, the efficiency to deal with a message is basically decided by CPU computation to resolve the message and the bandwidth to transmit the message. From a qualitative analysis, the CPU in mobile terminals is faster and faster, which ensures the computation of even text message. The bandwidth of 3G or after-3G network may be wider to accomodate the text-based tracker and peer protoocol message.
   I support your suggestion that it would be great to provide the quantative analysis why we use HTTP and why we don't use binary in the protocol design (at least we can have an analysis based on the above model). 

Yunfei

zhangyunfei
2011-04-08

发件人： Ping Pan
发送时间： 2011-04-07 22:26:12
收件人： Martin Stiemerling
抄送： zhangyunfei; Cullen Jennings; [email-masked]
主题： Re: [ppsp] WG item adoption confirmation

If binary is not a part of the protocol, why is it taking over 1/3 of the document as appendix?

If HTTP, it may be helpful if it can provide the same level of details as illustrated in  Alto protocol design.

Also, from the survey, it shows that there are many existing tracker protocols. How did we reach the conclusion of using HTTP?

Thanks!

- Ping

Dear all,

Thanks,

 Martin

---

From: [email-masked]
Date: Fri, 8 Apr 2011 17:06:16 +0800

Personally, I prefer HTTP, but I am not sure.
I think transferring and watching video would consume much more resources 
of peer compared with transferring and processing signal messages. 
I don't worry mobile terminal's resources if the terminal has enough 
resources to download and display online video.
I worry text coding and TCP connection's impact on the performance of 
tracker. I agree with you two. It's better to make decision based on 
existing tracker protocols and quantitative analysis.

BR
Lichun

[email-masked] 写于 2011-04-08 14:21:42:

> Hi Ping,
>    I remember that in last IETF and after the meeting(in the mailing
> list), the author had a poll to ask for the WG's attitude on the 
> encoding. It seemed that most favored of http based encoding.
>    Personally at a first sight the binary encoding is more efficient
> in mobile environment. But just as I mentioned in this IETF, the 
> efficiency to deal with a message is basically decided by CPU 
> computation to resolve the message and the bandwidth to transmit the
> message. From a qualitative analysis, the CPU in mobile terminals is
> faster and faster, which ensures the computation of even text 
> message. The bandwidth of 3G or after-3G network may be wider to 
> accomodate the text-based tracker and peer protoocol message.
>    I support your suggestion that it would be great to provide the 
> quantative analysis why we use HTTP and why we don't use binary in 
> the protocol design (at least we can have an analysis based on the 
> above model). 
> 
> Yunfei
> 
> 
> zhangyunfei
> 2011-04-08
> 
> 发件人： Ping Pan
> If HTTP, it may be helpful if it can provide the same level of 
> details as illustrated in  Alto protocol design.
> 

> I have serious doubts about whether the working group has read the 
> draft and is fine with the impending adoption as WG item.
> 
> I would suggest that the WG reads the draft and gives feedback until
> April 10th if the draft is **ok** to be accepted as WG item or if it
> is **not ok**.
> 
> Not sending any email to the list (i.e., pure silence) would read in
> my opinion as "we just do not care" and not as accept as WG item. 
> Don't care doesn't seem to be a good option...
> 
> Thanks,
> 
>  Martin
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Ping Pan <[email-masked]>
Date: Fri, 8 Apr 2011 05:22:36 -0700

Both encoding approaches make sense. For HTTP, it's easier to implement,
secure and less NAT issues. However, it may be associated with more
processing overhead on inexpensive mobile devices.

Curious, other than tracker, the P2P devices also need to support the gossip
protocols, right? Aren't all gossip protocols using binary encoding...

Ping

2011/4/7 zhangyunfei <[email-masked]>

>  Hi Ping,
>    I remember that in last IETF and after the meeting(in the mailing list),
> the author had a poll to ask for the WG's attitude on the encoding. It
> seemed that most favored of http based encoding.
>    Personally at a first sight the binary encoding is more efficient in
> mobile environment. But just as I mentioned in this IETF, the efficiency to
> deal with a message is basically decided by CPU computation to resolve the
> message and the bandwidth to transmit the message. From a qualitative
> analysis, the CPU in mobile terminals is faster and faster, which ensures
> the computation of even text message. The bandwidth of 3G or after-3G
> network may be wider to accomodate the text-based tracker and peer protoocol
> message.
> quantative analysis why we use HTTP and why we don't use binary in the
> protocol design (at least we can have an analysis based on the above model).
>
>
> Yunfei
>
>  ------------------------------
>  zhangyunfei
> 2011-04-08
>  ------------------------------
>  *发件人：* Ping Pan
> *发送时间：* 2011-04-07 22:26:12
> *收件人：* Martin Stiemerling
> *抄送：* zhangyunfei; Cullen Jennings; [email-masked]
> *主题：* Re: [ppsp] WG item adoption confirmation
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 8 Apr 2011 14:25:29 +0000

[speaking as individual - not as PPSP co-chair]

Hi there,

Here is my incomplete review of draft-gu-ppsp-tracker-protocol-03 and my opinion of whether it is ready to become WG item:

- Why are there still 2 encodings in the draft? Isn't it time to conclude on one encoding?
- Section 1: "the main part is the abstract description of the operations...". This means that this is actually not a draft about the tracker protocol?
- Section 1: "for both a bittorrent style offline and real-time streaming protocol". Why is it so? We are in PPSP, so we should work on something for streaming, isn't it?
- Why is there the notion of battery level in the status messages?
- Section 9.1.3: What is the issue with fragmentation in here? 
- What is the transport protocol where the tracker protocol should run over?

The proposed methods look reasonable, but the overall draft organization still suffers from what Section 1 hints to that it is solely an abstract description of the operations. 

I'm **not** in favor of getting draft-gu-ppsp-tracker-protocol-03 to be a WG item, for these reasons:
- document quality is not good enough in my opinion
- it is unclear what the transport protocol is. there is a hint to UDP, which is not a good choice to be used in this particular case
- there is not yet a real protocol described in the draft, but only the skeletons of two protocols (binary and HTTP). 

I would suggest (still speaking as individual) to first make some important decisions, e.g., encoding, fix the document, etc and **afterwards** make a new call for WG adoption.

Thanks,

  Martin

---

From: Ping Pan <[email-masked]>
Date: Fri, 8 Apr 2011 07:32:07 -0700

I agree on this assessment.

2011/4/8 Martin Stiemerling <[email-masked]>

> Here is my incomplete review of draft-gu-ppsp-tracker-protocol-03 and my
> opinion of whether it is ready to become WG item:
>
> - Section 1: "the main part is the abstract description of the
> operations...". This means that this is actually not a draft about the
> tracker protocol?
> - Section 1: "for both a bittorrent style offline and real-time streaming
> protocol". Why is it so? We are in PPSP, so we should work on something for
> streaming, isn't it?
> The proposed methods look reasonable, but the overall draft organization
> still suffers from what Section 1 hints to that it is solely an abstract
> description of the operations.
>
>
>
> - it is unclear what the transport protocol is. there is a hint to UDP,
> which is not a good choice to be used in this particular case
> - there is not yet a real protocol described in the draft, but only the
> skeletons of two protocols (binary and HTTP).
>
> I would suggest (still speaking as individual) to first make some important
> decisions, e.g., encoding, fix the document, etc and **afterwards** make a
> new call for WG adoption.
>
> Thanks,
>
>  Martin
>
>

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Sat, 09 Apr 2011 11:56:19 +0800

Hi Akbar,

Thanks for your comments. 

See inline please.

> Rahman, Akbar

> Sent: Friday, April 08, 2011 1:59 AM

> To: [email-masked]

> Subject: Re: [ppsp] 答复: WG item adoption confirmation

> I have read the draft, draft-gu-ppsp-tracker-protocol, and have the following

> comments:

>    currently be biased a bit toward the offline approach, since the decision of the

> WG

>    Statement or requirements where this type of assumption is made.  Can the

> authors

>    this statement is proved to be wrong?

[gyj] This assumption is a legacy from previous version, I should remove it. After discussion on previous meetings and on mailing list, most voice from PPSP WG support text-based encoding. Hence, I move binary encoding to appendix, so that we could recover it if we encounter overwhelming support to binary encoding in IETF 80. Seems that people were okay with text-based encoding in IETF 80 and I will remove appendix in later version.

> 2) How are the Trackers discovered?  In section 4.2.1 (Bootstrapping) it simply

> says

>    to be a bit more prescriptive then this.

[gyj] In draft-ietf-ppsp-reqs-02, section 4.2, it says “the tracker discovery and the possible communication
   between trackers are out of the scope of tracker protocol” . That’s why we make this description in Tracker protocol draft.

> 3) I think we need to have a separate "Security Considerations" section in the

> document

>    security approach.

[gyj] You are right, we need a dedicated “Security considerations”. This will be improved in later version. 

[gyj] Thanks for your comments and support.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ning

> Zong

> > We  will  likely  adopt  draft-gu-ppsp-tracker-protocol  as  a  WG

> > item

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Sat, 09 Apr 2011 12:15:22 +0800

Hi Ping,

See inline please.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping Pan
Sent: Thursday, April 07, 2011 8:43 PM
To: Martin Stiemerling
Cc: [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

[gyj] At IETF 79, we asked people for their opinions on encoding, most, if not all, voice from meeting support text-based encoding. The same opinion on mailing list before IETF 80. So, in Tracker protocol presentation in IETF 80 we made a decision to propose text-based encoding. In draft, we moved binary encoding to appendix, because we still need the feedback from IETF 80 PPSP session discussion. If we encountered overwhelming support to binary encoding, we can recover it from appendix. If no strong opposition to text-based encoding, we will remove binary encoding from the draft forever. Now, since no strong opposition to text-based encoding at IETF 80, we will remove binary encoding in later version. 

[gyj] we will add more detail in updated version. 

[gyj] IETF suggests reuse existing protocol as much as we can. HTTP can be a suitable candidate. Any other suitable candidate protocol are welcome, we can analyze and compare them. 

Thanks!

[gyj] Thanks for your comments.

- Ping

Dear all,

Thanks,

 Martin

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Sat, 09 Apr 2011 14:11:29 +0800

Hi Martin,

See inline please.

2011/4/8 Martin Stiemerling < <mailto:[email-masked]> [email-masked]>

Hi there,

[gyj] The binary encoding has been moved to appendix. We have discussed on previous meetings and got rough consensus on choosing text-based encoding. As a history of Tracker protocol, we still leave binary encoding in appendix, we can remove it later. See more detail in my response to Ping Pan’s comments.

[gyj] I should revise this sentence. At the very beginning of composing Tracker protocol, main part of draft was descriptive. However, after several round of discussion and revision, the main part is message definition and encoding. I will revise this description in updated version. 

[gyj] Definitely we should work for streaming. The sentence you have cited implies that we should take both offline streaming (provided as file) and real-time streaming (e.g. TV broadcast) in consideration. 

- Why is there the notion of battery level in the status messages?
[gyj] This is a requirement from mobile peer, in which case, battery level is an important property of peer. I remembered there was some discussion on mobile peer support before either on meeting discussion or on mailing list. 

[gyj] This is an open issue. I think fragmentation makes more sense in Peer-peer traffic than in tracker-peer communication.  David Bryan, co-author of tracker protocol could give more explaination.

[gyj] The definition of Tracker protocol in draft-ietf-ppsp-reqs is “The tracker protocol defines how the peers report and request
   information to/from the tracker and how the tracker replies to the requests. ”  Choosing which transport protocol is not in scope of Tracker protocol definition. 
Besides, in draft-ietf-ppsp-reqs-03, section 4.1, “   PPSP.REQ-7: The tracker protocol and peer protocol are Recommended to be carried over TCP (or UDP, when delivery requirements cannot be met by TCP). So Tracker protocol will first consider running on TCP. However, in order to improve applicability, Tracker protocol may also need to consider specific requirements, e.g. retransmission, of UDP as transport protocol. No matter which transport protocol is chosen, message exchange definition and encoding shouldn’t be influence.

[gyj] The authors promise to correct the historic mis-wording in updated version. Sorry for the confusion. 

”
     [gyj] Please refer to my answer above.

[gyj] I was unable to present Tracker protocol by myself at Prague. But at IETF 79 and mailing list discussion before IETF 80, the authors asked for opinions on encoding, most, if not all, voice support text-based encoding. So the authors decided to use text-based encoding and asked for feedback in IETF80 presentation. If there was no strong opposition, I believe we have gotten rough consensus on text-based encoding. 
Thanks,
[gyj] Thanks for your comments. I propose the WG to adopt Tracker protocol because the basic open issues, i.e. encoding and NAT Traversal, have been decided, and no announced opposition to methods definition. The definition of Tracker protocol influences the definition of Peer protocol a lot, as we have listed in slides. So the later the maturity of Tracker protocol, the slower the progress on Peer Protocol. The adoption of Tracker protocol draft will absorb more effort from the WG to make it completed in detail. 
 Martin

> be accepted as WG document fulfilling the 鈥渢racker protocol鈥?br> > deliverable.Thanks.
>
> BR
> Yunfei
>
>
>
> 鍙戜欢浜猴細 Cullen Jennings
> 鍙戦€佹椂闂达細 2011-03-28 17:27:23
> 鏀朵欢浜猴細 [email-masked]
> 鎶勯€侊細
> 涓婚锛?[ppsp] Notes from PPSP meeting IETF80
>
>

---

From: [email-masked]
Date: Sun, 10 Apr 2011 16:33:35 +0800

By "less NAT issues", do you mean firewall issues?
HTTP can pass firewalls easier. But HTTP is using TCP, which has more NAT 
issues than UDP.
According to the requirement draft ("The tracker and the peer protocols 
SHOULD be as similar
   as possible"), peer protocol should use HTTP if tracker protocol uses 
it. If so, there will be more NAT issues.
Is it possible to allow PPSP to run over multiple transport protocols? SIP 
can run over TCP/UDP/... Maybe PPSP can run over HTTP and COAP?

I guess the overhead of processing PPSP signal can be omitted compared 
with the overhead of process streaming media.

I support to adopt this draft as WG item. And I hope the encoding and 
transport issues can be clarified in the new version of the draft. 

BR
Lichun

[email-masked] 写于 2011-04-08 20:22:36:

> Both encoding approaches make sense. For HTTP, it's easier to 
> implement, secure and less NAT issues. However, it may be associated
> with more processing overhead on inexpensive mobile devices. 
> 
> Curious, other than tracker, the P2P devices also need to support 
> the gossip protocols, right? Aren't all gossip protocols using 
> binary encoding...
> 
> Ping
>

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 12 Apr 2011 12:03:22 +0800

Hi all,
      For the transport protocol, which is beyond the current scope of PPSP, as suggested in the charter. However when we talk about the transport protocol used in practice for P2P streaming applications, UDP has been seen the most commonly used protocol now, with the transition from TCP to UDP both for data transport. And many applications(e.g., ppstream, pplive) even change from TCP to use UDP for signaling transport(draft-zhang-ppsp-protocol-comparison-measurement-00). 
       The rational behind this is that firstly, streaming applications *don't*care much of packet loss and secondly, p2p streaming tracker and peer query mechanism ensures there are *enough* active peers to exchange data, so a peer doesn't care *much* if one request is successfully transmitted or not. This is proven in wired network. But when we consider a converged environment, we may need more investigation on whether UDP is *enough* for transport.
      For the encoding issue, since we polled and seems "text" is acceptable by most guys and there are some uncertainty on "binary", I would suggest (individually) to add one section to analyze the strengh and drawback of both encodings in the protocol draft. 
      Regarding the WG item adoption, I would like to see that there is rough consensus on the questions recently raised and discussed in the mailing list before the adoption.

BR
Yunfei

zhangyunfei
2011-04-12

发件人： Martin Stiemerling
发送时间： 2011-04-08 22:25:40
收件人： [email-masked]
抄送： 
主题： Re: [ppsp] WG item adoption confirmation

Hi  there,

Thanks,

   Martin

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Fri, 15 Apr 2011 21:26:23 +0800

Hi, 
 
I think PPSP WG has the interest to study the PPSP tracker protocol,and "draft-gu-ppsp-tracker-protocol-03" is the only draft on the table, so we should accept this as WG draft. It's true that efforts are still needed to improve the quality of the draft, but more work still can be done after it's accepted as a WG draft, right?  Do we have another choice?

BR 
Lin

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Tuesday, April 12, 2011 12:03 PM
To: Martin Stiemerling; [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

Hi all,
 
BR
Yunfei

zhangyunfei
2011-04-12

发件人： Martin Stiemerling

Hi  there,

 

 
 
Thanks,
 
   Martin

---

From: Ping Pan <[email-masked]>
Date: Fri, 15 Apr 2011 06:57:10 -0700

Interesting logic!

I go a restaurant for vegetarian food. Instead, I'm offered with steak. What
would my choices? Eat the meat because it's cooked already? Have a salad and
let it go by? Leave the restaurant altogether? Or ask the chef to prepare
the food I want?

2011/4/15 Xiao, Lin (NSN - CN/Beijing) <[email-masked]>

>  Hi,
>
> I think PPSP WG has the interest to study the PPSP tracker
> protocol,and "draft-gu-ppsp-tracker-protocol-03" is the only draft on the
> table, so we should accept this as WG draft. It's true that efforts are
> still needed to improve the quality of the draft, but more work still can be
> done after it's accepted as a WG draft, right?  Do we have another choice?
>
>
> BR
> Lin
>
>
>  *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext zhangyunfei
> *Sent:* Tuesday, April 12, 2011 12:03 PM
> *To:* Martin Stiemerling; [email-masked]
> *Subject:* Re: [ppsp] WG item adoption confirmation
>
>  Hi all,
>       For the transport protocol, which is beyond the current scope of
> PPSP, as suggested in the charter. However when we talk about the transport
> protocol used in practice for P2P streaming applications, UDP has been seen
> the most commonly used protocol now, with the transition from TCP to UDP
> both for data transport. And many applications(e.g., ppstream, pplive) even
> change from TCP to use UDP for signaling
> transport(draft-zhang-ppsp-protocol-comparison-measurement-00).
>        The rational behind this is that firstly, streaming applications
> *don't*care much of packet loss and secondly, p2p streaming tracker and peer
> query mechanism ensures there are *enough* active peers to exchange data, so
> a peer doesn't care *much* if one request is successfully transmitted or
> not. This is proven in wired network. But when we consider a converged
> environment, we may need more investigation on whether UDP is *enough* for
> transport.
>       For the encoding issue, since we polled and seems "text" is
> acceptable by most guys and there are some uncertainty on "binary", I would
> suggest (individually) to add one section to analyze the strengh and
> drawback of both encodings in the protocol draft.
>       Regarding the WG item adoption, I would like to see that there is
> rough consensus on the questions recently raised and discussed in the
> mailing list before the adoption.
>
> BR
> Yunfei
>
>  *发件人：* Martin Stiemerling
> *发送时间：* 2011-04-08 22:25:40
> *收件人：* [email-masked]
> *抄送：*
> Here  is  my  incomplete  review  of  draft-gu-ppsp-tracker-protocol-03
>  and  my  opinion  of  whether  it  is  ready  to  become  WG  item:
>
>  operations...".  This  means  that  this  is  actually  not  a  draft
>  about  the  tracker  protocol?
> -  Section  1:  "for  both  a  bittorrent  style  offline  and  real-time
>  streaming  protocol".  Why  is  it  so?  We  are  in  PPSP,  so  we  should
>  work  on  something  for  streaming,  isn't  it?
> The  proposed  methods  look  reasonable,  but  the  overall  draft
>  organization  still  suffers  from  what  Section  1  hints  to  that  it
>  is  solely  an  abstract  description  of  the  operations.
>
>
>
> -  it  is  unclear  what  the  transport  protocol  is.  there  is  a  hint
>  to  UDP,  which  is  not  a  good  choice  to  be  used  in  this
>  particular  case
> -  there  is  not  yet  a  real  protocol  described  in  the  draft,  but
>  only  the  skeletons  of  two  protocols  (binary  and  HTTP).
>
> I  would  suggest  (still  speaking  as  individual)  to  first  make  some
>  important  decisions,  e.g.,  encoding,  fix  the  document,  etc  and
>  **afterwards**  make  a  new  call  for  WG  adoption.
>
> Thanks,
>
>    Martin
>
>
> NEC  Europe  Limited  |  Registered  Office:  NEC  House,  1  Victoria
>  Road,  London  W3  6BL  |  Registered  in  England  2832014
>
>
>  draft-gu-

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Sun, 17 Apr 2011 16:54:15 +0800

I don't think it's fanny at all! I remember the WG chairs showed the same idea with me, and got the consensus at the meeting.
 
If it's a vegetarian restaurant, no one will cook steak for you.You can say the food is not that good, but I believe it's still vegetable. What's your solution? Cook yourself? or I think we should help the chef to improve the quality of the food "in the restaurant". Or if you are not interested in the restaurant, you can just leave.

From: ext Ping Pan [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 9:57 PM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext zhangyunfei; Martin Stiemerling; [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

Interesting logic! 

I go a restaurant for vegetarian food. Instead, I'm offered with steak. What would my choices? Eat the meat because it's cooked already? Have a salad and let it go by? Leave the restaurant altogether? Or ask the chef to prepare the food I want?

	Hi, 

	BR 
	Lin

	Hi all,
	 
	BR
	Yunfei

	zhangyunfei
	2011-04-12

	发件人： Martin Stiemerling

	Hi  there,

	 

	 
	 
	Thanks,
	 
	   Martin

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 18 Apr 2011 09:24:54 +0800

Hi, 

Thank all of you for your comments and supports.

All comments are aiming to make the draft more suitable for a WG item, though people may have different ideas on adoption. 

I always agree the draft-gu-ppsp-tracker-protocol still need improvement no matter we adopt it now or later.

As answer to chairs’ and other experts comments,  

1)     composing a section to ‘analyze the strengh and drawback of both encodings in the protocol draft’, It’s okay to add some analysis text in the draft, but since we can not make an accurate calculation on bandwidth consuming before we make exact messages definition, I don’t think the analysis text will include bandwidth consuming calculation comparison between text-based and binary based. Besides, since we already have a rough consensus on Text-based encoding, I think we can answer the encoding question as “text-based encoding”.  Any objection to this? The draft has described a HTTP-based encoding. 

2)     As for Transport protocol, as Yunfei has said as a chair, this has been clarified in Charter.  Personally, I think TCP is okay for Tracker protocol, but UDP is better for Peer protocol. This is idea is also from some other people I talked with. But currently, the WG has not make any decision that Transport protocol choice is in scope of Tracker and Peer Protocol, so Tracker protocol authors will follow WG Charter for now, unless Transport protocol choice is pushed to PPSP protocol design.

3)     As for NAT Traversal, there is already a good draft to analyzing and providing solution to it. Tracker protocol will receive the requirements from the NAT draft and make sure Tracker protocol is able to support common requirements for various NAT Traversal solution. 

4)     There is some confusing description, most in introduction section, the authors promise to revise it next version.

5)     The Binary encoding, which is in appendix now, will be removed in next version.

Are there other major comments I missed?

If you have any objection to the above answer, please voice out, so that the WG can have a discussion on that.

If there is no objection, will the Chairs be glad with rough consensus on the above comments?

Again, thank all of you and all the comments are highly appreciated.

BR

Yingjie

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiao, Lin (NSN - CN/Beijing)
Sent: Sunday, April 17, 2011 4:54 PM
To: ext Ping Pan
Cc: [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

  _____  

Interesting logic! 

 

Hi, 

 

BR 

Lin

  _____  

Hi all,

BR

Yunfei

  _____  

zhangyunfei

2011-04-12

  _____  

发件人： Martin Stiemerling

收件人： [email-masked]

抄送： 

Hi  there,

 

Thanks,

   Martin

 

ppsp  mailing  list

[email-masked]

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 18 Apr 2011 00:24:55 -0400

Hi Yingjie,

I agree with your list of major improvements required for the tracker I-D.  I would also add to this list the comment that I had given on security previously.  Specifically:

   I think we need to have a separate "Security Considerations" section in the document

   security approach.

Sincerely,

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yingjie Gu(yingjie)
Sent: Sunday, April 17, 2011 9:25 PM
To: 'Xiao, Lin (NSN - CN/Beijing)'; 'ext Ping Pan'
Cc: [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

Hi, 

BR

Yingjie

Interesting logic! 

 

Hi, 

 

BR 

Lin

Hi all,

BR

Yunfei

zhangyunfei

2011-04-12

发件人： Martin Stiemerling

收件人： [email-masked]

抄送： 

Hi  there,

 

Thanks,

   Martin

 

ppsp  mailing  list

[email-masked]

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 18 Apr 2011 16:08:47 +0800

Sorry, I remembered this comment, but forget to list it. We definitely need a security consideration.

Thanks again.

  _____  

From: Rahman, Akbar [mailto:[email-masked]] 
Sent: Monday, April 18, 2011 12:25 PM
To: Yingjie Gu(yingjie)
Cc: [email-masked]; Xiao, Lin (NSN - CN/Beijing); ext Ping Pan
Subject: RE: [ppsp] WG item adoption confirmation

Hi Yingjie,

   security approach.

Sincerely,

Akbar

Hi, 

BR

Yingjie

  _____  

  _____  

Interesting logic! 

 

Hi, 

 

BR 

Lin

  _____  

Hi all,

BR

Yunfei

  _____  

zhangyunfei

2011-04-12

  _____  

发件人： Martin Stiemerling

收件人： [email-masked]

抄送： 

Hi  there,

 

Thanks,

   Martin

 

ppsp  mailing  list

[email-masked]

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 18 Apr 2011 10:25:58 -0400

So a few comments here. In full disclosure, I'm an author on the
draft, and so would personally like to see it adopted and think it is
a good base, but there is obviously some inherent bias on my part...

My experience in the past has been that until you have a draft of some
kind (protocol or a design document) in which to document consensus it
is very hard to drive forward. Some folks don't even read drafts or
get involved in a group until it has WG items. We have had debate at
several meetings on some of these issues (HTTP/Binary, offline
support, etc.) and it has been tough to drive toward consensus, get it
documented, and move on. Newcomers join and the same issues get hashed
again and again since there isn't a document to track consensus.
(Sometimes you are lucky if you can get the comments until last
call...)

In P2PSIP, we had several competing (and in function, very similar,
with one exception) proposals, and the authors spent lots of time
incorporating each other's tweaks into their drafts. It took years
(literally) to resolve, finally by merging the drafts. Once that
happened, the group debated the technical points, and had a clear
place to document the consensus -- the adopted draft. Other groups
achieve the same goal using a design draft.

I prefer we adopt, but if we don't adopt
draft-gu-ppsp-tracker-protocol as a WG item, then I would at least
suggest a WG item for a new design draft that does nothing but list
the big questions, and use that to drive and document WG consensus
(i.e., discussion, then slides and hums on each question, then confirm
it on list and wrap up that document), or appoint a design team to go
make either a design or protocol draft so that we can spend time
productively. What I'd like to avoid is spending time nailing down
every detail of multiple proposals when there is no place to clearly
document the direction the group wants to go in the first place.

On a few specific issues raised about the draft:

The binary encoding remains in the draft simply because while the
authors prefer HTTP, we haven't been able to get a clear WG consensus.
We would be willing to adjust the draft to reflect the desired
encoding (and change/modify as the group discussion evolves
accordingly). We spend more time on the operations -- I feel the
encoding is much less important than getting the operations right
(which we would love feedback on -- we may very well have them wrong,
but there hasn't been much discussion on list about that, despite it
being the most important question in my opinion)

On the offline question, there has been a great deal of discussion in
the early meetings (I missed Prague, so forgive me if things changed)
to allow time-shifted, BT style designs as well. We reflected that in
the draft, but again, it would be good to discuss further. For those
asking about this, it might be good to go back and listen to the old
minutes (particularly the BoF). There was very strong consensus in the
room to support offline as well as real-time. I do agree this is
perhaps not well reflected in the charter, and again, it would be good
to document this consensus -- one way or another -- somewhere.

As mentioned, bootstrapping is explicitly out of scope in the charter
at present.

Security definitely needs more work and Akbar's comment is valid -- we
need to reorganize the text into one location. We would also love
comments on list about this topic. The discussion online has been
pretty quiet.

David

On Mon, Apr 18, 2011 at 4:08 AM, Yingjie Gu(yingjie)
<[email-masked]> wrote:
> I agree with your list of major improvements required for the tracker I-D.
> I would also add to this list the comment that I had given on security
> previously.  Specifically:
>
>
>
> Yingjie Gu(yingjie)
> All comments are aiming to make the draft more suitable for a WG item,
> though people may have different ideas on adoption.
>
> As answer to chairs' and other experts comments,
>
> 1)  composing a section to 'analyze the strengh and drawback of both
> encodings in the protocol draft', It's okay to add some analysis text in the
> draft, but since we can not make an accurate calculation on bandwidth
> consuming before we make exact messages definition, I don't think the
> analysis text will include bandwidth consuming calculation comparison
> between text-based and binary based. Besides, since we already have a rough
> consensus on Text-based encoding, I think we can answer the encoding
> question as "text-based encoding".  Any objection to this? The draft has
> described a HTTP-based encoding.
>
> 2)  As for Transport protocol, as Yunfei has said as a chair, this has been
> clarified in Charter.  Personally, I think TCP is okay for Tracker protocol,
> but UDP is better for Peer protocol. This is idea is also from some other
> people I talked with. But currently, the WG has not make any decision that
> Transport protocol choice is in scope of Tracker and Peer Protocol, so
> Tracker protocol authors will follow WG Charter for now, unless Transport
> protocol choice is pushed to PPSP protocol design.
>
> 3)  As for NAT Traversal, there is already a good draft to analyzing and
> providing solution to it. Tracker protocol will receive the requirements
> from the NAT draft and make sure Tracker protocol is able to support common
> requirements for various NAT Traversal solution.
>
> 4)  There is some confusing description, most in introduction section, the
> authors promise to revise it next version.
>
> Xiao, Lin (NSN - CN/Beijing)
> I don't think it's fanny at all! I remember the WG chairs showed the same
> idea with me, and got the consensus at the meeting.
>
>
>
> If it's a vegetarian restaurant, no one will cook steak for you.You can say
> the food is not that good, but I believe it's still vegetable. What's your
> solution? Cook yourself? or I think we should help the chef to improve the
> quality of the food "in the restaurant". Or if you are not interested in the
> restaurant, you can just leave.
>
>
>
>       For the transport protocol, which is beyond the current scope of PPSP,
> as suggested in the charter. However when we talk about the transport
>       For the encoding issue, since we polled and seems "text" is acceptable
> by most guys and there are some uncertainty on "binary", I would suggest
> (individually) to add one section to analyze the strengh and drawback of
> both encodings in the protocol draft.
>
> Here  is  my  incomplete  review  of  draft-gu-ppsp-tracker-protocol-03  and
>  my  opinion  of  whether  it  is  ready  to  become  WG  item:
>
>
>
>>  be  accepted  as  WG  document  fulfilling  the  "tracker  protocol"
>
>>  deliverable.Thanks.
>
>>
>
>>  BR
>
>>  Yunfei
>
>>
>
>>
>
>>
>

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 18 Apr 2011 10:38:58 +0800

Hi all,
    As the co-chair,I would suggest to concentrate the discussion on the techincal issues. My understanding is that the current draft is indeed *vegetables*. It may be not perfect now. But anyway it's not *steak*. This is just what the WG should do to improve the draft quality accroding to the techincal discussion.
    Shall I ask the WG: For the encoding issue, who doesn't think that it's a reasonable way to add the comparison analysis part betwwen binary and text in the draft, in the context of no convincing reason to use binary?Shall we move forward the draft in this way?

Yunfei

zhangyunfei
2011-04-18

发件人： Xiao, Lin (NSN - CN/Beijing)
发送时间： 2011-04-17 16:54:58
收件人： ext Ping Pan
抄送： ext zhangyunfei; Martin Stiemerling; [email-masked]
主题： RE: [ppsp] WG item adoption confirmation

Interesting logic! 

Hi, 

BR 
Lin

Hi all,

BR
Yunfei

zhangyunfei
2011-04-12

发件人： Martin Stiemerling

Hi  there,

Thanks,

   Martin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 21 Apr 2011 09:48:30 -0400

Hi Yunfei,

I support your proposal for analyzing the encoding issue (as per the quote below)

“For the encoding issue, since we polled and seems "text" is acceptable by most guys and there are some uncertainty on "binary", I would suggest (individually) to add one section to analyze the strength and drawback of both encodings in the protocol draft.”

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of zhangyunfei
Sent: Sunday, April 17, 2011 10:39 PM
To: Xiao, Lin (NSN - CN/Beijing); ext Ping Pan
Cc: [email-masked]
Subject: Re: [ppsp] WG item adoption confirmation

Hi all,

Yunfei

zhangyunfei

2011-04-18

收件人： ext Ping Pan

Interesting logic! 

 

Hi, 

 

BR 

Lin

Hi all,

BR

Yunfei

zhangyunfei

2011-04-12

发件人： Martin Stiemerling

收件人： [email-masked]

抄送： 

Hi  there,

 

Thanks,

   Martin

 

ppsp  mailing  list

[email-masked]