Re: [OFF-PATH-BOF] SIP, naming, APIs and control

Scott W Brim <swb@employees.org> Fri, 28 July 2006 12:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rp4-0005zu-SI; Fri, 28 Jul 2006 08:52:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rp4-0005zo-4Y for off-path-bof@ietf.org; Fri, 28 Jul 2006 08:52:10 -0400
Received: from willers.employees.org ([192.83.249.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Rp2-00055s-IJ for off-path-bof@ietf.org; Fri, 28 Jul 2006 08:52:10 -0400
Received: from [172.16.2.41] (unknown [195.70.5.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by willers.employees.org (Postfix) with ESMTP id 55FB15CABD; Fri, 28 Jul 2006 05:52:06 -0700 (PDT)
Message-ID: <44CA0871.3090707@employees.org>
Date: Fri, 28 Jul 2006 14:52:01 +0200
From: Scott W Brim <swb@employees.org>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: Saikat Guha <saikat@cs.cornell.edu>
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
References: <C0DC1986.10CBB%mshore@cisco.com> <1152894044.13866.213.camel@localhost.localdomain>
In-Reply-To: <1152894044.13866.213.camel@localhost.localdomain>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: off-path-bof@ietf.org, Teemu Koponen <koponen@ICSI.Berkeley.EDU>
X-BeenThere: off-path-bof@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <off-path-bof.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/off-path-bof>
List-Post: <mailto:off-path-bof@ietf.org>
List-Help: <mailto:off-path-bof-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=subscribe>
Errors-To: off-path-bof-bounces@ietf.org

Catching up after being on the road for three weeks ...

On 07/14/2006 18:20 PM, Saikat Guha allegedly wrote:
>    _----------S---------_
>   /                      \
>  /                        \
> A --- N --Internet-- M --- B
>
> If A and B are the two endpoints that want to communicate, the path
> that data packets between the two will ultimately take is termed the
> DATA-PATH. Data refers to some application data (not the signaling
> packet).
>
> OFF-PATH signaling, synonymous with DATA-DECOUPLED signaling, refers
> to the case where signaling packets (at least the first signaling
> packet) _necessarily_ take a path different than the DATA-PATH.

First I want to push for a few terminology nits ...

Technically they are not synonymous, at least in some circles.  Path-
(or data-) decoupled means it NEED not take the same path as the data,
but MIGHT.  That's what we usually mean with SIP.  On the other hand
some network operators want true off-path, which means signaling and
data MUST take separate paths.

> IN-BAND signaling is defined as a subset of ON-PATH signaling where
> the signaling packets are piggy-backed on the data packets
> themselves i.e.  use the same 5-tuple as the data flow.

Well, they are piggy-backed on the same FLOW but could be in different
packets.

> END-TO-MIDDLE-SIG is where the signaling message sent by one end (A)
> cannot be delivered to the other end.

Hm, you say "cannot be delivered".  Is that required?  Do you mean
that interaction with the intermediary is required to reach the other
end?  E2M signaling would seem to be where the source end explicitly
knows of and speaks to a middlebox ... whether it could (also) speak
to the other endpoint or not.  Why not just say that e2m is where the
"signaling" is addressed to something that is known to be an
intermediary and not the ultimately desired endpoint?

On 07/13/2006 19:35 PM, Teemu Koponen allegedly wrote:
> The fundamental aspect I still do not understand is that how the
> decoupling of signaling and data paths helps at all. It strikes to
> be problem roaming only for me. (I think Bob Briscoe asked this
> without getting a decent answer.) I'm not sure whether I heard the
> word in some comment, but I think the group name misses a single
> word: control. This all is about getting the control back to the
> end-points and not that much about decoupling the paths.

It enables indirection, which doesn't necessarily mean being at the
mercy of a third party.  An intermediary could be under your control.
You are right that the signaling doesn't have to be off-path, but you
don't want to assume that it's on-path.  This is where Melinda's work
comes in.

swb




_______________________________________________
OFF-PATH-BOF mailing list
OFF-PATH-BOF@ietf.org
https://www1.ietf.org/mailman/listinfo/off-path-bof