EKR, I am not sure why the flag does not work for symmetric return, state keeping by intermediaries is optional according to section 3.3 and is not required for it to work.
Roni > -----Original Message----- > From: Eric Rescorla [mailto:[email protected]] > Sent: Wednesday, February 09, 2011 7:20 PM > To: Roni Even > Cc: 'Cullen Jennings'; 'P2PSIP WG' > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > Yes, I understand this argument. > > My point is that you need to make symmetric return routing work in any > case, > which means you need to do whatever you do to the via list to make that > work, so that this flag doesn't work. > > -Ekr > > On Feb 9, 2011, at 1:43 AM, Roni Even wrote: > > > 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
