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

"Bruce Lowekamp" <bbl@lowekamp.net> Wed, 12 November 2008 20:10 UTC

Return-Path: <p2psip-bounces@ietf.org>
X-Original-To: p2psip-archive@optimus.ietf.org
Delivered-To: ietfarch-p2psip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE5E28C14D; Wed, 12 Nov 2008 12:10:29 -0800 (PST)
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97CC3A6B48 for <p2psip@core3.amsl.com>; Wed, 12 Nov 2008 12:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEYBCslXNqUb for <p2psip@core3.amsl.com>; Wed, 12 Nov 2008 12:10:27 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id EF73E3A6B45 for <p2psip@ietf.org>; Wed, 12 Nov 2008 12:10:26 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id b25so528917rvf.49 for <p2psip@ietf.org>; Wed, 12 Nov 2008 12:10:27 -0800 (PST)
Received: by 10.114.37.1 with SMTP id k1mr6332498wak.28.1226520626803; Wed, 12 Nov 2008 12:10:26 -0800 (PST)
Received: by 10.114.92.9 with HTTP; Wed, 12 Nov 2008 12:10:26 -0800 (PST)
Message-ID: <bc023dcd0811121210i20558fb4maecc7680492694fc@mail.gmail.com>
Date: Wed, 12 Nov 2008 15:10:26 -0500
From: Bruce Lowekamp <bbl@lowekamp.net>
To: jiangxingfeng 36340 <jiang.x.f@huawei.com>
In-Reply-To: <f8c6aca15b85f.5b85ff8c6aca1@huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <f8c6aca15b85f.5b85ff8c6aca1@huawei.com>
Cc: even.roni@gmail.com, p2psip@ietf.org
Subject: Re: [P2PSIP] Fwd:New Version Notification for draft-jiang-p2psip-relay-00
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2psip-bounces@ietf.org
Errors-To: p2psip-bounces@ietf.org

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
<jiang.x.f@huawei.com> 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 <idsubmission@ietf.org>
> To: jiang.x.f@huawei.com
> 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
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>
>
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip