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
