On the topic of a flag to not keep state... just having a flag won't work. It has to be an overlay option because all the nodes in the overlay need to support it. Once you have it as an overlay option, you don't need it in the base spec. I just don't see any reason to put it in the base spec - it can be done in extension just as well - and I see lots of reasons not to but it in the base spec. We don't really know how to make this work well yet. Ideally it would be an optimization you used when you could so that a client could still connect to a peer that would do state and do the DDR for it. Saying something like the flag indicates don't keep state breaks clients among other things. You would need the option to be a little more nuanced than that. I think we should define all of this in the DDR draft - trying to guess what we need before we know what we are doing is likely to result in getting it wrong.
On Feb 4, 2011, at 9:05 AM, Bruce Lowekamp wrote: > Roni, > > Since we made it an option for intermediate peers using SRR to keep > state rather than modify the forwarding header, I think we should try > to keep that option reasonably well supported. And while I agree with > you that the timeout such an implementation provides is sufficient for > supporting DRR without other modifications, I'd really rather provide > an good way for such implementation to avoid keeping state for all DRR > (potentially most/many messages) until timeout, thus my support for a > flag. > > We can flag this as an open issue for more discussion, though (pun intended). > > Bruce > > > On Mon, Jan 31, 2011 at 1:54 AM, Roni Even <[email protected]> wrote: >> 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
