On Feb 8, 2011, at 6:42 PM, Bruce Lowekamp wrote: > On Tue, Feb 8, 2011 at 8:11 PM, Eric Rescorla <[email protected]> wrote: >> >> 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. >> > > I don't think this is what is proposed here. DRR requires the sender > and receiver to support it. The no-state flag simply indicates that > the intermediate peer should not keep internal state (i.e. use a > compressed id, etc).
Right now, there isn't a no-state flag, so I think what it indicates is what's at question here. The no-state flag in the version I checked in meant that there was not going to be a response and so no state should be kept of any kind. > It can forward the message by adding itself to > the via-list as normal. I'm not sure this is "normal". It's one of several options, that as far as I know of have no preference ranking in the draft. I'm very uncomfortable with creating a flag that affects only one mechanism for symmetric return routing. > And for DRR, in particular, the nodes need to be prepared for the > response to be dropped regardless of whether they both support the > extension, so presumably any such extension would specify a fallback > to normal routing on retransmissions of the original request. > Really? Why would you think that? All sorts of things can go wrong that don't indicate that reverse routing is the problem. > Certainly we need a draft that fully specifies DRR and eventually > other routing options. But I don't believe it's true that all nodes > need to support it. On the contrary, if we don't have the flag then > all nodes (at least routing peers) would need to support DRR, but if > we do have the flag then DRR can be implemented to work between any > two nodes that support it. With no discovery mechanism, I don't see how this is useful, which is why the DRR mechanism we just removed required universal support in the overlay. -Ekr >> 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
