Subject: [P2PSIP] more draft-baset-p2psip-p2pcommon-01 questions

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 7 May 2007 15:54:36 +0200

some observations on the draft:

TLV structure

It is not quite clear from the text if TLV objects (eg Peer-ID)are nested. I guess they are,
but it should mentioned somewhere.

7.3.1.1 Address-Info
This object describes a single ip-address/port pair. Why does it contain a number
of gathered 4-tuples of address, port, transport, address type? Can this object
appear more than once? Where's the transport field?

Maybe this is clear to somebody who knows his ICE, but some clarifications would
be helpful.

7.3.3 P2P-Options
This object carries an overlayID-len field. Isn't this redundant?

Wolfgang Beck

--
T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*,
Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 8 May 2007 10:38:58 -0400 (EDT)

Inline.

> but it should mentioned somewhere.

Yes, it is indeed among the many clarifications marked for the next
version.

> Maybe this is clear to somebody who knows his ICE, but some clarifications would

I agree that we should describe this in more detail.

> This object carries an overlayID-len field. Isn't this redundant?

Overlay-ID is the only variable length field in P2P-Options so far, so in
that sense you can say it is redundant. However, we still have not
discounted the possibility of adding other (variable size) fields to
P2P-Options and hence the length field for overlay-ID.

Regards,
Salman

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Wed, 9 May 2007 11:13:20 +0200

> Overlay-ID is the only variable length field in P2P-Options 
> so far, so in that sense you can say it is redundant. 
> However, we still have not discounted the possibility of 
> adding other (variable size) fields to P2P-Options and hence 
> the length field for overlay-ID.
I see. The 'num entries' field in the Routing-Table and Neighbor-Table 
objects is required for the same reason?

I've an issue with the format of Peer-ID. The draft has this wording
'If the Algorithm-Len field queried at join is zero, a length field
of 16 bits MUST be present before Peer-ID.'

Is it really necessary to have two separate ways to express the
algorithm-length; either at Join or later? Are there any P2P-Algorithms
that don't know their Peer-ID length at the time of Join? We should
really avoid all that accidental complexity that plagues SIP today.

For the same reason UDP should be dropped. Thanks to the Common Header,
TCP framing is easy. UDP doesn't relieve the client form maintaining
session state, it just pushes the load to user space. In SIP, we ended
up with cases where implementations have to switch from UDP to TCP.

7.4
The Error object usage is not clear. Where do I put the Error codes
that are mentioned in 7.4.2?

8. API
'An application using peer-to-peer protocol issues non-blocking calls
to P2PP layer to accomplish the following operations'. This needs some
elaboration. How can an application decide when and how an operation
has finished?

Wolfgang

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 9 May 2007 14:02:27 -0400 (EDT)

> really avoid all that accidental complexity that plagues SIP today.

This was done so that P2PP can potentially be used to implement an
unstructured p2p protocol for which Peer-ID may not be of fixed length.
The draft addresses one way to accomplish this. There are other approaches
such as having a default Peer-ID for unstructured networks and use the
'Unhashed-ID' TLV object to convey the information. I agree that
converying peer-IDs for unstructured networks require more consideration.

> up with cases where implementations have to switch from UDP to TCP.

I agree that UDP is an issue but consider the case of iterative routing,
where the node issuing the query has control over the traversed nodes. It
will be a performance hit for the node issuing the query to establish a
TCP connection with every node in an iterative mode.

> that are mentioned in 7.4.2?

The error codes are essentially response codes and they should be put in
the response common header. Sorry for the confusion.

> elaboration. How can an application decide when and how an operation

Indeed. The description should clearly say that there is a call-back
function mechanism. This needs to be updated in the draft.

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Thu, 10 May 2007 10:00:58 +0200

> > algorithm-length; either at Join or later? Are there any 
> > P2P-Algorithms that don't know their Peer-ID length at the time of 
> > Join? We should really avoid all that accidental complexity that 
> > plagues SIP today.
> 
> This was done so that P2PP can potentially be used to 
> implement an unstructured p2p protocol for which Peer-ID may 
> not be of fixed length.
OK, this makes sense. Can we put a statement into the draft, like
"For P2P algorithms with a fixed-length Peer-ID, the field
Algorithm-Length of the P2P-Options object MUST contain that length.
For P2P algorithms with a variable-length Peer-ID, the field
Algorithm-Length of the P2P-Options object MUST be 0 and the Peer-ID
MUST have the format  | 16 bit length | ID |."?

So, if my implementation only supports a p2p algorithm
with fixed-length peer-id, I don't need handle two formats of
Peer-ID.

> > [first charge in the inevitable UDP/TCP battle]
> I agree that UDP is an issue but consider the case of 
> iterative routing, where the node issuing the query has 
> control over the traversed nodes. It will be a performance 
> hit for the node issuing the query to establish a TCP 
> connection with every node in an iterative mode.
I am concerned about implementation complexity. TCP is a
highly optimized part of the OS. With UDP, you have to implement
your own retransmission and message segmentation mechanisms
(413 Message too large) or switch to TCP, combining the worst of
both worlds.

The only advantage of UDP is, that it gives you better control
over timeouts in case the remote party doesn't answer at all.

Perhaps this should be a per P2P algorithm decision, in a table
like (just illustrative)

Algorithm    | Peer-ID variable? | iterative 
Alfachord             n                UDP
Betakademlia          n                TCP
Gammabamboo           y                 n 
..

This would limit the number of options an implementation of a certain
P2P-Algorithm has to support.

> The error codes are essentially response codes and they 
> should be put in the response common header. Sorry for the confusion.
Oops, I overlooked the response code in that header.

Wolfgang

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 11 May 2007 17:05:09 -0400 (EDT)

> MUST have the format  | 16 bit length | ID |."?

I will add the statement further clarifying this.

> with fixed-length peer-id, I don't need handle two formats of

Yes, if your implementation only supports fixed-length Peer-ID, you do not
need to handle two formats of Peer-ID.

> Algorithm    | Peer-ID variable? | iterative

The choice of iterative vs. recursive routing is independent of the DHT
algorithm being used. I agree that a table will help clearly state the
issues of DHT-specific and DHT-independent mechanisms.