Hi Guys, I am not sure I understand your points. I would like to describe again the DRR proposal in draft-jiang-p2psip-relay-04 and explain the status keeping flag.
The DRR proposal proposes to add a new forwarding option for an extensive routing mode that will supply the information that will allow the destination peer to connect directly back to the requestor to establish a DRR mode. So this still allows the receiver to use SRR if it does not support DRR. Note that the new forwarding option must include all the information needed to support the DRR or Relay mode. The issue with the state keeping flag in my view is to try to address the issue where according to the base draft as describe at the figure at the end of section 3.3 where the intermediary node keep the state of the via list expecting the response to go back via itself, note that the flag only recommends to the intermediary that it may not be useful to change the via list but it does not change the via list. If DRR is preferred, the flag means that it is not required to keep state. On the other hand I think that the solution will work even without the flag since there is timeout for the response, the intermediary will delete the state after the timeout but having the flag will make it cleaner. Regards Roni Even > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Eric Rescorla > Sent: Wednesday, February 09, 2011 3:12 AM > To: Cullen Jennings > Cc: P2PSIP WG; Roni Even > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > > On Feb 8, 2011, at 3:48 PM, Cullen Jennings wrote: > > > > > On the topic of a flag to not keep state... just having a flag won't > work. It has to be an overlay option because all the nodes in the > overlay need to support it. Once you have it as an overlay option, you > don't need it in the base spec. I just don't see any reason to put it > in the base spec - it can be done in extension just as well - and I see > lots of reasons not to but it in the base spec. We don't really know > how to make this work well yet. Ideally it would be an optimization you > used when you could so that a client could still connect to a peer that > would do state and do the DDR for it. Saying something like the flag > indicates don't keep state breaks clients among other things. You would > need the option to be a little more nuanced than that. I think we > should define all of this in the DDR draft - trying to guess what we > need before we know what we are doing is likely to result in getting it > wrong. > > > > > I don't think this is quite right: the issue isn't really whether all > nodes in the overlay support it but rather whether > they support DRR. > > Here's my reasoning: a requester who uses this option is basically > committing to only receiving responses via DRR, > since the Via List will not be unwindable by the responder. However, > because a requester has no real a priori way > of knowing a responder's capability this means that any node in the > overlay must already support DRR because > otherwise any intermediate or terminal node has no way of responding to > the request. So, this extension is > only useful in an overlay in which everyone supports DRR; where it's > basically a way of indicating "use DRR only" > and telling intermediaries they don't need to store state. > > However, with that said, it seems to me that the forward compatibility > issue goes away: if we do decide to use this > flag to enable DRR, then all the nodes in the overlay will have to be > DRR-capable, at which point we can define > this extension or similar at the time we define DRR. > > So while I had originally edited this extension into the draft, I have > now concluded we should remove it after > all. > > Best, > -Ekr > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
