Subject: [P2PSIP] FW: New version of draft-bryan-p2psip-reload

From: JiangXingFeng <[email-masked]>
Date: Wed, 18 Jun 2008 09:23:35 +0800

Hi:

I don't know what happened to the list. I posted comments but have not been
put on the list, despite Cullen received it and gave the response. So I
repost them again. 

Regards!
--
Jiang XingFeng
----Original Message-----
From: JiangXingFeng [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2008 4:22 PM
To: 'Cullen Jennings'; 'P2PSIP WG'
Cc: 'Salman Abdul Abdul Baset'
Subject: RE: [P2PSIP] New version of draft-bryan-p2psip-reload

Hi, 
Some comments on the new RELOAD-4. Hope it is helpful. 

1.connect: IMHO, the peer sending the connect request SHOULD check whether
the 
destination peer ID equals the peer ID it wants to connect or not when
receiving 
the response. But in some case, the peer may find a peer who is reponsible
for the 
requested Node ID, not the peer whose ID equals the request Node ID. For 
example, if a peer receives a UPDATE request and start to connect with the
peer 
in the routing table in the UPDATE reqeust. Maybe some peer is not alive or 
offline, in this case, the connect request will be directed to the peer
being 
responsbile for the Node ID. So suggestion is to check whether mismatch
happens. 

(Open Issue: do we need extend connect to distinguish connect for a resource
or 
for a peer? For example, if the resource value is so large that not be 
appropriate delivered through the overlay, a direct connection may be needed
for 
the future transfer.)

2.In section 1.2.4 When connections are made or broken, the Forwarding Layer

notifies the Topology Plugin, which adjusts the routing table as
appropriate.

To me, I am not clear how the RELOAD detects the connection has been broken 
down? Just relying on the STUN keepalive message or conclusion from failure
to 
deliver the packets to the next hop if the transport protocol is not
reliable, 
such as UDP? Why not use a keepalive mechansim at the peer layer to detect
the 
connection failure?

3.In section 6.1.1, the value for retransimisson time is set to 3 seconds? I

want to know based on what kinds of experimental data, the authors choose
the 
value? Is 3 seconds chosen as the maximum end-to-end latency? IMHO, the
latency 
of the transaction depends greatly on the number of hops requests will
traverse. 
So it will vary among overlays whose scale are different.

4. In section 3.3.1, some routing alternatives are listed. As for direct 
response and relay peer, I think they could be well used together with the 
symmetric routing proposed in RELOAD-04 although there are some limits with 
their use. For example, the original peer could convey its contact address 
and/or the chosen relay peer information to the destination in the request,
it's 
up to the destination peer to choose whether send the response in all ways
or 
only in a subset of ways. In this way, they could bring enhancement to the 
symmetric routing. 

As for routing in the overlay, my major concern is still the stablity of the

reverse connection due to the churn. In my mind, symmetric routing works
better 
where the hops for the request is not big and direct response and relay peer

could provide much help when the hops is big. I've done a few work on
comparing 
different routing modes listed in RELOAD-4 which has not finished yet. If
some 
data comes out, I will share them with the community. 

5. Data models in current RELOAD-4 are single value, array, dictionary. My 
suggestion is to use scalar, array and map which are borrowed from
literatures 
in data structure.

6. In section 4.2, it says the RELAOD has not defined a generic service 
discovery mechanism, but in section 9, a mechanism to discover TURN server
is 
defined. Does the RELOAD consider the TURN server as a special service? Why
not 
define a generic service discovery mechanism which also address the TURN
server 
discovery? 

7.         struct {
            ResourceId             resource;
            uint8                  replica_number;
            StoreKindData          kind_data<0..2^32-1>;   a IP packet could
not hold it. jiangxingfeng
        } StoreReq;

>From the above definition, the StoreReq consists of up to 2^32-1
StoreKindData, 
the scale of the array kind_data is too large to be possible put into a
single IP packet.

Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Cullen Jennings
> Sent: Wednesday, June 11, 2008 2:47 AM
> To: P2PSIP WG
> Cc: Salman Abdul Abdul Baset
> Subject: [P2PSIP] New version of draft-bryan-p2psip-reload
> 
> 
> We've just uploaded an update to the reload draft.  Until it shows up
> in the drafts directory, you can find it at
> 
>
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-
04.txt
> or
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-
04.html
> 
> reload-04 represents a total rewrite of the presentation of the
> protocol.  There were a number of goals:
> 
> - add several descriptive sections at the beginning that detail how
> the protocol works and the design choices we made (and some of the
> options we chose not to incorporate at this point)
> - Simplify the presentation (and protocol) wherever possible by
> removing extraneous features from this draft.  Some of these may come
> back in future drafts, but we felt simplifying wherever possible was
> good.
> - remove the bit-field diagrams from the protocol descriptions in
> favor of c-like message structure presentations.
> 
> We are very interested in comments on this draft.  We expect to have
> time for another revision in about 2 weeks.  We have tried to address
> as many of the comments and questions that have been raised as we
> can.  In some areas we have made deliberate choices to avoid adding
> features that have been requested.  Where possible we discuss the
> tradeoffs that adding additional features will require.  We think it's
> important for the working group to decide as a whole where additional
> features are worth the added complexity.
> 
> Please send your comments to the working group list - it would make it
> easier for us if people tried to keep separate issues in separate
> threads and start new threads where it appropriate. I think we would
> all like to hash out as many protocol issues as possible before we get
> to Dublin.
> 
> Cullen
> Bruce
> Eric
> Salman
> Henning
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

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