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

Saikat Guha <> Fri, 14 July 2006 17:58 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G1Rw3-0004xM-9B; Fri, 14 Jul 2006 13:58:43 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G1Rw1-0004xF-IV for; Fri, 14 Jul 2006 13:58:41 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1G1Rw0-0004HA-BC for; Fri, 14 Jul 2006 13:58:41 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 13:58:40 -0400
Received: from ( []) by (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k6EHwdv23513; Fri, 14 Jul 2006 13:58:39 -0400 (EDT)
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
From: Saikat Guha <>
To: Teemu Koponen <koponen@ICSI.Berkeley.EDU>
In-Reply-To: <CA038C2C-5AD9-440E-889D-F86FBE678B55@ICSI.Berkeley.EDU>
References: <CA038C2C-5AD9-440E-889D-F86FBE678B55@ICSI.Berkeley.EDU>
Date: Fri, 14 Jul 2006 18:58:39 +0100
Message-Id: <1152899919.13866.246.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4)
X-OriginalArrivalTime: 14 Jul 2006 17:58:40.0119 (UTC) FILETIME=[233F3070:01C6A76F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1585963813=="

On Thu, 2006-07-13 at 10:35 -0700, Teemu Koponen wrote:
> The fundamental aspect I still do not understand is that how the
> decoupling of signaling and data paths helps at all.

I guess one way to put what we (Paul and I) were trying to say is that
there is a present need for "end-to-end off-path signaling" today.

Connection establishment in the original Internet involved an
end-to-middle off-path lookup (DNS) followed by an end-to-end on-path
signal (TCP SYN).

That is no longer sufficient today, especially when you have firewalls
that drop all inbound traffic to be on the safe side. One such firewall
at each end and your end-to-end on-path signal can no longer make it.

If instead of the end-to-middle off-path signaling (DNS) you first
perform end-to-end off-path signaling (SIP or something such), the ends
now can punch the holes to let your end-to-end on-path signal (TCP SYN)

So the architecture can be viewed as either:

a) decoupling the existing end-to-end path (TCP SYN) into 
   end-to-end off-path and end-to-end on-path components.

  or alternatively as:

b) extending the existing end-to-middle off-path lookup (DNS) to an
   end-to-end off-path signaling

still not sure if I am caffinated enough,
OFF-PATH-BOF mailing list