Bruce, Good point about the store state in the intermediate peers I think that we need to do something about it. Having a flag in the forwarding header may be a good option. I think that stored state can also happens in SRR if the response fails in an intermediate peer that gets the response before the one that kept the state so I think that some timeout on keeping the state is necessary anyhow for the base draft.
Regards Roni Even -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Lowekamp Sent: Wednesday, November 12, 2008 10:10 PM To: jiangxingfeng 36340 Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [P2PSIP] Fwd:New Version Notification for draft-jiang-p2psip-relay-00 I think it's great to see this written up. While I've argued against incorporating DRR and RPR into the base spec, I think developing it as an extension is an excellent idea. A few high-level comments. I think the right thing to do is to separate out an p2p-based implementation of nat-behavior-discovery as a separate usage and put it in its own draft. I'm more than happy to contribute to such an effort. Note that because nat-behavior-discovery is experimental, such a draft (and anything that depends on it, such as this) will need to be experimental as well. I agree with the decision to use a ForwardingOption for signalling the desired response address. But a couple details concern me. - I'm not sure I agree DESTINATION_CRITICAL needs to be set here. It seems like if the responder doesn't support this routing mode, it will just return via SRR like normal. - The only complication I see is that reload's SRR allows intermediate peers to keep state about transactions rather than store the state in the Via list (5.1.2.2). Not using SRR would cause such a peer to have a possible state explosion waiting for transactions to time out. Options I can think of offhand for solving that are: 1) ignore the problem, 2) make the ForwardingOption FORWARD_CRITICAL, 3) add a new flag to the forwarding header that suggests intermediate peers not keep state. Bruce On Sun, Oct 26, 2008 at 8:20 PM, jiangxingfeng 36340 <[EMAIL PROTECTED]> wrote: > Hi, folks: > > We've just submitted a draft which proposes an extension to RELOAD to support direct response and relay peer routing mode. This topic has been discussed during Dublin meeting and is based on the draft-jiang-p2psip-sep-01. > > Any comments are appreciated. > > Regards > > Jiang XingFeng > > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Sat, 25 Oct 2008 06:52:12 -0700 (PDT) > Subject: New Version Notification for draft-jiang-p2psip-relay-00 > > A new version of I-D, draft-jiang-p2psip-relay-00.txt has been successfuly submitted by XingFeng Jiang and posted to the IETF repository. > > Filename: draft-jiang-p2psip-relay > Revision: 00 > Title: An extension to RELOAD to support Direct Response and Relay Peer routing > Creation_date: 2008-10-25 > WG ID: Independent Submission > Number_of_pages: 19 > > Abstract: > This document proposes an extension to RELOAD to support direct > response and relay peer routing modes. The document starts with the > problem statement and address concerns about these two routing modes > mentioned in RELOAD. Then methods about how to discover NAT behavior > of the client in P2PSIP situations are discussed. The last part > proposes extensions to RELOAD for supporting these additional routing > modes. > > > > The IETF Secretariat. > > > > _______________________________________________ > 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
