Bruce, I am with you and think that having a flag is a good idea Roni > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Bruce Lowekamp > Sent: Friday, February 04, 2011 6:05 PM > To: Roni Even > Cc: P2PSIP WG > Subject: Re: [P2PSIP] WG decisions and issues on RELOAD base draft from > meeting - DRR > > 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
