Re: [P2PSIP] Fwd:New Version Notification for draft-jiang-p2psip-relay-00

["Bruce Lowekamp" <[e-mail]>]

On Wed, Nov 12, 2008 at 3:19 PM, Roni Even <[e-mail]> wrote:
> 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.

Roni,

Absolutely.  An earlier thread discussed the need for the e2e timeouts
to be improved a bit, and this needs some work as well.  At the least,
it needs to specify the minimum amount of time the state must be
stored before timing out...

Bruce



>
> Regards
> Roni Even
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Bruce Lowekamp
> Sent: Wednesday, November 12, 2008 10:10 PM
> To: jiangxingfeng 36340
> Cc: [e-mail]; [e-mail]
> 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
> <[e-mail]> 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 <[e-mail]>
>> To: [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
_______________________________________________
P2PSIP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2psip