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

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Jun 2008 07:39:25 -0700

Great comments - thanks - more inline

On Jun 17, 2008, at 1:22 AM, JiangXingFeng wrote:

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

Good point - I'm not really sure what to do here. I can see the use  
case you are making for connects to an ID that is different than the  
id of the node that ends up connecting. The only way I see to allow  
that is to remove the check but I'd have to think about if this breaks  
anything.

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

Yes, I agree some sort of keep alive is needed to detect liveness on  
these connection. We also need to be able to deal with receiving a TCP  
RST for the TLS connections.

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

Agreed - the 3 seconds is largely a number pulled out of thin air but  
it was chosen around the SIP application. If the overlay is taking  
longer than 3 seconds, the user may not be willing to wait for the  
resulting post dial delay. So the time came from more what was  
required than what I expected the overlay to be able to provide. This  
time could be made a configuration parameter of the overlay if folks  
felt that was important.

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

I suspect this is an important topic worth of it's own thread. I look  
forward to seeing your work and I hope this is the sort of thing we  
end up getting time in the WG meetings to talk about because it is  
important. My main concern with all these is that the routing works  
well enough that two partitioned networks that each have a ring  can  
successfully merge back together.  Any scheme where that does not  
allow this would seem somewhat broken to me.

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

This would be fine with me - but the terms have been changed so much  
at times I'd rather have enough agreement on them that I did not end  
up changing them back and forth all the time. So other folks, let us  
know if you like these terms and we can change them.

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

Over time I believe there will be a variety of service discovery  
algorithm defined ranging from simple to complex and optimized for  
various things. The base draft requires ICE with TURN and I wanted to  
make sure that draft had at least a minimal way of doing all the  
things required for the base draft. Because of that there is a pretty  
naive algorithm for TURN discovery. It would certainly not be the best  
we could do so we did not want to over sell it's functionality.

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

Well, I'm going to blame some other author on the 2^32 :-) but  
seriously this is allowed to be much larger than the IP MTU. The  
transport will need to deal with fragmenting and sending this. Clearly  
TCP already does this and in the case of UDP, reload provides  
fragmentation. There is not too much on that yet as it's fairly well  
understood how to do it and we just need to go add text and work with  
the transport folks on getting it right.

> Regards!

Once again, thanks for the careful read

Cullen (send in my individual contributor role)

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

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 18 Jun 2008 15:13:19 -0400

> that is to remove the check but I'd have to think about if this breaks  

Establishing a direct connection before transferring a large resource is 
clearly pretty important and useful.  I think you've hit on a good point 
and the exact mechanism for doing so may need a little more thought.

> RST for the TLS connections.

Why should the keepalive be at the peer layer rather than using STUN? 
It seems like that mechanism is well-understood and lightweight.  Now 
detecting failure is a slightly different question (and very hard, in 
general), but in general it seems to me that the stun keepalives solve 
this.

(You're right that the draft doesn't say that you should be using STUN 
keepalives over TCP/TLS.  But assuming it did, do you think it needs 
something else at the peer layer?)

Bruce