I think I would be most happy with your suggestion: > There's another option where we add a ForwardingOptions flag to the > base draft that specifies not to keep state about the message, but > isn't explicitly a DRR flag. There might even be a benefit to doing > that, in that it wouldn't be explicitly tied to the DRR mechanism in > there now.
I think this is exactly what I would like to see. My concern with the present routing mechanism is it is a bit underspecified, and also that if we later flesh out a more detailed one, there will be confusion. I definitely don't want to remove the routing stuff completely -- we clearly need the flags -- but think the current attempt at using it for direct routing is a bit underspecified. I'd rather remove it (leaving the mechanism) so we can get the next version out with as few changes as possible, and get RELOAD published so we can move on to other work. David (as individual) On Thu, Dec 2, 2010 at 1:53 PM, Bruce Lowekamp <[email protected]> wrote: > The motivation for putting it into the base draft was that if it is > part of the base spec, then in the future nodes that implement > whatever is specified in the relay/DRR draft can make use of those > techniques while on an overlay with nodes that only implement the base > draft. For example: > > - any sort of relay/DRR requires intermediate nodes to not keep any > state about routed messages. If support for the routing flag that > allows this is not in the base draft, they will have to simply reject > the message. > - knowledge of how to set up a relay node isn't required to make use > of the relay node. > > The intention of the current text was that it could currently only be > used with no-ice. But it would provide support so that nodes that > only implement the base draft would be able to forward messages using > relay/DRR and would also be able to send messages to a relay node in > the future without knowing the details of how that is set up. As > currently specified, it definitely needs some text stating explicitly > that it can currently only be used with no-ice. > > There's another option where we add a ForwardingOptions flag to the > base draft that specifies not to keep state about the message, but > isn't explicitly a DRR flag. There might even be a benefit to doing > that, in that it wouldn't be explicitly tied to the DRR mechanism in > there now. > > Or , of course, we can remove it completely, at the cost that base > nodes won't be compatible with whatever is done in the relay/DRR > draft. > > Bruce > > > On Tue, Nov 30, 2010 at 8:03 AM, David A. Bryan <[email protected]> wrote: >> I also think the current text is too limiting. The best approach is to >> make it clear in the draft that other routing techniques are allowed >> and supported, leave in the flags but remove the very skeletal direct >> response routing from this draft and we instead do that in the >> relay/direct response draft. >> >> David (as individual) >> >> On Sun, Nov 21, 2010 at 3:04 AM, Roni Even <[email protected]> wrote: >>> >>>> >>>> Direct Response Routing and ICE >>>> • Specified in §5.3.2.4 >>>> This option can only be used if the direct-return-response-permitted >>>> flag in the configuration for the overlay is set to TRUE. The >>>> RESPONSE_COPY flag SHOULD be set to false while the FORWARD_CRITICAL >>>> and DESTINATION_CRITICAL MUST be set to true. When a node that >>>> supports this forwarding options receives a request with it, it acts >>>> as if it had send an Attach request to the the requesting_node and it >>>> had received the connection_information in the answer. This causes it >>>> to form a new connection directly to that node. >>>> • This doesn’t work with ICE because the sender of the request doesn’t >>>> have your information >>>> Proposed Resolution: DRR can only be used with No-ICE >>>> ***NOTE: This slide generated significant discussion in the meeting. >>>> There were some comments that this was incomplete, and discussion of >>>> moving this out of the base draft and into the relay/direct response >>>> draft. ADDITIONAL DISCUSSION REQUIRED. >>> >>> I see the problem and think that we should take this section out from >>> RELOAD and continue with the individual relay draft >>> (draft-jiang-p2psip-relay-04) for the use case where the node is not behind >>> NAT or a relay can be used. >>> In this case we will need to verify that RELOAD allows such extensions and >>> that there are no issues with supporting it due to some routing assumptions. >>> >>> Roni Even >>> >>> >>> >>> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
