Subject: [P2PSIP] Direction on protocol selection

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Feb 2008 11:08:08 -0500

Quite a number of protocols have been merged, by their authors, into one
proposal (RELOAD/ASP/P2PSIP).  It seems to the chairs that this
indicates the beginning of consensus within the group on the direction
of the protocol.  The chairs invite list discussion, and will allocate
agenda time, to determining if in fact consensus exists.

There remain a number of protocols on the table, many of which have been
introduced later in the process.  The chairs invite discussion on the
list and will allocate a limited amount of agenda time for the
proponents of other protocols to show:
1. That their proposals have characteristics which make them more
attractive than the merged protocol 

2. That there exists some support within the working group beyond the
authors for the protocol

Selecting a draft to make WG item is important; we can't document
consensus until we have one. This doesn't mean everything in whatever
draft is adopted makes it to the final RFC -- the authors become scribes
of working group consensus.  If you have a proposal and *don't* want it
considered for the WG item, but think that it has a good idea you would
like in the RFC, we are open to you presenting on that issue. 

We emphasize that no decisions have been made.  There is ample
opportunity for discussion on the selection of the base protocol for our
work.  However, to meet our milestones, we must choose a document to
become the basis for a working group protocol RFC.  We must focus our
attention on this issue and make hard choices.  We invite your comments.

The Chairs
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 27 Feb 2008 17:52:38 +0100

> like in the RFC, we are open to you presenting on that issue. 

I think this is the case with XPP-PCAN and the "passive joins" approach
(nodes effectively become peers only when invited by actual peers blah
blah).  However, I'm not sure there is need for a presentation about
this, both because it is arguably more related to the DHT than the peer
protocol and because it is exactly what Skype does.

-- 
Ciao,
Enrico

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Feb 2008 09:04:40 -0800

Howdy,

At 8:08 AM -0800 2/27/08, Rosen, Brian wrote:

><snip>

>attractive than the merged protocol

If I can suggest a slightly different take on this question:

Are there proposals whose beneficial characteristics *cannot* be
merged with the Reload-et-al proposal?

Once a draft has been chosen as a working group draft, it is the basis
of further work.  There is no reason at the process level to prevent
incorporation of any beneficial characteristics from any existing proposal
into the working group draft at that point.  The key question is whether
the design choices made at some more fundamental level prevent
the incorporation, because the good bits lack the right fundamental
parts to work off.

We need to understand any of those issues now, before the fundamental
design choices circumscribe the field.  We don't need to know about
the beneficial characteristics that can be incorporated, as the working
group can consider those and support their inclusion at any time.

			regards,
				Ted

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 27 Feb 2008 16:54:28 -0500

Sure.

I just don't want to close the door quite yet to other protocols that
would make a better basis, although we clearly have some momentum
building.

Brian

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2008 12:05 PM
> To: Rosen, Brian; [email-masked]
> Subject: Re: [P2PSIP] Direction on protocol selection
> 
> Howdy,
> 
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 28 Feb 2008 04:13:51 -0800

The merger of the best protocol proposals is indeed the right procedure
for an accredited standards organization such as the IETF. As such, I
would like to add some specific items to a merged protocol proposal and
will take Reload-03 as a discussion example. We can then discuss item by
item.

1.      Naming the protocol

2.      Added key technical features need real write up

3.      An editor is required

4.      Discussing design decisions

1.      Naming the protocol

Reload-03 is already a nominal merger of about 5 other protocols and
more items may be added. In fairness, a new, neutral name is therefore
required. Why not call it P2PSIP-00?

2.      Added key technical features need real write-up

Reload-03 claims the notions of 

*         Selecting the DHT, (we like such as Bamboo, Chord and
Kademlia)

*         Defining a client protocol and 

*         The possibility of using HIP. 

*         Why not include the DHT AS A SERVICE as in the openDHT?

These claims must be backed up by meaningful text, definitions, etc.
mostly taken from P2PP, the two P2PSIP client I-Ds and HIP BONE and
there are probably more. Just make these claims real.

Contributors can write to the list what other key technical items should
be included in P2PSIP-00 and propose the text for the additional
section(s).

3.      An editor is required

All this work needs an editor to work with the contributors and include
the various contributions. An editor is also required to clean up the
present Reload-03 I-D, for such reasons as:

*         Remove the tutorial part and just reference some of the 1,000s
of papers on P2P and DHT.

*         Use common technical terms and avoid confusion. For example
the notion of P2P connection in the draft: I believe the writer meant
long hop neighbors and near neighbors (leaf set).  Also, routing state
means the routing table + the neighbor tables. If in doubt, the
Wikipedia and openDHT have very extensive text on this. 

4.      Discussing design decisions

*         Symmetric routing has been criticized on the list already, but
never discussed. It seems to me a bad idea (and I can argue why)

*         I would also like to understand for example why Via and GRUU
are proposed and exactly how it would work here

Especially via seems to duplicate SIP routing with the underlying DHT
routing - or does it? Please explain.

I believe a fair technical process is critical to a successful P2PSIP
and to avoid having winners and losers and unhappy campers who feel they
may better ignore this emerging standard.

What do you think of these items?

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rosen, Brian
Sent: Wednesday, February 27, 2008 10:08 AM
To: [email-masked]
Subject: [P2PSIP] Direction on protocol selection

authors for the protocol

The Chairs

P2PSIP mailing list

[email-masked]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 28 Feb 2008 12:05:47 -0600

It would also be good for people to look at Reload-et-al and see whether 
they have application scenarios that can't be met with this proposal.

We haven't had a meaningful discussion of the application scenarios draft, 
which is fine, but if there are scenarios in 
http://www.p2psip.org/drafts/draft-bryan-p2psip-app-scenarios-00.txt that 
you care about, and Reload-et-al doesn't work for them, this would be a 
great time to say so.

For instance, I've seen postings from Dean that talked about overlays that 
were large enough that (1) signaling routing efficiency mattered, and (2) 
media path efficiency mattered. This would be a great example of something 
to look at in Reload-et-al, and say "no problem", or "we need to talk". The 
relevant scenarios are probably 4.1.1 and 4.1.2 in 
http://www.p2psip.org/drafts/draft-bryan-p2psip-app-scenarios-00.txt.

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 28 Feb 2008 10:48:15 -0800

Hi Henry,

Wanted to comment on these - ran of of time before meeting for all of  
them but hope to get back to them later.

On Feb 28, 2008, at 4:13 AM, Henry Sinnreich wrote:

> more items may be added. In fairness, a new, neutral name is  
> therefore required. Why not call it P2PSIP-00?

I would certainly be happy to see if we could find a better name.   I  
don't know what the right name is but I think it should be associated  
with peer to peer. I'd love to get the a list possible names then just  
select one of the mailing list. I'd be fine with P2PSIP. (Part of the  
current naming had to do with we really needed the extra week between  
the 00 and non 00 draft deadline).

> ·         Selecting the DHT, (we like such as Bamboo, Chord and  
> Kademlia)
> ·         Defining a client protocol and
> ·         The possibility of using HIP.
> ·         Why not include the DHT AS A SERVICE as in the openDHT?
>

I think that someone will do this but it would be a storage usage on  
top of reload. I think it is better done as a separate document. I'd  
be glad to help if someone wanted to write such a usage. On a related  
note, Phillip is already working on a nice id/locator split document  
that could provide as a RELOAD usage an generic routing layer for  
applications that were non P2P aware.

Cullen <with my individual contributor hat on>

---

From: [email-masked]
Date: Thu, 28 Feb 2008 13:50:30 -0500 (EST)

Hi Henry,

> 3.      An editor is required

Ultimately, the chairs may decide that an editor is appropriate, but
certainly we're willing to continue to do the work.

> of papers on P2P and DHT.

I think it's a really tough call how much tutorial should be in here and
how much should be somewhere else.  You're right that we should have
informative references to a few more papers (there have been more in some
prior drafts), but that doesn't serve the same purpose as the conceptual
overview.  Our goal has been to make the draft reasonably stand-alone, so
that it could be given to a network engineer who is implementing the
protocol and they can understand the key concepts.  Sure, I like reading
the Kademlia paper in raw form, and I actually have a copy of Rhea's
dissertation on my desktop right now, but I don't want a programmer to
have to understand it from that source.

> Wikipedia and openDHT have very extensive text on this.

Again, this is a hard line to follow.  We're trying to use terminology
from p2psip-concepts and use terminology that will be consistent with the
rest of IETF practice.  While we try to use terminology from the
literature when appropriate, it isn't always there, it may conflict with
other ietf terminology, and it isn't always consistent.  But if you have
terminology you think we should be using, by all means bring it up as a
suggestions for the concepts document.

Regarding the connection, in particular, I think the term you are
referring to has more to do with the establishment of a link between two
peers (forming an edge in the overlay network) and use of that term in the
draft dates back to p2psip-dsip-nat-traversal that Eric, Philip, David,
and I worked on.  The discussion of what the connection table is may not
have carried forward as well, though...

> 4.      Discussing design decisions

Obviously these technical decisions will continue to be rehashed by the
group once a protocol document is adopted, but many have been discussed
extensively on list.

> never discussed. It seems to me a bad idea (and I can argue why)

Please refer to the "Routing mode in P2PSIP" thread from November 20-26,
2007.  Other forms of routing can be used as an optimization in many
circumstances, but it's complicated to determine when they can be used. 
Symmetric is needed for overlay healing and nat traversal situations.  I
think there is still room to say more on this topic, though, and the
decision of efficiency vs complexity is always a tough one.

> routing - or does it? Please explain.

The via list concept is key to allowing client nodes to participate and to
reduce the state required of peers when performing symmetric routing.  If
you were to route SIP messages across the DHT, I wouldn't expect overlap
because the peers wouldn't be modifying the SIP message, they'd be
modifying the peer protocol message.

You're right that this concept still needs more explanation and examples.

> may better ignore this emerging standard.

I'm sure I speak for all the authors when I say that we're very interested
in receiving any technical criticism or suggestions that will make this a
successful protocol.

Bruce