Hi Bruce, I think that the flag for not keeping state may be useful but there is also another mechanism which is the time out that tells intermediate nodes to discard any state after a timeout. Roni
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bruce Lowekamp > Sent: Thursday, December 02, 2010 8:54 PM > To: David A. Bryan > Cc: P2PSIP WG; Roni Even > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
