Subject: [ppsp] tickets for IETF 83

From: zhangyunfei <[email-masked]>
Date: Thu, 3 May 2012 16:12:38 +0800

Hi all,
    I have summarized an initial tickets list for IETF 83 meeting. Please review it and actions on these tickets are expected. Thanks.

BR
Yunfei &Stefano
-----------------------------------------------------------------------------------------------------------
Peer protocol:
Ticket #1：Post and discuss the alternative proposal besides MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff among complexity / overhead / efficiency / implementation) and check gaps. [Martin， Yunfei, Fabio, Lichun]
This ticket is partly solved. Simple nature number addressing and ranged expression on chunk availability. The analysis and comparison is ongoing. I'd suggest to have a deadline for the resolution time after discussing with Stefano, i.e.,  May 26th from now on to make the decision in the WG level.

Ticket #2：Discuss the possible “"state-building attacks" attack on peers.[Martin](related Proposal 26)
Martin, Do you still have concerns on this? If nobody shows up, we propose to close this ticket.

Ticket #3: Discuss the Membership certificates impact on the tracker’s workload.[Fabio](related to Proposal 17+20)

Tracker protocol:
Ticket#4: Specify the FIND use case and reduce the overhead to the tracker.[Martin,Yunfei，Fabio，Richardo]
Ticket#5: Discuss concrete use cases of additional messages if there are(e.g.,reconnect and rejoin) , and conclude the basic messages and optional ones in tracker protocol. [Mark, Fabio]
 We propose to the tracker protocol authors to address their tickets with a splitting of their proposal:
. base spec
. additional options.

Survey
Ticket#6: Call for reviewers for survey draft, and maybe P2P streaming providers’ contribution on updating the draft.   

zhangyunfei

---

From: Picconi Fabio <[email-masked]>
Date: Mon, 14 May 2012 14:04:38 +0200

Hi,
Somme comments:
Ticket #1 (chunk addressing mechanism). See my email send today.
Ticket #2. I can’t remember what this was about. :-)
Ticket #3 (secure PEX): I think that we can stick to a simple PEX mechanism that can be augmented by an optional secure algorithm. In addition to the solution proposed by Arno, there is a simple mechanism described by Jesi et al. [1].
Ticket #4 (FIND use case). I don’t recall exactly the details of this issue. If it’s only motivating a request to the tracker to find peers subject to attribute constraints, then finding peers with a similar upload capacity (to speed up the discovery phase) is already a good motivation.
Ticket #5 (additional messages). I think the proponents of these messages should describe the use cases where these messages can be useful.
Cheers,
Fabio
[1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Computer Networks, 2010.

From: [email-masked] [mailto:[email-masked]] On Behalf Of zhangyunfei
Sent: jeudi 3 mai 2012 10:13
To: ppsp
Subject: [ppsp] tickets for IETF 83

Hi all,

BR
Yunfei &Stefano

Tracker protocol:

Survey

________________________________
zhangyunfei

---

From: Arno Bakker <[email-masked]>
Date: Mon, 14 May 2012 14:37:43 +0200

Hi Fabio and all

On 14/05/2012 14:04, Picconi Fabio wrote:
>
> Ticket #3 (secure PEX): I think that we can stick to a simple PEX
> mechanism that can be augmented by an optional secure algorithm. In
> addition to the solution proposed by Arno, there is a simple mechanism
> described by Jesi et al. [1].
>

IMHO, leaving PEX unsecured will get us comments from the IESG. My 
proposal is actually compatible with Jesi, Montresor, van Steen (Maarten 
van Steen is my boss). My membership certificates correspond to their 
signed node descriptors. This mechanism alone will prevent the addresses 
of innocent hosts being spread. I add some extra security by exploiting 
the central tracker. They go fully decentralized by probing the graph 
for malicious structures.

CU,
     Arno

---

From: zhangyunfei <[email-masked]>
Date: Tue, 15 May 2012 11:01:37 +0800

Hi Fabio,
    Ticket #2 was what Martin proposed in Paris meeting. Martin, Do you still have concerns on this?

BR
Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp
Subject: RE: [ppsp] tickets for IETF 83
Hi,
Somme comments:

Hi all,
 
BR
Yunfei &Stefano

 
Tracker protocol:
 
Survey

zhangyunfei

---

From: zhangyunfei <[email-masked]>
Date: Tue, 15 May 2012 11:10:36 +0800

Hi Rui and Yingjie,
    Would you please confirm the ticket #4 for Paris meeting?
     For ticket #5, I am fine with Fabio's proposal.

BR
Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp

Hi all,
 
BR
Yunfei &Stefano

 
Tracker protocol:
 
Survey

zhangyunfei

---

From: zhangyunfei <[email-masked]>
Date: Tue, 15 May 2012 11:13:32 +0800

Hi Arno，
   I guess Fabio's concern is mainly on the extra burden evaluation on the tracker by the security mechanism in PEX.

zhangyunfei

From: Arno Bakker
Date: 2012-05-14 20:37
To: [email-masked]
Subject: Re: [ppsp] tickets for IETF 83
Hi Fabio and all

CU,
     Arno
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Rui Cruz <[email-masked]>
Date: Tue, 15 May 2012 11:59:48 +0100

Hi,

On Ticket #4: The FIND use case can perfectly be seen as Fabio described, i.e., "to find peers subject to attribute constraints" in order to speed up discovery, i.e., may be used in special situations only, therefore, the overhead to the tracker can be considered minimal.

On Ticket #5: The tracker protocol proposal is being split in a base specification and extensions. We do not see the need for "additional messages e.g.,reconnect and rejoin)" as this type of "action" is perfectly solved with the already proposed messages.  This is the case of the new semantic for the CONNECT message with implicit JOINs which behaves as a re-CONNECT with re-JOINs.

We would appreciate an advise from the chairs on splitting the tracker protocol proposal in a base specification and extensions. Should it be done with two different draft documents or with a single document where the extensions are clearly separate to an Annex??

Regards,

Rui Cruz
[email-masked]

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

On 15/05/2012, at 04:10, zhangyunfei wrote:

> Ticket #1：Post and discuss the alternative proposal besides MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff among complexity / overhead / efficiency / implementation) and check gaps. [Martin，Yunfei, Fabio, Lichun]

---

From: Picconi Fabio <[email-masked]>
Date: Tue, 15 May 2012 14:45:38 +0200

Indeed, I don’t think we should impose a security mechanism on the base protocol. There are existing systems that perform PEX without any security. Even the BitTorrent tracker allows you to spoof somebody and register them in the swarm.
There can be deployments where a secured PEX is not necessary (e.g., within a company).
In my view secure PEX can be left as an option.
Fabio

From: zhangyunfei [mailto:[email-masked]]
Sent: mardi 15 mai 2012 05:14
To: [email-masked]; ppsp; Picconi Fabio
Subject: Re: Re: [ppsp] tickets for IETF 83

Hi Arno，

From: Arno Bakker<mailto:[email-masked]>
Date: 2012-05-14 20:37
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [ppsp] tickets for IETF 83
Hi Fabio and all

CU,
     Arno
_______________________________________________
ppsp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ppsp

---

From: zhangyunfei <[email-masked]>
Date: Wed, 16 May 2012 09:40:56 +0800

Thanks Rui for the clarification. I would suggest to sperate the base specification and the extensions with two different drafts for two reasons:
1) It would be much easier to get consensus on the base draft since its scope is highly limited. In this way the progress will be earlier to achieve.
2) We see many similar operations in IETF drafts practices which may be proved to be an efficient way in IETF circle.

BR
Yunfei 

zhangyunfei

From: Rui Cruz
Date: 2012-05-15 18:59
To: ppsp
CC: Rui Cruz; Picconi Fabio; Yingjie Gu(yingjie); zhangyunfei ([email-masked])
Subject: Re: [ppsp] tickets for IETF 83
Hi,

Regards,

Rui Cruz
[email-masked]

Hi Rui and Yingjie,

BR
Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp

Hi all,
 
BR
Yunfei &Stefano

 
Tracker protocol:
 
Survey

zhangyunfei

---

From: Arno Bakker <[email-masked]>
Date: Wed, 16 May 2012 08:09:50 +0200

On 15/05/2012 14:45, Picconi Fabio wrote:
> Indeed, I don’t think we should impose a security mechanism on the base 
> protocol. There are existing systems that perform PEX without any 
> security. Even the BitTorrent tracker allows you to spoof somebody and 
> register them in the swarm.
> 

Hi

I agree that one must be able to turn it off, but in public networks one
MUST either turn PEX off or use a secure version, IMHO. Hence, a
secure version must be in the spec. I propose to use the membership
certs which correspond to the signed descriptors from literature.
We should then discuss how certification of peers can be done.

BitTorrent wasn't designed by professionals,  and it appears its PEX
feature is currently being exploited by anti-piracy outfits to attack
the health of swarms ;o)
http://yro.slashdot.org/story/12/05/13/1928215/microsoft-funded-startup-aims-to-kill-bittorrent-traffic

CU,
    Arno

---

From: stefano previdi <[email-masked]>
Date: Wed, 16 May 2012 10:28:01 +0200

> 2) We see many similar operations in IETF drafts practices which may be proved to be an efficient way in IETF circle.

yes, different drafts is the best choice so we can move them on 
autonomously from each other. The goal, at this stage, is to reach 
consensus on the base specification in a reasonable time.

Extensions will go in separate documentS (i.e.: we may need more 
than one extension document).

It's a common IETF practice with proven efficiency.

s.