Subject: [ppsp] Look forward to hear your opinion on Open Issues in Tracker Protocol

From: "Y.J. GU" <[email-masked]>
Date: Wed, 16 Feb 2011 09:50:23 +0800

Hi all,

At IETF 79 meeting, we discussed some open issues in Tracker protocol. However, because of time limitation, we don't have enough discussion to make any decision on some of the most important issues. The authors of draft-gu-ppsp-tracker-protocol and draft-gu-ppsp-peer-protocol enumerate two of the open issues, which they think are very crucial to both Tracker and Peer Protocol design.

We sincerely hope you can voice your opinion on these two issues to help us make concrete progress in Protocol design. There are more other issues, and we will discuss them after the circle of discussion.

1)  Tracker protocol encoding, text or binary? At last meeting, David suggested to consider easy-reading encoding, like XML. I think it's reasonable. What's other persons' opinion? 

    Lars suggests to make peer protocol to be similar to tracker protocol. So I guess the encoding decision we make will influence both protocols.

2)  IP Address or PeerID for ID/NAT Traversal? Similarly, the decision on this issue will apply to both Tracker and Peer Protocol. If using PeerID for NAT Traversal, we can reuse NAT Traversal mechanism described in P2PSIP; if using IP Address, we can use ICE, with additional functionality deployed on Tracker and/or peers. 

Any comments are highly appreciated.

BR

Yingjie Gu

---

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Fri, 18 Feb 2011 15:20:37 +0800

Hi Yingjie,
 
Some comments in line.
 
Br
Lin
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Y.J. GU
Sent: Wednesday, February 16, 2011 9:50 AM
To: [email-masked]
Subject: [ppsp] Look forward to hear your opinion on Open Issues in
TrackerProtocol

Hi all,

At IETF 79 meeting, we discussed some open issues in Tracker protocol.
However, because of time limitation, we don't have enough discussion to
make any decision on some of the most important issues. The authors of
draft-gu-ppsp-tracker-protocol and draft-gu-ppsp-peer-protocol enumerate
two of the open issues, which they think are very crucial to both
Tracker and Peer Protocol design.

We sincerely hope you can voice your opinion on these two issues to help
us make concrete progress in Protocol design. There are more other
issues, and we will discuss them after the circle of discussion.

1)  Tracker protocol encoding, text or binary? At last meeting, David
suggested to consider easy-reading encoding, like XML. I think it's
reasonable. What's other persons' opinion? 

    Lars suggests to make peer protocol to be similar to tracker
protocol. So I guess the encoding decision we make will influence both
protocols. 

[lin]: It's not a big issue. Both ways can work. If I must make a
choice, I prefer text based. It's true that no matter which way to
choose, both tracker protocol and peer protocol should follow to keep
the same style.

2)  IP Address or PeerID for ID/NAT Traversal? Similarly, the decision
on this issue will apply to both Tracker and Peer Protocol. If using
PeerID for NAT Traversal, we can reuse NAT Traversal mechanism described
in P2PSIP; if using IP Address, we can use ICE, with additional
functionality deployed on Tracker and/or peers. 

 [lin]: Do we really need to touch the NAT traversal issue in PPSP?
IMHO, PPSP is to define request/reply protocols (like HTTP) for
communication between peers and tracker, and among peers. It's not a
protocol for constructing a overlay network by connecting nodes like
P2PSIP. So, we just need to define the message format and procedure
between nodes, but don't care how these two nodes connected. Either
Reload or pure ICE should work below the layer of PPSP. 

For me, Both Peer ID and IP address should be supported in PPSP, not
only for NAT traversal. Peer ID is the identity for a peer, IP is the
locator in current IP network. With the mobility of a node, its IP may
change, but the Peer ID is kept unchanged for consistency. For NAT
traversal, Reload actually also use modified ICE. So, even if we use
Reload message for NAT traversal, it does not mean the nodes should be
organized and located by Reload. We'd better de-couple the ppsp with the
overlay connection method.

BR

Yingjie Gu

---

From: "Lei, Jun" <[email-masked]>
Date: Fri, 18 Feb 2011 19:29:18 +0100

Hi, Yingjie and all,

please see inline.

============================================
Dr. Jun Lei
Research Associate

Address:
Georg-August-Universitaet Goettingen
Institut für Informatik
Computer Networks Group
Goldschmidtstr. 7
37077 Göttingen
Germany

Fax: +49 (551) 39-1 44 03
Tel: +49 (6221) 32-77091

Email: [email-masked]

-----Original Message-----
From: [email-masked] on behalf of Y.J. GU
Sent: Wed 2/16/2011 2:50
To: [email-masked]
Subject: [ppsp] Look forward to hear your opinion on Open Issues in
TrackerProtocol
 
Hi all,

At IETF 79 meeting, we discussed some open issues in Tracker protocol.
However, because of time limitation, we don't have enough discussion to make
any decision on some of the most important issues. The authors of
draft-gu-ppsp-tracker-protocol and draft-gu-ppsp-peer-protocol enumerate two
of the open issues, which they think are very crucial to both Tracker and
Peer Protocol design.

We sincerely hope you can voice your opinion on these two issues to help us
make concrete progress in Protocol design. There are more other issues, and
we will discuss them after the circle of discussion.

    Lars suggests to make peer protocol to be similar to tracker protocol. So
I guess the encoding decision we make will influence both protocols.
 
[Jun] I would agree that it is reasonable and common to use plain-text based
encoding, like XML.

2)  IP Address or PeerID for ID/NAT Traversal? Similarly, the decision on
this issue will apply to both Tracker and Peer Protocol. If using PeerID for
NAT Traversal, we can reuse NAT Traversal mechanism described in P2PSIP; if
using IP Address, we can use ICE, with additional functionality deployed on
Tracker and/or peers. 

[Jun] I would say it might not necessary to put the focus on this issue as we
can rely on existing technologies to solve it. We can leave it to specific
implementation. 

BR

Yingjie Gu

---

From: [email-masked]
Date: Mon, 21 Feb 2011 09:42:17 +0800

Hi Yingjie and all,

    For the first issue, I think human readable format like XML
may be better.

    For the second issue, I agree with Lin. We may not touch the NAT
issue here. But, we should provide flexibility in the tracker/peer
protocol design, so that necessary information for different solutions
could be transferred. For example, maybe both PeerID and IP addresses
(of different types) cloud be used as Peer identities in the peer list. 

Best Regards
Wei

> Hi all,
> At IETF 79 meeting, we discussed some open issues in Tracker 
> protocol. However, because of time limitation, we don't have enough 
> discussion to make any decision on some of the most important 
> issues. The authors of draft-gu-ppsp-tracker-protocol and draft-gu-
> ppsp-peer-protocol enumerate two of the open issues, which they 
> think are very crucial to both Tracker and Peer Protocol design.
> We sincerely hope you can voice your opinion on these two issues to 
> help us make concrete progress in Protocol design. There are more 
> other issues, and we will discuss them after the circle of discussion.
> 
> 1)  Tracker protocol encoding, text or binary? At last meeting, 
> David suggested to consider easy-reading encoding, like XML. I think
> it's reasonable. What's other persons' opinion? 
> protocol. So I guess the encoding decision we make will influence 
> both protocols. 
> 
> choose, both tracker protocol and peer protocol should follow to 
> keep the same style.
> 
> 
> 2)  IP Address or PeerID for ID/NAT Traversal? Similarly, the 
> decision on this issue will apply to both Tracker and Peer Protocol.
> If using PeerID for NAT Traversal, we can reuse NAT Traversal 
> mechanism described in P2PSIP; if using IP Address, we can use ICE, 
> with additional functionality deployed on Tracker and/or peers. 
> 
> only for NAT traversal. Peer ID is the identity for a peer, IP is 
> the locator in current IP network. With the mobility of a node, its 
> IP may change, but the Peer ID is kept unchanged for consistency. 
> For NAT traversal, Reload actually also use modified ICE. So, even 
> if we use Reload message for NAT traversal, it does not mean the 
> nodes should be organized and located by Reload. We'd better de-
> couple the ppsp with the overlay connection method.
> 
> 
> Yingjie Gu_______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

--------------------------------------------------------
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: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Mon, 21 Feb 2011 10:46:51 +0800

Thanks Lin, Jun and Wei for your comments.

Could you please voice your considerations for choosing Text-based encoding? I guess there might be persons who prefer Binary encoding, e.g. for mobile peers. So we need to consider the pros and cons of both. 

Hope to hear others’ opinion too.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 21, 2011 9:42 AM
To: ext Y.J. GU
Cc: [email-masked]
Subject: 答复: Re: [ppsp] Look forward to hear your opinion on Open Issues in TrackerProtocol

Hi Yingjie and all, 

Best Regards 
Wei

---

From: [email-masked]
Date: Tue, 22 Feb 2011 11:30:51 +0800

Hi Yingjie，

    IMHO, Http/XML is more preferable for the following reasons: 

1. Http/XML is widely used for application protocol development. Existing 
protocol stacks
and libraries would greatly reduce development cost for both the tracker 
and peer. 
It is also very flexible and easy to extend.

2. If we adopt the REST architecture, we can reuse many deployed 
infrastructures such as
proxies and web caches. In this case, we may use http GET, instead of POST 
(as suggested
in the tracker protocol), for operations that do not change the 
"resources" on the tracker.
Messages such as FIND or STAT_Query could then be cached to reduce the 
burden of the tracker.

   I agree with you that binary encoding is more efficient than text based 
encoding. However
the bandwidth consumption of control message is very small compared to the 
streaming data. 
Moreover, it is likely that operators would provide a unified 
infrastructure for http compression
over the wireless link for mobile peers, when http flows become a burden 
for wireless links.
If we use http/xml, then we can again reuse the existing solutions for 
mobile users. 

Best Regards
Wei 

"Yingjie Gu(yingjie)" <[email-masked]> 写于 2011-02-21 10:46:51:

> Could you please voice your considerations for choosing Text-based 
> encoding? I guess there might be persons who prefer Binary encoding,
> e.g. for mobile peers. So we need to consider the pros and cons of both. 

> 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.