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 PROTECTED] [mailto:[EMAIL PROTECTED] 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 protected]
>> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
