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). It can forward the message by adding itself to the via-list as normal. Now an intermediate peer that was aware of DRR could know that adding itself to the via-list is unnecessary and not do it. But I think that should be left to the extension. 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. 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. Bruce > 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
