I've made this change. -Ekr
On Jan 7, 2011, at 2:29 PM, Bruce Lowekamp wrote: > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
