From off-path-bof-bounces@ietf.org Thu Jul 13 13:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G155j-0003Xl-9t; Thu, 13 Jul 2006 13:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G155i-0003XX-I1 for off-path-bof@ietf.org; Thu, 13 Jul 2006 13:35:10 -0400 Received: from nz-out-0102.google.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G155g-0000Rm-8v for off-path-bof@ietf.org; Thu, 13 Jul 2006 13:35:10 -0400 Received: by nz-out-0102.google.com with SMTP id i11so8742nzi for ; Thu, 13 Jul 2006 10:35:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer:sender; b=l7VxsLHubTi2VRFB+MsK9R2vFLrHqV4JYSB2e9yfWIgSMGDvty9Me8MS7ouUvxI0d4YqRw+1hmqrwpz4wT8Lkh2UWb0PngNuoUptQ1fl8QzRDvCtkqBzyG1zYPVPZRZSU6FW4/mEBxxnWA3jqde1SqcymHm5j6XPT7A/onYX/c8= Received: by 10.65.93.20 with SMTP id v20mr354598qbl; Thu, 13 Jul 2006 10:35:07 -0700 (PDT) Received: from ?132.219.6.122? ( [132.219.6.122]) by mx.gmail.com with ESMTP id q16sm1285165qbq.2006.07.13.10.35.06; Thu, 13 Jul 2006 10:35:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: off-path-bof@ietf.org From: Teemu Koponen Date: Thu, 13 Jul 2006 10:35:02 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [OFF-PATH-BOF] SIP, naming, APIs and control X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org Thanks for a very interesting BoF, Paul, Mark and Saikat. There's definitely ongoing work in this area elsewhere too. :) Here's my unstructured initial stake on the matter. I have to say that I was more than slightly concerned about the proposed content before hearing the presentations. It seemed that the called approach would not be a "clean-slate" one but a more engineering oriented effort. Especially, o) The promotion of SIP was concerning. I tend to see the current SIP as a rather complex beast indeed. While it does have certain attractive primitives built-in (e.g., delegation to impose off-path middleboxes), I would not like to remain fixed to SIP. In the end, I believe something more simple can meet the requirements. Fortunately, SIP was less emphasized in the presentions themselves than in the call. o) Mixing the needs to persistently identify an end-point for machines and for users was distracting. I do not think hierarchical names should remain the sole option to consider. Flat names are rather attractive option indeed to identify end-points for machines. In fact, I think one should support both. "Newsock" was mentioned, but I was somewhat confused when the focus was in the API and when in the protocol. I feel that explicitly considering the API first would enforce us to think the requirements before moving down to the protocol level issues. Moreover, I could imagine an outcome where applications could use multiple "offpath protocols" through the same API. 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. Teemu -- _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Thu Jul 13 14:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15g1-0001mG-Nz; Thu, 13 Jul 2006 14:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15g0-0001j4-B8 for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:12:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15fy-0003Fb-1b for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:12:40 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2006 14:12:38 -0400 X-IronPort-AV: i="4.06,238,1149480000"; d="scan'208"; a="92680391:sNHT25888188" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DICb1S010017; Thu, 13 Jul 2006 14:12:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DICb7t018440; Thu, 13 Jul 2006 14:12:37 -0400 (EDT) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 14:12:37 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 18:12:37 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 13 Jul 2006 14:12:36 -0400 Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control From: Melinda Shore To: Teemu Koponen , Message-ID: Thread-Topic: [OFF-PATH-BOF] SIP, naming, APIs and control Thread-Index: Acamp+sOKaKWkBKbEduQ3AAKleNSdA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 18:12:37.0304 (UTC) FILETIME=[EBD5BB80:01C6A6A7] DKIM-Signature: a=rsa-sha1; q=dns; l=2546; t=1152814357; x=1153678357; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:Melinda=20Shore=20 |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20,=20; X=v=3Dcisco.com=3B=20h=3DX1X521665gjuB0ybUPJheZZiEaE=3D; b=aB8uGeJMo0rKtuZzgZ/WSmhTup8j/63u3j+KCKAYfwlptCDhrT+GlY4WO2vesOuBTKWs8gMG WCSHoeBYHDZRBABPmniMsO0tDEJdf0UG05bpwUP1t9Evra/9OEa29yXb; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org On 7/13/06 1:35 PM, "Teemu Koponen" wrote: > o) Mixing the needs to persistently identify an end-point for machines > and for users was distracting. I do not think hierarchical names > should remain the sole option to consider. Flat names are rather > attractive option indeed to identify end-points for machines. In fact, > I think one should support both. I think it's probably early to bog down in deployment issues, but I do think it's worth mentioning deployment issues *un*related to compatibility issues and I think this is one of them, for two reasons: 1) flat namespaces are just plain hard to manage, and 2) I'm not sure where Paul or anybody else stands on this but I've been laboring in these particular fields for a few years now and from my perspective the really hard problems relate to topology and "findability." It's much harder to find your way around a flat namespace. > 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. When I first brought the proposal for on-path middlebox communication to the IETF I described it as "topology insensitive," and I think that's still the desired outcome. However, what we've found over the past few years is that on-path middlebox signaling is nearly impossible to deploy in all but the most constrained networks. I agree that focusing on the question of whether or not the signaling is on-path or off-path is largely orthogonal to the work that needs to be done, but by now we know an awful lot about how to do both on-path and off-path control/request/communications but not how to solve the extremely difficult problems introduced by even modest topological complexity. My opinion is that ultimately it's the path-decoupled stuff (I guess "off-path" is kind of misleading in this context) that's going to be *actually* useful in real networks, but obviously there's not yet any consensus about this and some further discussion is undoubtedly necessary. But it is my feeling that the "control" aspect has kind of been done to death and is well beyond the research stage. Melinda _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Thu Jul 13 14:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16Pa-0007eN-Jj; Thu, 13 Jul 2006 14:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16PZ-0007eD-14 for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:59:45 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16PX-000821-OJ for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:59:45 -0400 Received: by nf-out-0910.google.com with SMTP id l24so17101nfc for ; Thu, 13 Jul 2006 11:59:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=YzNCxjr59wuourBcDPw+ZT9xBxbtm+JclcAP6F7DDZKHEcOp6qH9jnYTwP7o58aXwSfgxvWw99GBgFMbLCeNTRlukHHaaHVEBIFjBxzq+4guKLBuc2tEUs21dmry8gjf/djXkOYEqbS6d8VRVxsu6QxZQIXo1gJ+KvWXG3eAd8A= Received: by 10.78.166.7 with SMTP id o7mr1121853hue; Thu, 13 Jul 2006 11:59:42 -0700 (PDT) Received: from ?132.219.13.202? ( [132.219.13.202]) by mx.gmail.com with ESMTP id 20sm601344huf.2006.07.13.11.59.41; Thu, 13 Jul 2006 11:59:42 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control Date: Thu, 13 Jul 2006 11:59:38 -0700 To: Melinda Shore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: off-path-bof@ietf.org X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org On Jul 13, 2006, at 11:12, Melinda Shore wrote: > When I first brought the proposal for on-path middlebox communication > to the IETF I described it as "topology insensitive," and I think > that's > still the desired outcome. However, what we've found over the past > few years is that on-path middlebox signaling is nearly impossible > to deploy > in all but the most constrained networks. I believe everyone agrees on this; requiring middleboxes to be on the path complicates deployment. However, when questioning the point of decoupling signaling and data paths, I all the time assumed this combined data and signaling path to be different from a path routers give you. Is this what you mean or do you opt for three different paths: a router given, signaling, and data path? > control/request/communications but not how to solve the extremely > difficult problems introduced by even modest topological complexity. Could you elaborate these difficult problems? Teemu -- _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Thu Jul 13 15:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G171S-0003OQ-DB; Thu, 13 Jul 2006 15:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G171R-0003O6-1g for off-path-bof@ietf.org; Thu, 13 Jul 2006 15:38:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G171N-0002nM-54 for off-path-bof@ietf.org; Thu, 13 Jul 2006 15:38:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2006 12:38:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="32152831:sNHT25700080" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJcmp2011600; Thu, 13 Jul 2006 15:38:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJcm7t013916; Thu, 13 Jul 2006 15:38:48 -0400 (EDT) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:38:48 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 19:38:47 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 13 Jul 2006 15:38:46 -0400 Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control From: Melinda Shore To: Teemu Koponen Message-ID: Thread-Topic: [OFF-PATH-BOF] SIP, naming, APIs and control Thread-Index: Acams/SeM12RfhKnEduQ3AAKleNSdA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 19:38:48.0079 (UTC) FILETIME=[F5DB61F0:01C6A6B3] DKIM-Signature: a=rsa-sha1; q=dns; l=3603; t=1152819528; x=1153683528; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:Melinda=20Shore=20 |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20; X=v=3Dcisco.com=3B=20h=3DX1X521665gjuB0ybUPJheZZiEaE=3D; b=FloNAKsAtfiptSxHnJW6eFwcYG/n3H9qothz2dTDhjmKsUqUz8WvNtMhUl5B886CuVnzY3P4 I4loYkPOJevjcXFTJzSgtB0QxUwIqGW6HdLv/nKICdFrpDlvXvB9JuvO; Authentication-Results: rtp-dkim-1.cisco.com; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: off-path-bof@ietf.org X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org On 7/13/06 2:59 PM, "Teemu Koponen" wrote: > I believe everyone agrees on this; requiring middleboxes to be on the > path complicates deployment. Actually, it's my impression that some people agree with this at this time, but not yet the preponderance of people. > However, when questioning the point of > decoupling signaling and data paths, I all the time assumed this > combined data and signaling path to be different from a path routers > give you. Is this what you mean or do you opt for three different > paths: a router given, signaling, and data path? Ah. Maybe somebody should write up an informational document defining some of these terms so that we're at least all using the same language. "Off-path" middlebox control assumes that you know the address of the middlebox you'd like to control and that you can establish a relationship with it directly (client/server, if you like). The actual route taken is irrelevant in terms of the protocol design, although obviously there may be some operational considerations. "On-path" middlebox control typically (but not always) assumes that you do not know the addresses of any middlebox along the path or, for that matter, which path the data will be taking. It works much like RSVP, where the requests are addressed to the application peer and intercepted by middleboxes they happen to traverse. nsis is actually somewhere in the middle. >> control/request/communications but not how to solve the extremely >> difficult problems introduced by even modest topological complexity. > Could you elaborate these difficult problems? Probably not exhaustively - every time you think you've got something licked another one crops up. But basically, if you're going to address a middlebox directly you have to know where it is, and again, aside from operational considerations (operators/network administrators typically are loathe to reveal the locations of their firewalls, not to mention configuration/provisioning of firewall locations) you have to know which firewall is the correct one. Throw in NATs, and you start having to know who is where in relationship to each other, so that you can request the correct firewall pinhole addresses, or QoS reservations, or anything else that requires installing a network address in the middle of the network. For example, if your network looks like: Host----NAT----firewall you'll need to request an external (to the NAT) address, while if it's Host----firewall----NAT you'll need to request the internal (to the NAT) address. This problem in conjunction with figuring out how to handle multihoming and route changes is what motivated the topology-insensitive work in the first place, but the problem is that for the on-path stuff you need a path, which is a route between two (or more, but we won't go there) endpoints. If the other guy doesn't have a network presence because he's NATted or otherwise invisible, you don't have a path. Now, it's possible to start sticking proxies into the network to act on behalf of unpresent hosts, but that reintroduces the topology problems that we find in off-path signaling and then you end up, in my opinion, with the worst of both approaches. There are some unbelievably hacky workarounds for these problems, but they introduce other issues around resource consumption and security vulnerabilities. In fact, one of the things that I really like about Paul's proposal is the focus on authorization for middlebox traversal. Melinda _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Fri Jul 14 12:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QPI-0000mn-NY; Fri, 14 Jul 2006 12:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QPH-0000mf-7M for off-path-bof@ietf.org; Fri, 14 Jul 2006 12:20:47 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1QPF-0001j4-Uj for off-path-bof@ietf.org; Fri, 14 Jul 2006 12:20:47 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 12:20:45 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k6EGKiv29615; Fri, 14 Jul 2006 12:20:44 -0400 (EDT) Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control From: Saikat Guha To: Melinda Shore In-Reply-To: References: Date: Fri, 14 Jul 2006 17:20:44 +0100 Message-Id: <1152894044.13866.213.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 14 Jul 2006 16:20:45.0491 (UTC) FILETIME=[75B21830:01C6A761] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: off-path-bof@ietf.org, Teemu Koponen X-BeenThere: off-path-bof@ietf.org 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="===============0149097796==" Errors-To: off-path-bof-bounces@ietf.org --===============0149097796== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rFkSdX/9sXlaMLwphmZu" --=-rFkSdX/9sXlaMLwphmZu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-07-13 at 15:38 -0400, Melinda Shore wrote: > Maybe somebody should write up an informational document > defining some of these terms so that we're at least all using the > same language. I'll draft up a proposal for the terms, but just so we are all on the same page for mailing list discussion, my understanding of {on,off}path, data{coupled,decoupled}, {in,out of}band, end-to-{end,middle}-signaling are as follows. _----------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. ON-PATH signaling, synonymous with DATA-COUPLED signaling, is when signaling packets (even the first) do _not necessarily_ take a path different from the DATA-PATH. 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. OUT-OF-BAND signaling is a subset of ON-PATH signaling where the signaling packets are not piggy-backed on the data packets and use a different 5-tuple. END-TO-END-SIG is where the signaling message sent by one end (A) MAY be delivered to the other end (B). END-TO-MIDDLE-SIG is where the signaling message sent by one end (A) cannot be delivered to the other end. Here is how I would classify some signaling protocols: [Disclaimer: Some protocols can move between classification depending on the mode they can be put in. Classification for other protocols may just be entirely wrong. :-p] OFF-PATH / DATA-DECOUPLED, END-TO-END-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SIP, XMPP (e.g. data is filetransfer), MPLS-LDP (END here is the LSR) OFF-PATH / DATA-DECOUPLED, END-TO-MIDDLE-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DNS ON-PATH / DATA-COUPLED, OUT-OF-BAND, END-TO-END-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NSIS, RTCP, FTP control ON-PATH / DATA-COUPLED, OUT-OF-BAND, END-TO-MIDDLE-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D UPnP, Midcom, SOCKS (for bind request), Remote-WinSock ON-PATH / DATA-COUPLED, IN-BAND, END-TO-END-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCP SYN, TURN (note, TURN server may not be on the direct IP path, but it is still on the DATA-PATH), BEEP ON-PATH / DATA-COUPLED, IN-BAND, END-TO-MIDDLE-SIG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SOCKS (for connect request) --=20 Saikat --=-rFkSdX/9sXlaMLwphmZu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEt8RcnFltqi691/oRAjodAJ97K1hnn95xCMRlkK4Iqiie8J+KJgCaAoTl dLkeyKE+qkQ++sybpp4GmS8= =XjVM -----END PGP SIGNATURE----- --=-rFkSdX/9sXlaMLwphmZu-- --===============0149097796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof --===============0149097796==-- From off-path-bof-bounces@ietf.org Fri Jul 14 12:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Qlj-0006ky-Ak; Fri, 14 Jul 2006 12:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Qlh-0006ks-Sw for off-path-bof@ietf.org; Fri, 14 Jul 2006 12:43:57 -0400 Received: from nz-out-0102.google.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Qle-0004x3-If for off-path-bof@ietf.org; Fri, 14 Jul 2006 12:43:57 -0400 Received: by nz-out-0102.google.com with SMTP id o37so265045nzf for ; Fri, 14 Jul 2006 09:43:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=n+7/TY1tl9QL70JWHXG+fBo6AXDfdEgqWNX1B7uUerR3ArMryaUI+SNuBkECRMJ07FWioYX4hria2zM3YAQR//yqsq5bTOHk5Z+NyglV0vkKfcC3iEuD6VUXkU/a+uvSlxY4xEejN2njMKoMZ1X/FY+db98ENbJ2ZqLy5bR4/gM= Received: by 10.65.182.20 with SMTP id j20mr798697qbp; Fri, 14 Jul 2006 09:43:54 -0700 (PDT) Received: from ?132.219.13.202? ( [132.219.13.202]) by mx.gmail.com with ESMTP id e15sm1762165qbe.2006.07.14.09.43.53; Fri, 14 Jul 2006 09:43:53 -0700 (PDT) In-Reply-To: <1152894044.13866.213.camel@localhost.localdomain> References: <1152894044.13866.213.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59D9917D-BD2F-4F0C-982C-C9327753A53B@ICSI.Berkeley.EDU> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control Date: Fri, 14 Jul 2006 09:43:52 -0700 To: Saikat Guha X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: off-path-bof@ietf.org X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org On Jul 14, 2006, at 9:20, Saikat Guha wrote: > On Thu, 2006-07-13 at 15:38 -0400, Melinda Shore wrote: >> Maybe somebody should write up an informational document >> defining some of these terms so that we're at least all using the >> same language. > > I'll draft up a proposal for the terms, but just so we are all on the > same page for mailing list discussion, my understanding of {on,off} > path, > data{coupled,decoupled}, {in,out of}band, end-to-{end,middle}- > signaling > are as follows. > > > _----------S---------_ > / \ > / \ > A --- N --Internet-- M --- B Your classification assumes M and N are not explicitly addressed middleboxes, right? Teemu -- _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Fri Jul 14 13:35:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1RZ7-0005QQ-NZ; Fri, 14 Jul 2006 13:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1RZ5-0005QL-Ly for off-path-bof@ietf.org; Fri, 14 Jul 2006 13:34:59 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1RZ4-0000fw-EI for off-path-bof@ietf.org; Fri, 14 Jul 2006 13:34:59 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 13:34:57 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.25) with ESMTP id k6EHYuv18553; Fri, 14 Jul 2006 13:34:57 -0400 (EDT) Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control From: Saikat Guha To: Teemu Koponen In-Reply-To: <59D9917D-BD2F-4F0C-982C-C9327753A53B@ICSI.Berkeley.EDU> References: <1152894044.13866.213.camel@localhost.localdomain> <59D9917D-BD2F-4F0C-982C-C9327753A53B@ICSI.Berkeley.EDU> Date: Fri, 14 Jul 2006 18:34:56 +0100 Message-Id: <1152898496.13866.234.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 14 Jul 2006 17:34:57.0982 (UTC) FILETIME=[D3964DE0:01C6A76B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: off-path-bof@ietf.org X-BeenThere: off-path-bof@ietf.org 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="===============0523702092==" Errors-To: off-path-bof-bounces@ietf.org --===============0523702092== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NPsAUZX8Pzo2NsVf2whX" --=-NPsAUZX8Pzo2NsVf2whX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-07-14 at 09:43 -0700, Teemu Koponen wrote: > On Jul 14, 2006, at 9:20, Saikat Guha wrote: > > _----------S---------_ > > / \ > > / \ > > A --- N --Internet-- M --- B >=20 > Your classification assumes M and N are not explicitly addressed =20 > middleboxes, right? The classification applies more to the signaling protocol than devices themselves. However, the choice of the device may preclude one signaling protocol or another. Here, N and M may or may not be explicitly addressed depending on the nature of the device. If N and M are UPnP/midcom/TURN/SOCKS servers etc., then they need to be addressed explicitly, and for that, some off-path signaling needs to happen first to discover their addresses. This off-path signaling can be as simple as a DNS query, link-level broadcast, or a more complicated SIP discovery/negotiation. -- Some lookup mechanism that _won't_ be used for the actual data. If N and M are firewall/NAT boxes, they need not be explicitly addressed, therefore there is no such need for an off-path lookup to discover N/M -- i.e. N and M can be discovered (invoked?) by the same mechanism that'll be used to send data (unicast IP routing from A to B). An off-path lookup, however, may still be needed to find B in the first place. Not sure if I answered your question, --=20 Saikat --=-NPsAUZX8Pzo2NsVf2whX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEt9XAnFltqi691/oRAuEmAJ0cEHrYX5ig3fqNcguusLTU65XkYgCfQ3kP h+XKZ0HNdyGwywHNgjywrgA= =HtVX -----END PGP SIGNATURE----- --=-NPsAUZX8Pzo2NsVf2whX-- --===============0523702092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof --===============0523702092==-- From off-path-bof-bounces@ietf.org Fri Jul 14 13:58:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rw3-0004xM-9B; Fri, 14 Jul 2006 13:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rw1-0004xF-IV for off-path-bof@ietf.org; Fri, 14 Jul 2006 13:58:41 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Rw0-0004HA-BC for off-path-bof@ietf.org; Fri, 14 Jul 2006 13:58:41 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 13:58:40 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (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 In-Reply-To: References: 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 Cc: off-path-bof@ietf.org X-BeenThere: off-path-bof@ietf.org 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==" Errors-To: off-path-bof-bounces@ietf.org --===============1585963813== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-HCHHCQKKFFhetXvrhtNO" --=-HCHHCQKKFFhetXvrhtNO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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) through. So the architecture can be viewed as either: a) decoupling the existing end-to-end path (TCP SYN) into=20 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, --=20 Saikat --=-HCHHCQKKFFhetXvrhtNO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEt9tPnFltqi691/oRAmASAJ9VAo5KHIXBrCDsFAbsYQtJfLAY5wCdHjIT lrzDgO/Zn3ySDvgvKCGxAdc= =7X2h -----END PGP SIGNATURE----- --=-HCHHCQKKFFhetXvrhtNO-- --===============1585963813== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof --===============1585963813==-- From off-path-bof-bounces@ietf.org Tue Jul 25 11:49:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5P9o-0002jE-MI; Tue, 25 Jul 2006 11:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5P9m-0002gB-NA for off-path-bof@ietf.org; Tue, 25 Jul 2006 11:49:14 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5P9l-0006Gt-GO for off-path-bof@ietf.org; Tue, 25 Jul 2006 11:49:14 -0400 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.42]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 11:49:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 25 Jul 2006 11:49:11 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed IRTF agenda Thread-Index: AcamorURyjc1zgYSReSo/Qa5N3UqMAJXg/+A From: "Paul Francis" To: X-OriginalArrivalTime: 25 Jul 2006 15:49:13.0032 (UTC) FILETIME=[E03F0480:01C6B001] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Mark Handley Subject: [OFF-PATH-BOF] Proposed IRTF agenda X-BeenThere: off-path-bof@ietf.org 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: , Errors-To: off-path-bof-bounces@ietf.org There are about 50 folks on this mailing list now. I know y'all are all feverishly awaiting a draft agenda to discuss, but = I'm going on holiday for the next week and a half, so don't want to start anything until after that. PF _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof From off-path-bof-bounces@ietf.org Fri Jul 28 08:52:11 2006 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 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 Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control References: <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 X-BeenThere: off-path-bof@ietf.org 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: , 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 From off-path-bof-bounces@ietf.org Fri Jul 28 16:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YXw-00076k-Qm; Fri, 28 Jul 2006 16:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YXv-00076P-8u for off-path-bof@ietf.org; Fri, 28 Jul 2006 16:02:55 -0400 Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6YXr-0007mE-No for off-path-bof@ietf.org; Fri, 28 Jul 2006 16:02:55 -0400 Received: from sundial.cs.cornell.edu ([128.84.96.115]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 16:02:51 -0400 Received: from himalaya.cs.cornell.edu (himalaya.cs.cornell.edu [128.84.223.110]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.27) with ESMTP id k6SK2oT29629; Fri, 28 Jul 2006 16:02:50 -0400 (EDT) Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control From: Saikat Guha To: Scott W Brim In-Reply-To: <44CA0871.3090707@employees.org> References: <1152894044.13866.213.camel@localhost.localdomain> <44CA0871.3090707@employees.org> Date: Fri, 28 Jul 2006 21:02:50 +0100 Message-Id: <1154116970.12449.78.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 28 Jul 2006 20:02:51.0482 (UTC) FILETIME=[CE6373A0:01C6B280] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: off-path-bof@ietf.org, Teemu Koponen X-BeenThere: off-path-bof@ietf.org 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="===============1513574424==" Errors-To: off-path-bof-bounces@ietf.org --===============1513574424== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-m2Ej+Gy7JcbVdwhsxp8G" --=-m2Ej+Gy7JcbVdwhsxp8G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-07-28 at 14:52 +0200, Scott W Brim wrote: > On 07/14/2006 18:20 PM, Saikat Guha allegedly wrote: > > 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. >=20 > First I want to push for a few terminology nits ... >=20 > Technically they are not synonymous, at least in some circles. =20 Agreed. I should have used different terms; what I was trying to get at was a slightly broader picture of a communication session between two endpoints. Take an FTP transfer for instance between client C and server S. Consider how it would be accomplished in various architectures today. Arch #1: Internet before DNS ---------------------------- 1. Assumption: C must know S's IP address. - How? Business card, phone call, ... somehow 2. C sends a TCP SYN to S's IP address - This 'signal' follows the same path that data will eventually follow.=20 3. Over the signaling channel in #2, C sends a request. S opens a=20 data connection by sending another SYN signal. Data can now flow. #1 =3D assumption: knows IP address #2 =3D end-to-end signal #3 =3D end-to-end data Arch #2: Internet with DNS -------------------------- 1. Assumption: C must know S's hostname 2. C does a DNS request to it's local resolver - This 'signal' is along a different path than the e2e path that the data will eventually take 3. Same as #2 above 4. Same as #3 above. #1 =3D assumption: knows hostname #2 =3D end-to-middle signal #3 =3D end-to-end signal #4 =3D end-to-end data Arch #3: With SIP/ICE/NAT-Traversal ----------------------------------- 1. Assumption: C must know S's URI 2. C sends 'INVITE' to S over SIP - This path _may_ be different from the ultimate e2e data path 3. S responds with a transient IP address/port pair over SIP 4. Same as #3 above 5. Same as #4 above #1 =3D assumption: knows URI=20 #2 =3D end-to-middle-to-end signal (possible disjoint from data-path) #3 =3D end-to-middle-to-end signal (possible disjoint from data-path) #4 =3D end-to-end signal #5 =3D end-to-end data Arch #4: With TURN relay in addition with SIP/ICE/... ----------------------------------------------------- 1. Assumption: C must know S's URI 2. Same as #2 above 3. Same as #3 above, except returns a TURN server's address 4. C sends a SYN to the TURN server, TURN server connects to S 5. For data conection, S connects to TURN server, which connects to C #1 =3D assumption: knows URI #2 =3D end-to-middle-to-end signal (possible disjoint from data-path) #3 =3D end-to-middle-to-end signal (possible disjoint from data-path) #4 =3D end-to-middle-to-end signal (along data-path) #5 =3D end-to-middle-to-end data =20 So basically, I was shooting for terms to differentiate the various components of these architectures. a) end-to-middle signal (DNS, UPnP, ....) b) end-to-middle-to-end signal (SIP, i3, TURN, NSIS, ...) b1) not necessarily along data path (SIP, i3, ...) b2) along the data path (TURN, NSIS, ...) b21) same "flow" (TURN, ...) b22) different "flow" (NSIS, ...) c) end-to-end signal (TCP SYN, ...) d) end-to-end data (TCP Data, ...)=20 e) end-to-middle-to-end data (TURN Data) --=20 Saikat --=-m2Ej+Gy7JcbVdwhsxp8G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQBEym1qnFltqi691/oRAjaTAJ9FgI+UCNOXcsH1+H7od8foIySfwQCfUXRZ CaY1ZSiSGcAADkoRyeUMMbM= =Z+Tr -----END PGP SIGNATURE----- --=-m2Ej+Gy7JcbVdwhsxp8G-- --===============1513574424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OFF-PATH-BOF mailing list OFF-PATH-BOF@ietf.org https://www1.ietf.org/mailman/listinfo/off-path-bof --===============1513574424==--