Hi Bruce, I do not think it is required for every message, just for the case when the intermediary node keeps state of the message (it is per such a message). This may be needed due to failures on the route and not only for DRR support Roni
> -----Original Message----- > From: Bruce Lowekamp [mailto:[email protected]] > Sent: Saturday, January 08, 2011 12:30 AM > To: Roni Even > Cc: David A. Bryan; P2PSIP WG > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > I think requiring the state timeout mechanism to be used for every > message would be a bit much to put on the peers. I would rather > provide the explicit flag. > > Bruce > > On Thu, Jan 6, 2011 at 9:07 AM, Roni Even <[email protected]> wrote: > > 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
