Subject: [ppsp] Fwd: Re: New version of Peer protocol, looking forward to your comments.

From: jlei <[email-masked]>
Date: Tue, 05 Jul 2011 16:26:47 +0200

-------- Original-Nachricht --------
Betreff: 	Re: [ppsp] New version of Peer protocol,looking forward to
your comments.
Datum: 	Tue, 05 Jul 2011 16:24:52 +0200
Von: 	jlei <[email-masked]>
An: 	Yingjie Gu(yingjie) <[email-masked]>

Hi, Yingjie:

please see inline.
>
> Hi Jun,
>
> Thank you very much for your comments.
>
> Please find my reply in below.
>
> ------------------------------------------------------------------------
>
> Best Regards
> Gu Yingjie
>
> *发件人:*jlei [mailto:[email-masked]]
> *发送时间:*2011年7月5日 乐乐14:57
> *收件人:*Yingjie Gu(yingjie)
> *主题:*Re: [ppsp] New version of Peer protocol,looking forward to your
> comments.
>
> Hi, Yingjie,
>
> thanks for your effort.
>
> please find some comments below.
>
> 1. section 4.2.1.3.1
>
> “FIND message is sent from a peer to remote peer or a Tracker. ”
>
> If FIND is sent from a peer to a Tracker, in which senario? as the
> peer protocol is used to carry information to faciliate peering and
> data exchange.
> [Gu] I agree that my description is confusing. When I design the
> Tracker and peer protocol, I hope they could be consistent, i.e.
> similar encoding and some methods can be shared. FIND and FIND_CHUNK
> are the shared methods. They have similar intention: to find the peers
> that can provide specific content. If FIND is sent to Tracker, the
> requesting peer hopes that Tracker can feedback with list of candidate
> peers. If FIND is sent to remote peer, the requesting peer hopes that
> the remote peer can feedback with list of candidate peers. You may
> find that the encoding of FIND in both Tracker and Peer protocol is
> the same, except for the <Stats> part, which can also be added to FIND
> message in Peer protocol.
>
I understand your intention here. However, it might be better to keep
the focus out of Tracker in this sense as you describe peer protocol. If
you emphasize the consistence, you could add the similarity for "FIND"
or "FIND_CHUNK" with tracker protocol.
>
>
> 2. Section 3.2
>
> The example gives a swarming procedure. Does it possible for a peer to
> contact some remote peer directly if the connection history is
> available in its local cache? as it is common in most existing p2p
> applications (e.g. Skype).
> [Gu] Yes, it’s quite possible. Considering of this case, the first two
> steps in Figure should be optional.
>
Agree.
>
>
> 3. Do you consider using HTTPS after the first stage of connection? If
> you rely on HTTP to communicate at the first place, for security
> reasons it might be better to use HTTPS later. What do you think?
>
> [Gu] For security, HTTPs is better. However we need to consider the
> additional workload introduced by HTTPs. I do not oppose HTTPs, it’s
> not bad for standards to make a perfect protocol, but we should also
> take the implementation into consideration. We need to answer: do
> users care so much about privacy when they use P2P streaming? I hope
> we can hear more voice on this problem.
>

I agree that HTTPS may introduce additional workload. Besides, using
HTTPS here is not only for taking care of users' privacy but securing
the transmitted data and related mechanisms. As we measured Joost, it
relies on HTTPS to transmit data after authenticating users.

thanks

Jun
>
> Thank you again for reviewing and commenting.
>
> Best Regards
>
> Jun
>
>
>
> Hi all,
>
> The authors have updated the peer protocol draft. You can find it at
>
> http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-02.
>
> Any comments are welcome.
>
> Let’s have some discussion before meeting.
>
> Best Regards
>
> Yingjie
>
>  
>  
> _______________________________________________
> ppsp mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
>
>
> -- 
> Dr. Jun Lei
> Research Associate
>  
> Address:
> Georg-August-Universitaet Goettingen
> Institut fuer Informatik
> Computer Networks Group
> Goldschmidtstr. 7
> 37077 Goettingen 
>  
>  
> Fax: +49 (551) 39-1 44 03
> Tel: +49 (551) 39-1 35 78
>  
> Email: [email-masked] <mailto:[email-masked]>

-- 
Dr. Jun Lei
Research Associate

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Computer Networks Group
Goldschmidtstr. 7
37077 Goettingen 

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Wed, 06 Jul 2011 09:28:50 +0800

Hi Jun,

Do you mean that we use HTTPs for data transferring? According to the scope
of peer protocol, the peer protocol provides mechanism for transport
protocol negotiation, but itself doesn’t define how to transfer data. But I
think we need to designate a mandatory transport protocol.  

If you mean that HTTPs should be used for Peer connection, e.g. property
exchange and chunk availability exchange,  I think it’s reasonable to take
it into account.

  _____  

Best Regards
Gu Yingjie

发件人: [email-masked] [mailto:[email-masked]] 代表 jlei
发送时间: 2011年7月5日 乐乐22:27
收件人: [email-masked]
主题: [ppsp] Fwd: Re: New version of Peer protocol, looking forward to your
comments.

-------- Original-Nachricht -------- 

Betreff: 

Re: [ppsp] New version of Peer protocol,looking forward to your comments.

Datum: 

Tue, 05 Jul 2011 16:24:52 +0200

Von: 

jlei  <mailto:[email-masked]>
<[email-masked]>

An: 

Yingjie Gu(yingjie)  <mailto:[email-masked]> <[email-masked]>

Hi, Yingjie:

please see inline.

Hi Jun,

  _____  

Best Regards
Gu Yingjie

发件人: jlei [mailto:[email-masked]] 
发送时间: 2011年7月5日 乐乐14:57
收件人: Yingjie Gu(yingjie)
主题: Re: [ppsp] New version of Peer protocol,looking forward to your
comments.

Hi, Yingjie,

thanks for your effort.

1. section 4.2.1.3.1 

If FIND is sent from a peer to a Tracker, in which senario? as the peer
protocol is used to carry information to faciliate peering and data
exchange.
[Gu] I agree that my description is confusing.  When I design the Tracker
and peer protocol, I hope they could be  consistent, i.e. similar encoding
and some methods can be shared. FIND and FIND_CHUNK are the shared methods.
They have similar intention: to find the peers that can provide specific
content. If FIND is sent to Tracker, the requesting peer hopes that Tracker
can feedback with list of candidate peers. If FIND is sent to remote peer,
the requesting peer hopes that the remote peer can feedback with list of
candidate peers. You may find that the encoding of FIND in both Tracker and
Peer protocol is the same, except for the <Stats> part, which can also be
added to FIND message in Peer protocol.

I understand your intention here. However, it might be better to keep the
focus out of Tracker in this sense as you describe peer protocol. If you
emphasize the consistence, you could add the similarity for "FIND" or
"FIND_CHUNK" with tracker protocol. 

2. Section 3.2

The example gives a swarming procedure. Does it possible for a peer to
contact some remote peer directly if the connection history is available in
its local cache? as it is common in most existing p2p applications (e.g.
Skype).
[Gu] Yes, it’s quite possible. Considering of this case, the first two
steps in Figure should be optional. 

Agree.

3. Do you consider using HTTPS after the first stage of connection? If you
rely on HTTP to communicate at the first place, for security reasons it
might be better to use HTTPS later. What do you think?

[Gu] For security, HTTPs is better. However we need to consider the
additional workload introduced by HTTPs. I do not oppose HTTPs, it’s not
bad for standards to make a perfect protocol, but we should also take the
implementation into consideration. We need to answer: do users care so much
about privacy when they use P2P streaming? I hope we can hear more voice on
this problem. 

I agree that HTTPS may introduce additional workload. Besides, using HTTPS
here is not only for taking care of users' privacy but securing the
transmitted data and related mechanisms. As we measured Joost, it relies on
HTTPS to transmit data after authenticating users. 

thanks

Jun

Best Regards

Jun

Hi all,

Best Regards

Yingjie

 
[email-masked]

-- 
Dr. Jun Lei
Research Associate
 
Address:

-- 
Dr. Jun Lei
Research Associate
 
Address:

---

From: jlei <[email-masked]>
Date: Wed, 06 Jul 2011 03:48:29 +0200

Hello, Yingjie:

HTTPs, I mean, is used to exchange information (after the first access
control) to faciliate peer connection.

Yes, it is necessary to define at least one mandatory transport protocol
(in order to guarantee the data transfer).

thanks for your reply!

B.R.

Jun

> Hi Jun,
>
> Do you mean that we use HTTPs for data transferring? According to the
> scope of peer protocol, the peer protocol provides mechanism for
> transport protocol negotiation, but itself doesn’t define how to
> transfer data. But I think we need to designate a mandatory transport
> protocol.
>
> If you mean that HTTPs should be used for Peer connection, e.g.
> property exchange and chunk availability exchange, I think it’s
> reasonable to take it into account.
>
> *发件人:[email-masked] [mailto:[email-masked]] *代表 *jlei
> *发送时间:*2011年7月5日 乐乐22:27
> *收件人:[email-masked]
> *主题:*[ppsp] Fwd: Re: New version of Peer protocol, looking forward
> to your comments.
>
>
>
> *Betreff: ***
> *Datum: ***
> *Von: ***
> jlei <[email-masked]>
> <mailto:[email-masked]>
>
> *An: ***
>
> 	
>
> Yingjie Gu(yingjie) <[email-masked]> <mailto:[email-masked]>
>
>
>
> Hi, Yingjie:
>
> please see inline.
>
> Hi Jun,
>
> the focus out of Tracker in this sense as you describe peer protocol.
> If you emphasize the consistence, you could add the similarity for
> "FIND" or "FIND_CHUNK" with tracker protocol.
>
>
> 2. Section 3.2
>

-- 
Dr. Jun Lei
Research Associate

Address:

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 6 Jul 2011 09:50:09 +0800

Hi Yingjie and Jun,
   I am not sure HTTP is suitable for data transfer in streaming service. HTTP is based on TCP, who has been replaced by UDP in the leading P2P streaming providers because of the inefficiency.
   I am fine to designate a mandatory transport protocol in PPSP(although this will arise the discussion on re-chartering PPSP, if most of people think it's a reasonable step, why not do it?) in case that we have a detailed discussion on the transfer protocol selection.

BR
Yunfei

zhangyunfei
2011-07-06

发件人： Yingjie Gu(yingjie)
发送时间： 2011-07-06 09:26:48
收件人： 'jlei'; [email-masked]
抄送： 
主题： [ppsp] 答复: Fwd: Re: New version of Peer protocol, looking forward to your comments.

Hi Jun,
Do you mean that we use HTTPs for data transferring? According to the scope of peer protocol, the peer protocol provides mechanism for transport protocol negotiation, but itself doesn’t define how to transfer data. But I think we need to designate a mandatory transport protocol.  
 
If you mean that HTTPs should be used for Peer connection, e.g. property exchange and chunk availability exchange,  I think it’s reasonable to take it into account.

Best Regards
Gu Yingjie
 
发件人: [email-masked] [mailto:[email-masked]] 代表 jlei
发送时间: 2011年7月5日 乐乐22:27
收件人: [email-masked]
主题: [ppsp] Fwd: Re: New version of Peer protocol, looking forward to your comments.

-------- Original-Nachricht -------- 
Betreff: Re: [ppsp] New version of Peer protocol,looking forward to your comments.
Datum: Tue, 05 Jul 2011 16:24:52 +0200
Von: jlei <[email-masked]>
An: Yingjie Gu(yingjie) <[email-masked]>

Hi, Yingjie:

please see inline.

Hi Jun,

Best Regards
Gu Yingjie
 
发件人: jlei [mailto:[email-masked]] 
发送时间: 2011年7月5日 乐乐14:57
收件人: Yingjie Gu(yingjie)
主题: Re: [ppsp] New version of Peer protocol,looking forward to your comments.
 
Hi, Yingjie,

thanks for your effort.

1. section 4.2.1.3.1 

If FIND is sent from a peer to a Tracker, in which senario? as the peer protocol is used to carry information to faciliate peering and data exchange.
[Gu] I agree that my description is confusing.  When I design the Tracker and peer protocol, I hope they could be  consistent, i.e. similar encoding and some methods can be shared. FIND and FIND_CHUNK are the shared methods. They have similar intention: to find the peers that can provide specific content. If FIND is sent to Tracker, the requesting peer hopes that Tracker can feedback with list of candidate peers. If FIND is sent to remote peer, the requesting peer hopes that the remote peer can feedback with list of candidate peers. You may find that the encoding of FIND in both Tracker and Peer protocol is the same, except for the <Stats> part, which can also be added to FIND message in Peer protocol.
 
I understand your intention here. However, it might be better to keep the focus out of Tracker in this sense as you describe peer protocol. If you emphasize the consistence, you could add the similarity for "FIND" or "FIND_CHUNK" with tracker protocol. 

2. Section 3.2

The example gives a swarming procedure. Does it possible for a peer to contact some remote peer directly if the connection history is available in its local cache? as it is common in most existing p2p applications (e.g. Skype).
[Gu] Yes, it’s quite possible. Considering of this case, the first two steps in Figure should be optional. 
Agree.

3. Do you consider using HTTPS after the first stage of connection? If you rely on HTTP to communicate at the first place, for security reasons it might be better to use HTTPS later. What do you think?
 
[Gu] For security, HTTPs is better. However we need to consider the additional workload introduced by HTTPs. I do not oppose HTTPs, it’s not bad for standards to make a perfect protocol, but we should also take the implementation into consideration. We need to answer: do users care so much about privacy when they use P2P streaming? I hope we can hear more voice on this problem. 

I agree that HTTPS may introduce additional workload. Besides, using HTTPS here is not only for taking care of users' privacy but securing the transmitted data and related mechanisms. As we measured Joost, it relies on HTTPS to transmit data after authenticating users. 

thanks

Jun

Best Regards

Jun

Hi all,
 
Best Regards
Yingjie

-- 
Dr. Jun Lei
Research Associate
 
Address:

-- 
Dr. Jun Lei
Research Associate
 
Address: