From architecture-discuss-bounces@ietf.org Wed Mar 01 01:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEL06-0003pd-C8; Wed, 01 Mar 2006 01:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEL05-0003pG-0N for architecture-discuss@ietf.org; Wed, 01 Mar 2006 01:39:53 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEL03-0007WC-QX for architecture-discuss@ietf.org; Wed, 01 Mar 2006 01:39:52 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 67228E043D; Wed, 1 Mar 2006 01:39:51 -0500 (EST) Date: Wed, 1 Mar 2006 01:39:51 -0500 From: John Leslie To: "Bound, Jim" Subject: Re: [arch-d] What Problems are We Solving for the InternetArchitecture Message-ID: <20060301063951.GA31110@verdi> References: <936A4045C332714F975800409DE0924001DEFA89@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE0924001DEFA89@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: > > <356 lines> ... mostly saying, "SCTP is good enough". I don't believe folks who write 350-line posts should be rewarded; but I'll stipulate that SCTP is good. We, however, need to discuss architecture. Fred Baker quite correctly framed his post in terms of architecture; and I sincerely hope we can discuss it in those terms. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 02:27:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELk0-00018X-Jx; Wed, 01 Mar 2006 02:27:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELj4-00077e-0m for architecture-discuss@ietf.org; Wed, 01 Mar 2006 02:26:22 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELZW-0000lN-Ju for architecture-discuss@ietf.org; Wed, 01 Mar 2006 02:16:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 45F97E0438; Wed, 1 Mar 2006 02:16:30 -0500 (EST) Date: Wed, 1 Mar 2006 02:16:30 -0500 From: John Leslie To: Fred Baker Message-ID: <20060301071630.GB31110@verdi> References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: architecture-discuss@ietf.org, "Bound, Jim" Subject: [arch-d] Name this concept X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker wrote: > On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote: > >> Problem: Transport Layer needs to provide in the market failover to >> new IP address, but not tear down the IP session association. TCP/ >> UDP do not provide session layer failover to multiple IP >> addresses. SCTP does permit this behavior. How do we deprecate >> TCP/UDP so SCTP can become the dominant NGN for the Transport >> Layer, is there anything the IETF can do? (Ignoring DCCP for this >> example). > > The architectural question is really, I think, to complete the > separation between the internet and transport layers, so that a > transport layer session is not tied to a single address pair. Exactly. It is good that SCTP does this, but SCTP is engineering, not architecture. > In TCP, we could simply copy the SCTP approach, which has the session > tied to a single address pair at any given time, or we could have > each TCP-speaker simply announce to the other the various addresses > it might use, and once the announcement has been reliably received, > have it assume that segments might arrive from any of the peer's > announced addresses to any one of this system's addresses, but using > the same port pair and other TCB state. This is architecture. "Reliably received", of course, is handwaving; but that's OK in an architecture discussion. The critical issue is that there would be multiple paths, with each endpoint (potentially) having multiple IP addresses. > In that case, the peer is able to spread his traffic on all address > pairs if it suits him, or change them at a whim, because instead of > the TCP session having one address/port-pair tuple that identifies it, > it has m*n identifiers that are mutual aliases, all equally valid at > any given time. Note the use of "TCP session"... Fred certainly doesn't mean TCP-as-we-know-it-today; but it might be better to say "TCP-bis"... Regardless, we need a way to talk about this "TCP-bis session". I'm quite open to suggestions, but for now I'll use "TCP-bis session". >> - Important to SHIM6, HIP, and Mobile IP. Are these priorities and >> are they building shims around TCP/UDP. > > Personally, I think each of these has its place operationally and yet > is also something of a kluge and overkill. That, to me, is the single > biggest reason that the marketplace hasn't necessarily adopted them > or is driving these solutions. I agree with Fred. But again, we need to talk architecture: those are engineering... > If TCP and SCTP can announce an alternate address like I described > above, now add the concept that they could withdraw an announced > address. Mobile handover just got fixed - at least the easy case in > which there is a multiple RTT overlap during which the moving > endpoint can send a message that announces the new address and > withdraws the old one. This is a nice architectural solution, free of most kludgery that we see in typical "mobility" engineering. (Fred goes on to discuss engineering of announcing addresses. I mostly agree with him, but I want to stick to architecture.) > ... That would require some concept of a session identifier... See > RFC 2103. No thanks on 2103 (16 pages). It really doesn't discuss "session". But "session identifier" is architecture: we should discuss it. > Say "Locator/Endpoint Identifier split" (RFC 1992)... (27 pages.) Nice work, actually; but I think we can stay away from routing for the time being. > ... while the Locator is a network layer address, the Endpoint > Identifier is a session layer concept, and what we're really saying > is that we need some form of session management layer that lives > *above* the transport. I agree. I'm not particular about the name; but there are many reasons to work on "session management": - mobility; - security; - congestion; - pre-emption; - Quality-of-Service; - et cetera. > Note I didn't say "the ISO Session Layer" - please God, no - but > something that lives in about that place and securely manages sessions. We need a name for this animal. I quite agree that "ISO Session" won't do... "TCP-bis session" is ugly, but I think it gets the idea across. Any other suggestions? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 03:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEN7i-0007sX-EH; Wed, 01 Mar 2006 03:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEN7g-0007sS-Nx for architecture-discuss@ietf.org; Wed, 01 Mar 2006 03:55:52 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEN7f-0003s7-Gl for architecture-discuss@ietf.org; Wed, 01 Mar 2006 03:55:52 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006030108555001400e432qe>; Wed, 1 Mar 2006 08:55:50 +0000 Message-ID: <440561C6.3050307@tony.li> Date: Wed, 01 Mar 2006 00:56:38 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Leslie Subject: Re: [arch-d] Name this concept References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> In-Reply-To: <20060301071630.GB31110@verdi> 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: e8a67952aa972b528dd04570d58ad8fe Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> If TCP and SCTP can announce an alternate address like I described >> above, now add the concept that they could withdraw an announced >> address. Mobile handover just got fixed - at least the easy case in >> which there is a multiple RTT overlap during which the moving >> endpoint can send a message that announces the new address and >> withdraws the old one. > >> ... That would require some concept of a session identifier... See >> RFC 2103. > >> Say "Locator/Endpoint Identifier split" (RFC 1992)... > > (27 pages.) Nice work, actually; but I think we can stay away from > routing for the time being. > >> ... while the Locator is a network layer address, the Endpoint >> Identifier is a session layer concept, and what we're really saying >> is that we need some form of session management layer that lives >> *above* the transport. > > I agree. I'm not particular about the name; but there are many > reasons to work on "session management": > > - mobility; > - security; > - congestion; > - pre-emption; > - Quality-of-Service; > - et cetera. > >> Note I didn't say "the ISO Session Layer" - please God, no - but >> something that lives in about that place and securely manages sessions. > > We need a name for this animal. I quite agree that "ISO Session" > won't do... > > "TCP-bis session" is ugly, but I think it gets the idea across. > Any other suggestions? The work on GSE/8+8 points out that if we have a host identifier and use that as part of the pseudo-header, that that is sufficient to identify the connection. Such a host identifier obviates the real need for a session layer and the possible ISO-ish trap. That said, the more general "endpoint identifier" provides another level of indirection over the host identifier, and yes would be a session layer entity. However, the architectural overhead for this indirection is non-trivial and to me only seems to be advantageous over a host identifier if we actually expect to migrate endpoints across hosts. Do we really have significant drivers for that in the architecture? While it has always been a pet interest of mine, I find the minimalistic side of my nature rebelling. That said, I actually do see a crying need for a real session layer. We seem to kludge this currently (e.g., X tunneled over SSH) and perhaps for security reasons alone, we should bite the bullet and do it properly. Thoughts? Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 06:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEP4v-0002BA-2H; Wed, 01 Mar 2006 06:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEP4t-0002Au-BF for architecture-discuss@ietf.org; Wed, 01 Mar 2006 06:01:07 -0500 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEP4r-0000d1-Jr for architecture-discuss@ietf.org; Wed, 01 Mar 2006 06:01:07 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k21B0d9B002499; Wed, 1 Mar 2006 22:00:40 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060301215220.0324f890@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 01 Mar 2006 22:00:41 +1100 To: Tony Li , John Leslie From: Geoff Huston Subject: Re: [arch-d] Name this concept In-Reply-To: <440561C6.3050307@tony.li> References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> <440561C6.3050307@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >The work on GSE/8+8 points out that if we have a host identifier and use >that as part of the pseudo-header, that that is sufficient to identify >the connection. Such a host identifier obviates the real need for a >session layer and the possible ISO-ish trap. > >That said, the more general "endpoint identifier" provides another level >of indirection over the host identifier, and yes would be a session >layer entity. However, the architectural overhead for this indirection >is non-trivial and to me only seems to be advantageous over a host >identifier if we actually expect to migrate endpoints across hosts. Do >we really have significant drivers for that in the architecture? While >it has always been a pet interest of mine, I find the minimalistic side >of my nature rebelling. > >That said, I actually do see a crying need for a real session layer. We >seem to kludge this currently (e.g., X tunneled over SSH) and perhaps >for security reasons alone, we should bite the bullet and do it properly. 'host' always appears to me to be a somewhat indistinct and messy kludge, given the somewhat indistinct and morphable definition of what a 'host' is. I must admit that I had always associated the term 'end-point' with an instance of a protocol stack. The reason why is that at least at the application layer such an identifier is used both in the context of establishing a conversation and in maintaining a conversation. The association of such an identifier as a session layer identity appears to me to be consistent with the second of these roles, but its connotations in terms of being a identification of a rendezvous point is a little harder to think of in a session layer context. Either way the point that this is non-trivial is well taken, but there is some merit to 'do it properly' as far as I can see. regards. Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 07:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQeQ-00079m-IR; Wed, 01 Mar 2006 07:41:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEQeQ-00079g-0z for architecture-discuss@ietf.org; Wed, 01 Mar 2006 07:41:54 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEQeL-0004Ee-QE for architecture-discuss@ietf.org; Wed, 01 Mar 2006 07:41:54 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0154E34087; Wed, 1 Mar 2006 07:41:46 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 07:41:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Wed, 1 Mar 2006 07:41:43 -0500 Message-ID: <936A4045C332714F975800409DE0924001E53757@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9Df79MNEmIREpTRWew58UTWCxFQAHkCPw From: "Bound, Jim" To: "Tony Li" , "John Leslie" X-OriginalArrivalTime: 01 Mar 2006 12:41:45.0310 (UTC) FILETIME=[7FC557E0:01C63D2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On GSE 8+8. I think met morphing the concept for discussion is good as it was is probably long debate down long black tube. This is probably a whacky idea but I throw it out. The low order 64bits of IPv6 address are pretty much now the End User Identifier (EUI) and we are not going to use it in most address formats for anything else it appears today. =20 Would we be able to determine a means to use the EUI as location identifier for when required (that is TBD) and also as seed to an IP-session-ID (I am making up this term to avoid ever being connected to the OSI session layer feel free to change it but I think we need to make that clear unless we have dissent on god no OSI session layer). The Fred issue that it is a number I think is ok if it is part of the address and the IP-Session-ID does not have to be a number and could be indirect pointer the EUI. One problem to deal with is that there are some parts of the market that are going to mandate use of IPv6 address use of RFC 3041 (whack the EUI periodically so it changes and it cannot be tracked on the net - and 3041 has draft-biz update in process too). Thus assuming any permanent EUI is not good assumption. Probably true for IP-Session-ID too. This could also have a seamless transition that is backwards compatible. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 08:28:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERNd-0001g6-G5; Wed, 01 Mar 2006 08:28:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERNc-0001fr-8r for architecture-discuss@ietf.org; Wed, 01 Mar 2006 08:28:36 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERNa-0005dN-QD for architecture-discuss@ietf.org; Wed, 01 Mar 2006 08:28:36 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k21DQnMg004066; Wed, 1 Mar 2006 15:26:54 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 15:28:09 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 15:28:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Wed, 1 Mar 2006 15:28:08 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> In-Reply-To: <20060301071630.GB31110@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9Aggmz5nP1wSiSVaqMpcdY4K3WwAL8+Hg From: To: , X-OriginalArrivalTime: 01 Mar 2006 13:28:07.0827 (UTC) FILETIME=[FA47BE30:01C63D33] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, A quick additional point: >> ... while the Locator is a network layer address, the Endpoint >> Identifier is a session layer concept, and what we're really saying is >> that we need some form of session management layer that lives >> *above* the transport. > > I agree. I'm not particular about the name; but there are >many reasons to work on "session management": > >- mobility; >- security; >- congestion; >- pre-emption; >- Quality-of-Service; >- et cetera. With regards to the "session", I think some notion of 'path' is needed. Path would essentially be the rough data path packets traverse between the address pairs one the two end-nodes. Each path will have some notion of congestion, admission / premption / policing and potentially security as well. I think the notion of path is quite important if there are multiple (potential) 'connections' beneath the session. =20 If these connections are using different link-layers, there might be very different RTT, latency, packet loss, etc. for these paths, and that surely will effect the overall session. I think we're already finding issues when running apps with various small devices over cellular & wifi radios, for example. =20 For example, I don't think we have a good understanding of all of the issues when running traditional TCP congestion control over the myriad moblity solutions & extensions that the IETF is working on. This begs the question, should TCP-bis congestion be re-worked? John Loughney _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 10:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETEp-0004LT-KJ; Wed, 01 Mar 2006 10:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETEn-0004LO-Oo for architecture-discuss@ietf.org; Wed, 01 Mar 2006 10:27:37 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETEm-00020z-A2 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 10:27:37 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k21FRB024169; Wed, 1 Mar 2006 10:27:11 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.217] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 10:26:41 -0500 Message-ID: <4405BD2C.7050300@nortel.com> Date: Wed, 01 Mar 2006 10:26:36 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [arch-d] Name this concept References: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 15:26:41.0120 (UTC) FILETIME=[8A221E00:01C63D44] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This brings up a point I wanted to make against Jim's original post on SCTP, I think: engineering considerations may mess up the architectural concept. Randy Stewart originally intended SCTP to use all its paths at once. But, it's my impression, eventually active usage was limited to a single path at a time because our congestion adaptation models don't tell us how to handle congestion across multiple inhomogeneous paths. john.loughney@nokia.com wrote: > John, >... > > If these connections are using different link-layers, there might be > very different RTT, latency, packet loss, etc. for these paths, and that > surely will effect the overall session. I think we're already finding > issues when running apps with various small devices over cellular & wifi > radios, for example. > > For example, I don't think we have a good understanding of all of the > issues when running traditional TCP congestion control over the myriad > moblity solutions & extensions that the IETF is working on. This begs > the question, should TCP-bis congestion be re-worked? > > John Loughney > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 10:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETgR-0001v3-2Y; Wed, 01 Mar 2006 10:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FETgP-0001us-MP for architecture-discuss@ietf.org; Wed, 01 Mar 2006 10:56:09 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FETgO-0003ZB-Cn for architecture-discuss@ietf.org; Wed, 01 Mar 2006 10:56:09 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FETgI-0006A6-00; Wed, 01 Mar 2006 10:56:02 -0500 From: Tim Shepard To: John Leslie Subject: Re: [arch-d] Name this concept In-reply-to: Your message of Wed, 01 Mar 2006 02:16:30 -0500. <20060301071630.GB31110@verdi> Date: Wed, 01 Mar 2006 10:56:02 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > Note I didn't say "the ISO Session Layer" - please God, no - but > > something that lives in about that place and securely manages sessions. > > We need a name for this animal. I quite agree that "ISO Session" > won't do... > > "TCP-bis session" is ugly, but I think it gets the idea across. > Any other suggestions? > I like the idea of calling it an association. Today (at least in our heads, if not in our systems) we can have shim6 associations, HIP associations, and IPsec associations. So perhaps we need a simple small word to stick in front of "association" to explicitly genericize the concept a bit for use in architectural discussions. I also think it may make sense (in our architectural thinking and discussions) to avoid insisting on an ordering in the stack between the transport layer stuff (e.g. TCP) and this [generic] association. ISO had it above transport. Mobile IP, HIP, shim6, IPsec all have an end-to-end (or end-to-middlebox) association below transport that can be shared by multiple transports (that go between the same two endpoints). The channel binding stuff being discussed in BTNS illustrates (IMHO) that there's usefulness to be found both above and below the transport layer (at least in being able to interface to the association layer). -Tim Shepard shep@alum.mit.edu _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 11:32:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUFs-0005o1-D8; Wed, 01 Mar 2006 11:32:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUFr-0005nw-Sp for architecture-discuss@ietf.org; Wed, 01 Mar 2006 11:32:47 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUFo-0005Io-Hu for architecture-discuss@ietf.org; Wed, 01 Mar 2006 11:32:47 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k21GVNw15959; Wed, 1 Mar 2006 08:31:23 -0800 (PST) Message-ID: <4405CC55.5080807@isi.edu> Date: Wed, 01 Mar 2006 08:31:17 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tim Shepard Subject: Re: [arch-d] Name this concept References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tim Shepard wrote: >>> Note I didn't say "the ISO Session Layer" - please God, no - but >>> something that lives in about that place and securely manages sessions. >> We need a name for this animal. I quite agree that "ISO Session" >> won't do... >> >> "TCP-bis session" is ugly, but I think it gets the idea across. >> Any other suggestions? >> > > > I like the idea of calling it an association. > > Today (at least in our heads, if not in our systems) we can have shim6 > associations, HIP associations, and IPsec associations. > > So perhaps we need a simple small word to stick in front of > "association" to explicitly genericize the concept a bit for use in > architectural discussions. Skip the adjective. Just call it what it is: "connection". Joe _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 12:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUmC-0004Z3-M7; Wed, 01 Mar 2006 12:06:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUmB-0004Yy-Js for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:06:11 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUmA-0006bP-7f for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:06:11 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k21H4Fw23261; Wed, 1 Mar 2006 09:04:15 -0800 (PST) Message-ID: <4405D409.8050703@isi.edu> Date: Wed, 01 Mar 2006 09:04:09 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Geoff Huston Subject: Re: [arch-d] Name this concept References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> <440561C6.3050307@tony.li> <6.2.0.14.2.20060301215220.0324f890@localhost> In-Reply-To: <6.2.0.14.2.20060301215220.0324f890@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Geoff Huston wrote: ... > 'host' always appears to me to be a somewhat indistinct and messy > kludge, given the somewhat indistinct and morphable definition of > what a 'host' is. I must admit that I had always associated the > term 'end-point' with an instance of a protocol stack. The reason > why is that at least at the application layer such an identifier is > used both in the context of establishing a conversation and > in maintaining a conversation.... There's more than that - the association of other apps with that single stack instance. Marco Zec's Clonable Stacks already implements this for FreeBSD. IMO, that's still a "host", since there are non-protocol issues involved (application access, filesystem, etc.) that need to be partitioned 'per stack' as well. We need to relax the notion of "host" from mapping 1:1 to a computer, but we have been for a while. In the early 1990s, Netstation and the Desktop Area Network (DAN) extended that map to 1:N; In the late 1990s/early 2000s Clonable Stacks and supporting virtual OS's (Xen, VMware, etc.) extended the map to M:1, and the supercomputer folk have been working on ways to unify the two to support arbrary M:N maps for a while (since the mid 1990s as well). Joe _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 12:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUwl-0006rI-G8; Wed, 01 Mar 2006 12:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUwk-0006qt-BZ for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:17:06 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUwg-0006uz-38 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:17:06 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0661234044; Wed, 1 Mar 2006 12:17:02 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 12:16:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Wed, 1 Mar 2006 12:16:09 -0500 Message-ID: <936A4045C332714F975800409DE0924001E53951@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9Aggmz5nP1wSiSVaqMpcdY4K3WwAL8+HgAAhr6WA= From: "Bound, Jim" To: , , X-OriginalArrivalTime: 01 Mar 2006 17:16:10.0899 (UTC) FILETIME=[D606D630:01C63D53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, good point but I think the IP-Session-ID for say multiple transport connections is more of a conrol plane transport where as for example the SCTP associations underneath are specific instances of transport connection that would weigh in on the overall nodes knowledge of the transport connection. Also each connection for each media layer would need to provide metrics for that network path as you state regarding hints and intelligence and security. /jim=20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Wednesday, March 01, 2006 8:28 AM > To: john@jlc.net; fred@cisco.com > Cc: architecture-discuss@ietf.org; Bound, Jim > Subject: RE: [arch-d] Name this concept >=20 > John, >=20 > A quick additional point: >=20 > >> ... while the Locator is a network layer address, the Endpoint > >> Identifier is a session layer concept, and what we're really saying > is > >> that we need some form of session management layer that lives > >> *above* the transport. > > > > I agree. I'm not particular about the name; but there are > >many reasons to work on "session management": > > > >- mobility; > >- security; > >- congestion; > >- pre-emption; > >- Quality-of-Service; > >- et cetera. >=20 > With regards to the "session", I think some notion of 'path'=20 > is needed. > Path would essentially be the rough data path packets traverse between > the address pairs one the two end-nodes. Each path will have some > notion of congestion, admission / premption / policing and potentially > security as well. I think the notion of path is quite=20 > important if there > are multiple (potential) 'connections' beneath the session. =20 >=20 > If these connections are using different link-layers, there might be > very different RTT, latency, packet loss, etc. for these=20 > paths, and that > surely will effect the overall session. I think we're already finding > issues when running apps with various small devices over=20 > cellular & wifi > radios, for example. =20 >=20 > For example, I don't think we have a good understanding of all of the > issues when running traditional TCP congestion control over the myriad > moblity solutions & extensions that the IETF is working on. This begs > the question, should TCP-bis congestion be re-worked? >=20 > John Loughney >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 12:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEV8t-0002EX-Kl; Wed, 01 Mar 2006 12:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEV8s-0002DO-6g for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:29:38 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEV8n-0007LC-U5 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 12:29:38 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 452FA3407D; Wed, 1 Mar 2006 12:29:44 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 12:29:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Wed, 1 Mar 2006 12:29:13 -0500 Message-ID: <936A4045C332714F975800409DE0924001E53961@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9RKsb4atH3+gAQ06IIFbBeL73HwAEIPmg From: "Bound, Jim" To: "Tom-PT Taylor" , X-OriginalArrivalTime: 01 Mar 2006 17:29:15.0087 (UTC) FILETIME=[A9706DF0:01C63D55] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I know of two customers using it for multipath and its new features of failover and record boundaries for multiple messages over SCTP so I believe Randy's initial design center is in fact in tact and I did work with Randy on this from the beginning as supporter and still am supporter. Have reviewed and seen 3 IP Stack implementations and with all the diffs each was still able to do the multipathing. Agree we need to do architecture first so suggest taking the SCTP core principles and extrapolating to the architecture need, which would avoid mixing engineering initially. But, before we say the architecture is good it required engineering reality verification in some form. /jim=20 > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Sent: Wednesday, March 01, 2006 10:27 AM > To: john.loughney@nokia.com > Cc: john@jlc.net; fred@cisco.com;=20 > architecture-discuss@ietf.org; Bound, Jim > Subject: Re: [arch-d] Name this concept >=20 > This brings up a point I wanted to make against Jim's=20 > original post on=20 > SCTP, I think: engineering considerations may mess up the=20 > architectural=20 > concept. Randy Stewart originally intended SCTP to use all=20 > its paths at=20 > once. But, it's my impression, eventually active usage was=20 > limited to a=20 > single path at a time because our congestion adaptation models don't=20 > tell us how to handle congestion across multiple inhomogeneous paths. >=20 > john.loughney@nokia.com wrote: > > John, > >... > >=20 > > If these connections are using different link-layers, there might be > > very different RTT, latency, packet loss, etc. for these=20 > paths, and that > > surely will effect the overall session. I think we're=20 > already finding > > issues when running apps with various small devices over=20 > cellular & wifi > > radios, for example. =20 > >=20 > > For example, I don't think we have a good understanding of=20 > all of the > > issues when running traditional TCP congestion control over=20 > the myriad > > moblity solutions & extensions that the IETF is working on.=20 > This begs > > the question, should TCP-bis congestion be re-worked? > >=20 > > John Loughney > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 > >=20 >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 13:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWQ6-00006R-BD; Wed, 01 Mar 2006 13:51:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWQ5-0008Vd-1X for architecture-discuss@ietf.org; Wed, 01 Mar 2006 13:51:29 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEWQ3-0002mT-Qw for architecture-discuss@ietf.org; Wed, 01 Mar 2006 13:51:29 -0500 Received: from h-68-165-4-155.snvacaid.dynamic.covad.net ([68.165.4.155] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEWQ3-0007TW-00 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 13:51:27 -0500 Message-ID: <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> Subject: Re: [arch-d] Name this concept Date: Wed, 1 Mar 2006 10:53:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: > To: ; > Cc: ; > Sent: Wednesday, March 01, 2006 5:28 AM > Subject: RE: [arch-d] Name this concept ... > With regards to the "session", I think some notion of 'path' is needed. > Path would essentially be the rough data path packets traverse between > the address pairs one the two end-nodes. Each path will have some > notion of congestion, admission / premption / policing and potentially > security as well. I think the notion of path is quite important if there > are multiple (potential) 'connections' beneath the session. > > If these connections are using different link-layers, there might be > very different RTT, latency, packet loss, etc. for these paths, and that > surely will effect the overall session. I think we're already finding > issues when running apps with various small devices over cellular & wifi > radios, for example. ... I think this leads naturally to the conclusion that when an session / association is created, the application could specify the bounds for the end-to-end QoS, which would in turn serve to constrain the underlying transport parameters, including the decision whether to use connection-oriented or connection-less transport (or even both). Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 01 14:18:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWq7-0003OG-2F; Wed, 01 Mar 2006 14:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEWq5-0003O8-M7 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 14:18:21 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEWq4-0003iu-FP for architecture-discuss@ietf.org; Wed, 01 Mar 2006 14:18:21 -0500 Received: from h-68-165-4-155.snvacaid.dynamic.covad.net ([68.165.4.155] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEWKZ-0005TF-00 for architecture-discuss@ietf.org; Wed, 01 Mar 2006 13:45:47 -0500 Message-ID: <002001c63d60$9ad76540$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [arch-d] Name this concept Date: Wed, 1 Mar 2006 10:47:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "Tim Shepard" > To: "John Leslie" > Cc: > Sent: Wednesday, March 01, 2006 7:56 AM > Subject: Re: [arch-d] Name this concept ... > I like the idea of calling it an association. ... As do I. However, the term might lead to confusion with ACSE. I'm not sure yet whether this would be a bug or a feature. Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 13:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsPP-0000sP-3a; Thu, 02 Mar 2006 13:20:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsPN-0000rv-Ng for architecture-discuss@ietf.org; Thu, 02 Mar 2006 13:20:13 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEsPM-0001G4-Fi for architecture-discuss@ietf.org; Thu, 02 Mar 2006 13:20:13 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2006 10:20:12 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k22IKE7T026397; Thu, 2 Mar 2006 10:20:14 -0800 (PST) Received: from [149.43.82.28] (sjc-vpn5-254.cisco.com [10.21.88.254]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k22ILiGh029533; Thu, 2 Mar 2006 10:22:21 -0800 In-Reply-To: <20060301071630.GB31110@verdi> References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D4DC053-CDC5-4866-87AC-8DEE2AC89109@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Thu, 2 Mar 2006 06:48:51 -0500 To: John Leslie X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=660; t=1141323742; x=1141755942; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Name=20this=20concept |To:John=20Leslie=20; X=v=3Dmtcc.com=3B=20h=3DpVCSjCMX+BG5VT3/tpKGwfbLOt8=3D; b=h/c0YfGYqQsoLrP8wT8p6rUn+PE7+1IlzDKZUCIGdBOZSH1a9lB2Kp4IsgsjbJkg3M8iXnoo KZcB5n/O0XuBHobhaC9Se+QoJsIhR6P9T+u81NQ4qG/+LrkUZC/O8ZnCAF9dSGzFSz/735LHOZh mqOe2D+y+G4uyjTuv9wo2haU=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org, "Bound, Jim" Subject: [arch-d] Re: Name this concept X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org for the record, I was postulating TCP as we know it today, but with at least one (announce-address) and perhaps two (withdraw-address) new options. The comment about "reliable receipt" presumed the acknowledgment of a TCP segment that contained such an option. As you say, the details of TCP are engineering more than architecture. As you otherwise noted, I think SCTP is a good thing, but I don't see a need to discard TCP. I do see a need to change it in some way similar to this. On Mar 1, 2006, at 2:16 AM, John Leslie wrote: > Fred certainly doesn't mean TCP-as-we-know-it-today; but it might > be better to say "TCP-bis"... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 14:27:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtSS-0007pp-Dd; Thu, 02 Mar 2006 14:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEi6u-00036F-CS for architecture-discuss@ietf.org; Thu, 02 Mar 2006 02:20:28 -0500 Received: from mx4.fundp.ac.be ([138.48.4.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEi6o-0007vX-WE for architecture-discuss@ietf.org; Thu, 02 Mar 2006 02:20:28 -0500 Received: from backus.info.fundp.ac.be (backus.info.fundp.ac.be [138.48.32.107]) by mx4.fundp.ac.be (8.11.7p1+Sun/8.11.7) with ESMTP id k227JaC14274; Thu, 2 Mar 2006 08:19:36 +0100 (MET) Received: from [127.0.0.1] (backus.info.fundp.ac.be [138.48.32.107]) by backus.info.fundp.ac.be (8.11.7p1+Sun/8.9.1) with ESMTP id k227JZe02273; Thu, 2 Mar 2006 08:19:35 +0100 (MET) Message-ID: <44069C8F.4050605@info.fundp.ac.be> Date: Thu, 02 Mar 2006 08:19:43 +0100 From: Schumacher Laurent User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org, john@jlc.net, jim.bound@hp.com Subject: Re: [arch-d] Name this concept Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FUNDP-MailScanner-Information: Please contact the ISP for more information X-FUNDP-MailScanner: Found to be clean X-FUNDP-SpamCheck: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 02 Mar 2006 14:27:26 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hello, John Leslie wrote : >> ... while the Locator is a network layer address, the Endpoint >> Identifier is a session layer concept, and what we're really saying >> is that we need some form of session management layer that lives >> *above* the transport. > > I agree. I'm not particular about the name; but there are many >reasons to work on "session management": > >- mobility; >- security; >- congestion; >- pre-emption; >- Quality-of-Service; >- et cetera. > Isn't it what Session Initiation Protocol (SIP, RFC 3261) is addressing? Just my two cents, LS -- Laurent Schumacher Computer Science Institute, FUNDP - The University of Namur ------------------------------------------------------------ Web page: http://www.info.fundp.ac.be/~lsc/ ------------------------------------------------------------ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 15:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu7L-0000rR-UV; Thu, 02 Mar 2006 15:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu7K-0000qx-9t for architecture-discuss@ietf.org; Thu, 02 Mar 2006 15:09:42 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEu7J-0005W4-3N for architecture-discuss@ietf.org; Thu, 02 Mar 2006 15:09:42 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with ESMTP id <2006030220093901200j4912e>; Thu, 2 Mar 2006 20:09:39 +0000 Message-ID: <4407512F.7050400@tony.li> Date: Thu, 02 Mar 2006 12:10:23 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Re: Name this concept References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> <9D4DC053-CDC5-4866-87AC-8DEE2AC89109@cisco.com> In-Reply-To: <9D4DC053-CDC5-4866-87AC-8DEE2AC89109@cisco.com> 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: ea4ac80f790299f943f0a53be7e1a21a Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred, Do we want this flexibility in the transport protocol? Or should it be in a lower layer? Tony Fred Baker wrote: > for the record, I was postulating TCP as we know it today, but with at > least one (announce-address) and perhaps two (withdraw-address) new > options. The comment about "reliable receipt" presumed the > acknowledgment of a TCP segment that contained such an option. > > As you say, the details of TCP are engineering more than architecture. > As you otherwise noted, I think SCTP is a good thing, but I don't see a > need to discard TCP. I do see a need to change it in some way similar to > this. > > On Mar 1, 2006, at 2:16 AM, John Leslie wrote: > >> Fred certainly doesn't mean TCP-as-we-know-it-today; but it might >> be better to say "TCP-bis"... > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 16:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEve2-0006jH-B4; Thu, 02 Mar 2006 16:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuxC-0006Ch-UB for architecture-discuss@ietf.org; Thu, 02 Mar 2006 16:03:19 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuxB-0001RM-3v for architecture-discuss@ietf.org; Thu, 02 Mar 2006 16:03:17 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 63C8A11B46 for ; Thu, 2 Mar 2006 16:03:16 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k22L3E3C010187; Thu, 2 Mar 2006 16:03:14 -0500 (EST) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k22L3Bnk026761; Thu, 2 Mar 2006 16:03:12 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k22L3Bku026749; Thu, 2 Mar 2006 16:03:11 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id BC9214FDF4; Thu, 2 Mar 2006 16:02:36 -0500 (EST) Date: Thu, 2 Mar 2006 16:02:36 -0500 From: Wesley Eddy To: john.loughney@nokia.com Subject: Re: [arch-d] Name this concept Message-ID: <20060302210236.GB5094@grc.nasa.gov> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> Mime-Version: 1.0 In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1930456389==" Errors-To: architecture-discuss-bounces@ietf.org --===============1930456389== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 01, 2006 at 03:28:08PM +0200, john.loughney@nokia.com wrote: >=20 > With regards to the "session", I think some notion of 'path' is needed. > Path would essentially be the rough data path packets traverse between > the address pairs one the two end-nodes. Each path will have some > notion of congestion, admission / premption / policing and potentially > security as well. I think the notion of path is quite important if there > are multiple (potential) 'connections' beneath the session. =20 >=20 > If these connections are using different link-layers, there might be > very different RTT, latency, packet loss, etc. for these paths, and that > surely will effect the overall session. I think we're already finding > issues when running apps with various small devices over cellular & wifi > radios, for example. =20 Another important one is a difference in path MTU. =20 > For example, I don't think we have a good understanding of all of the > issues when running traditional TCP congestion control over the myriad > moblity solutions & extensions that the IETF is working on. This begs > the question, should TCP-bis congestion be re-worked? This has been looked at a little and discussed some in TSVWG and TCPM. Currently, two internet-drafts that modify TCP to deal better with different kinds of connectivity changes are being merged together: https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D12= 091 and https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D10= 165 The merged version is not yet available, and (sadly) there hasn't been a strong WG response that this is even a valid issue that requires work. The two questions that remain, even if these changes to TCP are actually adopted are: 1) What are the standard signals from lower layers that TCP can use to trigger such actions? I think getting these nailed down is an important part of the protocol architecture. 2) Do we require a mandate that other protocols that rely on estimates of path state adopt similar mechanisms for responding to lower layer change indications? https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D12= 376 is a starting point for the discussion. -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEB11szBuYqbnj3IwRAuTVAJ94kYzc7UDqWN1ExTGvJdpumKB9ewCdHhUK 4MFvtfDKsvWNm1mR8DGtO94= =OzvB -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- --===============1930456389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1930456389==-- From architecture-discuss-bounces@ietf.org Thu Mar 02 17:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvux-000680-50; Thu, 02 Mar 2006 17:05:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvuv-00067t-NJ for architecture-discuss@ietf.org; Thu, 02 Mar 2006 17:05:01 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvuv-0007dJ-Ch for architecture-discuss@ietf.org; Thu, 02 Mar 2006 17:05:01 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 1DCD1E0434; Thu, 2 Mar 2006 17:04:57 -0500 (EST) Date: Thu, 2 Mar 2006 17:04:57 -0500 From: John Leslie To: john.loughney@nokia.com Subject: Re: [arch-d] Name this concept Message-ID: <20060302220456.GA98050@verdi> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org john.loughney@nokia.com wrote: > To: , > >>> ... while the Locator is a network layer address, the Endpoint >>> Identifier is a session layer concept, and what we're really saying >>> is that we need some form of session management layer that lives >>> *above* the transport. >> >> I agree. I'm not particular about the name; but there are >> many reasons to work on "session management": >> >> - mobility; >> - security; >> - congestion; >> - pre-emption; >> - Quality-of-Service; >> - et cetera. > > With regards to the "session", I think some notion of 'path' is needed. > Path would essentially be the rough data path packets traverse between > the address pairs one the two end-nodes. Let me see if I understand... A "session" (your quotes) is defined by end-points, ports, and whatever; a 'path' is whatever limited knowledge the "session" management at each end-point may have about how packets get from one end to the other. Conceptually, there may be multiple paths in each direction for packet transfer. > Each path will have some notion of congestion, admission / premption / > policing and potentially security as well. I agree that congestion, pre-emption, etc. are per-path. Rules on admissible traffic and policing would be per-path, but may not be fully known. Security practices would also be per-path, but I wouldn't expect endpoints to have much knowledge of them. > I think the notion of path is quite important if there are multiple > (potential) 'connections' beneath the session. I'm not sure what you mean by 'connections'. I haven't been thinking in terms of multiple 'connections' making up one session; rather I've been thinking of multiple 'paths' behaving as a single 'connection'. (Note, I don't mean to say that a single 'connection' implies a single stream of data.) > If these connections are using different link-layers, there might be > very different RTT, latency, packet loss, etc. for these paths, and that > surely will effect the overall session. I would expect all of these to differ for different 'paths'. Ideally, the "session" management will be able to discover all these. > I think we're already finding issues when running apps with various > small devices over cellular & wifi radios, for example. > > For example, I don't think we have a good understanding of all of the > issues when running traditional TCP congestion control over the myriad > moblity solutions & extensions that the IETF is working on. I'm reasonably sure traditional TCP congestion-control behaves badly under fairly common mobility situations. > This begs the question, should TCP-bis congestion be re-worked? IMHO, yes. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 18:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExSV-00009y-2h; Thu, 02 Mar 2006 18:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExST-00009X-SL for architecture-discuss@ietf.org; Thu, 02 Mar 2006 18:43:45 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExST-0005go-J8 for architecture-discuss@ietf.org; Thu, 02 Mar 2006 18:43:45 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FExSO-000066-W3; Thu, 02 Mar 2006 15:43:41 -0800 Message-Id: <6.2.3.4.2.20060302234953.072194c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 03 Mar 2006 00:05:10 +0100 To: ,, From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Name this concept In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Noki a.com> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-4598345E X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:28 01/03/2006, john.loughney@nokia.com wrote: > >> ... while the Locator is a network layer address, the Endpoint > >> Identifier is a session layer concept, and what we're really saying >is > >> that we need some form of session management layer that lives > >> *above* the transport. > > > > I agree. I'm not particular about the name; but there are > >many reasons to work on "session management": Full agreement. I just add that in my "upper layers" usage architecture perspective it includes content oriented services as well. >With regards to the "session", I think some notion of 'path' is needed. >Path would essentially be the rough data path packets traverse between >the address pairs one the two end-nodes. There is a need to differentiate between the intended/requested/ordered path - something one can repeat, and the real path of the data. I would tend to say route/path ? > Each path will have some >notion of congestion, admission / premption / policing and potentially >security as well. I think the notion of path is quite important if there >are multiple (potential) 'connections' beneath the session. Full agreement. Now can you clarify is the potentional connections are intrinsic or accidental to the session in your vision. I mean do you consider that ends may "weld" different connections with different kind of traffic (data, signals, types of content, etc.)? Do you consider that a session can accept different connections with different ends (like for a conference?). If yes, do you consider them as in a star or as in a meshed network? >If these connections are using different link-layers, there might be >very different RTT, latency, packet loss, etc. for these paths, and that >surely will effect the overall session. I think we're already finding >issues when running apps with various small devices over cellular & wifi >radios, for example. True. But this is also true (not only in technical terms) if you have multiple connection sessions using different technologies, legal domains, encryption, etc). >For example, I don't think we have a good understanding of all of the >issues when running traditional TCP congestion control over the myriad >moblity solutions & extensions that the IETF is working on. This begs >the question, should TCP-bis congestion be re-worked? Probably yes. But if you answered yes to some of the questions, it is not only a point for TCP but a point for a smart end. In that case what about OPES like systems which may assist the end management: are they part of the session or to be differently perceived and named (I call them exchanges). Question: do you accept to consider in your vision multiple asynchornous session as part of a relation obeying to common rules/parameters? >John Loughney > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 18:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExSh-0000F7-Ix; Thu, 02 Mar 2006 18:43:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExSf-0000F2-GV for architecture-discuss@ietf.org; Thu, 02 Mar 2006 18:43:57 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExSe-0005i2-B2 for architecture-discuss@ietf.org; Thu, 02 Mar 2006 18:43:57 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with ESMTP id <20060302234354013001n1d7e>; Thu, 2 Mar 2006 23:43:55 +0000 Message-ID: <44078367.1090509@tony.li> Date: Thu, 02 Mar 2006 15:44:39 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Leslie Subject: Re: [arch-d] Name this concept References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <20060302220456.GA98050@verdi> In-Reply-To: <20060302220456.GA98050@verdi> 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I'm reasonably sure traditional TCP congestion-control behaves badly > under fairly common mobility situations. I think that it's been pretty widely documented that current TCP congestion-control pretty much goes in the can with as little as 1% packet loss. Folks have demonstrated that employing FEC, for example, can dramatically improve these types of situations. However, this is again a subject for transport folks to work on, and really isn't rightfully an architectural subject, IMHO. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 19:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExnc-0007OL-Og; Thu, 02 Mar 2006 19:05:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FExnb-0007Mr-6a for architecture-discuss@ietf.org; Thu, 02 Mar 2006 19:05:35 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FExnX-0007wC-Us for architecture-discuss@ietf.org; Thu, 02 Mar 2006 19:05:35 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B1A9E042A; Thu, 2 Mar 2006 19:05:32 -0500 (EST) Date: Thu, 2 Mar 2006 19:05:31 -0500 From: John Leslie To: Randy Presuhn Subject: Re: [arch-d] Name this concept Message-ID: <20060303000531.GC98050@verdi> References: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Randy Presuhn wrote: > From: > ... >> With regards to the "session", I think some notion of 'path' is needed. >> Path would essentially be the rough data path packets traverse between >> the address pairs one the two end-nodes. Each path will have some >> notion of congestion, admission / premption / policing and potentially >> security as well. I think the notion of path is quite important if there >> are multiple (potential) 'connections' beneath the session. >> >> If these connections are using different link-layers, there might be >> very different RTT, latency, packet loss, etc. for these paths, and that >> surely will effect the overall session. I think we're already finding >> issues when running apps with various small devices over cellular & wifi >> radios, for example. > ... > > I think this leads naturally to the conclusion that when > an session / association is created, the application could > specify the bounds for the end-to-end QoS, which would in > turn serve to constrain the underlying transport parameters, I do think this would be helpful... > including the decision whether to use connection-oriented or > connection-less transport (or even both). I can wrap my mind around the idea that a "session" could use a connection-less transport; but I find it confusing: it immediately brings up the question, "What does 'connectionless session' mean? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 19:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEy0B-00077m-Ky; Thu, 02 Mar 2006 19:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEy0B-00076G-5v for architecture-discuss@ietf.org; Thu, 02 Mar 2006 19:18:35 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEy09-0000CL-Qj for architecture-discuss@ietf.org; Thu, 02 Mar 2006 19:18:35 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C2800E0434; Thu, 2 Mar 2006 19:18:32 -0500 (EST) Date: Thu, 2 Mar 2006 19:18:32 -0500 From: John Leslie To: Schumacher Laurent Subject: Re: [arch-d] Name this concept Message-ID: <20060303001832.GD98050@verdi> References: <44069C8F.4050605@info.fundp.ac.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44069C8F.4050605@info.fundp.ac.be> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Schumacher Laurent wrote: > John Leslie wrote : > >> I agree. I'm not particular about the name; but there are many >> reasons to work on "session management": >> >> - mobility; >> - security; >> - congestion; >> - pre-emption; >> - Quality-of-Service; >> - et cetera. >> > Isn't it what Session Initiation Protocol (SIP, RFC 3261) is addressing? To tell truth, I don't know. I took RFC3261 at its word: " " SIP is an agile, general-purpose tool for creating, modifying, and " terminating sessions that works independently of underlying transport " protocols and without dependency on the type of session that is being " established. ... which is pretty open-ended. OTOH, it goes into so many details of multimedia that I'm left scratching my head whether it can deal with anything else. In any case, when I say "TCP-bis session" I'm thinking of ordinary stuff like web-surfing, instant messaging, and email, not multimedia. Perhaps someone else can enlighten us whether SIP sessions are the right animal to be discussing? (I'd be happy to start saying "SIP session" instead of "TCP-bis session"...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 02 22:06:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0cS-0007Lj-8T; Thu, 02 Mar 2006 22:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF0cR-0007Fq-3N for architecture-discuss@ietf.org; Thu, 02 Mar 2006 22:06:15 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF0cP-0007DI-QW for architecture-discuss@ietf.org; Thu, 02 Mar 2006 22:06:15 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2336Ac13367; Thu, 2 Mar 2006 22:06:10 -0500 (EST) Received: from [127.0.0.1] ([47.130.18.23] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 22:05:53 -0500 Message-ID: <4407B28C.9010903@nortel.com> Date: Thu, 02 Mar 2006 22:05:48 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Leslie Subject: Re: [arch-d] Name this concept References: <44069C8F.4050605@info.fundp.ac.be> <20060303001832.GD98050@verdi> In-Reply-To: <20060303001832.GD98050@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 03:05:53.0102 (UTC) FILETIME=[61E04EE0:01C63E6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Schumacher Laurent , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org SIP's strength lies in achieving rendezvous. It is not a transport protocol, though some would use it that way. With multimedia and with any other application, the details of flow specification are in the message body, not technically part of the SIP protocol itself. SIP does have protocol support for the negotiation process before the session is set up. John Leslie wrote: > Schumacher Laurent wrote: > >>John Leslie wrote : >> >> >>>I agree. I'm not particular about the name; but there are many >>>reasons to work on "session management": >>> >>>- mobility; >>>- security; >>>- congestion; >>>- pre-emption; >>>- Quality-of-Service; >>>- et cetera. >>> >> >>Isn't it what Session Initiation Protocol (SIP, RFC 3261) is addressing? > > > To tell truth, I don't know. I took RFC3261 at its word: > " > " SIP is an agile, general-purpose tool for creating, modifying, and > " terminating sessions that works independently of underlying transport > " protocols and without dependency on the type of session that is being > " established. > > ... which is pretty open-ended. OTOH, it goes into so many details of > multimedia that I'm left scratching my head whether it can deal with > anything else. > > In any case, when I say "TCP-bis session" I'm thinking of ordinary > stuff like web-surfing, instant messaging, and email, not multimedia. > > Perhaps someone else can enlighten us whether SIP sessions are > the right animal to be discussing? (I'd be happy to start saying > "SIP session" instead of "TCP-bis session"...) > > -- > John Leslie > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 03:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF5XV-0008Bv-Ml; Fri, 03 Mar 2006 03:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF5XU-0008A9-BU for architecture-discuss@ietf.org; Fri, 03 Mar 2006 03:21:28 -0500 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF5XT-0001mF-1Z for architecture-discuss@ietf.org; Fri, 03 Mar 2006 03:21:28 -0500 Received: from h-64-105-34-78.snvacaid.dynamic.covad.net ([64.105.34.78] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FF5XS-0004TC-00 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 03:21:26 -0500 Message-ID: <000001c63e9b$b98fcd60$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> <20060303000531.GC98050@verdi> Subject: Re: [arch-d] Name this concept Date: Thu, 2 Mar 2006 17:41:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "John Leslie" > To: "Randy Presuhn" > Cc: > Sent: Thursday, March 02, 2006 4:05 PM > Subject: Re: [arch-d] Name this concept ... > I can wrap my mind around the idea that a "session" could use a > connection-less transport; but I find it confusing: it immediately > brings up the question, "What does 'connectionless session' mean? ... I'm not sure calling a session "connectionless" is helpful. An example of something which could sensibly be modeled as a session employing a connectionless transport would be SNMPv3 auth-priv (including initial clock synchronization) over UDP. There's no connection in any traditional sense, and reordering of packets (within a temporal window) is tolerated, but there is definitely an "association" or "session" in terms of authentication keys, privacy keys, and clock sync (not to be confused in any way with what goes on in protocols like NTP)for each pair of engines communicating on behalf of some user. This has resurfaced in the discussions of the isms working group. Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 09:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBDM-0008IF-Gq; Fri, 03 Mar 2006 09:25:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBDL-0008Ht-GN for architecture-discuss@ietf.org; Fri, 03 Mar 2006 09:25:03 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBDL-00073U-AJ for architecture-discuss@ietf.org; Fri, 03 Mar 2006 09:25:03 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FFBDJ-0007od-Tm; Fri, 03 Mar 2006 06:25:02 -0800 Message-Id: <6.2.3.4.2.20060303130216.069d5810@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 03 Mar 2006 13:03:03 +0100 To: John Leslie ,Randy Presuhn From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Name this concept In-Reply-To: <20060303000531.GC98050@verdi> References: <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> <20060303000531.GC98050@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-70301B28 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 01:05 03/03/2006, John Leslie wrote: >I can wrap my mind around the idea that a "session" could use a >connection-less transport; but I find it confusing: it immediately >brings up the question, "What does 'connectionless session' mean? Signals? Semaphores? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDl5-0003RP-3j; Fri, 03 Mar 2006 12:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDl4-0003QQ-PL for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:08:02 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDl4-000528-3A for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:08:02 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id B27F3E043B; Fri, 3 Mar 2006 12:08:00 -0500 (EST) Date: Fri, 3 Mar 2006 12:08:00 -0500 From: John Leslie To: Wesley Eddy Subject: Re: [arch-d] Name this concept Message-ID: <20060303170800.GB60506@verdi> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <20060302210236.GB5094@grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060302210236.GB5094@grc.nasa.gov> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Wesley Eddy wrote: > On Wed, Mar 01, 2006 at 03:28:08PM +0200, john.loughney@nokia.com wrote: > >> For example, I don't think we have a good understanding of all of the >> issues when running traditional TCP congestion control over the myriad >> moblity solutions & extensions that the IETF is working on. This begs >> the question, should TCP-bis congestion be re-worked? > > This has been looked at a little and discussed some in TSVWG and TCPM. > > Currently, two internet-drafts that modify TCP to deal better with > different kinds of connectivity changes are being merged together: > https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12091 " The basic idea is to trigger a speculative retransmission attempt when " a TCP implementation receives an indication that connectivity to a " previously unreachable peer node may have returned. > and > https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=10165 " This document describes a TCP option that allows a connection endpoint " to inform a peer when it changes location. This document also outlines " the proper congestion control behavior that should take place in the " face of such network layer mobility. For our purposes, I think the second is more interesting... " ACKs received for packets sent on the old path do not indicate the " congestion state of the new path, and should not be used in the " computation of TCP's congestion window. Agreed. " Slow-start based probing from the initial window should take place in " the new path, with the slow-start threshold (SS_THRESH) reset to its " initial value. This is not attractive -- unless we can arrange for the slow-start to overlap transmission across the old path for long enough to reach stability, or at least equivalent bandwidth to the old path. " 3. Congestion Control Issues with Subnet Change "... " During the transitional period, when MN moves from Old to New Subnet, " AR-1 might not be able to deliver packets it receives which are " addressed for MN. This could result in a large burst of packet loss. ... quite unrelated to congestion, of course. " To address this, there are several suggested means of doing "fast" or " "seamless" handovers, which involve adding machinery in the ARs to " buffer and redirect packets originally sent to the Old Subnet, to the " New Subnet... " In the alternative scenario, all packets destined to " are forwarded to by AR-1 by some means This, of course, depends upon a middle-box which knows that one end is mobile. I think we should discuss architecture, not engineering, and that the discussion is simpler without middle-boxes. I also think it's conceptually simpler to consider the computer(s) to receive packets on multiple IP addresses. Among other things, this keeps path characteristics differentiated and more obvious. YMMV... > The two questions that remain, even if these changes to TCP are actually > adopted are: > > 1) What are the standard signals from lower layers that TCP can use to > trigger such actions? I think getting these nailed down is an > important part of the protocol architecture. Obviously, there's packet loss. Explicit congestion notification would certainly be interesting. Possibly transit time might give some hints. But perhaps you mean explicit messages generated at one layer and passed to another. I'd prefer not to go there, since 1) it's engineering, not architecture; 2) they're so easily forged; 3) automated interpretation is dangerous; 4) if generated at all, they're likely to get dropped along the way. Some equivalent of cell-tower handoffs may be worth discussing; but I'm worried it might prove too expensive to implement. As a general rule, we'd do well to limit discussion of signals-from-lower-layers to cases with major and obvious benefits. > 2) Do we require a mandate that other protocols that rely on estimates > of path state adopt similar mechanisms for responding to lower layer > change indications? I doubt we could enforce such a mandate. But if we do things right, our mechanisms will prove attractive. > https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12376 > is a starting point for the discussion. " This document summarizes current proposals, describes the architectural " issues and provides examples of appropriate and inappropriate uses of " link layer indications. 50 pages. (I haven't read every word.) " 1.4.1. Internet Layer " " The Internet layer is the primary consumer of link indications, as " one of its functions is to shield applications from the specifics of " link behavior. This is accomplished by validating and filtering link " indications and selecting outgoing and incoming interfaces based on " routing metrics. This deals mainly with link-up and link-down from a routing perspective. " 1.4.2. Transport Layer " " The Transport layer processes Internet layer and link indications " differently for the purposes of transport parameter estimation and " connection management. A bunch of good stuff here, which I won't repeat. " As described in Appendix A.3, the algorithms for improving transport " parameter estimates using link layer indications are still under " development. Good reading there, too, which I won't repeat. " 1.4.3. Application Layer " " The Transport layer provides indications to the Application layer by " propagating Internet layer indications (such as IP address " configuration and changes), as well as providing its own indications, " such as connection teardown. Not sure how applicable this section is... " 2. Architectural Considerations Eleven good points here (which I won't repeat). ==== -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:13:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDqd-0005ul-VY; Fri, 03 Mar 2006 12:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDqc-0005uV-3s for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:13:46 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDqW-0005H7-S9 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:13:46 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 6679234044; Fri, 3 Mar 2006 12:13:38 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:13:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Re: Name this concept Date: Fri, 3 Mar 2006 12:13:36 -0500 Message-ID: <936A4045C332714F975800409DE0924001E54422@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: Name this concept Thread-Index: AcY+NVrhoWwgwJdERmOKzy+H9+tNxQAsG5sg From: "Bound, Jim" To: "Tony Li" , "Fred Baker" X-OriginalArrivalTime: 03 Mar 2006 17:13:38.0146 (UTC) FILETIME=[CFCE1420:01C63EE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I believe at the transport. /jim=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Thursday, March 02, 2006 3:10 PM > To: Fred Baker > Cc: John Leslie; architecture-discuss@ietf.org; Bound, Jim > Subject: Re: [arch-d] Re: Name this concept >=20 >=20 > Fred, >=20 > Do we want this flexibility in the transport protocol? Or=20 > should it be > in a lower layer? >=20 > Tony >=20 >=20 > Fred Baker wrote: > > for the record, I was postulating TCP as we know it today,=20 > but with at > > least one (announce-address) and perhaps two (withdraw-address) new > > options. The comment about "reliable receipt" presumed the > > acknowledgment of a TCP segment that contained such an option. > >=20 > > As you say, the details of TCP are engineering more than=20 > architecture. > > As you otherwise noted, I think SCTP is a good thing, but I=20 > don't see a > > need to discard TCP. I do see a need to change it in some=20 > way similar to > > this. > >=20 > > On Mar 1, 2006, at 2:16 AM, John Leslie wrote: > >=20 > >> Fred certainly doesn't mean TCP-as-we-know-it-today; but it might > >> be better to say "TCP-bis"... > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:15:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDrw-0006rS-NJ; Fri, 03 Mar 2006 12:15:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDrw-0006qK-Bh for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:15:08 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDrv-0005I8-4f for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:15:08 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 29D64E043B; Fri, 3 Mar 2006 12:15:07 -0500 (EST) Date: Fri, 3 Mar 2006 12:15:07 -0500 From: John Leslie To: Tony Li Subject: Re: [arch-d] Name this concept Message-ID: <20060303171506.GC60506@verdi> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <20060302220456.GA98050@verdi> <44078367.1090509@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44078367.1090509@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > To: John Leslie > >> I'm reasonably sure traditional TCP congestion-control behaves badly >> under fairly common mobility situations. > > I think that it's been pretty widely documented that current TCP > congestion-control pretty much goes in the can with as little as 1% > packet loss. Folks have demonstrated that employing FEC, for example, > can dramatically improve these types of situations. Agreed. > However, this is again a subject for transport folks to work on, and > really isn't rightfully an architectural subject, IMHO. It's certainly an architectural subject _whether_ this beongs at the transport level. And, IMHO, it's an architectural subject whether transport is getting enough information to effectively deal with the issue; or whether better information would be available at some other layer. (In short, I don't agree that such a subject should be off-limits for architectural discussions.) Clearly, Forward Error Correction is an appropriate tool at some level. We don't want to get into engineering details of how it's done; but a "TCP-bis session" might well want to recommend its use, and might have better information on suggested parameters. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDvV-0000Zv-P2; Fri, 03 Mar 2006 12:18:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDvU-0000WF-Ee for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:18:48 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDvR-0005MW-56 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:18:48 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id DBE2B35AB2; Fri, 3 Mar 2006 12:18:44 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:18:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Fri, 3 Mar 2006 12:18:11 -0500 Message-ID: <936A4045C332714F975800409DE0924001E54433@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY+RV55XFKnx73MSuuEsVnIVBcNZgAoOY0w From: "Bound, Jim" To: "John Leslie" , X-OriginalArrivalTime: 03 Mar 2006 17:18:13.0034 (UTC) FILETIME=[73A6A8A0:01C63EE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org contrary to somes wishes end nodes are going to have more knowledge of path through a new services plane that will exist as client even on a handheld thus assuming the ends will not have some knowledge to transfer or report from that path I would suggest is not a good assumption. /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Thursday, March 02, 2006 5:05 PM > To: john.loughney@nokia.com > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Name this concept >=20 > john.loughney@nokia.com wrote: > > To: , > >=20 > >>> ... while the Locator is a network layer address, the Endpoint > >>> Identifier is a session layer concept, and what we're=20 > really saying > >>> is that we need some form of session management layer that lives > >>> *above* the transport. > >>=20 > >> I agree. I'm not particular about the name; but there are > >> many reasons to work on "session management": > >>=20 > >> - mobility; > >> - security; > >> - congestion; > >> - pre-emption; > >> - Quality-of-Service; > >> - et cetera. > >=20 > > With regards to the "session", I think some notion of=20 > 'path' is needed. > > Path would essentially be the rough data path packets=20 > traverse between > > the address pairs one the two end-nodes.=20 >=20 > Let me see if I understand... A "session" (your quotes) is defined > by end-points, ports, and whatever; a 'path' is whatever limited > knowledge the "session" management at each end-point may have about > how packets get from one end to the other. Conceptually, there may be > multiple paths in each direction for packet transfer. >=20 > > Each path will have some notion of congestion, admission /=20 > premption / > > policing and potentially security as well. >=20 > I agree that congestion, pre-emption, etc. are per-path. Rules on > admissible traffic and policing would be per-path, but may=20 > not be fully > known. Security practices would also be per-path, but I=20 > wouldn't expect > endpoints to have much knowledge of them. >=20 > > I think the notion of path is quite important if there are multiple > > (potential) 'connections' beneath the session. =20 >=20 > I'm not sure what you mean by 'connections'. I haven't=20 > been thinking > in terms of multiple 'connections' making up one session; rather I've > been thinking of multiple 'paths' behaving as a single 'connection'. > (Note, I don't mean to say that a single 'connection' implies a single > stream of data.) >=20 > > If these connections are using different link-layers, there might be > > very different RTT, latency, packet loss, etc. for these=20 > paths, and that > > surely will effect the overall session.=20 >=20 > I would expect all of these to differ for different=20 > 'paths'. Ideally, > the "session" management will be able to discover all these. >=20 > > I think we're already finding issues when running apps with various > > small devices over cellular & wifi radios, for example. =20 > >=20 > > For example, I don't think we have a good understanding of=20 > all of the > > issues when running traditional TCP congestion control over=20 > the myriad > > moblity solutions & extensions that the IETF is working on.=20 >=20 > I'm reasonably sure traditional TCP congestion-control=20 > behaves badly > under fairly common mobility situations. >=20 > > This begs the question, should TCP-bis congestion be re-worked? >=20 > IMHO, yes. >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE0c-0002H0-8v; Fri, 03 Mar 2006 12:24:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE0a-0002Gg-D8 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:24:04 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFE0X-0005ge-5j for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:24:04 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id E0440344F8; Fri, 3 Mar 2006 12:24:00 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:23:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Mar 2006 12:23:28 -0500 Message-ID: <936A4045C332714F975800409DE0924001E5443A@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scope of this mail list ??? Thread-Index: AcY+UzBOiH10PDnJSCqURFoxbCmEKgAk2oxA From: "Bound, Jim" To: "Tony Li" , "John Leslie" X-OriginalArrivalTime: 03 Mar 2006 17:23:29.0878 (UTC) FILETIME=[30813760:01C63EE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org Subject: [arch-d] Scope of this mail list ??? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, you may be right? List, So for the record is this list only concerned with IP layer and routing or are we concerned with all 5 layers of the Internet Protocol Reference Model. Also not all problems will be solved by the IP layer we seem to have some light on but also by transport. Thus not including the transport here seems not possible to me? /jim > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Thursday, March 02, 2006 6:45 PM > To: John Leslie > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Name this concept >=20 > > I'm reasonably sure traditional TCP congestion-control=20 > behaves badly > > under fairly common mobility situations. >=20 >=20 > I think that it's been pretty widely documented that current TCP > congestion-control pretty much goes in the can with as little as 1% > packet loss. Folks have demonstrated that employing FEC, for example, > can dramatically improve these types of situations. >=20 > However, this is again a subject for transport folks to work on, and > really isn't rightfully an architectural subject, IMHO. >=20 > Tony >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:25:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE1d-0002Wv-Qd; Fri, 03 Mar 2006 12:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFE1d-0002Wi-2f for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:25:09 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFE1Z-0005jE-QX for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:25:09 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8F0E8347AD; Fri, 3 Mar 2006 12:25:05 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 12:24:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Fri, 3 Mar 2006 12:24:40 -0500 Message-ID: <936A4045C332714F975800409DE0924001E5443E@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY+WAaEi04t9bK6SDaSV1meBpndqQAj0BQA From: "Bound, Jim" To: "John Leslie" , "Schumacher Laurent" X-OriginalArrivalTime: 03 Mar 2006 17:24:42.0284 (UTC) FILETIME=[5BA97EC0:01C63EE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org SIP is just one incantation of a session but I think it far to limiting to our thinking to say just SIP. SIP is good use case for us I believe. /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Thursday, March 02, 2006 7:19 PM > To: Schumacher Laurent > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Name this concept >=20 > Schumacher Laurent wrote: > > John Leslie wrote : > >=20 > >> I agree. I'm not particular about the name; but there are many > >> reasons to work on "session management": > >> > >> - mobility; > >> - security; > >> - congestion; > >> - pre-emption; > >> - Quality-of-Service; > >> - et cetera. > >> > > Isn't it what Session Initiation Protocol (SIP, RFC 3261)=20 > is addressing? >=20 > To tell truth, I don't know. I took RFC3261 at its word: > "=20 > " SIP is an agile, general-purpose tool for creating, modifying, and > " terminating sessions that works independently of underlying=20 > transport > " protocols and without dependency on the type of session=20 > that is being > " established. >=20 > ... which is pretty open-ended. OTOH, it goes into so many details of > multimedia that I'm left scratching my head whether it can deal with > anything else. >=20 > In any case, when I say "TCP-bis session" I'm thinking of ordinary > stuff like web-surfing, instant messaging, and email, not multimedia. >=20 > Perhaps someone else can enlighten us whether SIP sessions are > the right animal to be discussing? (I'd be happy to start saying > "SIP session" instead of "TCP-bis session"...) >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 12:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEVV-0007Hh-Q1; Fri, 03 Mar 2006 12:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFESw-0003iQ-66 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:53:22 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFELz-0006L9-W8 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 12:46:13 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 561B86D0CC for ; Fri, 3 Mar 2006 12:46:11 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k23HkA3C004672; Fri, 3 Mar 2006 12:46:10 -0500 (EST) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k23HkApb026293; Fri, 3 Mar 2006 12:46:10 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k23Hk5tB026270; Fri, 3 Mar 2006 12:46:05 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id DEDEB4FDF4; Fri, 3 Mar 2006 12:45:29 -0500 (EST) Date: Fri, 3 Mar 2006 12:45:29 -0500 From: Wesley Eddy To: John Leslie Subject: Re: [arch-d] Name this concept Message-ID: <20060303174529.GA18209@grc.nasa.gov> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <20060302210236.GB5094@grc.nasa.gov> <20060303170800.GB60506@verdi> Mime-Version: 1.0 In-Reply-To: <20060303170800.GB60506@verdi> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1572200947==" Errors-To: architecture-discuss-bounces@ietf.org --===============1572200947== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 03, 2006 at 12:08:00PM -0500, John Leslie wrote: >=20 > But perhaps you mean explicit messages generated at one layer and > passed to another. I'd prefer not to go there, since There are two distinct, but related issues: a) local message passing between stack layers on a single host b) signaling relevent properties (address changes, etc) to remote hosts > 1) it's engineering, not architecture; The (lack of) architecture in this regard forces it to be engineered. Engineering solutions in multiple ways for each combination of transport and/or particular link layer > 2) they're so easily forged; And they're easily detected. > 3) automated interpretation is dangerous; Especially if there's no architectural guidance ... > 4) if generated at all, they're likely to get dropped along the way. Why would these be more likely than any other packet to be dropped? -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFECIC5zBuYqbnj3IwRAnz7AJ43i5eMow9uzNosMYro5X/yti8qcACfagM2 WdB11e/FzSZXeNWCqVVp7lY= =4FOd -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- --===============1572200947== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1572200947==-- From architecture-discuss-bounces@ietf.org Fri Mar 03 13:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFEH-0003tH-1N; Fri, 03 Mar 2006 13:42:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFFEF-0003qe-Un for architecture-discuss@ietf.org; Fri, 03 Mar 2006 13:42:15 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFFEE-0008UK-OI for architecture-discuss@ietf.org; Fri, 03 Mar 2006 13:42:15 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4068857; Fri, 03 Mar 2006 13:41:08 -0500 In-Reply-To: <20060303171506.GC60506@verdi> References: <20060301071630.GB31110@verdi> <1AA39B75171A7144A73216AED1D7478D01869D38@esebe100.NOE.Nokia.com> <20060302220456.GA98050@verdi> <44078367.1090509@tony.li> <20060303171506.GC60506@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Name this concept Date: Fri, 3 Mar 2006 13:42:22 -0500 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hello; On Mar 3, 2006, at 12:15 PM, John Leslie wrote: > Tony Li wrote: >> To: John Leslie >> >>> I'm reasonably sure traditional TCP congestion-control behaves badly >>> under fairly common mobility situations. >> >> I think that it's been pretty widely documented that current TCP >> congestion-control pretty much goes in the can with as little as 1% >> packet loss. Folks have demonstrated that employing FEC, for >> example, >> can dramatically improve these types of situations. > > Agreed. > >> However, this is again a subject for transport folks to work on, and >> really isn't rightfully an architectural subject, IMHO. > > It's certainly an architectural subject _whether_ this beongs at > the transport level. > > And, IMHO, it's an architectural subject whether transport is > getting > enough information to effectively deal with the issue; or whether > better > information would be available at some other layer. This is what Fecframe is supposed to do https://www1.ietf.org/mailman/listinfo/fecframe Regards Marshall > > (In short, I don't agree that such a subject should be off-limits > for architectural discussions.) > > Clearly, Forward Error Correction is an appropriate tool at some > level. > We don't want to get into engineering details of how it's done; but a > "TCP-bis session" might well want to recommend its use, and might have > better information on suggested parameters. > > -- > John Leslie > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 15:26:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGr8-0002qk-RB; Fri, 03 Mar 2006 15:26:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFGr7-0002pc-NE for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:26:29 -0500 Received: from smtp4.na.baesystems.com ([63.164.202.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFGr7-0003Xo-F3 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:26:29 -0500 Received: from BLUMS0022.bluelnk.net (blums0022.na.baesystems.com [10.40.96.145]) by smtp4.na.baesystems.com (8.12.10/8.12.10) with ESMTP id k23KQS3V007954 for ; Fri, 3 Mar 2006 15:26:28 -0500 (EST) Received: from blums0001.bluelnk.net (blums0001.na.baesystems.com [10.40.96.101]) by smtp1.na.baesystems.com (8.12.10/8.12.10) with ESMTP id k23KQSe3012144; Fri, 3 Mar 2006 15:26:28 -0500 (EST) Received: from BLUMS0005.bluelnk.net ([10.40.96.105]) by blums0001.bluelnk.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Mar 2006 15:26:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Scope of this mail list ??? Date: Fri, 3 Mar 2006 15:26:27 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Scope of this mail list ??? Thread-Index: AcY+UzBOiH10PDnJSCqURFoxbCmEKgAk2oxAAAZXhsA= From: "Frye, Robert J \(US SSA\)" To: "Bound, Jim" , "Tony Li" , "John Leslie" X-OriginalArrivalTime: 03 Mar 2006 20:26:28.0105 (UTC) FILETIME=[C009B790:01C63F00] X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org As a lurker on the list, I believe the list SHOULD be focused on more than just "IP layer and routing". The issues you have all been discussing, and possible solutions/directions, go to more than "simple" IP layer and routing. Proper ARCHITECTURE discussions shouldn't be limited to particular semi-arbitrary layers of technology, but rather how to address the needs and requirements (of end-users, operators, vendors, etc) in rational ways [not just bandaids built on fixing existing cruft] - and in so doing, partition the solution space (and possibly problem space as well) into whatever layers make sense. Limiting the layers limits the innovation. My $0.02. Rob Frye BAE SYSTEMS CNIR 11487 Sunset Hills Road Reston, VA 20190 (v)703-668-4520 (m)571-331-2846 (e)robert.frye@baesystems.com =20 -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com]=20 Sent: Friday, March 03, 2006 12:23 PM To: Tony Li; John Leslie Cc: architecture-discuss@ietf.org Subject: [arch-d] Scope of this mail list ??? Tony, you may be right? List, So for the record is this list only concerned with IP layer and routing or are we concerned with all 5 layers of the Internet Protocol Reference Model. Also not all problems will be solved by the IP layer we seem to have some light on but also by transport. Thus not including the transport here seems not possible to me? /jim > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Thursday, March 02, 2006 6:45 PM > To: John Leslie > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Name this concept >=20 > > I'm reasonably sure traditional TCP congestion-control=20 > behaves badly > > under fairly common mobility situations. >=20 >=20 > I think that it's been pretty widely documented that current TCP > congestion-control pretty much goes in the can with as little as 1% > packet loss. Folks have demonstrated that employing FEC, for example, > can dramatically improve these types of situations. >=20 > However, this is again a subject for transport folks to work on, and > really isn't rightfully an architectural subject, IMHO. >=20 > Tony >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 15:38:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFH39-0006oP-8P; Fri, 03 Mar 2006 15:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFH37-0006oK-S4 for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:38:53 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFH36-00041h-Mc for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:38:53 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5E23F86AED; Fri, 3 Mar 2006 15:38:52 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Scope of this mail list ??? Message-Id: <20060303203852.5E23F86AED@mercury.lcs.mit.edu> Date: Fri, 3 Mar 2006 15:38:52 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" > is this list only concerned with IP layer and routing or are we > concerned with all 5 layers Well, I certainly think that the entire ensemble of components (which can be roughly grouped into layers) are suitable for discussion here. Deciding where in the modularity to put functions is (as someone just pointed out) the very essence of architecture. A perfect example is the recentq discussion of whether or not support for use of multiple locations belongs below or above the reliable stream layer... I don't recall if the list has a charter, and if so what it says, but the name alone ("architecture-discuss@ietf.org") seems to be fairly generic. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 03 15:47:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHB4-0006jh-Tw; Fri, 03 Mar 2006 15:47:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHB3-0006Yj-El for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:47:05 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFHB0-0004Dg-TP for architecture-discuss@ietf.org; Fri, 03 Mar 2006 15:47:05 -0500 Received: (qmail invoked by alias); 03 Mar 2006 20:47:01 -0000 Received: from dslb-084-057-226-189.pools.arcor-ip.net (EHLO hive) [84.57.226.189] by mail.gmx.net (mp009) with SMTP; 03 Mar 2006 21:47:01 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [arch-d] Scope of this mail list ??? Date: Fri, 03 Mar 2006 21:48:18 +0100 Message-ID: References: <20060303203852.5E23F86AED@mercury.lcs.mit.edu> In-Reply-To: <20060303203852.5E23F86AED@mercury.lcs.mit.edu> X-Mailer: Forte Agent 3.2/32.830 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org * Noel Chiappa wrote: >I don't recall if the list has a charter, and if so what it says, but the >name alone ("architecture-discuss@ietf.org") seems to be fairly generic. https://www1.ietf.org/mailman/listinfo/architecture-discuss has The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions. Discussions that drill down and dwell on specifics of individual protocols or technologies are to be discouraged, redirected to appropriate other fora, or re-cast to discussions of broader implications for Internet architecture. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Mar 05 07:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFslV-0002lI-D4; Sun, 05 Mar 2006 07:55:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFslU-0002lD-1E for architecture-discuss@ietf.org; Sun, 05 Mar 2006 07:55:12 -0500 Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFslT-00053b-JH for architecture-discuss@ietf.org; Sun, 05 Mar 2006 07:55:12 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k25CsnrE003026; Sun, 5 Mar 2006 14:54:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 14:54:34 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 14:54:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Sun, 5 Mar 2006 14:54:34 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869D9B@esebe100.NOE.Nokia.com> In-Reply-To: <936A4045C332714F975800409DE0924001E53951@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9Aggmz5nP1wSiSVaqMpcdY4K3WwAL8+HgAAhr6WAAwBY/oA== From: To: , , X-OriginalArrivalTime: 05 Mar 2006 12:54:34.0421 (UTC) FILETIME=[F3D95E50:01C64053] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim, That is one solution for it, and I think something that would work now. I was bumping up to a higher-view. John=20 >-----Original Message----- >From: ext Bound, Jim [mailto:Jim.Bound@hp.com]=20 >Sent: 01 March, 2006 19:16 >To: Loughney John (Nokia-NRC/Helsinki); john@jlc.net; fred@cisco.com >Cc: architecture-discuss@ietf.org >Subject: RE: [arch-d] Name this concept > >John, good point but I think the IP-Session-ID for say=20 >multiple transport connections is more of a conrol plane=20 >transport where as for example the SCTP associations=20 >underneath are specific instances of transport connection that=20 >would weigh in on the overall nodes knowledge of the transport=20 >connection. Also each connection for each media layer would=20 >need to provide metrics for that network path as you state=20 >regarding hints and intelligence and security. > >/jim=20 > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Wednesday, March 01, 2006 8:28 AM >> To: john@jlc.net; fred@cisco.com >> Cc: architecture-discuss@ietf.org; Bound, Jim >> Subject: RE: [arch-d] Name this concept >>=20 >> John, >>=20 >> A quick additional point: >>=20 >> >> ... while the Locator is a network layer address, the Endpoint=20 >> >> Identifier is a session layer concept, and what we're=20 >really saying >> is >> >> that we need some form of session management layer that lives >> >> *above* the transport. >> > >> > I agree. I'm not particular about the name; but there are many=20 >> >reasons to work on "session management": >> > >> >- mobility; >> >- security; >> >- congestion; >> >- pre-emption; >> >- Quality-of-Service; >> >- et cetera. >>=20 >> With regards to the "session", I think some notion of 'path'=20 >> is needed. >> Path would essentially be the rough data path packets=20 >traverse between=20 >> the address pairs one the two end-nodes. Each path will have some=20 >> notion of congestion, admission / premption / policing and=20 >potentially=20 >> security as well. I think the notion of path is quite important if=20 >> there are multiple (potential) 'connections' beneath the session. >>=20 >> If these connections are using different link-layers, there might be=20 >> very different RTT, latency, packet loss, etc. for these paths, and=20 >> that surely will effect the overall session. I think we're already=20 >> finding issues when running apps with various small devices over=20 >> cellular & wifi radios, for example. >>=20 >> For example, I don't think we have a good understanding of=20 >all of the=20 >> issues when running traditional TCP congestion control over=20 >the myriad=20 >> moblity solutions & extensions that the IETF is working on. =20 >This begs=20 >> the question, should TCP-bis congestion be re-worked? >>=20 >> John Loughney >>=20 > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Mar 05 07:57:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsne-0004OP-7m; Sun, 05 Mar 2006 07:57:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFsnd-0004N0-Bx for architecture-discuss@ietf.org; Sun, 05 Mar 2006 07:57:25 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFsnb-00055X-VL for architecture-discuss@ietf.org; Sun, 05 Mar 2006 07:57:25 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k25CttAP001421; Sun, 5 Mar 2006 14:55:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 14:57:22 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Mar 2006 14:57:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Sun, 5 Mar 2006 14:57:22 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869D9C@esebe100.NOE.Nokia.com> In-Reply-To: <002501c63d61$6c87d0c0$6401a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY9Yx7999KEZImKRoWtbmHssYmR2wC8Phxg From: To: , X-OriginalArrivalTime: 05 Mar 2006 12:57:22.0769 (UTC) FILETIME=[58313C10:01C64054] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Randy, =20 >I think this leads naturally to the conclusion that when an=20 >session / association is created, the application could=20 >specify the bounds for the end-to-end QoS, which would in turn=20 >serve to constrain the underlying transport parameters,=20 >including the decision whether to use connection-oriented or=20 >connection-less transport (or even both). Maybe, but what about real-time applications that can renegotiate=20 codecs? I've been thinking of a session-shim layer that would be able to propigate up some info about the current association characteristics, so if the upperlayer needed to react to changes in the underlying connectivity, that would be available. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 06:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEDf-0005MC-Jd; Mon, 06 Mar 2006 06:49:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEDe-0005Kp-Mc for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:49:42 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEDe-0005cD-7X for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:49:42 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BnLd6021291; Mon, 6 Mar 2006 13:49:25 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:49:15 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:49:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Mon, 6 Mar 2006 13:49:14 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DCE@esebe100.NOE.Nokia.com> In-Reply-To: <20060302210236.GB5094@grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY+PMm9RQmEOASVR0GV+fQMxEiWwwC1uBgg From: To: X-OriginalArrivalTime: 06 Mar 2006 11:49:15.0846 (UTC) FILETIME=[FE9C0660:01C64113] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Wes, >This has been looked at a little and discussed some in TSVWG and TCPM. > >Currently, two internet-drafts that modify TCP to deal better=20 >with different kinds of connectivity changes are being merged together: >https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 12 091 >and >https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 10 165 >The merged version is not yet available, and (sadly) there=20 >hasn't been a strong WG response that this is even a valid=20 >issue that requires work. > >The two questions that remain, even if these changes to TCP=20 >are actually adopted are: > > 1) What are the standard signals from lower layers that TCP can use to > trigger such actions? I think getting these nailed down is an > important part of the protocol architecture. > > 2) Do we require a mandate that other protocols that rely on estimates > of path state adopt similar mechanisms for responding to lower layer > change indications? > >https://datatracker.ietf.org/public/idindex.cgi?command=3Did_detail&id=3D= 12 376 >is a starting point for the discussion. These are really good points, actually this could form good input to some things like SHIM6 - I think the triggers are a important issue - I wonder if this would be tied into the IP over Foo documents, for each potential Foo layer. Additionally, there is a lot of work going on in groups like DNA (Detecting Network Attachment) where the above drafts could have some discussion. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 06:52:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEFt-0007Mg-0x; Mon, 06 Mar 2006 06:52:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEFr-0007IZ-OJ for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:51:59 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEFq-0005gx-As for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:51:59 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BoPcx015293; Mon, 6 Mar 2006 13:50:25 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:51:56 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:51:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Mon, 6 Mar 2006 13:51:54 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DCF@esebe100.NOE.Nokia.com> In-Reply-To: <20060302220456.GA98050@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY+RV/vszh32HGhSeaZybxXiBJjeACzrmFw From: To: X-OriginalArrivalTime: 06 Mar 2006 11:51:55.0413 (UTC) FILETIME=[5DB80450:01C64114] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, >> I think the notion of path is quite important if there are multiple >> (potential) 'connections' beneath the session. =20 > > I'm not sure what you mean by 'connections'. I haven't been=20 >thinking in terms of multiple 'connections' making up one=20 >session; rather I've been thinking of multiple 'paths'=20 >behaving as a single 'connection'. >(Note, I don't mean to say that a single 'connection' implies=20 >a single stream of data.) Well, maybe this is some part of the terminology we should nail down, or we will get completely lost. I was thinking that a session would be name for multiple paths, especially if separate TCP connections (for example) were used. >> If these connections are using different link-layers, there might be=20 >> very different RTT, latency, packet loss, etc. for these paths, and=20 >> that surely will effect the overall session. > > I would expect all of these to differ for different=20 >'paths'. Ideally, the "session" management will be able to=20 >discover all these. Agreed. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 06:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEIg-00016k-KW; Mon, 06 Mar 2006 06:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEIf-00016f-6g for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:54:53 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEIe-0005mV-PP for architecture-discuss@ietf.org; Mon, 06 Mar 2006 06:54:53 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26BrjF7021260; Mon, 6 Mar 2006 13:53:46 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:54:42 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 13:54:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Name this concept Date: Mon, 6 Mar 2006 13:54:41 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Nokia.com> In-Reply-To: <6.2.3.4.2.20060302234953.072194c0@mail.jefsey.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Name this concept Thread-Index: AcY+UynST+4Pp/56QyyoQ+XECqwwEwCwUZxw From: To: , , X-OriginalArrivalTime: 06 Mar 2006 11:54:42.0632 (UTC) FILETIME=[C1639C80:01C64114] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org JFC, >Full agreement. Now can you clarify is the potentional=20 >connections are intrinsic or accidental to the session in your=20 >vision. I mean do you consider that ends may "weld" different=20 >connections with different kind of traffic (data, signals,=20 >types of content, etc.)? Do you consider that a session can=20 >accept different connections with different ends (like for a=20 >conference?). If yes, do you consider them as in a star or as=20 >in a meshed network? I'm considering that the final endpoints of the communication would be the same - host-to-host sessions. I think multiparty communication is a different issue. >>If these connections are using different link-layers, there might be=20 >>very different RTT, latency, packet loss, etc. for these paths, and=20 >>that surely will effect the overall session. I think we're already=20 >>finding issues when running apps with various small devices over=20 >>cellular & wifi radios, for example. > >True. But this is also true (not only in technical terms) if=20 >you have multiple connection sessions using different=20 >technologies, legal domains, encryption, etc). Agreed. >>For example, I don't think we have a good understanding of all of the=20 >>issues when running traditional TCP congestion control over the myriad >>moblity solutions & extensions that the IETF is working on. =20 >This begs the question, should TCP-bis congestion be re-worked? > >Probably yes. But if you answered yes to some of the=20 >questions, it is not only a point for TCP but a point for a=20 >smart end. In that case what about OPES like systems which may=20 >assist the end management: are they part of the session or to=20 >be differently perceived and named (I call them exchanges). > >Question: do you accept to consider in your vision multiple=20 >asynchornous session as part of a relation obeying to common=20 >rules/parameters? If I understand you correctly, this is above the session layer, and more at the application layer. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 07:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFBQ-0002x7-Ka; Mon, 06 Mar 2006 07:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFBP-0002r5-6u for architecture-discuss@ietf.org; Mon, 06 Mar 2006 07:51:27 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFBN-000800-MC for architecture-discuss@ietf.org; Mon, 06 Mar 2006 07:51:27 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k26CpJQk217230 for ; Mon, 6 Mar 2006 12:51:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k26CpdeB234280 for ; Mon, 6 Mar 2006 13:51:39 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k26CpJvW015997 for ; Mon, 6 Mar 2006 13:51:19 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k26CpIrl015987; Mon, 6 Mar 2006 13:51:19 +0100 Received: from zurich.ibm.com (sig-9-145-251-242.de.ibm.com [9.145.251.242]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA60016; Mon, 6 Mar 2006 13:51:18 +0100 Message-ID: <440C303E.1060704@zurich.ibm.com> Date: Mon, 06 Mar 2006 13:51:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> In-Reply-To: <43F69DC1.5040805@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Oh Tony, you've woken me up ;-) Tony Li wrote: > Thomas, > > Architectural proposals have been lofted. They were specific, had clear > migration plans, and the discussion was shut down with the usual "v6 has > already shipped" dogma. Specific topics were: > > - GSE (more generally locator/identifier splits) > - locator agile transport protocols > > Without these types of capabilities, the architecture is stuck > supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT > in the host), and various forms of tunneling. I don't understand why you disparage SHIM6 (end-to-end NAT-in-the-host) but don't disparage GSE (edge-to-edge NAT-in-the-router). It was thinking about the end-to-end problems created by GSE that led directly to the conception of SHIM6. If one is a kludge, so is the other. They both result in the upper layer protocol using a different "address" than the routing system to identify a session. Viewed at an appropriate distance, they are isomorphic. The common point is that by doing *and undoing* the NAT action at both ends, the essential end-to-end properties of IP datagrams are not destroyed. Viewed at a slightly greater distance, they are both isomorphic with map-and-encap. > > To truly move forward, we first need to have consensus on the following: > > - We have a problem. Which needs to be described with precision > - The current crop of solutions are unsatisfactory. Which needs to be justified. > - We are willing to make changes. Who's we? That's not intended flippantly - "we" would need to figure out in detail exactly who needs to be on board. Brian > > Until then, we have the status quo. > > Tony > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 08:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFOn-0004k2-Vy; Mon, 06 Mar 2006 08:05:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGFOm-0004ju-Mk for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:05:16 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGFOj-0001Ps-Cu for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:05:16 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 0B287340A6; Mon, 6 Mar 2006 08:05:13 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 08:05:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches Date: Mon, 6 Mar 2006 08:05:11 -0500 Message-ID: <936A4045C332714F975800409DE0924001EBBCD1@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcZBHLVirlWQNVXaSI2muE6QbXVNjgAARsdg From: "Bound, Jim" To: "Brian E Carpenter" X-OriginalArrivalTime: 06 Mar 2006 13:05:13.0129 (UTC) FILETIME=[9AF63990:01C6411E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Brian, agree with you below 100%. One point. And I am on board for SHIM6 as you and Eric N. know (but still have SCTP bias but won't move on that unless Randy works on SHIM6 too I see no point without his support/help). We are moving in deployment land for NGN to end-to-end security model and most of the commercial Internet architects in enterprises (customers with PHD's in Computer Science et al) I speak with agree and also the security agency type folks in multiple geographies within multiple governments that end-to-end securiity is a stronger model than current model and that is longgggggggggggg discussion but just take me at face value for now. Also wireless affects everything as you know. As long as the edges do not have to look at the payload because it is encrypted and can just forward the packet from the IP header then all is ok, but if not that is still an issue regarding end-to-end for SHIM6? Thoughts? thanks /jim=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Monday, March 06, 2006 7:51 AM > To: Tony Li > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Valid and Invalid Internet=20 > architectures and approaches >=20 > Oh Tony, you've woken me up ;-) >=20 > Tony Li wrote: > > Thomas, > >=20 > > Architectural proposals have been lofted. They were=20 > specific, had clear > > migration plans, and the discussion was shut down with the=20 > usual "v6 has > > already shipped" dogma. Specific topics were: > >=20 > > - GSE (more generally locator/identifier splits) > > - locator agile transport protocols > >=20 > > Without these types of capabilities, the architecture is stuck > > supporting multihoming and mobility with kludges such as=20 > NAT, SHIM6 (NAT > > in the host), and various forms of tunneling. >=20 > I don't understand why you disparage SHIM6 (end-to-end=20 > NAT-in-the-host) > but don't disparage GSE (edge-to-edge NAT-in-the-router). It=20 > was thinking > about the end-to-end problems created by GSE that led directly to the > conception of SHIM6. If one is a kludge, so is the other.=20 > They both result > in the upper layer protocol using a different "address" than=20 > the routing > system to identify a session. Viewed at an appropriate distance, they > are isomorphic. >=20 > The common point is that by doing *and undoing* the NAT=20 > action at both ends, > the essential end-to-end properties of IP datagrams are not destroyed. > Viewed at a slightly greater distance, they are both isomorphic with > map-and-encap. >=20 > >=20 > > To truly move forward, we first need to have consensus on=20 > the following: > >=20 > > - We have a problem. >=20 > Which needs to be described with precision >=20 > > - The current crop of solutions are unsatisfactory. >=20 > Which needs to be justified. >=20 > > - We are willing to make changes. >=20 > Who's we? That's not intended flippantly - "we" would need to > figure out in detail exactly who needs to be on board. >=20 > Brian > >=20 > > Until then, we have the status quo. > >=20 > > Tony > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 08:47:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGG3Y-0003JI-8l; Mon, 06 Mar 2006 08:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGG3Y-0003JB-0y for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:47:24 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGG3W-0002Fx-JZ for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:47:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id k26DlLVV132002 for ; Mon, 6 Mar 2006 13:47:21 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k26DlfeB221422 for ; Mon, 6 Mar 2006 14:47:41 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k26DlKNN003801 for ; Mon, 6 Mar 2006 14:47:21 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k26DlKdx003789; Mon, 6 Mar 2006 14:47:20 +0100 Received: from zurich.ibm.com (sig-9-145-251-242.de.ibm.com [9.145.251.242]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA35888; Mon, 6 Mar 2006 14:47:19 +0100 Message-ID: <440C3D64.9080805@zurich.ibm.com> Date: Mon, 06 Mar 2006 14:47:16 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <936A4045C332714F975800409DE0924001EBBCD1@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE0924001EBBCD1@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Jim, > As long as the edges do not have to look at the payload because it is > encrypted and can just forward the packet from the IP header then all is > ok, but if not that is still an issue regarding end-to-end for SHIM6? Unless they changed something since I stopped being active in shim6, it really has no impact on IPSec - the addresses are flipped after the crypto computation at the sender and before the crypto computation at the receiver. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 08:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGCV-0004Xp-NQ; Mon, 06 Mar 2006 08:56:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGGCT-0004SO-Ue for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:56:37 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGGCT-0002n6-CZ for architecture-discuss@ietf.org; Mon, 06 Mar 2006 08:56:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3225A89898; Mon, 6 Mar 2006 15:56:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BFDB889897; Mon, 6 Mar 2006 15:56:35 +0200 (EET) Message-ID: <440C3F93.2060606@piuha.net> Date: Mon, 06 Mar 2006 15:56:35 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard , Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tim, I agree -- and would add that often the IETF succeeds better when it gets to start from a relatively mature proposal, with architecture and early designs worked out by a smaller group. I think we should encourage this, particularly on areas that simultaneously have hard problems, a number of possible alternative designs, designs that deviate significantly from what we have now, no clear consensus on what the right solution is, and when we are looking at an important function. Obviously, it is impossible to provide any sort of guarantees about the end result, other than that serious proposals will be considered. Whether that consideration results in a real change in IETF specifications would have to be decided when we know what is being proposed, what the benefits are, what the deployment implications are, etc. However, what we can do is to encourage work on these areas. In some cases the IRTF/IETF has even assisted efforts with the publication of Experimental RFCs, RGs, etc. Also, independent of solutions I would also encourage working with others in the IETF to provide problem statements, allowing us to understand better what issues we currently have. --Jari Tim Shepard wrote: >(I'm behind on e-mail reading, and I'm responding to a message from 5 >days ago.) > >Tony Li said: > > > >>Thomas, >> >> >> >>>Actually, I don't think the IAB is the right place for this to happen, >>>at least not to get it going. >>> >>> >>Just to be crystal clear: I am *not* suggesting that the IAB actually be >>the work force for this. I *am* asking that the IAB clearly articulate >>its openness to accept and standardize architectural changes to v6 at >>this point. >> >> > >I think that is asking for *way* too much. Whether or not any >architectural changes are going to be accepted and standardized >depends on what those changes are and what the consequences would be. >If/when any such changes are proposed, the community will evaluate >them and decide. The IAB is merely part of that community. > >The problem is that figuring out what is going to be the right thing >to do is (at this point, at least) a matter of research. And opinions >will vary. > >There's nothing stopping anyone from investigating new architectures, >writing protocol specifications, writing papers discussing the ideas, >building prototype implementations, and teaching others about their work. > >The IAB holds no veto over what research can happen in network >architecture, design, and implementation. > >And if the IAB or IESG were to make any statement that some particular >proposal will not proceed within the IETF process, that is not an >irreversible decision. > >For example, the folk working on HIP were told at the London IETF >that HIP could not proceed within the IETF as its advocates wished. >They kept on working on it anyway (and IMHO have made a valuable >contribution to the field of network architecture). > >I wish HIP were not the only such example in the last 5 years. It >would be nice if there were a number of architected, designed, >implemented, and (experementally) deployed worked examples >demonstrating alternative ways of doing things. Running code that >can be read alongside protocol specifications and architecture >documents is very valuable. > > > > >>>The first step is to get a small design team together ... >>> >>> >>Before that can happen, the design team members need to know that their >>work can possibly succeed. Right now, no one is willing to invest in >>this because the outcome seems preordained. Only the IAB is really in a >>position to reverse this. >> >>Tony >> >> > >I disagree. Anybody can reverse this if they are willing to invest >effort into seeing an idea along. > >HIP got to where it is today through slow recruitment (over 7 years) >into an expanding community of fans through hallway conversations at >IETF meetings and other venues. The IAB has, AFAIK, no power to >regulate what people talk about in the hallways of IETF meetings, >nor in the larger networking research community. > >If you want to move an idea within the IETF community, I suggest (1) >write it down as clearly as you can (anyone can publish an internet >draft on anything), and (2) recruit fans of the idea, and (3) to >your hallway conversations at IETF meetings (and to the larger >networking research community), bring open-source prototype >implementations that you can demo and let other people read and test >drive. > >The IAB and IESG are in charge of the IETF process. They do not >control the fate of ideas. The community does. > >I hope this is helpful. > > -Tim Shepard > shep@alum.mit.edu > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 10:16:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHRU-0006hd-4d; Mon, 06 Mar 2006 10:16:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGHRT-0006hY-3P for architecture-discuss@ietf.org; Mon, 06 Mar 2006 10:16:11 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGHRO-0005fU-R6 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 10:16:11 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 4FDFE34351; Mon, 6 Mar 2006 10:16:06 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 10:16:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches Date: Mon, 6 Mar 2006 10:16:02 -0500 Message-ID: <936A4045C332714F975800409DE0924001EBBDD6@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcZBJIDJkPXgyB7iTuO/85ulhiKccwACv6FQ From: "Bound, Jim" To: "Brian E Carpenter" X-OriginalArrivalTime: 06 Mar 2006 15:16:06.0217 (UTC) FILETIME=[E3C45B90:01C64130] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Brian, still tracking and reading it and not giving implementation input yet till it matures but IMO it is very close, but that is still the case you state below, and for any solutions we do need to do the same as SHIM6 did assuming nothing is exposed except the IP header (e.g. for QoS, Streaming Media, Network Management). Caveat is with IPv6 there could be a DST, HOP-BY-HOP, others.. option before the IPsec SPI after the IP header. There is a proposal now in ITU to use IPv6 option for QoS data per Dr. Larry Roberts as you probably know, which we rejected here in the IETF for the time being. NB: Also as a note as long time IETF member I am very happy and impressed with your IETF Chair Leadership and do notice the subtle but evolutionary changes for the IETF and our community and attention to detail on our processes (I LOVE the new Dinner model :--)). Good job sir. And out of the IETF I am far more supportive of the progress we are making to streamline deliverables regarding time-to-market which is very important out of the IETF for us to not be avoided, and trust me on that one :--). Thanks /jim=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Monday, March 06, 2006 8:47 AM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Valid and Invalid Internet=20 > architectures and approaches >=20 > Hi Jim, >=20 > > As long as the edges do not have to look at the payload=20 > because it is > > encrypted and can just forward the packet from the IP=20 > header then all is > > ok, but if not that is still an issue regarding end-to-end=20 > for SHIM6? >=20 > Unless they changed something since I stopped being active in shim6, > it really has no impact on IPSec - the addresses are flipped after > the crypto computation at the sender and before the crypto computation > at the receiver. >=20 > Brian >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 17:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOHo-0001yQ-KZ; Mon, 06 Mar 2006 17:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOHn-0001vV-Ja for architecture-discuss@ietf.org; Mon, 06 Mar 2006 17:34:39 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNN9-0008H5-FU for architecture-discuss@ietf.org; Mon, 06 Mar 2006 16:36:07 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGN18-0004yY-Lp for architecture-discuss@ietf.org; Mon, 06 Mar 2006 16:13:24 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2006 13:13:23 -0800 X-IronPort-AV: i="4.02,168,1139212800"; d="scan'208"; a="259892447:sNHT33863048" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k26LDLGv015754; Mon, 6 Mar 2006 13:13:21 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k26LFH3t027728; Mon, 6 Mar 2006 13:15:17 -0800 In-Reply-To: <4407512F.7050400@tony.li> References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> <9D4DC053-CDC5-4866-87AC-8DEE2AC89109@cisco.com> <4407512F.7050400@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65ABA869-E603-4FB7-AF76-E93942A89CDC@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Re: Name this concept Date: Mon, 6 Mar 2006 13:13:21 -0800 To: Tony Li X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1835; t=1141679718; x=1142111918; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Re=3A=20Name=20this=20concept |To:Tony=20Li=20; X=v=3Dmtcc.com=3B=20h=3DviXFQGQZZQJXoei85rKlF+5o1co=3D; b=gp30bs1paUlUJdqQlL4oAY0nIMgvAuFi8L637wiyqXVc7Iqg1WsTB/W0qAo2wkKQuvkIcmeW PtZ51J2JczbLl0nRng8NtJfDN1JZ/c4n2oJE11n5hwl7+zryYrtmPMATNhZkCfBSvBZPzlp31VU YN3TwU9h/3hoQvjSeW0PHQOA=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mar 2, 2006, at 12:10 PM, Tony Li wrote: > Fred, > > Do we want this flexibility in the transport protocol? Or should > it be > in a lower layer? That's up for discussion. I think we want the transport to be able to handle changes of address at the network layer, and as I said there are cases in which network connectivity can be completely lost using one address and and later restored using another. If the transport session cannot be re-targeted to the new address with appropriate security, we have a problem. That says we somehow want to have the retargeting happen. Next question is "same layer or one in between". I would tend to think of the one in between as being an API demultiplexing layer, which sounds to me like a sublayer of the transport. That's not a firm position, but my current hunch, and squares with the current SCTP implementation. > Fred Baker wrote: >> for the record, I was postulating TCP as we know it today, but >> with at >> least one (announce-address) and perhaps two (withdraw-address) new >> options. The comment about "reliable receipt" presumed the >> acknowledgment of a TCP segment that contained such an option. >> >> As you say, the details of TCP are engineering more than >> architecture. >> As you otherwise noted, I think SCTP is a good thing, but I don't >> see a >> need to discard TCP. I do see a need to change it in some way >> similar to >> this. >> >> On Mar 1, 2006, at 2:16 AM, John Leslie wrote: >> >>> Fred certainly doesn't mean TCP-as-we-know-it-today; but it might >>> be better to say "TCP-bis"... >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 18:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOik-00089F-Ez; Mon, 06 Mar 2006 18:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGOik-000899-2o for architecture-discuss@ietf.org; Mon, 06 Mar 2006 18:02:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGOih-0005XW-AO for architecture-discuss@ietf.org; Mon, 06 Mar 2006 18:02:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 15:02:27 -0800 X-IronPort-AV: i="4.02,169,1139212800"; d="scan'208"; a="412918443:sNHT34243610" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k26N2Q7T003584 for ; Mon, 6 Mar 2006 15:02:26 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k26N4MKs028771 for ; Mon, 6 Mar 2006 15:04:22 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Fred Baker Date: Mon, 6 Mar 2006 15:02:24 -0800 X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=6297; t=1141686262; x=1142118462; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Defining=20terms |To:architecture-discuss@ietf.org; X=v=3Dmtcc.com=3B=20h=3D3PX95LxhM3/S8EgNwx3OaXcDnjg=3D; b=dr5Z1P2remePqmGcbhnlm8jtVTDJlDapmiOST2abTJ9r+eMit6tKYK+NPPlt1ARQwRCxWTXF gkGDnUADx+RViTRxp2RWCkBRlWUCjK9VnF3e3/H1qkOIYYX3YzkgE4zAn0y/GMvcabzNDiFZ6XS gLcNcqIIVTlZfygIzw3Ti4Sk=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [arch-d] Defining terms X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org OK, so this takes off on one of the many topics we have been discussing... There are a variety of papers that have tried to define the concept of a 'session" in a network that is connectionless at the network layer. I'm not sure what the orgiginal document is, although I am sure that it vastly predates RFC 1144, which is the oldest RFC that seems to use the terms "shared state" and "fate sharing". But bottom line, while the internet layer has no concept of what we now call a "virtual circuit" or "virtual channel", it has been long recognized that the applications and the transports in question have to have some degree of shared state to enable them to function, and that in the event that something goes completely south there is a necessity for "fate sharing" - all systems retaining the shared state have to at some point decide that it is for nought and delete it. I would therefore define a "session" as the shared state in the end systems and in the network, whatever it may be, which directly or indirectly reflects the state of two or more communicating applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), this would include information stored in network nodes, and it generally includes keys associated with security associations, sequence numbers etc in TCP and SCTP, and the various addresses that are used by endpoints in a multihomed route. I would suggest that we start out with a rational definition of the various layers. I include a questioned layer, which I think Tony is alluding to, and the ISO and XNS Session models, which have some history. I suspect that we will have various comments on these architecturally, and when we get this part of the question sorted out, we will have a better notion of what further we might want to say. physical layer: The physical layer is the lowest communication layer, consisting of the physical medium of communication and the means of signaling over it. It is responsible for defining the physical means of sending data, interfacing between network media and devices, and defining the media's optical, electrical and mechanical characteristics. Examples of this include a fiber optic link, in which the means of signaling is transmission of photons of a known frequency in a known pattern, and the reception of those photons, or a radio link, in which the "medium" is electromagnetic space, and the signaling is performed by electromagnetic effects conveyed in that space. link layer: The link layer defines the procedures for operating physical communication links. It encodes network layer data as physical layer signals, and recovers and decodes these signals at the receiving end. It also manages rate of flow and errors on the link, which at minimum means reporting statistics, and may include FEC, retransmission, or other techniques. Examples of this include HDLC, Ethernet, and so on. Network layer: The communication layer that builds networks out of link layer relationships and enables systems to communicate information between systems that are not directly connected at the link layer. The network layer contains at least two major sublayers, and these may be implemented recursively. Intranet Layer: The Intranet layer is the lower sublayer of the network layer. It connects systems that are under common administration, are intended to be connected in a simple manner, and generally applies no administrative policy within the network. Examples of this include X. 25, Frame Relay, ATM, MPLS, IEEE 802.1 Transparent Bridging, IEEE 802.1/802.5 Source-Route Bridging, and IEEE 802.11 wireless networking. Internet Layer: The Internet layer is the upper sublayer of the network layer. It may be used to connect systems under common administration and implementing common policy, but is also commonly used to connect systems under different administration or with differing administrative policy. Internet nodes include the internet layer in hosts or in routers, and each support at least one address by which they are reachable by their administration. In the Internet, IPv4 and IPv6 are examples of the Internet layer. Transport layer: The transport layer is the lowest layer that runs end to end. It may be viewed as the end-to-end counterpart to the link layer, enabling applications running in end systems to communicate effectively across the network connecting them. "Effective communication" are application concepts; many applications call for reliable sequential delivery of data within a transaction, and a subset can handle transactions in arbitrary order. TCP and SCTP are examples of protocols which run at the Transport layer; there are other examples. UDP is not an example of a transport, although it may be considered an example of the multiplexing sublayer of the transport, as the methods used to make communication effective are implemented in the application. Session Layer: As defined by ISO, the session layer manages user sessions and dialogues, controls establishment and termination of logic links between users, and reports upper layer errors. As defined by Xerox Network Systems, the middleware application Courier provided a Remote Procedure Call service in which incoming sessions were all referred to Courier and transferred from there to other applications a deemed appropriate through AAA policy and parameter acquisition procedures. Application Layer: In the Internet, the application generally includes the ISO concept of the presentation layer, which deals with encoding and deciding data. This is the communication layer or program that directly serves the user, whether directly or remotely. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 18:31:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPAa-0002CK-TK; Mon, 06 Mar 2006 18:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPAa-0002CF-0U for architecture-discuss@ietf.org; Mon, 06 Mar 2006 18:31:16 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPAS-0006h5-Q8 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 18:31:15 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 7773B34081 for ; Mon, 6 Mar 2006 18:31:08 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 18:31:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 6 Mar 2006 18:31:06 -0500 Message-ID: <936A4045C332714F975800409DE0924001EBC154@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZBchqjGkJb/Ij4RRKOGlh3bDKfSwAApVXQ From: "Bound, Jim" To: X-OriginalArrivalTime: 06 Mar 2006 23:31:08.0343 (UTC) FILETIME=[0B9D1C70:01C64176] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Folks in what is NCOIC www.ncoic.org we defined the layer between transport and application as infrastructure which leaves far more wiggle room than the OSI concept of "session" in now public document called the NCOIC Interoperability Framework (NIF). It is worth looking at is my input. NB: If someone here would post as URL I can send, it is 894KB I don't have place currently to post? /jim=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 19:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPlE-0005t7-TC; Mon, 06 Mar 2006 19:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPlD-0005oS-OL for architecture-discuss@ietf.org; Mon, 06 Mar 2006 19:09:07 -0500 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPlC-0007ql-IZ for architecture-discuss@ietf.org; Mon, 06 Mar 2006 19:09:07 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with ESMTP id <2006030700090501100kl1u2e>; Tue, 7 Mar 2006 00:09:05 +0000 Message-ID: <440CCEF8.7080503@tony.li> Date: Mon, 06 Mar 2006 16:08:24 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Re: Name this concept References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> <20060301071630.GB31110@verdi> <9D4DC053-CDC5-4866-87AC-8DEE2AC89109@cisco.com> <4407512F.7050400@tony.li> <65ABA869-E603-4FB7-AF76-E93942A89CDC@cisco.com> In-Reply-To: <65ABA869-E603-4FB7-AF76-E93942A89CDC@cisco.com> 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Next question is "same layer or one in between". I would tend to think > of the one in between as being an API demultiplexing layer, which sounds > to me like a sublayer of the transport. That's not a firm position, but > my current hunch, and squares with the current SCTP implementation. Interesting. My preferences would be to have this be wholly underneath transport, as I would hate to have to recreate this functionality separately for each transport protocol. UDP based traffic should be able to take advantage of these mechanisms too. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 19:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPr9-0003Nw-63; Mon, 06 Mar 2006 19:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGPr8-0003Jx-7M for architecture-discuss@ietf.org; Mon, 06 Mar 2006 19:15:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGPr7-00080R-UB for architecture-discuss@ietf.org; Mon, 06 Mar 2006 19:15:14 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2006 16:15:12 -0800 X-IronPort-AV: i="4.02,169,1139212800"; d="scan'208"; a="412939589:sNHT31867272" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k270FB7T011241; Mon, 6 Mar 2006 16:15:12 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k270GcJe029360; Mon, 6 Mar 2006 16:17:07 -0800 In-Reply-To: <440C303E.1060704@zurich.ibm.com> References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> <440C303E.1060704@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Mon, 6 Mar 2006 16:15:09 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=676; t=1141690627; x=1142122827; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Valid=20and=20Invalid=20Internet=20architectures=20an d=20approaches |To:Brian=20E=20Carpenter=20; X=v=3Dmtcc.com=3B=20h=3Dxg44buFZ4R+eh7oLSQbbBpFU+yU=3D; b=IGykIH67D/iEFmm0wSoiRBeOEHpyGgvxySDp9wJYeDkQJYf6M1eCKaJoHoTpePG2PV9B74/9 gJIZlhQmQulV36YMIxZ8dvqXuJxXu3oMQoVjUJTgTId9+aahtXlD6wbEh252/sHzahfTyXUCYvF 2Jt21+1ZtdGexfG3e3gl0oEA=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org not sure I agree with that. Map/encap permits me, knowing the global identity of a remote system, to use a tunnel-or-equivalent to get a message to it. NATs prevent the remote system from having a global identity, which makes it harder for me to send a message to the device. It is for this reason that marketing people sell NAT as a security solution. On Mar 6, 2006, at 4:51 AM, Brian E Carpenter wrote: > The common point is that by doing *and undoing* the NAT action at > both ends, > the essential end-to-end properties of IP datagrams are not destroyed. > Viewed at a slightly greater distance, they are both isomorphic with > map-and-encap. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 20:14:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQm6-0008VG-OI; Mon, 06 Mar 2006 20:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGQm6-0008TG-10 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:14:06 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGQm4-00023u-RE for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:14:06 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with ESMTP id <2006030701140101100ktn60e>; Tue, 7 Mar 2006 01:14:02 +0000 Message-ID: <440CDE30.8030206@tony.li> Date: Mon, 06 Mar 2006 17:13:20 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Defining terms References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> In-Reply-To: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Session Layer: > As defined by ISO, the session layer manages user sessions and > dialogues, controls establishment and termination of logic links between > users, and reports upper layer errors. As defined by Xerox Network > Systems, the middleware application Courier provided a Remote Procedure > Call service in which incoming sessions were all referred to Courier and > transferred from there to other applications a deemed appropriate > through AAA policy and parameter acquisition procedures. IMHO, the session layer should be responsible for authentication and security at a level above the transports. As a primary example, I'll point you to the interesting situation that the X window system has with authentication, and the games that we play with SSH tunneling. If a user has an existing session open with another host, then an application should be able to inherit appropriate authentication credentials from the session layer without a separate interactive authentication step. My $.02, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 20:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRN8-0007LH-VB; Mon, 06 Mar 2006 20:52:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRN7-0007Ib-8t for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:52:21 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRN4-0002yP-Uj for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:52:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 06 Mar 2006 17:52:18 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k271qI7T004333; Mon, 6 Mar 2006 17:52:18 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k271sDp3030082; Mon, 6 Mar 2006 17:54:13 -0800 In-Reply-To: <440CDE30.8030206@tony.li> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <440CDE30.8030206@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94E7D24E-8D79-44F7-B86F-2F1BBBEE0090@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Mon, 6 Mar 2006 17:52:15 -0800 To: Tony Li X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3780; t=1141696453; x=1142128653; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:Tony=20Li=20; X=v=3Dmtcc.com=3B=20h=3DG9DDMON3NC3vaE/Kl7dCin+wRyA=3D; b=Nj+j+xno1zFCmqyyFJ3xmgc7ke7jk49VBbSagBsmXkNWpDdaXdLtVK5clqVe8PFxBIzYcyU5 GQp33nFeRBgaGx19HYdgX9+7QARQwpJ6dCCPHHbDyfUMShSqRYROVRq/9oO4RP5AZOndp74P/2F xrp4CIZ3lSWI86OlgV7TR09w=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mar 6, 2006, at 5:13 PM, Tony Li wrote: >> Session Layer: >> As defined by ISO, the session layer manages user sessions and >> dialogues, controls establishment and termination of logic links >> between users, and reports upper layer errors. As defined by Xerox >> Network Systems, the middleware application Courier provided a >> Remote Procedure Call service in which incoming sessions were all >> referred to Courier and transferred from there to other >> applications a deemed appropriate through AAA policy and parameter >> acquisition procedures. > > IMHO, the session layer should be responsible for authentication > and security at a level above the transports. As a primary > example, I'll point you to the interesting situation that the X > window system has with authentication, and the games that we play > with SSH tunneling. If a user has an existing session open with > another host, then an application should be able to inherit > appropriate authentication credentials from the session layer > without a separate interactive authentication step. Hmm. The place I expected you to respond was: > describe transport, it is a sublayer of the transport layer, > although IPv6 incorporates it and other end-system to end-system > capabilities like fragmentation and reassembly into IPv6. Are these > functions of a session management layer? Is the session management > layer in fact the lowest end-2-end communications layer?> That question was partly a "how do we sort out the session management stuff, which in IPv6 includes fragmentation and assembly of messages and the IPsec header of IPv6?", and partly a response to your query "Do we want this flexibility in the transport protocol? Or should it be in a lower layer?", supported by your later comment On Mar 6, 2006, at 4:08 PM, Tony Li wrote: >> Next question is "same layer or one in between". I would tend to >> think of the one in between as being an API demultiplexing layer, >> which sounds to me like a sublayer of the transport. That's not a >> firm position, but my current hunch, and squares with the current >> SCTP implementation. > > Interesting. My preferences would be to have this be wholly > underneath transport, as I would hate to have to recreate this > functionality separately for each transport protocol. UDP based > traffic should be able to take advantage of these mechanisms too. From this, I conclude that your position includes two of the following: * we need a AAA layer above transport that sets up and tears down sessions securely regardless of the transport used * we need for the lowest end to end layer to be the upper reaches of the network layer, handling session management issues in the way IPv6 does * we need for the lowest end to end layer to be a session management layer between the network and transport layers, handling session management in the way IPsec does in an IPv4 implementation Care to comment further? Personally, if there is a session management sublayer in the network layer, or a session management layer between network and transport, or (as I posited it) a session management sublayer built into the demultiplexing function of the transport, I think we have separated the network layer from transport. That was what I thought we had set out to acheive. I tend to think that anything above transport wants to be a pretty identifiable setup protocol+application (Courier comes to mind, and SIP has some of those characteristics) or should be available to the application through an API. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 20:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRQL-0002zS-Ms; Mon, 06 Mar 2006 20:55:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRQK-0002sv-7d for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:55:40 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRQJ-00033s-W6 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 20:55:40 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGRQH-00073W-DN; Mon, 06 Mar 2006 17:55:37 -0800 Message-Id: <6.2.3.4.2.20060306230458.0630ceb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 06 Mar 2006 23:15:43 +0100 To: ,, From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Name this concept In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Noki a.com> References: <6.2.3.4.2.20060302234953.072194c0@mail.jefsey.com> <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-10627EEC X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:54 06/03/2006, john.loughney@nokia.com wrote: >JFC, > >Full agreement. Now can you clarify is the potentional > >connections are intrinsic or accidental to the session in your > >vision. I mean do you consider that ends may "weld" different > >connections with different kind of traffic (data, signals, > >types of content, etc.)? Do you consider that a session can > >accept different connections with different ends (like for a > >conference?). If yes, do you consider them as in a star or as > >in a meshed network? > >I'm considering that the final endpoints of the communication would >be the same - host-to-host sessions. I think multiparty communication >is a different issue. Communication is a generic term. We are talking of a session and connection. I understand you say it is a different issue. However broadcast, multicats, anycasts are multiparty? > >>If these connections are using different link-layers, there might be > >>very different RTT, latency, packet loss, etc. for these paths, and > >>that surely will effect the overall session. I think we're already > >>finding issues when running apps with various small devices over > >>cellular & wifi radios, for example. > > > >True. But this is also true (not only in technical terms) if > >you have multiple connection sessions using different > >technologies, legal domains, encryption, etc). > >Agreed. > > >>For example, I don't think we have a good understanding of all of the > >>issues when running traditional TCP congestion control over the myriad > > >>moblity solutions & extensions that the IETF is working on. > >This begs the question, should TCP-bis congestion be re-worked? > > > >Probably yes. But if you answered yes to some of the > >questions, it is not only a point for TCP but a point for a > >smart end. In that case what about OPES like systems which may > >assist the end management: are they part of the session or to > >be differently perceived and named (I call them exchanges). > > > >Question: do you accept to consider in your vision multiple > >asynchornous session as part of a relation obeying to common > >rules/parameters? > >If I understand you correctly, this is above the session layer, >and more at the application layer. This is a good question. It is above the session layer since it considers several sessions. But to which extent because: - this can be several sessions in succession. There is no "time layer" yet. - this can be application - same application for all the sessions. - this can be interapplication - different applications throughout the sessions. FYI, my model (ENS, 1985) includes layer 8 interapplications, 9 user agents, 10 users, 11 communicating structures, 12 society and 0 dioptres. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 21:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOw-0001sm-8Z; Mon, 06 Mar 2006 21:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOs-0001qc-8w for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:14 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGSOq-00055e-Vm for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:14 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGSOp-0001aK-UK; Mon, 06 Mar 2006 18:58:12 -0800 Message-Id: <6.2.3.4.2.20060307002248.04dc5530@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 07 Mar 2006 01:10:36 +0100 To: Fred Baker ,architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7B8763EB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 00:02 07/03/2006, Fred Baker wrote: >while the internet layer has no concept of what we now call a >"virtual circuit" or "virtual channel", it has been long recognized >that the applications and the transports in question have to have >some degree of shared state to enable them to function, and that in >the event that something goes completely south there is a necessity >for "fate sharing" - all systems retaining the shared state have to >at some point decide that it is for nought and delete it. Fred, I said I am interested in usage architecture.I will therefore word it differently and generalise. But I think we agree. The user is interested in some form of virtual circuit switch. He understant connexions as whate vehicle the data, and the session as what provides him with the circuit service he needs. Let say the connexions are what the network provides and the session what the user sees. >I would therefore define a "session" as the shared state in the end >systems and in the network, whatever it may be, which directly or >indirectly reflects the state of two or more communicating >applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), >this would include information stored in network nodes, and it >generally includes keys associated with security associations, >sequence numbers etc in TCP and SCTP, and the various addresses that >are used by endpoints in a multihomed route. So, this definition is OK with me. However probably not architecturally general enough. For example a user will accept different connexions through different technologies within a session. >I would suggest tFrom architecture-discuss-bounces@ietf.org Mon Mar 06 21:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOw-0001sm-8Z; Mon, 06 Mar 2006 21:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOs-0001qc-8w for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:14 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGSOq-00055e-Vm for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:14 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGSOp-0001aK-UK; Mon, 06 Mar 2006 18:58:12 -0800 Message-Id: <6.2.3.4.2.20060307002248.04dc5530@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 07 Mar 2006 01:10:36 +0100 To: Fred Baker ,architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7B8763EB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 00:02 07/03/2006, Fred Baker wrote: >while the internet layer has no concept of what we now call a >"virtual circuit" or "virtual channel", it has been long recognized >that the applications and the transports in question have to have >some degree of shared state to enable them to function, and that in >the event that something goes completely south there is a necessity >for "fate sharing" - all systems retaining the shared state have to >at some point decide that it is for nought and delete it. Fred, I said I am interested in usage architecture.I will therefore word it differently and generalise. But I think we agree. The user is interested in some form of virtual circuit switch. He understant connexions as whate vehicle the data, and the session as what provides him with the circuit service he needs. Let say the connexions are what the network provides and the session what the user sees. >I would therefore define a "session" as the shared state in the end >systems and in the network, whatever it may be, which directly or >indirectly reflects the state of two or more communicating >applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), >this would include information stored in network nodes, and it >generally includes keys associated with security associations, >sequence numbers etc in TCP and SCTP, and the various addresses that >are used by endpoints in a multihomed route. So, this definition is OK with me. However probably not architecturally general enough. For example a user will accept different connexions through different technologies within a session. >I would suggest that we start out with a rational definition of the >various layers. I include a questioned layer, which I think Tony is >alluding to, and the ISO and XNS Session models, which have some >history. I suspect that we will have various comments on these >architecturally, and when we get this part of the question sorted >out, we will have a better notion of what further we might want to say. As usage oriented, I will add a few layers: Dioptres layers all the dioptres in the physical layer. These are the computer systems, the different kind of techologies, the impact of external changes. For example crossing a boarder (rates, law, language, etc.) >physical layer: >link layer: >Network layer: >Intranet Layer: >Internet Layer: >Transport layer: >Session Layer: >Application Layer: I consider the users system as part of the network architecture. 1. this makes three different main layers: - infrastructure - basic service to the data - interconnexion - superstructure - value added services to the enveloppe - interoperability - metastrucuture - extended services to the content - interintelligibility 2. this makes subnetwork layers to be considered. - intranets at infrastructural layer (you noted it) - externet at superstructural layer (external network look-alike using the network resources) - sets (spaces of exchanges, trust and services) at metastructural layer - what users perceive as relational/service network. 3. I will add the ENSM (extended network system model) upper layers: Interapplications layer Manage relations independently from the network technologies and the way their similar applications behave. Assist in preparing a uniform interintelligibility Agent layer Assitance to the user in interfacing the applications. User Users and communities. Their common understanding of the way to use the system is the system brainware. Digital cultures varies (most probably increasingly) among nations, languages, cultures, communities, ages, etc. Communicating structures Many factors modify the communications strategies and abilities of a structure. A communications architecture must have the necessary parameters to adapt. Society The way the society perceives, develops and rule its digital ecosystem has an obvious impact in its communications solutions. (ex. WSIS) Maintenance, Operations and Brainware (consensual usage ways) are not layers as such but they must be embedded in the architecture. Different elements must be considered as part of an architecture: - security and trust - multilingualism - independence from and equal support of every language, culture, etc - user identification, privacy and empowerment (control of his global network zone) - statistics and billing - evolution and transition jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 21:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOs-0001qh-DA; Mon, 06 Mar 2006 21:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOr-0001qW-O1 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:13 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGSOr-00055f-GF for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:13 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGSOm-0001aK-3z; Mon, 06 Mar 2006 18:58:08 -0800 Message-Id: <6.2.3.4.2.20060306230458.0630ceb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 07 Mar 2006 03:57:58 +0100 To: ,, From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Name this concept In-Reply-To: <1AA39B75171Ahat we start out with a rational definition of the >various layers. I include a questioned layer, which I think Tony is >alluding to, and the ISO and XNS Session models, which have some >history. I suspect that we will have various comments on these >architecturally, and when we get this part of the question sorted >out, we will have a better notion of what further we might want to say. As usage oriented, I will add a few layers: Dioptres layers all the dioptres in the physical layer. These are the computer systems, the different kind of techologies, the impact of external changes. For example crossing a boarder (rates, law, language, etc.) >physical layer: >link layer: >Network layer: >Intranet Layer: >Internet Layer: >Transport layer: >Session Layer: >Application Layer: I consider the users system as part of the network architecture. 1. this makes three different main layers: - infrastructure - basic service to the data - interconnexion - superstructure - value added services to the enveloppe - interoperability - metastrucuture - extended services to the content - interintelligibility 2. this makes subnetwork layers to be considered. - intranets at infrastructural layer (you noted it) - externet at superstructural layer (external network look-alike using the network resources) - sets (spaces of exchanges, trust and services) at metastructural layer - what users perceive as relational/service network. 3. I will add the ENSM (extended network system model) upper layers: Interapplications layer Manage relations independently from the network technologies and the way their similar applications behave. Assist in preparing a uniform interintelligibility Agent layer Assitance to the user in interfacing the applications. User Users and communities. Their common understanding of the way to use the system is the system brainware. Digital cultures varies (most probably increasingly) among nations, languages, cultures, communities, ages, etc. Communicating structures Many factors modify the communications strategies and abilities of a structure. A communications architecture must have the necessary parameters to adapt. Society The way the society perceives, develops and rule its digital ecosystem has an obvious impact in its communications solutions. (ex. WSIS) Maintenance, Operations and Brainware (consensual usage ways) are not layers as such but they must be embedded in the architecture. Different elements must be considered as part of an architecture: - security and trust - multilingualism - independence from and equal support of every language, culture, etc - user identification, privacy and empowerment (control of his global network zone) - statistics and billing - evolution and transition jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 06 21:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOs-0001qh-DA; Mon, 06 Mar 2006 21:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGSOr-0001qW-O1 for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:13 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGSOr-00055f-GF for architecture-discuss@ietf.org; Mon, 06 Mar 2006 21:58:13 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGSOm-0001aK-3z; Mon, 06 Mar 2006 18:58:08 -0800 Message-Id: <6.2.3.4.2.20060306230458.0630ceb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 07 Mar 2006 03:57:58 +0100 To: ,, From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Name this concept In-Reply-To: <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Noki a.com> References: <6.2.3.4.2.20060302234953.072194c0@mail.jefsey.com> <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7B8763EB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:54 06/03/2006, john.loughney@nokia.com wrote: >JFC, > >Full agreement. Now can you clarify is the potentional > >connections are intrinsic or accidental to the session in your > >vision. I mean do you consider that ends may "weld" different > >connections with different kind of traffic (data, signals, > >types of content, etc.)? Do you consider that a session can > >accept different connections with different ends (like for a > >conference?). If yes, do you consider them as in a star or as > >in a meshed network? > >I'm considering that the final endpoints of the communication would >be the same - host-to-host sessions. I think multiparty communication >is a different issue. Communication is a generic term. We are talking of a session and connection. I understand you say it is a different issue. However broadcast, multicats, anycasts are multiparty? > >>If these connections are using different link-layers, there might be > >>very different RTT, latency, packet loss, etc. for these paths, and > >>that surely will effect the overall session. I think we're already > >>finding issues when running apps with various small devices over > >>cellular & wifi radios, for example. > > > >True. But this is also true (not only in technical terms) if > >you have multiple connection sessions using different > >technologies, legal domains, encryption, etc). > >Agreed. > > >>For example, I don't think we have a good understanding of all of the > >>issues when running traditional TCP congestion control over the myriad > > >>moblity solutions & extensions that the IETF is working on. > >This begs the question, should TCP-bis congestion be re-worked? > > > >Probably yes. But if you answered yes to some of the > >questions, it is not only a point for TCP but a point for a > >smart end. In that case what about OPES like systems which may > >assist the end management: are they part of the session or to > >be differently perceived and named (I call them exchanges). > > > >Question: do you accept to consider in your vision multiple > >asynchornous session as part of a relation obeying to common > >rules/parameters? > >If I understand you correctly, this is above the session layer, >and more at the application layer. This is a good question. It is above the session layer since it considers several sessions. But to which extent because: - this can be several sessions in succession. There is no "time layer" yet. - this can be application - same application for all the sessions. - this can be interapplication - different applications throughout the sessions. FYI, my model (ENS, 1985) in7144A73216AED1D7478D01869DD0@esebe100.NOE.Noki a.com> References: <6.2.3.4.2.20060302234953.072194c0@mail.jefsey.com> <1AA39B75171A7144A73216AED1D7478D01869DD0@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7B8763EB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org, Jim.Bound@hp.com X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:54 06/03/2006, john.loughney@nokia.com wrote: >JFC, > >Full agreement. Now can you clarify is the potentional > >connections are intrinsic or accidental to the session in your > >vision. I mean do you consider that ends may "weld" different > >connections with different kind of traffic (data, signals, > >types of content, etc.)? Do you consider that a session can > >accept different connections with different ends (like for a > >conference?). If yes, do you consider them as in a star or as > >in a meshed network? > >I'm considering that the final endpoints of the communication would >be the same - host-to-host sessions. I think multiparty communication >is a different issue. Communication is a generic term. We are talking of a session and connection. I understand you say it is a different issue. However broadcast, multicats, anycasts are multiparty? > >>If these connections are using different link-layers, there might be > >>very different RTT, latency, packet loss, etc. for these paths, and > >>that surely will effect the overall session. I think we're already > >>finding issues when running apps with various small devices over > >>cellular & wifi radios, for example. > > > >True. But this is also true (not only in technical terms) if > >you have multiple connection sessions using different > >technologies, legal domains, encryption, etc). > >Agreed. > > >>For example, I don't think we have a good understanding of all of the > >>issues when running traditional TCP congestion control over the myriad > > >>moblity solutions & extensions that the IETF is working on. > >This begs the question, should TCP-bis congestion be re-worked? > > > >Probably yes. But if you answered yes to some of the > >questions, it is not only a point for TCP but a point for a > >smart end. In that case what about OPES like systems which may > >assist the end management: are they part of the session or to > >be differently perceived and named (I call them exchanges). > > > >Question: do you accept to consider in your vision multiple > >asynchornous session as part of a relation obeying to common > >rules/parameters? > >If I understand you correctly, this is above the session layer, >and more at the application layer. This is a good question. It is above the session layer since it considers several sessions. But to which extent because: - this can be several sessions in succession. There is no "time layer" yet. - this can be application - same application for all the sessions. - this can be interapplication - different applications throughout the sessions. FYI, my model (ENS, 1985) includes layer 8 interapplications, 9 user agents, 10 users, 11 communicating structures, 12 society and 0 dioptres. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss cludes layer 8 interapplications, 9 user agents, 10 users, 11 communicating structures, 12 society and 0 dioptres. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 03:08:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXFL-0001Z6-Rz; Tue, 07 Mar 2006 03:08:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXFJ-0001YT-LI for architecture-discuss@ietf.org; Tue, 07 Mar 2006 03:08:41 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGXFI-0007PV-Eb for architecture-discuss@ietf.org; Tue, 07 Mar 2006 03:08:41 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006030708083901400e4hkoe>; Tue, 7 Mar 2006 08:08:39 +0000 Message-ID: <440D3F5D.6090000@tony.li> Date: Tue, 07 Mar 2006 00:07:57 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Defining terms References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <440CDE30.8030206@tony.li> <94E7D24E-8D79-44F7-B86F-2F1BBBEE0090@cisco.com> In-Reply-To: <94E7D24E-8D79-44F7-B86F-2F1BBBEE0090@cisco.com> 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From this, I conclude that your position includes two of the following: > > * we need a AAA layer above transport that sets up and tears down sessions > securely regardless of the transport used > * we need for the lowest end to end layer to be the upper reaches of the > network layer, handling session management issues in the way IPv6 does > * we need for the lowest end to end layer to be a session management layer > between the network and transport layers, handling session management in > the way IPsec does in an IPv4 implementation > > Care to comment further? At first blush, I would tend toward the third bullet, and also include that the transport endpoint is defined in terms of the session layer, so that it's possible to have session layer mobility, complete with connection migration. Note that I'm not certain that the session layer belongs "between" the network layer and transport layer. It is certainly a functionality provided to the transport and independent of the network, but it's ancillary, not a pre-requisite for operations. In much the same way, the routing subsystem is an adjunct of the network layer, not closely coupled to it. More generally, what we think of as network layering should probably be more of a lattice than a stack. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 03:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXbB-0001gU-UM; Tue, 07 Mar 2006 03:31:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGXaT-0007Qh-0U for architecture-discuss@ietf.org; Tue, 07 Mar 2006 03:30:33 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGXZ5-0000Cs-D8 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 03:29:09 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with ESMTP id <2006030708290201200ireqhe>; Tue, 7 Mar 2006 08:29:02 +0000 Message-ID: <440D4424.6060308@tony.li> Date: Tue, 07 Mar 2006 00:28:20 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> <440C303E.1060704@zurich.ibm.com> In-Reply-To: <440C303E.1060704@zurich.ibm.com> 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Brian, >> Without these types of capabilities, the architecture is stuck >> supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT >> in the host), and various forms of tunneling. > > I don't understand why you disparage SHIM6 (end-to-end NAT-in-the-host) > but don't disparage GSE (edge-to-edge NAT-in-the-router). It was thinking > about the end-to-end problems created by GSE that led directly to the > conception of SHIM6. I don't consider NAT to be disparagement -- just taxonomy. Yes, architecturally NAT is a kludge, but I'm fine with judiciously applied kludges. Sometimes kludges are *THE* pragmatic approach to forward progress. If you have further questions concerning my tolerance for kludges, I suggest that you consult any of my former IOS development colleagues -- they will probably give you an earful. ;-) As to GSE, I'm not sure that I consider GSE to be in the exact same realm as NAT. Yes, architecturally, swapping locators around offends my sense of preserving the pristine packet (as does modifying the DSCP), but inherently the locator is an ephemeral entity, much as a transient MAC address on the frame, somewhere in the middle of a transit ISP. In GSE, the EID is the true invariant in the packet, providing end-to-end context. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 05:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZ5u-0004O3-Gg; Tue, 07 Mar 2006 05:07:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZ5t-0004Nt-Po for architecture-discuss@ietf.org; Tue, 07 Mar 2006 05:07:05 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZ5s-0004mS-Hx for architecture-discuss@ietf.org; Tue, 07 Mar 2006 05:07:05 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Mar 2006 02:07:04 -0800 X-IronPort-AV: i="4.02,170,1139212800"; d="scan'208"; a="312199317:sNHT31484756" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k27A73w1010741; Tue, 7 Mar 2006 02:07:03 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k27A8woF032203; Tue, 7 Mar 2006 02:08:58 -0800 In-Reply-To: <440D3F5D.6090000@tony.li> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <440CDE30.8030206@tony.li> <94E7D24E-8D79-44F7-B86F-2F1BBBEE0090@cisco.com> <440D3F5D.6090000@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <886BD35E-F65C-40A0-BB31-A6291D7C3C14@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Tue, 7 Mar 2006 02:07:01 -0800 To: Tony Li X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=595; t=1141726138; x=1142158338; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:Tony=20Li=20; X=v=3Dmtcc.com=3B=20h=3DQ6i5v+I4DAiPX1+UXPo56M1xid8=3D; b=JmHXB9rWQ1SuDWdkNnw6YzvcEWNjNJZDMicHvnURo4+PisESWd+255XZ74rtLchDDdbgRkTE 2SrcYqAg0pPEe0al06Rjpkc/Q9Yqbjqrgmy6VMlBLeYlZZNviVpfTzeQxrppM3RjGhpKOstJimI nE7jQXVGdmNQtzOZX2mlxsI8=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mar 7, 2006, at 12:07 AM, Tony Li wrote: > Note that I'm not certain that the session layer belongs "between" the > network layer and transport layer. It is certainly a functionality > provided to the transport and independent of the network, but it's > ancillary, not a pre-requisite for operations. In much the same way, > the routing subsystem is an adjunct of the network layer, not closely > coupled to it. More generally, what we think of as network layering > should probably be more of a lattice than a stack. OK, no problem. Give me better words for my discussion. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 06:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZzy-0000g9-FT; Tue, 07 Mar 2006 06:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGZzw-0000g2-Gy for architecture-discuss@ietf.org; Tue, 07 Mar 2006 06:05:00 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGZzv-0006Uk-3L for architecture-discuss@ietf.org; Tue, 07 Mar 2006 06:05:00 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k27B4vnk239398 for ; Tue, 7 Mar 2006 11:04:57 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k27B5Dk6216364 for ; Tue, 7 Mar 2006 11:05:13 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k27B4vB1018901 for ; Tue, 7 Mar 2006 11:04:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k27B4uqr018880; Tue, 7 Mar 2006 11:04:56 GMT Received: from zurich.ibm.com (sig-9-146-222-120.de.ibm.com [9.146.222.120]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA71030; Tue, 7 Mar 2006 12:04:55 +0100 Message-ID: <440D68D5.2080601@zurich.ibm.com> Date: Tue, 07 Mar 2006 12:04:53 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Baker Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> <440C303E.1060704@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Fred Baker wrote: > not sure I agree with that. > > Map/encap permits me, knowing the global identity of a remote system, > to use a tunnel-or-equivalent to get a message to it. NATs prevent the > remote system from having a global identity, which makes it harder for > me to send a message to the device. It is for this reason that > marketing people sell NAT as a security solution. Single ended NAT, for sure. I was talking about double ended NAT, where there is some sort of e2e identity. Admittedly, there are probably precisely zero of those deployed today. Brian > > On Mar 6, 2006, at 4:51 AM, Brian E Carpenter wrote: > >> The common point is that by doing *and undoing* the NAT action at >> both ends, >> the essential end-to-end properties of IP datagrams are not destroyed. >> Viewed at a slightly greater distance, they are both isomorphic with >> map-and-encap. > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 06:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaoE-0001nv-Ig; Tue, 07 Mar 2006 06:56:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGaoD-0001nq-Av for architecture-discuss@ietf.org; Tue, 07 Mar 2006 06:56:57 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGao9-00089J-31 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 06:56:57 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id CA231340C9; Tue, 7 Mar 2006 06:56:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 06:56:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 7 Mar 2006 06:56:51 -0500 Message-ID: <936A4045C332714F975800409DE0924001EBC1FE@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZBhIQl2yXmhRfkQWi/uM/mfpZb/QAWapeg From: "Bound, Jim" To: "Tony Li" , "Fred Baker" X-OriginalArrivalTime: 07 Mar 2006 11:56:52.0810 (UTC) FILETIME=[3964F2A0:01C641DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org this is an important part for discussion and debated widely. I agree with Tony. /jim=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Monday, March 06, 2006 8:13 PM > To: Fred Baker > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 >=20 > > Session Layer: > > As defined by ISO, the session layer manages user sessions and > > dialogues, controls establishment and termination of logic=20 > links between > > users, and reports upper layer errors. As defined by Xerox Network > > Systems, the middleware application Courier provided a=20 > Remote Procedure > > Call service in which incoming sessions were all referred=20 > to Courier and > > transferred from there to other applications a deemed appropriate > > through AAA policy and parameter acquisition procedures. >=20 >=20 > IMHO, the session layer should be responsible for authentication and > security at a level above the transports. As a primary example, I'll > point you to the interesting situation that the X window=20 > system has with > authentication, and the games that we play with SSH tunneling. If a > user has an existing session open with another host, then an=20 > application > should be able to inherit appropriate authentication credentials from > the session layer without a separate interactive authentication step. >=20 > My $.02, > Tony >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 09:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGd53-0001gf-An; Tue, 07 Mar 2006 09:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGd52-0001gW-3C for architecture-discuss@ietf.org; Tue, 07 Mar 2006 09:22:28 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGd52-0004SD-18 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 09:22:28 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGd4d-0006aU-73 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 09:22:05 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 07 Mar 2006 06:22:02 -0800 X-IronPort-AV: i="4.02,171,1139212800"; d="scan'208"; a="1782601715:sNHT37588366" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k27ELx1l002003 for ; Tue, 7 Mar 2006 06:22:02 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 09:21:59 -0500 Received: from cisco.com ([10.86.240.24]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Mar 2006 09:21:59 -0500 Date: Tue, 7 Mar 2006 09:21:06 -0500 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060307142105.GA588@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 07 Mar 2006 14:21:59.0146 (UTC) FILETIME=[7EC664A0:01C641F2] X-Spam-Score: -2.6 (--) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote: > I would therefore define a "session" as the shared state in the end > systems and in the network, whatever it may be, which directly or > indirectly reflects the state of two or more communicating > applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), > this would include information stored in network nodes, and it > generally includes keys associated with security associations, > sequence numbers etc in TCP and SCTP, and the various addresses that > are used by endpoints in a multihomed route. This is a great start, but I think it needs to be refined. Elsewhere people have come up with the concept that a "session" is a relationship -- not a pipe, not a flow of packets -- created to align state information. To do so it may use one or multiple communication events. A successful session could be as simple as "are you there?" with a response. Neither is a session the state information itself. I think these terms will be more useful in the future if you distinguish the relationship between the endpoints -- the "session" -- from the "session state" which reflects the relationship in the participants and intermediate nodes. How is a session different from a connection? Just barely. A TCP "connection" can be used by HTTP for one exchange, then allowed to lie fallow, then used for a different one. That's one "flow" from the point of view of the network but multiple communications events from the point of view of the applications. One possible difference between session and connection might be that in a connection the participating endpoints are the same for all communication flows, while in a "session" involving multiple communication events, different parties could be involved in different ones. You don't buy it? In that case, really, the only difference I know of is that "connection" is used for lower layers, L4 and below, while "session" is used for L5 and above. The important thing about a session is not how information is carried, but that there is a relationship between participants for the purpose of communications. Sessions can be based on connectionless or connection-oriented underlying technology -- once you separate it from "connection" that doesn't matter. They can be unicast or multicast. They can but need not be assisted by intermediaries like SIP proxies. > I would suggest that we start out with a rational definition of the > various layers. I include a questioned layer, which I think Tony is > alluding to, and the ISO and XNS Session models, which have some > history. I suspect that we will have various comments on these > architecturally, and when we get this part of the question sorted > out, we will have a better notion of what further we might want to > say. Do we really need these absolutist layer definitions? They came out in 1978 (?) and were almost immediately considered inadequate for describing the real world. The GII replacement concepts came out in the early-to-mid-80s, and were themselves mostly replaced in the 90s, and yet the IETF is still using the simple model. Real networks can have so many layers, including multiple which one might call physical, multiple which might be called session, etc. The important characteristic of a layer is not where it sits absolutely, but the services it offers to layers above and the services it asks of the layers below, plus how its endpoints are identified (and I don't mean physical endpoints). As an example ... > describe transport, it is a sublayer of the transport layer, although > IPv6 incorporates it and other end-system to end-system capabilities > like fragmentation and reassembly into IPv6. Are these functions of a > session management layer? Is the session management layer in fact the > lowest end-2-end communications layer?> If IPsec has its own endpoint identifiers, then very probably yes. As far as I know you can't say you want a tunnel to a particular tunnel endpoint identifier, just to an IP address, so the answer is no. A tunnel is just a virtual link in the layer in which it is embedded. IPv6 was right to embed it downward. On the other hand, as an example of the opposite, MPLS pseudowires were not a layer -- just links -- until recently, when multi-segment PWs were introduced. Now you have an independent endpoint identifier space, you can switch on them, you can even do routing. MS-PWs are a layer in their own right. I believe grid middleware may also be a layer. In fact, Web Services probably is. Instead of using an absolutist model and saying there is *a* layer which is the MS-PW or Parlay or WS layer, you allow for the possibility of many layers, and you refer to them by their identifier space in a particular instantiation. All layers can potentially do things like fragmentation. They are universal capabilities. You have fragmentation in Web Services. In a particular instantiation you want coordinated behavior between your layers, just as you want coordination in mobility and restoration of connectivity. So far we seem to let all the layers define their own functionality and then turn off what we don't want when implementing. Things like fragmentation are not a separate layer themselves, they are "adaptation". They are the massaging the layer does to the information it is supposed to carry, at the edge of the service it provides, in order to be able to do so. > * we need a AAA layer above transport that sets up and tears down > sessions securely regardless of the transport used > * we need for the lowest end to end layer to be the upper reaches > of the network layer, handling session management issues in the > way IPv6 does > * we need for the lowest end to end layer to be a session > management layer between the network and transport layers, > handling session management in the way IPsec does in an > IPv4 implementation Again, all layers can potentially do AAA for the resources they manage. You have AAA for use of your DSL link. In this case you need AAA for "above transport" but it would not be a separate layer. I believe what you call "session management" is "adaptation" to the layer in question, not another layer. One final thought: while messing about with terminology, let's be sure to leave room for role-based functionality and not get too programmed into layerist thinking. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 10:02:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdhq-00009G-2n; Tue, 07 Mar 2006 10:02:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdho-00009B-HH for architecture-discuss@ietf.org; Tue, 07 Mar 2006 10:02:32 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdhn-0005f4-BN for architecture-discuss@ietf.org; Tue, 07 Mar 2006 10:02:32 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0F3A286AE6; Tue, 7 Mar 2006 10:02:31 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms Message-Id: <20060307150231.0F3A286AE6@mercury.lcs.mit.edu> Date: Tue, 7 Mar 2006 10:02:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" > now public document called the NCOIC Interoperability Framework (NIF). > It is worth looking at is my input. > NB: If someone here would post as URL I can send, it is 894KB I don't > have place currently to post? This is now online at: http://ana-3.lcs.mit.edu/~jnc/tech/archd/NCOIC_Interoperability_Framework_v1.pdf for people to download and peruse. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 10:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdm3-00042R-9S; Tue, 07 Mar 2006 10:06:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdm2-00042M-39 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 10:06:54 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdlw-0005r9-R9 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 10:06:54 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 8FACE34156; Tue, 7 Mar 2006 10:06:48 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 10:06:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 7 Mar 2006 10:06:44 -0500 Message-ID: <936A4045C332714F975800409DE0924001EBC31D@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZB+ERKydB+pb8qR2OuQHG2PPey7QAAHUGg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 07 Mar 2006 15:06:48.0153 (UTC) FILETIME=[C18C4C90:01C641F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thank You Noel. /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Tuesday, March 07, 2006 10:03 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] Defining terms >=20 > > From: "Bound, Jim" >=20 > > now public document called the NCOIC Interoperability=20 > Framework (NIF). > > It is worth looking at is my input. > > NB: If someone here would post as URL I can send, it is=20 > 894KB I don't > > have place currently to post? >=20 > This is now online at: >=20 > =20 > http://ana-3.lcs.mit.edu/~jnc/tech/archd/NCOIC_Interoperabilit > y_Framework_v1.pdf >=20 > for people to download and peruse. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 12:41:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgBF-0003B6-KN; Tue, 07 Mar 2006 12:41:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgBE-0003B0-FS for architecture-discuss@ietf.org; Tue, 07 Mar 2006 12:41:04 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgBD-0003dv-74 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 12:41:04 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 07 Mar 2006 09:41:02 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k27Hf2w1012841; Tue, 7 Mar 2006 09:41:02 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k27Hgt84002974; Tue, 7 Mar 2006 09:42:55 -0800 In-Reply-To: <20060307142105.GA588@sbrim-wxp01> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B515F34-277E-42CA-BF39-A6FF4693379E@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Tue, 7 Mar 2006 09:41:00 -0800 To: Scott W Brim X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1329; t=1141753375; x=1142185575; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:Scott=20W=20Brim=20; X=v=3Dmtcc.com=3B=20h=3Db6XEI34TsuJgdElIxzrKVKfZXRA=3D; b=Gf1rA5O8KKEGm5Y1MgMerpB0HVg9m9XWpwgmzaEuohdPDIcx1lq65e/ETXR5R+IdnqFFqKHo LvZMJ0F/vfDNBzt/AOfBqXfM4tMm24DAhOKJx5q7Aijmrkf4I8yZ1LsDcH1yxCGwSsNtkIk0FoU jL9cr5oSxPsGP92zXWfwIIZQ=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mar 7, 2006, at 6:21 AM, Scott W Brim wrote: > Do we really need these absolutist layer definitions? I think so. Yes, they are inadequate. In a private email to John Leslie, who was trying to nail down the distinction between the physical and the link layers, I wound up considering a DS1 interface. Think about pulse code modulation, clock recovery, framing, data carried, and so on. Placing the exact boundary between the two is "a leetle tough". That said, in teasing them apart and defining at least the general model, we clarify our thought. In this discussion, I have gleaned that Tony is interested in a layer above the transport that has a stated function, and I think he is also interested in a layer somewhere between the upper part of the network layer and the lower part of the transport layer, and maybe it's a layer in its own right, that accomplishes certain things. Nailing down those concepts lets us go to the next step with some clarity. I'm not working on absolutes here, or at least I don't think I am. I'm working on clarity. > One final thought: while messing about with terminology, let's be sure > to leave room for role-based functionality and not get too programmed > into layerist thinking. OK. Care to kick out some text we can pick apart? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 12:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgS8-0002IA-2Q; Tue, 07 Mar 2006 12:58:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgS6-0002E1-Tx for architecture-discuss@ietf.org; Tue, 07 Mar 2006 12:58:30 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgS5-0004Xb-MX for architecture-discuss@ietf.org; Tue, 07 Mar 2006 12:58:30 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc12) with SMTP id <20060307175828m12000m0oue>; Tue, 7 Mar 2006 17:58:28 +0000 Message-ID: <285d01c64210$70b751d0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com><20060307142105.GA588@sbrim-wxp01> <0B515F34-277E-42CA-BF39-A6FF4693379E@cisco.com> Subject: Re: [arch-d] Defining terms Date: Tue, 7 Mar 2006 11:56:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At the risk of horrifying a few real engineers... From: "Fred Baker" Sent: Tuesday, March 07, 2006 11:41 AM Subject: Re: [arch-d] Defining terms > In a private email to John Leslie, who was trying to nail down the > distinction between the physical and the link layers, I wound up > considering a DS1 interface. Think about pulse code modulation, clock > recovery, framing, data carried, and so on. Placing the exact boundary > between the two is "a leetle tough". That said, in teasing them apart and > defining at least the general model, we clarify our thought. My model for the physical layer is that the physical layer tops out when you can tell the zeros from the ones - this is the realm of digital communications... Thanks, Spencer, who was enough of a software guy that I started out assuming you could tell the zeros from the ones - which is actually a lot harder than it seems like it would be, to software guys! _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 16:27:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGji1-0008N2-2y; Tue, 07 Mar 2006 16:27:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGjIf-0005kp-WB for architecture-discuss@ietf.org; Tue, 07 Mar 2006 16:00:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGjIf-0005Bh-B2 for architecture-discuss@ietf.org; Tue, 07 Mar 2006 16:00:57 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 07 Mar 2006 13:00:49 -0800 X-IronPort-AV: i="4.02,172,1139212800"; d="scan'208"; a="413258798:sNHT21523270488" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k27L0mGv022463; Tue, 7 Mar 2006 13:00:48 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k27L2fZL004879; Tue, 7 Mar 2006 13:02:41 -0800 In-Reply-To: <285d01c64210$70b751d0$0500a8c0@china.huawei.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com><20060307142105.GA588@sbrim-wxp01> <0B515F34-277E-42CA-BF39-A6FF4693379E@cisco.com> <285d01c64210$70b751d0$0500a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6569FEEB-7E5E-470F-9DB8-8498EA0BE7F5@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Tue, 7 Mar 2006 13:00:46 -0800 To: Spencer Dawkins X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=514; t=1141765361; x=1142197561; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:Spencer=20Dawkins=20; X=v=3Dmtcc.com=3B=20h=3DxV6XXx1TH2rLyJxhPkgTCcPkHnM=3D; b=R5P1XbRToi35FqpyGsoC5K/NIeXTVA/T67PFhRKeM6GRtwf5C89eQV4XAlvcydF3I5aSur5U rc0A0XdFL5a0+XA6vFvgbUk6pjz0/M17iR88fWpaTG6IciYc5akx0DrbWQaBSX7naQuER1djynb +Oqnx4zt6SR4VlJ8nripXkUM=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mar 7, 2006, at 9:56 AM, Spencer Dawkins wrote: > My model for the physical layer is that the physical layer tops out > when you can tell the zeros from the ones - this is the realm of > digital communications... ah, yes, but which zeroes and which ones? On a T-1 etc, framing the link is generally considered to be one of the services of the particular physical layer. That physical layer has a number of sub- layers. This is getting a bit afield of where we need to go, I think. :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 07 19:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGm9b-0006iX-Rw; Tue, 07 Mar 2006 19:03:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGm9a-0006g2-Kl for architecture-discuss@ietf.org; Tue, 07 Mar 2006 19:03:46 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGm9Y-0003TF-Tk for architecture-discuss@ietf.org; Tue, 07 Mar 2006 19:03:46 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FGm9X-00066w-Of; Tue, 07 Mar 2006 16:03:44 -0800 Message-Id: <6.2.3.4.2.20060307225223.06833eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 07 Mar 2006 22:56:03 +0100 To: "Spencer Dawkins" , From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <285d01c64210$70b751d0$0500a8c0@china.huawei.com> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <0B515F34-277E-42CA-BF39-A6FF4693379E@cisco.com> <285d01c64210$70b751d0$0500a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2FDE673D X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 18:56 07/03/2006, Spencer Dawkins wrote: >At the risk of horrifying a few real engineers... > >From: "Fred Baker" >Sent: Tuesday, March 07, 2006 11:41 AM >Subject: Re: [arch-d] Defining terms > > >>In a private email to John Leslie, who was trying to nail down the >>distinction between the physical and the link layers, I wound up >>considering a DS1 interface. Think about pulse code modulation, >>clock recovery, framing, data carried, and so on. Placing the >>exact boundary between the two is "a leetle tough". That said, in >>teasing them apart and defining at least the general model, we >>clarify our thought. > >My model for the physical layer is that the physical layer tops out >when you can tell the zeros from the ones - this is the realm of >digital communications... > >Thanks, > >Spencer, who was enough of a software guy that I started out >assuming you could tell the zeros from the ones - which is actually >a lot harder than it seems like it would be, to software guys! Not only to software guys. Not only for hardware/infrastructure people (cf. Fred Baker's remark). Please remember the problem of defining the ancillary services and the role left to the FCC to define the boarder. I would say it is when you can change the 0 and 1 without changing what is necessary for the infrastructure to deliver properly. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 08 09:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzm2-0005Ji-6q; Wed, 08 Mar 2006 09:36:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGzlz-0005G6-Te for architecture-discuss@ietf.org; Wed, 08 Mar 2006 09:36:19 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGzlz-0003bb-NU for architecture-discuss@ietf.org; Wed, 08 Mar 2006 09:36:19 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4086784 for architecture-discuss@ietf.org; Wed, 08 Mar 2006 09:34:52 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6745611B-D19A-4365-B593-050B1EB4BFE2@multicasttech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Marshall Eubanks Date: Wed, 8 Mar 2006 09:36:29 -0500 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [arch-d] Informal FecFrame BOF in Dallas X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hello; Apologies if you receive duplicate posts. I am sending this to this list because I feel that there might be interest in transport layer FEC here. I asked why FecFrame was not meeting at the Dallas IETF, and whether it would become a Working Group, and was told that the BOF had recently lost a chair, and that for this and other reasons the meeting did not make the agenda. I think that this idea has merit and should be pursued, and volunteered to put together an informal meeting. It seems that Monday night is the best night for this, so we are going to have an informal dinner BOF the Monday of the IETF Week. The main agenda is, wither FecFrame ? Are enough people interested and willing to do something about this BOF to warrant the move to a WG ? Of course, people who are interested and who would like to learn more are also welcome. Meeting time : 8:00 PM Monday, March 20th. Meeting Location : TBD, but suggestions are welcomed. Meeting Rendezvous Point : TBD, but provisionally the Hotel lobby. RSVP : tme@multicasttech.com (I would like to gauge possible transportation and dining options, and I will keep people who respond apprised of details as they become available.) Note that Allison Mankin points out that as this is an IETF related meeting, the "NOTE WELL" will apply. For the curious, here are the proceedings from Vancouver : http://www3.ietf.org/proceedings/05nov/fecframe.html Feel free to distribute this invitation to others who might be interested. Regards Marshall Eubanks _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 16 19:42:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK33I-0007UT-0U; Thu, 16 Mar 2006 19:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJrs6-0002RM-ML for architecture-discuss@ietf.org; Thu, 16 Mar 2006 07:46:30 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJrs4-000895-52 for architecture-discuss@ietf.org; Thu, 16 Mar 2006 07:46:30 -0500 Received: from [10.0.1.9] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060316124626011002sg39e>; Thu, 16 Mar 2006 12:46:27 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060315164821.GC43552@caida.org> References: <20060315164821.GC43552@caida.org> Date: Thu, 16 Mar 2006 07:46:19 -0500 To: architecture-discuss@ietf.org From: John Day Subject: Re: [fred@cisco.com: [arch-d] Defining terms] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 X-Mailman-Approved-At: Thu, 16 Mar 2006 19:42:46 -0500 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >----- Forwarded message from Fred Baker ----- > > Date: Mon, 6 Mar 2006 15:02:24 -0800 > From: Fred Baker > Subject: [arch-d] Defining terms > To: architecture-discuss@ietf.org > X-Mailer: Apple Mail (2.746.2) > > OK, so this takes off on one of the many topics we have been > discussing... > Let me see what I can add to this. > There are a variety of papers that have tried to define the concept > of a 'session" in a network that is connectionless at the network > layer. I'm not sure what the orgiginal document is, although I am > sure that it vastly predates RFC 1144, which is the oldest RFC that > seems to use the terms "shared state" and "fate sharing". But bottom > line, while the internet layer has no concept of what we now call a > "virtual circuit" or "virtual channel", it has been long recognized > that the applications and the transports in question have to have > some degree of shared state to enable them to function, and that in > the event that something goes completely south there is a necessity > for "fate sharing" - all systems retaining the shared state have to > at some point decide that it is for nought and delete it. > Before we get to what is "session" we should probably review the degrees of shared state. It seems there are several: First there is the shared state associated with the 3 phases of communications: Enrollment phase: the operations necessary to create the minimal shared state necessary to allow an instance of communications to be created. This is all that messy initial stuff we like to ignore like making sure that both systems have operating instances of the same protocol machine, assigning addresses, and making them available to protocol machines, etc. All the initial stuff that needs to be in place. It is information held in common and so strictly speaking shared state. Establishment Phase: (I prefer to call it Allocation) the operations necessary to allocate an instance of communication creating sufficient shared state to support the mechanisms of the data transfer phase. This is generally what we think of as creating shared state. And the Data Transfer Phase: On-going operations during data transfer to maintain the shared state created in the Allocation phase. Allocation seems to have 3 forms/degrees of shared state: minimal: corresponding to a pure connectionless, such as UDP' moderate: corresponding to flows with only mechanisms involving the Transfer PDU and only need a 2-way handshake synchronization procedure, strong: corresponding to flows supporting feedback mechanisms that require a 3-way handshake synch mechanism. > > I would therefore define a "session" as the shared state in the end > systems and in the network, whatever it may be, which directly or > indirectly reflects the state of two or more communicating > applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), > this would include information stored in network nodes, and it > generally includes keys associated with security associations, > sequence numbers etc in TCP and SCTP, and the various addresses that > are used by endpoints in a multihomed route. > This would seem to roll a lot of things into a session. Let me defer commenting on this for now. But do let me say, I would prefer a definition that was more abstract and less in terms of specific things. Assuming that "session" is something above "transport layer" I am uncomfortable with it including information about the internal workings of "other layers." Each layer should have its own addressing structure, so saying the Session Layer has addresses is a bit redundant. > > I would suggest that we start out with a rational definition of the > various layers. I include a questioned layer, which I think Tony is > alluding to, and the ISO and XNS Session models, which have some > history. I suspect that we will have various comments on these > architecturally, and when we get this part of the question sorted > out, we will have a better notion of what further we might want to say. > > > physical layer: > The physical layer is the lowest communication layer, consisting of > the physical medium of communication and the means of signaling over > it. It is responsible for defining the physical means of sending > data, interfacing between network media and devices, and defining the > media's optical, electrical and mechanical characteristics. Examples > of this include a fiber optic link, in which the means of signaling > is transmission of photons of a known frequency in a known pattern, > and the reception of those photons, or a radio link, in which the > "medium" is electromagnetic space, and the signaling is performed by > electromagnetic effects conveyed in that space. > Right. All that messy physical stuff. > link layer: > The link layer defines the procedures for operating physical > communication links. It encodes network layer data as physical layer > signals, and recovers and decodes these signals at the receiving end. > It also manages rate of flow and errors on the link, which at minimum > means reporting statistics, and may include FEC, retransmission, or > other techniques. Examples of this include HDLC, Ethernet, and so on. > It may be a nit, but I would put the encoding of bits into signals as part of the physical layer. The purpose of the Data Link Layer is to manage the access to the physical medium, and provide error and flow control tailored to the characteristics of the media. The data link layer provides sufficient error control to make error control at higher layers, i.e. Transport, cost effective. Also the Link Layer has less scope than the higher layers so in some sense it is often more cost-effective to recover from errors in the smaller scope rather than propagating them to the greater scope of a higher layer and recovering from them there. In some sense, a data link layer is "end-to-end" it is just that the ends are closer together. I would also contend that this error and flow control function (LLC) is distinct from the managing the medium function (MAC) and depending on the nature of the medium a data link layer may have one or the other or both. A point to point wire might only have the LLC aspect, while a LAN supporting multiple endpoints might have the MAC but sufficiently reliable to require only minimal LLC or none. To media that require both. > Network layer: > The communication layer that builds networks out of link layer > relationships and enables systems to communicate information between > systems that are not directly connected at the link layer. The > network layer contains at least two major sublayers, and these may be > implemented recursively. > > Intranet Layer: > The Intranet layer is the lower sublayer of the network layer. It > connects systems that are under common administration, are intended > to be connected in a simple manner, and generally applies no > administrative policy within the network. Examples of this include X. > 25, Frame Relay, ATM, MPLS, IEEE 802.1 Transparent Bridging, IEEE > 802.1/802.5 Source-Route Bridging, and IEEE 802.11 wireless networking. > > Internet Layer: > The Internet layer is the upper sublayer of the network layer. It may > be used to connect systems under common administration and > implementing common policy, but is also commonly used to connect > systems under different administration or with differing > administrative policy. Internet nodes include the internet layer in > hosts or in routers, and each support at least one address by which > they are reachable by their administration. In the Internet, IPv4 and > IPv6 are examples of the Internet layer. These 3 are an interesting characterization. And very much reflects what is described in the OSI Internal Organization of the Network Layer. It might be worthwhile looking at it. While the document is in normal OSI double speak, it does contain a description of some interesting cases. It divided the Network Layer into 3 sub-layers: Subnetwork Access: things like X.25 etc. Subnetwork Dependent Convergence: Any and all functions necessary to support the Subnetwork Independent Convergence sublayer. Subnetwork Independent Convergence corresponds to what you have called the Internet Layer. But it was trying to address the same kind of issues you describe here although somewhat from the point of view of the late 80s. > > describe transport, it is a sublayer of the transport layer, although > IPv6 incorporates it and other end-system to end-system capabilities > like fragmentation and reassembly into IPv6. Are these functions of a > session management layer? Is the session management layer in fact the > lowest end-2-end communications layer?> > No, IPSEC is not a separate layer, but an add-on. It seems that its being a separate protocol is more an artifact of history than the way it really wants to be done. > Transport layer: > The transport layer is the lowest layer that runs end to end. It may > be viewed as the end-to-end counterpart to the link layer, enabling > applications running in end systems to communicate effectively across > the network connecting them. "Effective communication" are > application concepts; many applications call for reliable sequential > delivery of data within a transaction, and a subset can handle > transactions in arbitrary order. TCP and SCTP are examples of > protocols which run at the Transport layer; there are other examples. > UDP is not an example of a transport, although it may be considered > an example of the multiplexing sublayer of the transport, as the > methods used to make communication effective are implemented in the > application. > I pretty much agree, but I would consider UDP part of this layer. The question here is what is the layer, not how the protocols work. Applications request service with certain characteristics. The layer can use any set of mechanisms it likes to provide that service. If the layer below it is very reliable, then it may chose to use UDP for even a request wanting a reliable transfer. So UDP is just a degenerate case and it does carry necessary identfiiers, i.e. ports. > Session Layer: > As defined by ISO, the session layer manages user sessions and > dialogues, controls establishment and termination of logic links > between users, and reports upper layer errors. As defined by Xerox > Network Systems, the middleware application Courier provided a Remote > Procedure Call service in which incoming sessions were all referred > to Courier and transferred from there to other applications a deemed > appropriate through AAA policy and parameter acquisition procedures. > > Application Layer: > In the Internet, the application generally includes the ISO concept > of the presentation layer, which deals with encoding and deciding > data. This is the communication layer or program that directly serves > the user, whether directly or remotely. > By 1983, OSI had determined that the Session and Presentation Layers didn't exist. Well, that isn't entirely true. The ITU faction held on to the idea that the Session Layer existed. But that was because they had hi-jacked it for Videotex. In 83, OSI adjusted the protocol specs for Session and Presentation and ACSE (see below) so that the insightful implementor could implement them as a single state machine. (The feeling was the politics prevented from dropping 2 layers from the model and as I said ITU was still hanging on to Videotex at that point.) But most people saw these one layer. What OSI did find was that applications required a common establishment mechanism. All applications used the same application connection establishment mechanism, called ACSE. This is needed to carry the application naming information and probably initial security parameters. If you don't have it then someone needs to understand the format of the first message of every application protocol. This also allows one to avoid the well-known socket stop-gap that the ARPANet had done to get ready for the ICCC 72 demo. Its okay when you only have 3 applications but doesn't really scale. ACSE corresponds fairly closely to what is described as Session in other schemes, such as XNS. (An aside: OSI saw application made of building blocks called ASEs that were essentially modules of a protocol. ACSE was an ASE that every application protocol included to create the application connection. (There was also a Unit-Data version of ACSE as well.) Other ASEs might be defined for common functions like one or two phase commit, or ASEs specific to the application. These were bound by a "control function" that maintained coordination and sequencing of the ASEs making up an application protocol. It probably sounds more complicated than it was. OSI basically saw application protocols as being constructed of several modules.) Eventually, ACSE was modified to allow completely general nesting of application protocols. If OSI had been left to its own devices, ACSE would probably have ended up as the Session Layer. But with ITU usurping Session, this seemed to be the easiest way around it. It wasn't really. If you look at the "functional units" that were defined in the Session Layer, they are really just simple ASEs. Other problems arise with having these functions in the Session Layer when more complex applications are attempted but we won't go into that here. Also, if one goes back to our early discussions of "Session" in the early days, the term reflects a narrow view we had of what computers were all about in the 1970s. Had we pursued that I think it would have taken us toward something more like Netware, which while one useful application environment would be too narrow for the variety of things that need to be supported. So it turns out that ACSE is probably what you want for the general case and include specific ASEs if you need something more narrow. So that is how Fred's characterization stacks up against what OSI was thinking. Actually all of these are fairly traditional descriptions. And, while not entirely "wrong," I think this view isn't quite right either and a much simpler scheme is possible. Take care, John Day _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 17 19:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKP6T-00044M-SH; Fri, 17 Mar 2006 19:15:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKP6S-00043v-Ur for architecture-discuss@ietf.org; Fri, 17 Mar 2006 19:15:32 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKP6S-0003dW-Jw for architecture-discuss@ietf.org; Fri, 17 Mar 2006 19:15:32 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id A17FDE043B; Fri, 17 Mar 2006 19:15:32 -0500 (EST) Date: Fri, 17 Mar 2006 19:15:32 -0500 From: John Leslie To: John Day Subject: Re: [arch-d] Defining terms Message-ID: <20060318001532.GA92245@verdi> References: <20060315164821.GC43552@caida.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day wrote: > > It may be a nit, but I would put the encoding of bits into signals as > part of the physical layer. I suggest we recognize that things like "encoding of bits into signals" is a function of the interface between link layer and physical layer. I would agree with Spencer Dawkins that link layer deals in bits; so I agree with John Day that "encoding" into something else isn't "part of" the link layer. But we'd do well to allow ourselves to think that physical layer deals in "something else than bits" (typically electrons or photons); thus recognizing some interface which deals in electrons/photons on one side and bits on the other. Fortunately, we need say little or nothing about such an interface. ;^) > The purpose of the Data Link Layer is to manage the access to the > physical medium, and provide error and flow control tailored to the > characteristics of the media. I agree; but we should be careful not to read too much into these words. "Manage the access to" doesn't mean that every detail of the connectors is a link-layer function: those connectors are mostly a part of the physical layer. "Manage the access to" should mean to adjust timing, etc. to match the limitations of the physical medium. This makes "flow control" an obvious essential: don't introduce signals that the physical medium can't carry. "Error control" is not as clear, and I worry folks may expect too much of it. Link layer should introduce enough redundancy to recognize transmission errors, and _may_ include formal mechanisms to correct such errors. That's as far as we should go, IMHO. (Clearly, many implementations of link layer will go quite a bit farther: I merely mean we shouldn't stretch our definition of link layer to cover more than the minimum our architecture expects.) > The data link layer provides sufficient error control to make error > control at higher layers, i.e. Transport, cost effective. This statement actually worries me. There's nothing actually _wrong_ with it, except a suggestion that higher layers might "negotiate" what constitutes "sufficient error control". (Again, many implementations of link layer in combination with a higher layer _will_ negotiate exactly that: I mean we shouldn't stretch our definition of link layer to cover more than the minimum our architecture expects. A model is still useful even though an actual implementation applies tweaks outside of the model.) John Day _is_ quite right to point out that higher layers _do_ depend upon some amount of error control at the link layer. We cannot (IMHO) avoid that; but we should be very careful about writing it into our architecture. > Also the Link Layer has less scope than the higher layers so in some > sense it is often more cost-effective to recover from errors in the > smaller scope rather than propagating them to the greater scope of a > higher layer and recovering from them there. This is where it gets messy! Rather than go into details, let me try to label such considerations "engineering" and distinguish them from "architecture". From an engineering standpoint, recovering from noise-related errors is usually far better if you can reduce the hysteresis. But from an architectural standpoint, we need to recognize that we're designing for unknown uses. The engineering tweak which makes the use we're thinking of right now run twice as fast may well cause some future use to run slower, or even in extreme cases fail to run. This brings us back to the smart-network / dumb-network tradeoffs. I'm old-fashioned enough to generally prefer the dumb-network. YMMV. Clearly, repairing all errors with TCP retransmissions is no longer acceptable: but pushing error-correction expectations down to the link layer is _not_ the only trick available. We should have an architecture which is agnostic on that question. > In some sense, a data link layer is "end-to-end" it is just that the > ends are closer together. A link layer _can_ be designed "end-to-end". Some will be. But I believe we should be dwelling on distinguishing features of layers: not on similarities between layers. > I would also contend that this error and flow control function (LLC) > is distinct from the managing the medium function (MAC) Error control certainly can be distinct: we might want to discuss the benefits and costs of considering it separately. Flow control, OTOH, is essential to managing the medium. > and depending on the nature of the medium a data link layer may have > one or the other or both. I do not believe managing the medium can be avoided. > A point to point wire might only have the LLC aspect, I disagree: there's always a timing aspect. > while a LAN supporting multiple endpoints might have the MAC but > sufficiently reliable to require only minimal LLC or none. There are cases which _seem_ this way: that you get something "reliable enough" or nothing at all. This, IMHO, is a degenerate case of error control which discards all information except successful transmission. Yes, it happens; yes, we deal with it; but IMHO it is not an absence of error control. ==== I'll skip the other layers: I think this email is long enough... -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 17 19:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPOQ-0004zh-Sx; Fri, 17 Mar 2006 19:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKPOP-0004z6-T2 for architecture-discuss@ietf.org; Fri, 17 Mar 2006 19:34:05 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKPOO-0003vf-LZ for architecture-discuss@ietf.org; Fri, 17 Mar 2006 19:34:05 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2006 16:34:04 -0800 X-IronPort-AV: i="4.03,106,1141632000"; d="scan'208"; a="417375726:sNHT25350312" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2I0Y4Gv018337; Fri, 17 Mar 2006 16:34:04 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2I0ZIYI027028; Fri, 17 Mar 2006 16:35:19 -0800 In-Reply-To: <20060318001532.GA92245@verdi> References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <793B9C36-F86F-46D7-A886-26F6E6F01B09@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Fri, 17 Mar 2006 16:34:02 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=444; t=1142642119; x=1143074319; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:John=20Leslie=20; X=v=3Dmtcc.com=3B=20h=3DU1ptcI7Ao301CNOebuRFsnLeZzs=3D; b=qa6xMFKOAFRoWTYl41MzccCJpRRYDfoKbJEa05B4jpTiRp0HXm4jFFE1vOlyXt/iiirzwjD2 tYMbKH71DsUyCtyPZa2kLmmCl4HF9bC7HaziyCYKFlDHUi0u2fPQfYa0qz+S78xHmXJSIrZHCPM il0h6g4WP4knD/3OC/FA0sc8=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org as we have discussed privately, I think we need to agree that at the boundary between the physical and link layer the encoding is binary, and leave off pontificating about the physical layer. There is a lot to understand there. On Mar 17, 2006, at 4:15 PM, John Leslie wrote: > I suggest we recognize that things like "encoding of bits into > signals" > is a function of the interface between link layer and physical layer. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 17 22:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKSPc-0003IS-Bl; Fri, 17 Mar 2006 22:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKSPa-0003IN-Hu for architecture-discuss@ietf.org; Fri, 17 Mar 2006 22:47:30 -0500 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKSPZ-00018v-Ap for architecture-discuss@ietf.org; Fri, 17 Mar 2006 22:47:30 -0500 Received: from h-68-165-6-191.snvacaid.dynamic.covad.net ([68.165.6.191] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FKSPY-00076m-00 for architecture-discuss@ietf.org; Fri, 17 Mar 2006 22:47:28 -0500 Message-ID: <002601c64a3f$057e5bc0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> Subject: Re: [arch-d] Defining terms Date: Fri, 17 Mar 2006 19:49:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "John Leslie" > To: "John Day" > Cc: > Sent: Friday, March 17, 2006 4:15 PM > Subject: Re: [arch-d] Defining terms ... > This brings us back to the smart-network / dumb-network tradeoffs. > I'm old-fashioned enough to generally prefer the dumb-network. YMMV. > Clearly, repairing all errors with TCP retransmissions is no longer > acceptable: but pushing error-correction expectations down to the link > layer is _not_ the only trick available. We should have an architecture > which is agnostic on that question. ... "Agnostic" might not be quite the right word. I think we need an architecture that recognizes that (1) that some functions may, for good engineering reasons, be performed at multiple layers; (2) that the quality of service requested for a particular information flow may influence what a particular protocol does with that data, including the quality of service it requests from lower layers, as well as what it negotiates with its peers; (3) that if a lower layer cannot guarantee the requested quality of service, then the upper layer protocol needs the flexibility to either choose some other means of delivery, provide the service itself, or signal the inability to deliver the requested service quality up to its invoker. If that's what's meant by agnostic, cool. If not, we disagree. :-) Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Mar 18 08:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKbqO-0001rZ-Vw; Sat, 18 Mar 2006 08:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKbqN-0001rU-N5 for architecture-discuss@ietf.org; Sat, 18 Mar 2006 08:51:47 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKbqM-00026O-Dl for architecture-discuss@ietf.org; Sat, 18 Mar 2006 08:51:47 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 77773898A4; Sat, 18 Mar 2006 15:51:45 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2D82C898A0; Sat, 18 Mar 2006 15:51:43 +0200 (EET) Message-ID: <441C1069.6010901@piuha.net> Date: Sat, 18 Mar 2006 15:51:37 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Leslie , John Day Subject: Re: [arch-d] Defining terms References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> In-Reply-To: <20060318001532.GA92245@verdi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> Also the Link Layer has less scope than the higher layers so in some >>sense it is often more cost-effective to recover from errors in the >>smaller scope rather than propagating them to the greater scope of a >>higher layer and recovering from them there. >> >> > > This is where it gets messy! > > Rather than go into details, let me try to label such considerations >"engineering" and distinguish them from "architecture". > I'm not sure what we should label engineering and what architecture, but I'll just note that the issue of division of work between link and higher layers appears in many functions and not just in error correction. For instance, the same arguments can be made about mobility mechanisms. --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Mar 18 09:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKcKP-00057C-9m; Sat, 18 Mar 2006 09:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKcKN-000577-Bs for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:22:47 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKcKL-0003bF-U9 for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:22:47 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E8C16898A0; Sat, 18 Mar 2006 16:22:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 57A3B8988D; Sat, 18 Mar 2006 16:22:40 +0200 (EET) Message-ID: <441C17A9.2090903@piuha.net> Date: Sat, 18 Mar 2006 16:22:33 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Day Subject: Re: [arch-d] Defining terms References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> <441C1069.6010901@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org That it is cost-effective for local (perhaps L2) mechanisms to handle local movements, so that the global (perhaps L3) mechanisms do not handle to deal with too many events. John Day wrote: > What argument would that be? > > At 15:51 +0200 2006/03/18, Jari Arkko wrote: > >> >> Also the Link Layer has less scope than the higher layers so in some >> >>>> sense it is often more cost-effective to recover from errors in the >>>> smaller scope rather than propagating them to the greater scope of a >>>> higher layer and recovering from them there. >>>> >>> >>> >>> This is where it gets messy! >>> >>> Rather than go into details, let me try to label such considerations >>> "engineering" and distinguish them from "architecture". >>> >> I'm not sure what we should label engineering and what architecture, >> but I'll just note that the issue of division of work between link and >> higher >> layers appears in many functions and not just in error correction. For >> instance, the same arguments can be made about mobility mechanisms. >> >> --Jari > > > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 03:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFRL-0007rP-8o; Mon, 20 Mar 2006 03:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLFRI-0007rF-JS for architecture-discuss@ietf.org; Mon, 20 Mar 2006 03:08:32 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLFRI-0007k7-6m for architecture-discuss@ietf.org; Mon, 20 Mar 2006 03:08:32 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2K877Lm025277; Mon, 20 Mar 2006 10:07:10 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 10:08:28 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 10:08:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 10:08:26 +0200 Message-ID: In-Reply-To: <002601c64a3f$057e5bc0$6401a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZKProJfxQ92UNxQvqSAzKOvk69bwBtjw/A From: To: , X-OriginalArrivalTime: 20 Mar 2006 08:08:28.0287 (UTC) FILETIME=[783B70F0:01C64BF5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org randy_presuhn@mindspring.com wrote: > (3) that if a lower layer cannot guarantee the requested=20 >quality of service, then > the upper layer protocol needs the flexibility to=20 >either choose some other > means of delivery, provide the service itself, or=20 >signal the inability to deliver > the requested service quality up to its invoker. And if the upper layer can feasibly provide the service itself, why should the lower layer be burdened with the capability to guarantee the requested quality of service? Jarno Rajahalme _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 08:25:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKNd-0003kz-LZ; Mon, 20 Mar 2006 08:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKNb-0003kp-UW for architecture-discuss@ietf.org; Mon, 20 Mar 2006 08:25:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKNa-00026V-Kx for architecture-discuss@ietf.org; Mon, 20 Mar 2006 08:25:03 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2006 05:25:02 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="316193402:sNHT27347392" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2KDP17T024146; Mon, 20 Mar 2006 05:25:01 -0800 (PST) Received: from [204.96.114.235] (sjc-vpn1-315.cisco.com [10.21.97.59]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k2KDQ6Yw008978; Mon, 20 Mar 2006 05:26:06 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10111B73-6A95-4374-B47A-07933F970510@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Defining terms Date: Mon, 20 Mar 2006 07:24:59 -0600 To: X-Mailer: Apple Mail (2.746.3) DKIM-Signature: a=rsa-sha1; q=dns; l=2075; t=1142861167; x=1143293367; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Defining=20terms |To:=20; X=v=3Dmtcc.com=3B=20h=3D9oqfJI1Ve4ngdoJPDp/oyR91T60=3D; b=D10d98IpBamnFhPC9ibOo3wPG/VWRnEB67jjnFAnQgOyRMdxe5GmfUCCwp2r8ShOqRwkiA1L MNEIDUD4W5D5AXX6L5JF4RXZ0qzY9ZOok2DyLg+9clAXkVM5el4gyFR9HIM6mWiYMkH3Epw3RAU 6v2pnApsWfelGdOMrnK5VUmE=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This is a trade-off, and not one that should be made lightly. The thing I think we need to be careful with is knee-jerk application of the end to end principle. Saltzer and Reed's description was that "things should be done in the right place, once, and as simply as possible"; Isenberg's extension in "Dawn of the Stupid Network" is "everything should be done at the edge". Everything *can't* be done at the edge; for example, where do we do routing? Not at the edge, and we in fact have a knee-jerk response *against* having the edge involved in routing. Also, the logical outcome of that line of reasoning discards TCP in favor of UDP with application layer flow control and retransmission. So while I will agree with Isenberg on most of the cases he will bring up to discuss, I can't agree with him categorically, because the reasoning is faulty. If we are taking the model that things should be done in the right place and once, then if multiple upper layer protocols require the same service and the network layer is capable of delivering it, doing it once instead of many times makes sense to me. If only one upper layer protocol needs it, then it probably belongs there. On Mar 20, 2006, at 2:08 AM, wrote: > randy_presuhn@mindspring.com wrote: >> (3) that if a lower layer cannot guarantee the requested >> quality of service, then >> the upper layer protocol needs the flexibility to >> either choose some other >> means of delivery, provide the service itself, or >> signal the inability to deliver >> the requested service quality up to its invoker. > > And if the upper layer can feasibly provide the service itself, why > should the lower layer be burdened with the capability to guarantee > the > requested quality of service? > > Jarno Rajahalme > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 08:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKow-0003pz-IT; Mon, 20 Mar 2006 08:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLKov-0003pu-Mg for architecture-discuss@ietf.org; Mon, 20 Mar 2006 08:53:17 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLKos-0002hG-Do for architecture-discuss@ietf.org; Mon, 20 Mar 2006 08:53:17 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BEA5186AE7; Mon, 20 Mar 2006 08:53:13 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-Id: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> Date: Mon, 20 Mar 2006 08:53:13 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Fred Baker > Everything *can't* be done at the edge; for example, where do we do > routing? Not at the edge, and we in fact have a knee-jerk response > *against* having the edge involved in routing. I'm not sure exactly what you meant here, but please note that although we do routing (path selection) in the network today, it doesn't *have* to be done there; you *can* do routing (path selection) at the edge. (I produced such a design, and I feel that for architectural reasons it would be superior to do it at the edge, but I don't expect to see it in my lifetime - and that's not a rhetorical device, I'm already almost 50.) > if multiple upper layer protocols require the same service and the > network layer is capable of delivering it, doing it once instead of > many times makes sense to me. Right - but that doesn't mean the network layer should do it. The added functionality will make the network layer more complex, and applications which don't need that capability will have to pay the price even if they don't need it. As others here have pointed out, the whole "layer" concept is the wrong way to look at it. It's a modularized system, just like any other large system, and we need to look at it as a module dependency graph, hopefully one without any dependency loops (operating systems were the earliest to develop this whole model, but it's common now). So, yes, only implement that service once - but as a subsystem that other subsystems can call on when they need it. The only reason I can think off off the top of my head to make something mandatory, and part of some low-level abstraction, is when you want clients not to be aware that they are using it - e.g. paging (operating systems), or mobility (networks) - so that clients don't have to do anything "unusual" to get it, and so that users always have the capability, and the client designer/implementor can't screw up and take that capability away from the user. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLL33-0004IH-LL; Mon, 20 Mar 2006 09:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLL31-0004Bv-HY for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:07:51 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLL2y-0003Ch-6d for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:07:51 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id C4EAA349CD; Mon, 20 Mar 2006 09:07:47 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:07:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 09:07:41 -0500 Message-ID: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMJasRcM95omFQTbCJxGdsqmLd1wAALb6g From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 20 Mar 2006 14:07:47.0975 (UTC) FILETIME=[AACEC170:01C64C27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think we should for a moment imagine a world without layer but as modules. Really that is how the actual code is and not in layers. Sure IP packet gets parsed before TCP, and TCP makes decisions before passing data, as example here only, but is that layers or as Noel states modules? As far as the edge doing routing I think that is the wrong question? Once a packet has a destination path it should be move to that path? That is done with routing. Now finding the most optimal path at a point on a network is fine any time whether at the edge or within the core. So I think this may be a moot point. Also should we define what we mean by the "edge". Also is the only reason we use "layers" for the IP Reference Model because OSI did? If so that was a bad reason? I don't think that work in IEEE had anything right for an "Internet" model, as a bias clearly on my part. Noel I would like to see your design as one person here. Also I have interpretation of Saltzer/Reed for end-to-end which could take us down the religious path, but end-to-end to me is routers only get to forward based on the IP address and end-to-end cannot be possible unless each client on either end of the commo both have a globally routable source and destination address. Changing the IP address in a header breaks end-to-end. /jim =20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Monday, March 20, 2006 8:53 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Defining terms >=20 > > From: Fred Baker >=20 > > Everything *can't* be done at the edge; for example,=20 > where do we do > > routing? Not at the edge, and we in fact have a=20 > knee-jerk response > > *against* having the edge involved in routing.=20 >=20 > I'm not sure exactly what you meant here, but please note=20 > that although we > do routing (path selection) in the network today, it doesn't=20 > *have* to be > done there; you *can* do routing (path selection) at the edge. >=20 > (I produced such a design, and I feel that for architectural=20 > reasons it > would be superior to do it at the edge, but I don't expect to=20 > see it in my > lifetime - and that's not a rhetorical device, I'm already almost 50.) >=20 >=20 > > if multiple upper layer protocols require the same=20 > service and the > > network layer is capable of delivering it, doing it=20 > once instead of > > many times makes sense to me.=20 >=20 > Right - but that doesn't mean the network layer should do it.=20 > The added > functionality will make the network layer more complex, and=20 > applications > which don't need that capability will have to pay the price=20 > even if they > don't need it. >=20 > As others here have pointed out, the whole "layer" concept is=20 > the wrong way > to look at it. It's a modularized system, just like any other=20 > large system, > and we need to look at it as a module dependency graph, hopefully one > without any dependency loops (operating systems were the=20 > earliest to develop > this whole model, but it's common now). >=20 > So, yes, only implement that service once - but as a=20 > subsystem that other > subsystems can call on when they need it. >=20 > The only reason I can think off off the top of my head to=20 > make something > mandatory, and part of some low-level abstraction, is when=20 > you want clients > not to be aware that they are using it - e.g. paging=20 > (operating systems), or > mobility (networks) - so that clients don't have to do=20 > anything "unusual" to > get it, and so that users always have the capability, and the client > designer/implementor can't screw up and take that capability=20 > away from the > user. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLGn-0004mT-9j; Mon, 20 Mar 2006 09:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLGm-0004ll-1y for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:22:04 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLGk-0003hD-O7 for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:22:04 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id D08C7E0458; Mon, 20 Mar 2006 09:22:02 -0500 (EST) Date: Mon, 20 Mar 2006 09:22:02 -0500 From: John Leslie To: Scott W Brim , architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060320142202.GC49978@verdi> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060307142105.GA588@sbrim-wxp01> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Scott W Brim wrote: > On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote: > >> I would therefore define a "session" as the shared state in the end >> systems and in the network, whatever it may be, which directly or >> indirectly reflects the state of two or more communicating >> applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), >> this would include information stored in network nodes, and it >> generally includes keys associated with security associations, >> sequence numbers etc in TCP and SCTP, and the various addresses that >> are used by endpoints in a multihomed route. > > Elsewhere people have come up with the concept that a "session" is a > relationship -- not a pipe, not a flow of packets -- created to align > state information. To do so it may use one or multiple communication > events. A successful session could be as simple as "are you there?" > with a response. I see a benefit to thinking of "session" as a relationship between endpoints. I'm not quite sure either Fred or Scott have stated this distinctly enough. Fred is talking "shared state" which, I suppose, is correct; but it tends to direct our attention to details of connection(s) which I think deserve to be considered a different layer. IMHO, "session" may or may not imply an ordering in information transmitted over different connections. Scott talks of a "session" being "created to align state information." I do not see that either as the "purpose" of a "session" or even a necessary function of a "session". IMHO, a "session" should identify endpoints which are processes invoked by users without regard to the path over which information will flow between them. (Whether or not a "session" implies ordering of data communicated might well be implementation-dependent.) > Neither is a session the state information itself. I think these > terms will be more useful in the future if you distinguish the > relationship between the endpoints -- the "session" -- from the > "session state" which reflects the relationship in the participants > and intermediate nodes. I agree with Scott. > How is a session different from a connection? Just barely. I think we can draw a fairly clear distinction, actually. A "connection" is something maintained in a fully automated manner, without messy interactions. Our network must find a way to route packets from one end to the other. Thus, the endpoints of a connection must be machine-comprehensible addresses, most often globally unique. A "session" is something created in response to human action. In all likelihood, it depends upon rather messy DNS processes to resolve to IP addresses which routers can use. If conditions change so that those IP addresses no longer serve the necessary function, the human(s) creating the "session" would generally prefer that some further DNS magic makes the change transparent. > A TCP "connection" can be used by HTTP for one exchange, then allowed > to lie fallow, then used for a different one. Agreed. > That's one "flow" from the point of view of the network but multiple > communications events from the point of view of the applications. True, but in practice all the communications events are likely to represent the same "session". > One possible difference between session and connection might be that > in a connection the participating endpoints are the same for all > communication flows, while in a "session" involving multiple > communication events, different parties could be involved in different > ones. I think I've missed Scott's point here. "Participating endpoints" could mean a number of things. IMHO, we can correctly talk of "participating endpoints" for both "connections" and "sessions", and mean quite different things. > You don't buy it? In that case, really, the only difference I know of > is that "connection" is used for lower layers, L4 and below, while > "session" is used for L5 and above. Alas! We can't accept that kind of definition. ;^( -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:30:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLPL-0001Lv-C9; Mon, 20 Mar 2006 09:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLPK-0001Lp-Oo for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:30:54 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLPJ-0003zd-Hv for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:30:54 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id ABC2EE045C; Mon, 20 Mar 2006 09:30:53 -0500 (EST) Date: Mon, 20 Mar 2006 09:30:53 -0500 From: John Leslie To: Randy Presuhn Subject: Re: [arch-d] Defining terms Message-ID: <20060320143053.GD49978@verdi> References: <20060318001532.GA92245@verdi> <002601c64a3f$057e5bc0$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c64a3f$057e5bc0$6401a8c0@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Randy Presuhn wrote: >> From: "John Leslie" > ... >> This brings us back to the smart-network / dumb-network tradeoffs. >> I'm old-fashioned enough to generally prefer the dumb-network. YMMV. >> Clearly, repairing all errors with TCP retransmissions is no longer >> acceptable: but pushing error-correction expectations down to the link >> layer is _not_ the only trick available. We should have an architecture >> which is agnostic on that question. > ... > > "Agnostic" might not be quite the right word. I think we need an > architecture that recognizes > > (1) that some functions may, for good engineering reasons, be performed > at multiple layers; Agreed. However, _architectural_ definition of how the tasks are divided gets messy pretty fast... > (2) that the quality of service requested for a particular information > flow may influence what a particular protocol does with that data, > including the quality of service it requests from lower layers, > as well as what it negotiates with its peers; Agreed, except that QoS requests remain a largely unsolved problem. > (3) that if a lower layer cannot guarantee the requested quality of > service, then the upper layer protocol needs the flexibility to > either choose some other means of delivery, provide the service > itself, or signal the inability to deliver the requested service > quality up to its invoker. I fully agree. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLSh-00031c-VQ; Mon, 20 Mar 2006 09:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKcs6-0005db-Ug for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:57:38 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKcs6-0004EP-Il for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:57:38 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <20060318145735012007m2vce>; Sat, 18 Mar 2006 14:57:35 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060318001532.GA92245@verdi> References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> Date: Sat, 18 Mar 2006 09:57:31 -0500 To: John Leslie , John Day From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-Mailman-Approved-At: Mon, 20 Mar 2006 09:34:21 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 19:15 -0500 2006/03/17, John Leslie wrote: >John Day wrote: >> >> It may be a nit, but I would put the encoding of bits into signals as >> part of the physical layer. > > I suggest we recognize that things like "encoding of bits into signals" >is a function of the interface between link layer and physical layer. I >would agree with Spencer Dawkins that link layer deals in bits; so I >agree with John Day that "encoding" into something else isn't "part of" >the link layer. > > But we'd do well to allow ourselves to think that physical layer deals >in "something else than bits" (typically electrons or photons); thus >recognizing some interface which deals in electrons/photons on one side >and bits on the other. Fortunately, we need say little or nothing about >such an interface. ;^) Also in the past, it has proved useful to distinguish the Physical Layer from the Physical Media. But I agree there is not much need to say much about this interface. ;-) > >> The purpose of the Data Link Layer is to manage the access to the >> physical medium, and provide error and flow control tailored to the >> characteristics of the media. > > I agree; but we should be careful not to read too much into these >words. "Manage the access to" doesn't mean that every detail of the >connectors is a link-layer function: those connectors are mostly a >part of the physical layer. "Manage the access to" should mean to >adjust timing, etc. to match the limitations of the physical medium. > > This makes "flow control" an obvious essential: don't introduce >signals that the physical medium can't carry. "Error control" is not >as clear, and I worry folks may expect too much of it. Link layer >should introduce enough redundancy to recognize transmission errors, >and _may_ include formal mechanisms to correct such errors. That's >as far as we should go, IMHO. Agreed, as I elaborate further below. One must keep in mind that it is cheaper to recover errors in the lesser scope of the link layer than in the broader scope higher up. But one doesn't want to get too intent on it. > (Clearly, many implementations of link layer will go quite a bit >farther: I merely mean we shouldn't stretch our definition of link >layer to cover more than the minimum our architecture expects.) > >> The data link layer provides sufficient error control to make error >> control at higher layers, i.e. Transport, cost effective. > > This statement actually worries me. There's nothing actually _wrong_ >with it, except a suggestion that higher layers might "negotiate" what >constitutes "sufficient error control". Not the intent. The higher layers put requirements on the lower layers in some general way. When I teach this, I describe link layer error control as dealing with keeping media-related errors within the range expected by the network and transport layers. The errors recovered by the transport layer are those that occur as a consequence of relaying in the network layer, i.e. lost and duplicate PDUs and single bit errors caused by memory glitches during relaying. The job of data link error control is to stay within the tolerances transport expects of the network layer. > (Again, many implementations of link layer in combination with a >higher layer _will_ negotiate exactly that: I mean we shouldn't stretch >our definition of link layer to cover more than the minimum our >architecture expects. A model is still useful even though an actual >implementation applies tweaks outside of the model.) > > John Day _is_ quite right to point out that higher layers _do_ >depend upon some amount of error control at the link layer. We cannot >(IMHO) avoid that; but we should be very careful about writing it >into our architecture. Glad you agree. ;-) See above for what I hope was a better characterization. > > Also the Link Layer has less scope than the higher layers so in some >> sense it is often more cost-effective to recover from errors in the > > smaller scope rather than propagating them to the greater scope of a >> higher layer and recovering from them there. > > This is where it gets messy! > > Rather than go into details, let me try to label such considerations >"engineering" and distinguish them from "architecture". From an >engineering standpoint, recovering from noise-related errors is usually >far better if you can reduce the hysteresis. But from an architectural >standpoint, we need to recognize that we're designing for unknown uses. >The engineering tweak which makes the use we're thinking of right now >run twice as fast may well cause some future use to run slower, or even >in extreme cases fail to run. One has to have a clear definition of the service provided by the data link layer. Also there is not one data link layer. The data link layer is media-specific. You can't always make a silk purse from a sow's ear. > This brings us back to the smart-network / dumb-network tradeoffs. >I'm old-fashioned enough to generally prefer the dumb-network. YMMV. >Clearly, repairing all errors with TCP retransmissions is no longer >acceptable: but pushing error-correction expectations down to the link >layer is _not_ the only trick available. We should have an architecture >which is agnostic on that question. I am not sure what the smart network/dumb network means anymore. In 1972, packet switches were pretty dumb. Today core router does far more computation than the biggest CO circuit switch ever did. The other day, I was sort of constructing this model in my head and realized that perhaps a more proper analogy was that that the phone set corresponded to the dumb terminal and the first CO switch to a TIP. ;-) I prefer a model where there is crisp definition of that a layer does, so you know a priori what is in and what is out and not worry about whether it is dumb or smart. > > In some sense, a data link layer is "end-to-end" it is just that the >> ends are closer together. > > A link layer _can_ be designed "end-to-end". Some will be. But I >believe we should be dwelling on distinguishing features of layers: >not on similarities between layers. I don't think we meant end-to-end in the same sense. ;-) If a data link layer is end-to-end in the usual sense it is just a small network. > > I would also contend that this error and flow control function (LLC) >> is distinct from the managing the medium function (MAC) > > Error control certainly can be distinct: we might want to discuss >the benefits and costs of considering it separately. Flow control, OTOH, >is essential to managing the medium. > >> and depending on the nature of the medium a data link layer may have >> one or the other or both. > > I do not believe managing the medium can be avoided. It would seem to be difficult to do that. ;-) > > A point to point wire might only have the LLC aspect, > > I disagree: there's always a timing aspect. Not sure I understand this comment. > > while a LAN supporting multiple endpoints might have the MAC but >> sufficiently reliable to require only minimal LLC or none. > > There are cases which _seem_ this way: that you get something >"reliable enough" or nothing at all. This, IMHO, is a degenerate case >of error control which discards all information except successful >transmission. Yes, it happens; yes, we deal with it; but IMHO it is >not an absence of error control. I would agree. I am glad you made this point, it was what I had in mind. I always prefer degenerate cases, or as I like to say: Architecture is maximizing the invariances and minimizes the discontinuities. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLSi-000325-6p; Mon, 20 Mar 2006 09:34:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLDV-0001Ib-FA for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:18:42 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLDU-0003XV-8W for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:18:41 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060320141839011002t8eve>; Mon, 20 Mar 2006 14:18:39 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 20 Mar 2006 09:16:57 -0500 To: architecture-discuss@ietf.org From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Mon, 20 Mar 2006 09:34:21 -0500 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >>randy_presuhn@mindspring.com wrote: >>> (3) that if a lower layer cannot guarantee the requested >>>quality of service, then >>> the upper layer protocol needs the flexibility to >>>either choose some other >>> means of delivery, provide the service itself, or >>>signal the inability to deliver >>> the requested service quality up to its invoker. >> >>And if the upper layer can feasibly provide the service itself, why >>should the lower layer be burdened with the capability to guarantee the >>requested quality of service? > > >Because the lower layer has less scope and by doing it at the lower >layer it will put less work on the network as a whole, rather than >foisting the problem on a wider scope where it is not everyone's >problem. > >Also as I said earlier a variation of the 90/10 rule applies. If a >function like error control in a layer gets Y% of the problem and >there is significant cost associated with getting the last X%, where >X << Y and X is less than the probability of errors compensated for >by the layer above, then let the layer above deal with that last X%. > >However, that said, each layer is responsible for managing a set of >resources. Providing QoS in general requires affecting the >allocation of resources. If the resources to be affected are the >responsibility of a particular layer then it has to do it. > >Take care, >John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLSh-00030s-Nz; Mon, 20 Mar 2006 09:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKcbo-0000kP-Ah for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:40:48 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKcbn-0003oF-5H for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:40:48 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006031814404601400c2dvde>; Sat, 18 Mar 2006 14:40:46 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <441C17A9.2090903@piuha.net> References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> <441C1069.6010901@piuha.net> <441C17A9.2090903@piuha.net> Date: Sat, 18 Mar 2006 09:33:14 -0500 To: Jari Arkko , John Day From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Mon, 20 Mar 2006 09:34:21 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 16:22 +0200 2006/03/18, Jari Arkko wrote: >That it is cost-effective for local (perhaps L2) mechanisms to >handle local movements, so that the global (perhaps L3) mechanisms >do not handle to deal with too many events. Couldn't agree more. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLSh-00030n-HN; Mon, 20 Mar 2006 09:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKbz4-00085H-M8 for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:00:46 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKbz3-0002W5-82 for architecture-discuss@ietf.org; Sat, 18 Mar 2006 09:00:46 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060318140043m13005lu14e>; Sat, 18 Mar 2006 14:00:44 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <441C1069.6010901@piuha.net> References: <20060315164821.GC43552@caida.org> <20060318001532.GA92245@verdi> <441C1069.6010901@piuha.net> Date: Sat, 18 Mar 2006 08:58:15 -0500 To: Jari Arkko , John Leslie , John Day From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 20 Mar 2006 09:34:21 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org What argument would that be? At 15:51 +0200 2006/03/18, Jari Arkko wrote: > >> Also the Link Layer has less scope than the higher layers so in some >>>sense it is often more cost-effective to recover from errors in the >>>smaller scope rather than propagating them to the greater scope of a >>>higher layer and recovering from them there. >>> >>> >> >> This is where it gets messy! >> >> Rather than go into details, let me try to label such considerations >>"engineering" and distinguish them from "architecture". >> >I'm not sure what we should label engineering and what architecture, >but I'll just note that the issue of division of work between link and >higher >layers appears in many functions and not just in error correction. For >instance, the same arguments can be made about mobility mechanisms. > >--Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLSi-00032U-EV; Mon, 20 Mar 2006 09:34:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLDX-0001J7-LL for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:18:43 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLDW-0003XV-Fn for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:18:43 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060320141840011002t8f0e>; Mon, 20 Mar 2006 14:18:41 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> Date: Mon, 20 Mar 2006 09:18:34 -0500 To: "Bound, Jim" , "Noel Chiappa" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Mon, 20 Mar 2006 09:34:21 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > >Also is the only reason we use "layers" for the IP Reference Model >because OSI did? If so that was a bad reason? I don't think that work >in IEEE had anything right for an "Internet" model, as a bias clearly on >my part. No, the reason we use layers is because the ARPANet did. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLT4-0003WM-WA; Mon, 20 Mar 2006 09:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLT3-0003T1-Dz for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:34:45 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLT0-00045R-6h for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:34:45 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id F1F8A34BC6; Mon, 20 Mar 2006 09:34:41 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:34:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 09:34:39 -0500 Message-ID: <936A4045C332714F975800409DE0924001FD23B5@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMKUKtp4O6AMcwS8OyD5F44BnVlgAAhJJw From: "Bound, Jim" To: "John Day" , "Noel Chiappa" , X-OriginalArrivalTime: 20 Mar 2006 14:34:42.0163 (UTC) FILETIME=[6CF04C30:01C64C2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Well maybe we should review that decision....the code is not in layers or products. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Monday, March 20, 2006 9:19 AM > To: Bound, Jim; Noel Chiappa; architecture-discuss@ietf.org > Subject: RE: [arch-d] Defining terms >=20 > > > > > >Also is the only reason we use "layers" for the IP Reference Model > >because OSI did? If so that was a bad reason? I don't=20 > think that work > >in IEEE had anything right for an "Internet" model, as a=20 > bias clearly on > >my part. >=20 > No, the reason we use layers is because the ARPANet did. >=20 > Take care, > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLWC-0004w1-RB; Mon, 20 Mar 2006 09:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLWA-0004vm-Tq for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:37:58 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLW5-0004E8-Hi for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:37:58 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id BF7533402F; Mon, 20 Mar 2006 09:37:51 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:36:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 09:36:53 -0500 Message-ID: <936A4045C332714F975800409DE0924001FD23BB@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMKa/JwZUJBsAwTDCprY+w2AFSkgAAechA From: "Bound, Jim" To: "John Leslie" , "Scott W Brim" , X-OriginalArrivalTime: 20 Mar 2006 14:36:57.0274 (UTC) FILETIME=[BD7899A0:01C64C2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org A connection is a shared state between two end points for communications. A session is is a shared state between two applications regardless of the connection. Both should be end-to-end. /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Monday, March 20, 2006 9:22 AM > To: Scott W Brim; architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > Scott W Brim wrote: > > On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote: > >=20 > >> I would therefore define a "session" as the shared state=20 > in the end =20 > >> systems and in the network, whatever it may be, which directly or =20 > >> indirectly reflects the state of two or more communicating =20 > >> applications. In Flow RED=20 > (http://www.icir.org/floyd/red.html#flow), =20 > >> this would include information stored in network nodes, and it =20 > >> generally includes keys associated with security associations, =20 > >> sequence numbers etc in TCP and SCTP, and the various=20 > addresses that =20 > >> are used by endpoints in a multihomed route. > >=20 > > Elsewhere people have come up with the concept that a "session" is a > > relationship -- not a pipe, not a flow of packets --=20 > created to align > > state information. To do so it may use one or multiple=20 > communication > > events. A successful session could be as simple as "are you there?" > > with a response. >=20 > I see a benefit to thinking of "session" as a relationship between > endpoints. I'm not quite sure either Fred or Scott have stated this > distinctly enough. >=20 > Fred is talking "shared state" which, I suppose, is correct; but it > tends to direct our attention to details of connection(s)=20 > which I think > deserve to be considered a different layer. IMHO, "session" may or > may not imply an ordering in information transmitted over different > connections. >=20 > Scott talks of a "session" being "created to align state=20 > information." > I do not see that either as the "purpose" of a "session" or even a > necessary function of a "session". IMHO, a "session" should identify > endpoints which are processes invoked by users without regard to the > path over which information will flow between them. >=20 > (Whether or not a "session" implies ordering of data communicated > might well be implementation-dependent.) >=20 > > Neither is a session the state information itself. I think these > > terms will be more useful in the future if you distinguish the > > relationship between the endpoints -- the "session" -- from the > > "session state" which reflects the relationship in the participants > > and intermediate nodes. >=20 > I agree with Scott. >=20 > > How is a session different from a connection? Just barely. >=20 > I think we can draw a fairly clear distinction, actually. >=20 > A "connection" is something maintained in a fully automated manner, > without messy interactions. Our network must find a way to=20 > route packets > from one end to the other. Thus, the endpoints of a connection must be > machine-comprehensible addresses, most often globally unique. >=20 > A "session" is something created in response to human action. In > all likelihood, it depends upon rather messy DNS processes to resolve > to IP addresses which routers can use. If conditions change so that > those IP addresses no longer serve the necessary function,=20 > the human(s) > creating the "session" would generally prefer that some further DNS > magic makes the change transparent. >=20 > > A TCP "connection" can be used by HTTP for one exchange,=20 > then allowed > > to lie fallow, then used for a different one. >=20 > Agreed. >=20 > > That's one "flow" from the point of view of the network but multiple > > communications events from the point of view of the applications. >=20 > True, but in practice all the communications events are likely to > represent the same "session". >=20 > > One possible difference between session and connection might be that > > in a connection the participating endpoints are the same for all > > communication flows, while in a "session" involving multiple > > communication events, different parties could be involved=20 > in different > > ones. >=20 > I think I've missed Scott's point here. >=20 > "Participating endpoints" could mean a number of things. IMHO, we > can correctly talk of "participating endpoints" for both "connections" > and "sessions", and mean quite different things. >=20 > > You don't buy it? In that case, really, the only difference=20 > I know of > > is that "connection" is used for lower layers, L4 and below, while > > "session" is used for L5 and above. >=20 > Alas! We can't accept that kind of definition. ;^( >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLWC-0004vw-LI; Mon, 20 Mar 2006 09:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLWA-0004vh-QQ for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:37:58 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLW5-0004E7-Hi for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:37:58 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0505D34099; Mon, 20 Mar 2006 09:37:51 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:37:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 09:37:40 -0500 Message-ID: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMK2ooD3cq8DEfQ9GSl1DO0SodogAAGIGw From: "Bound, Jim" To: "John Day" , "Jari Arkko" X-OriginalArrivalTime: 20 Mar 2006 14:37:42.0195 (UTC) FILETIME=[D83F0030:01C64C2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Perfect example where L2 and L3 are meaningless at least to me. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Saturday, March 18, 2006 9:33 AM > To: Jari Arkko; John Day > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > At 16:22 +0200 2006/03/18, Jari Arkko wrote: > >That it is cost-effective for local (perhaps L2) mechanisms to > >handle local movements, so that the global (perhaps L3) mechanisms > >do not handle to deal with too many events. >=20 > Couldn't agree more. >=20 > John >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:57:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLpQ-0007z8-0o; Mon, 20 Mar 2006 09:57:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLpP-0007yy-4N for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:57:51 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLpN-0005PD-UJ for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:57:51 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FLLpM-0002zZ-Kt; Mon, 20 Mar 2006 06:57:49 -0800 Message-Id: <6.2.3.4.2.20060320153836.0669d7e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 20 Mar 2006 15:42:37 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> References: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-76297B28 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:53 20/03/2006, Noel Chiappa wrote: >(I produced such a design, and I feel that for architectural reasons it >would be superior to do it at the edge, but I don't expect to see it in my >lifetime - and that's not a rhetorical device, I'm already almost 50.) I do not know why. I am older and I saw it negotiated at the edge, and I do not see why I would not see it again on a large scale. Please let stop to consider the digital ecosystem as a unique space, with unique layers, and a unique technology. There can be multiple layer piles aside or on-top of each others. You just need a complete enough general model as I described to understand that. Is your design documented on line? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 09:59:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLqW-0001zx-Lo; Mon, 20 Mar 2006 09:59:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLqV-0001wh-3A for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:58:59 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLqQ-0005RV-Rv for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:58:59 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id DE431340A7; Mon, 20 Mar 2006 09:58:56 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 09:58:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 09:58:20 -0500 Message-ID: <936A4045C332714F975800409DE0924001FD23F3@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMLimk7SebnU0aTN6GpIfX6IYWagAAHEJQ From: "Bound, Jim" To: "John Day" , "Jari Arkko" X-OriginalArrivalTime: 20 Mar 2006 14:58:22.0616 (UTC) FILETIME=[BB983980:01C64C2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Agree with that diff yes. L1 too. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Monday, March 20, 2006 9:52 AM > To: Bound, Jim; John Day; Jari Arkko > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] Defining terms >=20 > At 9:37 -0500 2006/03/20, Bound, Jim wrote: > >Perfect example where L2 and L3 are meaningless at least to me. >=20 > Layer 2 and 3 as traditionally described have very different scopes.=20 > This is a very significant difference. >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 20 16:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRWj-00046D-H9; Mon, 20 Mar 2006 16:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLRWh-00045p-Q7 for architecture-discuss@ietf.org; Mon, 20 Mar 2006 16:02:55 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLRWf-0003V9-D7 for architecture-discuss@ietf.org; Mon, 20 Mar 2006 16:02:55 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA07950; Mon, 20 Mar 2006 13:02:44 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2KL2h916465; Mon, 20 Mar 2006 15:02:43 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Mar 2006 13:02:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 20 Mar 2006 13:02:42 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080258475B@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZMK2ooD3cq8DEfQ9GSl1DO0SodogAAGIGwAA1Tz2A= From: "Fleischman, Eric" To: "Bound, Jim" , "John Day" , "Jari Arkko" X-OriginalArrivalTime: 20 Mar 2006 21:02:43.0232 (UTC) FILETIME=[A1898200:01C64C61] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I don't know to what extent this discussion is based on words or whether we are seeing an actual disagreement about concepts. However, assuming the latter, I think that the key operative difference, from my knot-hole, has to do with the state machines used by the communicating peers/nodes.=20 Specifically, L2 differs from L3 in that the state machine used by the IP Layer protocol is different than the state machine that is used for whatever the underlying L2 protocol may be (e.g., ATM, Ethernet, etc.). -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com]=20 Sent: Monday, March 20, 2006 6:38 AM To: John Day; Jari Arkko Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms Perfect example where L2 and L3 are meaningless at least to me. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net] > Sent: Saturday, March 18, 2006 9:33 AM > To: Jari Arkko; John Day > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > At 16:22 +0200 2006/03/18, Jari Arkko wrote: > >That it is cost-effective for local (perhaps L2) mechanisms to handle > >local movements, so that the global (perhaps L3) mechanisms do not=20 > >handle to deal with too many events. >=20 > Couldn't agree more. >=20 > John >=20 > _______________________________________________ > Architecture-discuss mailing list Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 09:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGE-0004yH-EW; Tue, 21 Mar 2006 09:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLh2-0003Km-Nh for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:49:12 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLh1-0004hl-Gi for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:49:12 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006032014491001300ehru0e>; Mon, 20 Mar 2006 14:49:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> References: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> Date: Mon, 20 Mar 2006 09:48:58 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Tue, 21 Mar 2006 09:55:01 -0500 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >So, yes, only implement that service once - but as a subsystem that other >subsystems can call on when they need it. > >The only reason I can think off off the top of my head to make something >mandatory, and part of some low-level abstraction, is when you want clients >not to be aware that they are using it - e.g. paging (operating systems), or >mobility (networks) - so that clients don't have to do anything "unusual" to >get it, and so that users always have the capability, and the client >designer/implementor can't screw up and take that capability away from the >user. So one creates a module to hide complexity of what is going on under the covers. A black box. Granted. For communications, this means that for the communicating black boxes in different systems there has to be some shared state for communications to take place. Maybe not much, but some. At the very least the communicating parties have to have share the ability to understand the communications. Modules that do not have any shared state are not involved in communications by definition. So we have a collection of things in different systems all cooperating with some amount of shared state and doing it in some black box to hide the complexity from the user of the black box. Now of course, this collection of users can also cooperate to do something and provide a black box to their users. So now, if these are not layers what are they? pancakes? waffles? I would contend that layers are a means of organizing functionality, but have little to do with implementation. But that is nothing new, we have known that for 25 years. Although, if you *need* a boundary for some reason, some place a layer boundary is a good place to do it, if you have chosen your layers wisely. Perhaps we have not chosen wisely. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/arcFrom architecture-discuss-bounces@ietf.org Tue Mar 21 09:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGE-0004yH-EW; Tue, 21 Mar 2006 09:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLh2-0003Km-Nh for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:49:12 -0500 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLh1-0004hl-Gi for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:49:12 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006032014491001300ehru0e>; Mon, 20 Mar 2006 14:49:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> References: <20060320135313.BEA5186AE7@mercury.lcs.mit.edu> Date: Mon, 20 Mar 2006 09:48:58 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Tue, 21 Mar 2006 09:55:01 -0500 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >So, yes, only implement that service once - but as a subsystem that other >subsystems can call on when they need it. > >The only reason I can think off off the top of my head to make something >mandatory, and part of some low-level abstraction, is when you want clients >not to be aware that they are using it - e.g. paging (operating systems), or >mobility (networks) - so that clients don't have to do anything "unusual" to >get it, and so that users always have the capability, and the client >designer/implementor can't screw up and take that capability away from the >user. So one creates a module to hide complexity of what is going on under the covers. A black box. Granted. For communications, this means that for the communicating black boxes in different systems there has to be some shared state for communications to take place. Maybe not much, but some. At the very least the communicating parties have to have share the ability to understand the communications. Modules that do not have any shared state are not involved in communications by definition. So we have a collection of things in different systems all cooperating with some amount of shared state and doing it in some black box to hide the complexity from the user of the black box. Now of course, this collection of users can also cooperate to do something and provide a black box to their users. So now, if these are not layers what are they? pancakes? waffles? I would contend that layers are a means of organizing functionality, but have little to do with implementation. But that is nothing new, we have known that for 25 years. Although, if you *need* a boundary for some reason, some place a layer boundary is a good place to do it, if you have chosen your layers wisely. Perhaps we have not chosen wisely. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 09:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGE-0004yM-Kf; Tue, 21 Mar 2006 09:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLlu-0006vn-8t for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:54:14 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLlt-0004xQ-3N for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:54:14 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032014540901400c16bje>; Mon, 20 Mar 2006 14:54:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> Date: Mon, 20 Mar 2006 09:52:07 -0500 To: "Bound, Jim" , "John Day" , "Jari Arkko" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-Mailman-Approved-At: Tue, 21 Mar 2006 09:55:01 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 9:37 -0500 2006/03/20, Bound, Jim wrote: >Perfect example where L2 and L3 are meaningless at least to me. Layer 2 and 3 as traditionally described have very different scopes. This is a very significant difference. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss hitecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 09:55:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiGE-0004yM-Kf; Tue, 21 Mar 2006 09:55:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLLlu-0006vn-8t for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:54:14 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLLlt-0004xQ-3N for architecture-discuss@ietf.org; Mon, 20 Mar 2006 09:54:14 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032014540901400c16bje>; Mon, 20 Mar 2006 14:54:10 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> Date: Mon, 20 Mar 2006 09:52:07 -0500 To: "Bound, Jim" , "John Day" , "Jari Arkko" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-Mailman-Approved-At: Tue, 21 Mar 2006 09:55:01 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 9:37 -0500 2006/03/20, Bound, Jim wrote: >Perfect example where L2 and L3 are meaningless at least to me. Layer 2 and 3 as traditionally described have very different scopes. This is a very significant difference. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 10:04:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiOz-000198-Qw; Tue, 21 Mar 2006 10:04:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiOx-000192-Ry for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:04:03 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiOw-0002mY-KM for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:04:03 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2006 07:04:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,114,1141632000"; d="scan'208"; a="24087155:sNHT23659128" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2LF42VU006628; Tue, 21 Mar 2006 10:04:02 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:04:08 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:04:01 -0500 Date: Tue, 21 Mar 2006 09:03:23 -0600 From: Scott W Brim To: John Day Subject: Re: [arch-d] Defining terms Message-ID: <20060321150319.GA4560@sbrim-wxp01> Mail-Followup-To: Scott W Brim , John Day , "Bound, Jim" , Jari Arkko , architecture-discuss@ietf.org References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 21 Mar 2006 15:04:01.0629 (UTC) FILETIME=[B01340D0:01C64CF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Mar 20, 2006 09:52:07AM -0500, John Day allegedly wrote: > At 9:37 -0500 2006/03/20, Bound, Jim wrote: > >Perfect example where L2 and L3 are meaningless at least to me. > > Layer 2 and 3 as traditionally described have very different scopes. > This is a very significant difference. Some confusion comes from an assumption of coupling of functionality and protocol, while in fact protocols, particularly connectionless ones, are reusable in different roles. For example we can see IP as part of both the traditional L2 and L3 in some access networks. (Please don't ask me to define access network :-p.) swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 10:16:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiac-0007rR-5C; Tue, 21 Mar 2006 10:16:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiaa-0007rM-MQ for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:16:04 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiaZ-0003N2-8L for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:16:04 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0E79F212C59 for ; Tue, 21 Mar 2006 17:16:02 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BB857212C4C for ; Tue, 21 Mar 2006 17:14:38 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060321150319.GA4560@sbrim-wxp01> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Tue, 21 Mar 2006 09:14:35 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [arch-d] Layers (was Re: Defining terms) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Some confusion comes from an assumption of coupling of functionality > and protocol, while in fact protocols, particularly connectionless > ones, are reusable in different roles. I agree. As far as I can see, real "layering" boundaries are formed by whom the protocol is used to communicate with. If your protocol talks to a "middle box", your layer is "below" the "end-to-end" layer, which talks beyond the middle box. Of course, almost always there are different kinds of middle boxes, including bridges, routers, NATs, firewalls, and application level gateways. But that's all trivial. A major source of complication seems to be the desire to introduce new kinds of middle boxes without creating new "layers". NAT is a good example of what can happen. Other, perhaps less appreciated phenomena that seem to require layering are mobility and multi-path communication. Mobility requires indirection: you have to have separate stable identifiers (so that you can name your peer) and dynamic, location specific identifiers. From an architectural point of view, supporting such indirection within a single name space seems to lead to messy problems. Having two distinct name spaces leads to cleaner solutions, but at the same time create a new layer. More or less the same applies to multi-path communication, but in the spatial rather than temporal dimension. From that point of view, Mobile IP is a good example of what happens when you add mobility without modifying your layering. --Pekka N. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 10:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjBC-00039N-0i; Tue, 21 Mar 2006 10:53:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjBB-00039I-CY for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:53:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjBA-0004ui-53 for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:53:53 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Mar 2006 07:53:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,115,1141632000"; d="scan'208"; a="24093308:sNHT23474908" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2LFrpVc018811; Tue, 21 Mar 2006 10:53:51 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:53:43 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 10:53:42 -0500 Date: Tue, 21 Mar 2006 09:53:01 -0600 From: Scott W Brim To: John Day Subject: Re: [arch-d] Defining terms Message-ID: <20060321155257.GD5936@sbrim-wxp01> Mail-Followup-To: Scott W Brim , John Day , architecture-discuss@ietf.org References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 21 Mar 2006 15:53:42.0964 (UTC) FILETIME=[A116DF40:01C64CFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, Mar 21, 2006 10:13:58AM -0500, John Day allegedly wrote: > >On Mon, Mar 20, 2006 09:52:07AM -0500, John Day allegedly wrote: > >> At 9:37 -0500 2006/03/20, Bound, Jim wrote: > >> >Perfect example where L2 and L3 are meaningless at least to me. > >> > >> Layer 2 and 3 as traditionally described have very different scopes. > >> This is a very significant difference. > > > >Some confusion comes from an assumption of coupling of functionality > >and protocol, while in fact protocols, particularly connectionless > >ones, are reusable in different roles. For example we can see IP as > >part of both the traditional L2 and L3 in some access networks. > >(Please don't ask me to define access network :-p.) > > Could you elaborate? I have no clue what you are talking about. ;-) > > A case can be made that IP is a subnet access protocol since that is > what its addresses name. I have always found it amusing that > Ethernet addresses potentially had more scope than IP addresses. For example, there is a 3G wireless scenario -- which others can describe better than I -- where IP is used to support an IPsec tunnel purely in the "access network", and user IP runs over this. What "layer" is the underlying IP? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 11:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjtI-0005QM-F3; Tue, 21 Mar 2006 11:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjtH-0005QH-Kl for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:39:27 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjtG-0006pl-7E for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:39:27 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 04FD3212CB0; Tue, 21 Mar 2006 18:39:25 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3ED71212CAF; Tue, 21 Mar 2006 18:39:24 +0200 (EET) In-Reply-To: References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Layers (was Re: Defining terms) Date: Tue, 21 Mar 2006 10:39:22 -0600 To: John Day X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Saltzer, Jerry. "On the Naming and Binding of Network Destinations" > in Local Computer Networks, edited by P. Ravasio et al. P North- > Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. Re-reading is always helpful, even the fifth time. :-) A difficulty is created by one man's names being other man's addresses. As Scott pointed out, in modern networks layering tends to get blurred, for example, due to replicated usage of the same protocols. What are the relevant middle boxes (whether they are "routers" or whatever) becomes a function of how people deploy the protocols rather than how they are implemented in the stack of the end host. Messy, I'd say, but part of the reality. Consequently, layering tends to become more a network configuration(1) concept more than stack architecture concept. (1) Note that what we in the IETF usually consider as network configuration is often referred by telecom people (e.g. in 3GPP) as network architecture. Hence, beware of the different connotations of "architecture". --Pekka N. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 11:43:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjwh-0007Gy-Kt; Tue, 21 Mar 2006 11:42:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjwg-0007Gt-UL for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:42:58 -0500 Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjwf-00072B-HD for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:42:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2LGfT01032029; Tue, 21 Mar 2006 18:41:30 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 18:42:49 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 18:42:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 21 Mar 2006 18:42:48 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0A1@esebe100.NOE.Nokia.com> In-Reply-To: <20060321155257.GD5936@sbrim-wxp01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNAXafYNaZJnM3QE6Ol7AA1L+PawABNk9A From: To: , X-OriginalArrivalTime: 21 Mar 2006 16:42:49.0734 (UTC) FILETIME=[7D804A60:01C64D06] X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >For example, there is a 3G wireless scenario -- which others=20 >can describe better than I -- where IP is used to support an=20 >IPsec tunnel purely in the "access network", and user IP runs=20 >over this. What "layer" is the underlying IP?=20 Would this be the same as an IP-in-IP tunnel? =20 John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 11:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk1K-00026g-HX; Tue, 21 Mar 2006 11:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLk1J-00026E-9L for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:47:45 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLk1H-0007GJ-Su for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:47:45 -0500 Received: from [130.129.132.63] (DHCP-Wireless-132-63.ietf65.org [130.129.132.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2LGkgw19584; Tue, 21 Mar 2006 08:46:42 -0800 (PST) Message-ID: <44202DEC.30400@isi.edu> Date: Tue, 21 Mar 2006 08:46:36 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [arch-d] Defining terms References: <1AA39B75171A7144A73216AED1D7478D0186A0A1@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0A1@esebe100.NOE.Nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org, jeanjour@comcast.net X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org See RFC 3884 for the differences ;-) Joe john.loughney@nokia.com wrote: >> For example, there is a 3G wireless scenario -- which others >> can describe better than I -- where IP is used to support an >> IPsec tunnel purely in the "access network", and user IP runs >> over this. What "layer" is the underlying IP? > > Would this be the same as an IP-in-IP tunnel? > > John > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 18:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqYw-0004bp-E8; Tue, 21 Mar 2006 18:46:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqYv-0004bk-Iv for architecture-discuss@ietf.org; Tue, 21 Mar 2006 18:46:53 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqYu-0001iB-8b for architecture-discuss@ietf.org; Tue, 21 Mar 2006 18:46:53 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 52011E044C; Tue, 21 Mar 2006 18:46:52 -0500 (EST) Date: Tue, 21 Mar 2006 18:46:52 -0500 From: John Leslie To: "Bound, Jim" Subject: Re: [arch-d] Defining terms Message-ID: <20060321234652.GD11517@verdi> References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: > > I think we should for a moment imagine a world without layer but as > modules. Really that is how the actual code is and not in layers. Sure > IP packet gets parsed before TCP, and TCP makes decisions before passing > data, as example here only, but is that layers or as Noel states > modules? Let's not forget that layers are an abstraction, intended to limit the complexity which any one process needs to deal with. If we do layers correctly, every process can ignore most of what's happening at lower layers as well as everything happening at higher layers. Tunneling doesn't break the abstraction: it merely confuses the folks who try to visualize the whole system and think there's something wrong when a layer-four procedure is used to implement a layer-two function. The abstraction still works fine: the layer-three built on top of that tunnel need know nothing about how the layer-two is actually implemented over a layer-four tunnel. It's true that implementation may blend layers and implement the combined layers as modules. This doesn't break the abstraction either (unless the implementation is buggy). I used to write implementations like that, when processing cycles were expensive. The implementor can still think of layers even if the implementation isn't layered. > As far as the edge doing routing I think that is the wrong question? > Once a packet has a destination path it should be move to that path? > That is done with routing. "Routing" is two almost-unrelated things: generating a path which "should work" vs. passing packets to another router "closer" to the destination. Both of these get arbitrarily complex as topology changes. (And, believe me, it does!) The abstraction says that passing packets from router to router exists in a layer separate from encoding bits (a lower layers) and also separate from establishing and tearing down "connections" (a higher layer). The other "routing" function is quite a different matter; and might as well be considered out-of-band communications. > Now finding the most optimal path at a point on a network is fine any > time whether at the edge or within the core. So I think this may be a > moot point. Agreed. It is mostly orthogonal to our layering model. > Also should we define what we mean by the "edge". A bit late to start that... ;^) > Also is the only reason we use "layers" for the IP Reference Model > because OSI did? No. > If so that was a bad reason? It wouldn't have been a bad reason. We have formed an abstraction we call "layers" totally separate from what OSI called "layers". That the two have converged at all over the years is, IMHO, a good thing. > ... but end-to-end to me is routers only get to forward based on the > IP address "End-to-end" IMHO means that we didn't want routers guessing what something at layer four or above wanted to do with the data: we wanted routers doing a simple-minded task that was easy for layer four to model; and that layer four would do all the worrying about anything beyond that simple model that it might need. This has led to things like the Web just happening, without any waiting for routers to learn how to serve the needs of browsers and servers better. (We certainly know now how to serve those needs better; but most folks prefer that the Web happened when it did.) The IP address, BTW, _defines_ endpoints for layer three. The fact that it serves any other purpose is immaterial to layer three. > and end-to-end cannot be possible unless each client on either end > of the commo both have a globally routable source and destination > address. Fully agree. (That's pretty much the definition of layer three...) > Changing the IP address in a header breaks end-to-end. Um... I'd really like to agree. (I hate NATs.) But actually, NATs kludge the actual layer three so that it looks just like a layer three to unsuspecting layer-four processes, despite having been thoroughly broken in the middle. Thus end-to-end still works (mostly). (BTW, NATs could be much cleaner and less buggy if we kept "session" endpoint addressing entirely separate from level-three IP addressing.) To summarize: Jim is correct about implementation; but we should be discussing architecture. Implementation is engineering, not architecture. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 19:16:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLr1c-0004sP-Mv; Tue, 21 Mar 2006 19:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqzh-0004Gc-PH for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:14:33 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqoi-0002We-HB for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:03:13 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FLqoe-0002a5-2s; Tue, 21 Mar 2006 16:03:08 -0800 Message-Id: <6.2.3.4.2.20060321194006.04f66700@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 21 Mar 2006 19:42:10 +0100 To: Joe Touch From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <44202DEC.30400@isi.edu> References: <1AA39B75171A7144A73216AED1D7478D0186A0A1@esebe100.NOE.Nokia.com> <44202DEC.30400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E347206 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 17:46 21/03/2006, Joe Touch wrote: >See RFC 3884 for the differences ;-) I suggest that discussing architecture (to also have confusion with "configurations") means never alluding to an RFC, ISO standard, etc. Because they talk of a specific and past approach. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 19:30:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrFP-0007dj-4u; Tue, 21 Mar 2006 19:30:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrFO-0007dR-DG for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:30:46 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrFK-0003sS-0o for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:30:46 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 274E03439D; Tue, 21 Mar 2006 19:30:56 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:30:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 21 Mar 2006 19:30:39 -0500 Message-ID: <936A4045C332714F975800409DE09240020298DB@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNQcAb7qyqXGUyQUGt7WqHA7jAGgABbn1g From: "Bound, Jim" To: "John Leslie" X-OriginalArrivalTime: 22 Mar 2006 00:30:40.0881 (UTC) FILETIME=[D9356610:01C64D47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hey John no disagreement here good response. I was throwing out some fodder from short period in career when I worked in pure research and the manager would assign the same task to 3 of us and also ask questions like I did about layers (and I lapsed on ARPA clearly). I agree we are about architecture, but a logic check with implementation principles is a good thing too. =20 /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Tuesday, March 21, 2006 6:47 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > Bound, Jim wrote: > >=20 > > I think we should for a moment imagine a world without layer but as > > modules. Really that is how the actual code is and not in=20 > layers. Sure > > IP packet gets parsed before TCP, and TCP makes decisions=20 > before passing > > data, as example here only, but is that layers or as Noel states > > modules? >=20 > Let's not forget that layers are an abstraction, intended to limit > the complexity which any one process needs to deal with. If=20 > we do layers > correctly, every process can ignore most of what's happening at lower > layers as well as everything happening at higher layers. >=20 > Tunneling doesn't break the abstraction: it merely=20 > confuses the folks > who try to visualize the whole system and think there's=20 > something wrong > when a layer-four procedure is used to implement a layer-two function. > The abstraction still works fine: the layer-three built on top of that > tunnel need know nothing about how the layer-two is actually=20 > implemented > over a layer-four tunnel. >=20 > It's true that implementation may blend layers and implement the > combined layers as modules. This doesn't break the abstraction either > (unless the implementation is buggy). I used to write implementations > like that, when processing cycles were expensive. The implementor can > still think of layers even if the implementation isn't layered. >=20 > > As far as the edge doing routing I think that is the wrong question? > > Once a packet has a destination path it should be move to that path? > > That is done with routing. >=20 > "Routing" is two almost-unrelated things: generating a path which > "should work" vs. passing packets to another router "closer" to the > destination. Both of these get arbitrarily complex as=20 > topology changes. > (And, believe me, it does!) The abstraction says that passing packets > from router to router exists in a layer separate from encoding bits > (a lower layers) and also separate from establishing and tearing down > "connections" (a higher layer). >=20 > The other "routing" function is quite a different matter; and might > as well be considered out-of-band communications. >=20 > > Now finding the most optimal path at a point on a network=20 > is fine any > > time whether at the edge or within the core. So I think=20 > this may be a > > moot point. >=20 > Agreed. It is mostly orthogonal to our layering model. >=20 > > Also should we define what we mean by the "edge". >=20 > A bit late to start that... ;^) >=20 > > Also is the only reason we use "layers" for the IP Reference Model > > because OSI did? >=20 > No. >=20 > > If so that was a bad reason? >=20 > It wouldn't have been a bad reason. >=20 > We have formed an abstraction we call "layers" totally=20 > separate from > what OSI called "layers". That the two have converged at all over the > years is, IMHO, a good thing. >=20 > > ... but end-to-end to me is routers only get to forward based on the > > IP address >=20 > "End-to-end" IMHO means that we didn't want routers guessing what > something at layer four or above wanted to do with the data: we wanted > routers doing a simple-minded task that was easy for layer four to > model; and that layer four would do all the worrying about anything > beyond that simple model that it might need. >=20 > This has led to things like the Web just happening, without any > waiting for routers to learn how to serve the needs of browsers and > servers better. (We certainly know now how to serve those needs > better; but most folks prefer that the Web happened when it did.) >=20 > The IP address, BTW, _defines_ endpoints for layer three. The fact > that it serves any other purpose is immaterial to layer three. >=20 > > and end-to-end cannot be possible unless each client on either end > > of the commo both have a globally routable source and destination > > address. >=20 > Fully agree. (That's pretty much the definition of layer three...) >=20 > > Changing the IP address in a header breaks end-to-end. >=20 > Um... I'd really like to agree. (I hate NATs.) >=20 > But actually, NATs kludge the actual layer three so that it looks > just like a layer three to unsuspecting layer-four processes, despite > having been thoroughly broken in the middle. Thus end-to-end still > works (mostly). >=20 > (BTW, NATs could be much cleaner and less buggy if we kept=20 > "session" > endpoint addressing entirely separate from level-three IP addressing.) >=20 > To summarize: Jim is correct about implementation; but we should > be discussing architecture. Implementation is engineering, not > architecture. >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 19:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrHj-00009s-K9; Tue, 21 Mar 2006 19:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrHi-00009n-5W for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:33:10 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrHd-0003ug-Tk for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:33:10 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1BB6E34398; Tue, 21 Mar 2006 19:33:06 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 19:33:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 21 Mar 2006 19:33:04 -0500 Message-ID: <936A4045C332714F975800409DE09240020298DE@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNReQgsn744nUzQjm/YNiyfddYqAAAfwcA From: "Bound, Jim" To: "JFC (Jefsey) Morfin" , "Joe Touch" X-OriginalArrivalTime: 22 Mar 2006 00:33:05.0252 (UTC) FILETIME=[2F42AA40:01C64D48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Now that is very interesting view. I can go there but would like for it to be other than just the two of us ---). Anyone not ok with this suggestion? =20 But at the end if we break compatibility with today it may never happen for the right or wrong reasons. Thus we could spin and never get to deployment of the idea. Again that is ok with me too. /jim > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]=20 > Sent: Tuesday, March 21, 2006 1:42 PM > To: Joe Touch > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > At 17:46 21/03/2006, Joe Touch wrote: >=20 > >See RFC 3884 for the differences ;-) >=20 > I suggest that discussing architecture (to also have confusion with=20 > "configurations") means never alluding to an RFC, ISO standard, etc.=20 > Because they talk of a specific and past approach. > jfc=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 19:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrJR-0000Pb-Hn; Tue, 21 Mar 2006 19:34:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrJQ-0000PW-Ir for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:34:56 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrJP-0003w1-Aq for architecture-discuss@ietf.org; Tue, 21 Mar 2006 19:34:56 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id D3ACDE043E; Tue, 21 Mar 2006 19:34:55 -0500 (EST) Date: Tue, 21 Mar 2006 19:34:55 -0500 From: John Leslie To: Pekka Nikander Subject: Re: [arch-d] Layers (was Re: Defining terms) Message-ID: <20060322003455.GE11517@verdi> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: > > As far as I can see, real "layering" boundaries are formed by whom > the protocol is used to communicate with. This should be a good way to look at it. It used to be that layer one talked to the same wire, layer two talked to a network connected by wires, and layer three talked to anything on the network of networks. It's becoming more difficult to think that way. We now are asked to accept that layer one may be the "ether" carrying radio waves. We generally think of layer two as including "ethernets" connected only by switches (which actually behave quite differently than a network connected by wires). And layer three now suffers from any number of "middleboxes" such as NATs. > If your protocol talks to a "middle box", your layer is "below" > the "end-to-end" layer, which talks beyond the middle box. I'm afraid this way of looking at it isn't workable. It is correct to say that a layer talks beyond any middleboxes (which actually includes ethernet switches on an ethernet. Alas, it is no longer correct to say that communication with a "middlebox" is necessarily at a lower "layer". :^( > Of course, almost always there are different kinds of middle boxes, > including bridges, routers, NATs, firewalls, and application level > gateways. I agree these are all "middleboxes". > A major source of complication seems to be the desire to introduce > new kinds of middle boxes without creating new "layers". NAT is a > good example of what can happen. In fact, NATs arose to "solve" several problems, which could not be practically solved by introducing a new layer. Most of the folks implementing them knew they were implementing kludges. The customers only knew that these boxes "helped" with the problems. > Other, perhaps less appreciated phenomena that seem to require > layering are mobility and multi-path communication. I quite agree these would benefit from adding layer(s). > Mobility requires indirection: you have to have separate stable > identifiers (so that you can name your peer) and dynamic, location > specific identifiers. I agree we need stable identifiers; I'm not sure "indirection" is the only option for deriving location-specific identifiers. > From an architectural point of view, supporting such indirection > within a single name space seems to lead to messy problems. Agreed. > Having two distinct name spaces leads to cleaner solutions, but at > the same time create a new layer. More or less the same applies to > multi-path communication, but in the spatial rather than temporal > dimension. Agreed. > From that point of view, Mobile IP is a good example of what happens > when you add mobility without modifying your layering. Ouch! ;^) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 20:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrtA-0000i6-Eg; Tue, 21 Mar 2006 20:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrt8-0000ht-HX for architecture-discuss@ietf.org; Tue, 21 Mar 2006 20:11:50 -0500 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrt7-0004uw-MZ for architecture-discuss@ietf.org; Tue, 21 Mar 2006 20:11:50 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 21 Mar 2006 17:11:43 -0800 Received: from scsmsx332.sc.intel.com (HELO scsmsx332.amr.corp.intel.com) ([10.3.90.6]) by fmsmga001.fm.intel.com with ESMTP; 21 Mar 2006 17:11:43 -0800 X-IronPort-AV: i="4.03,116,1141632000"; d="scan'208"; a="14925807:sNHT138008857" Received: from scsmsx402.amr.corp.intel.com ([10.3.90.16]) by scsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 17:11:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 17:11:40 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Defining terms Thread-Index: AcZNQPXSBJKYgQbYS2aIFmtMs9ayagAAE7YQ From: "Fall, Kevin" To: X-OriginalArrivalTime: 22 Mar 2006 01:11:42.0776 (UTC) FILETIME=[949CC380:01C64D4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Subject: [arch-d] RE: Defining terms X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >=20 > ----- Forwarded message from Fred Baker ----- >=20 >=20 > Date: Mon, 6 Mar 2006 15:02:24 -0800 > From: Fred Baker > Subject: [arch-d] Defining terms > To: architecture-discuss at ietf.org > X-Mailer: Apple Mail (2.746.2) >=20 > OK, so this takes off on one of the many topics we have been discussing... >=20 >=20 > Let me see what I can add to this. >=20 >=20 > There are a variety of papers that have tried to define the concept of a > 'session" in a network that is connectionless at the network layer. I'm > not sure what the orgiginal document is, although I am sure that it vastly > predates RFC 1144, which is the oldest RFC that seems to use the terms > "shared state" and "fate sharing". But bottom line, while the internet > layer has no concept of what we now call a "virtual circuit" or "virtual > channel", it has been long recognized that the applications and the > transports in question have to have some degree of shared state to enable > them to function, and that in the event that something goes completely > south there is a necessity for "fate sharing" - all systems retaining the > shared state have to at some point decide that it is for nought and delete > it. > One of the things we have been interested in is when the session layer's state is persistent and when multiple transports (across different protocol families) can be used, perhaps simultaneously. More specifically, one can imagine a "socket" type of abstraction that is neither protocol family dependent and whose "socket buffer" contents are retained across (e.g.) reboots and long-term to moderate-term interruptions. In a world in which cell phones are arguably going to be the most numerous hosts on the Internet (when they are connected to the Internet, that is), the heterogeneity and persistence become I think more compelling than they have been in the past. Thinking along these lines brings up the question as to whether the app interface to a would-be session layer looks more VC-like or more message/packet-like. I think there are arguments for both. When beginning to undertake a high-level networking architecture discussion it seems appropriate to consider what you want 'your network' to ultimately do. Several folks on this list have begun to suggest this. I think that is an interesting conversation by itself, before you get into layering (primarily an implementation techique, imho). >=20 >=20 > Before we get to what is "session" we should probably review the degrees > of shared state. It seems there are several: >=20 >=20 > First there is the shared state associated with the 3 phases of > communications: >=20 > Enrollment phase: the operations necessary to create the minimal shared > state necessary to allow an instance of communications to be created. This > is all that messy initial stuff we like to ignore like making sure that > both systems have operating instances of the same protocol machine, > assigning addresses, and making them available to protocol machines, etc. > All the initial stuff that needs to be in place. It is information held in > common and so strictly speaking shared state. Even here I would ask to what degree the state is persistent. Traditionally the Internet version of this is not very.. but there may be new requirements now and a different $/megabyte storage tradeoff. >=20 > Establishment Phase: (I prefer to call it Allocation) the operations > necessary to allocate an instance of communication creating sufficient > shared state to support the mechanisms of the data transfer phase. This is > generally what we think of as creating shared state. >=20 > And the Data Transfer Phase: On-going operations during data transfer to > maintain the shared state created in the Allocation phase. If you believe in the "move your transport endpoint to a new place" approaches, there might be another. >=20 > Allocation seems to have 3 forms/degrees of shared state: > minimal: corresponding to a pure connectionless, such as UDP' connectionless !=3D never reliable > moderate: corresponding to flows with only mechanisms involving the > Transfer PDU and only need a 2-way handshake synchronization procedure, > strong: corresponding to flows supporting feedback mechanisms that require > a 3-way handshake synch mechanism. I'm not clear why 2 vs 3 way is fundamental, except perhaps as to whether your association abstraction is bi-directional. >=20 >=20 >=20 ... >=20 >=20 >=20 > This would seem to roll a lot of things into a session. Let me defer > commenting on this for now. But do let me say, I would prefer a definition > that was more abstract and less in terms of specific things. yes > Assuming that > "session" is something above "transport layer" I am uncomfortable with it > including information about the internal workings of "other layers." Each > layer should have its own addressing structure, so saying the Session > Layer has addresses is a bit redundant. I wonder how fundamental even this is. For example, if you are on your own non-IP Ethernet LAN, we can certainly imagine two processes exchanging data without a formalized transport protocol. Not that I object, per se, but in our experience just what is "transport" v not a transport protocol is sometimes not so straightforward. > I would suggest that we start out with a rational definition of the > various layers. I include a questioned layer, which I think Tony is > alluding to, and the ISO and XNS Session models, which have some history. > I suspect that we will have various comments on these architecturally, and > when we get this part of the question sorted out, we will have a better > notion of what further we might want to say. I would suggest that comes just after figuring out what your really want the network to do. (that said, I'll comment on the layers anyhow :o). >=20 >=20 > physical layer: > The physical layer is the lowest communication layer > consisting of the > physical medium of communication and the means of signaling over > it. It is responsible for defining the physical means of sending data, > interfacing between network media and devices, and defining the media's > optical, electrical and mechanical characteristics. (and acoustic, if you've been hanging out with people building underwater acoustic networks like I have) > Examples of this ... >=20 > link layer: ... >=20 >=20 > It may be a nit, but I would put the encoding of bits into signals as part > of the physical layer. Yes, agreed.. in fact the 'modulation sub-layer' if you are willing to divide up the physical layer... or media-dependent phys layer if you like IEEE-speak. > The purpose of the Data Link Layer is to manage the > access to the physical medium, and provide error and flow control tailored > to the characteristics of the media. The data link layer provides > sufficient error control to make error control at higher layers, i.e. > Transport, cost effective. Hmm. That's sort of subjective, and (unfortunately) not generally true. For various wireless systems it just might not be possible to provide that. > Also the Link Layer has less scope than the > higher layers so in some sense it is often more cost-effective to recover > from errors in the smaller scope rather than propagating them to the > greater scope of a higher layer and recovering from them there. In some > sense, a data link layer is "end-to-end" it is just that the ends are > closer together. Or maybe end-to-end(s), given shared multiaccess networks which would be the focus of the next point: >=20 > I would also contend that this error and flow control function (LLC) is > distinct from the managing the medium function (MAC) and depending on the > nature of the medium a data link layer may have one or the other or both. Sure. Well-covered by IEEE I think. Even MAC can be further divided into the stuff to manage access to the channel that's common across modulation/coding schemes and those that are dependent. > A point to point wire might only have the LLC aspect, while a LAN > supporting multiple endpoints might have the MAC but sufficiently reliable > to require only minimal LLC or none. To media that require both. >=20 >=20 > Network layer: > The communication layer that builds networks out of link layer > relationships and enables systems to communicate information between > systems that are not directly connected at the link layer. Wouldn't a bridged L2 network meet this criteria? I guess you answer that next... > The network > layer contains at least two major sublayers, and these may be implemented > recursively. >=20 > Intranet Layer: > The Intranet layer is the lower sublayer of the network layer. It connects > systems that are under common administration, are intended to be connected > in a simple manner, and generally applies no administrative policy within > the network. Examples of this include X. > 25, Frame Relay, ATM, MPLS, IEEE 802.1 Transparent Bridging, IEEE > 802.1/802.5 Source-Route Bridging, and IEEE 802.11 wireless networking. Ok, but certainly there can be administrative policy even among bridges or within 802.11 ESS's. >=20 > Internet Layer: > The Internet layer is the upper sublayer of the network layer. It may be > used to connect systems under common administration and implementing > common policy, but is also commonly used to connect systems under > different administration or with differing administrative policy. Internet > nodes include the internet layer in hosts or in routers, and each support > at least one address by which they are reachable by their administration. > In the Internet, IPv4 and IPv6 are examples of the Internet layer. >=20 > These 3 are an interesting characterization. And very much reflects what ... >=20 >=20 >=20 > describe transport, it is a sublayer of the transport layer, although IPv6 > incorporates it and other end-system to end-system capabilities like > fragmentation and reassembly into IPv6. Are these functions of a session > management layer? Is the session management layer in fact the lowest end- > 2-end communications layer?> >=20 >=20 >=20 > No, IPSEC is not a separate layer, but an add-on. It seems that its being > a separate protocol is more an artifact of history than the way it really > wants to be done. I think maybe you don't try to describe it :), at least for now. >=20 >=20 > Transport layer: > The transport layer is the lowest layer that runs end to end. So, eh, is "split-TCP" a transport layer, or no? Also, it seems to me that IP/network layer is 'end to end' in which end ends are whatever have network layer addresses. > It may be > viewed as the end-to-end counterpart to the link layer, enabling > applications running in end systems to communicate effectively across the > network connecting them. "Effective communication" are application > concepts; many applications call for reliable sequential delivery of data > within a transaction, and a subset can handle transactions in arbitrary > order. TCP and SCTP are examples of protocols which run at the Transport > layer; there are other examples. UDP is not an example of a transport, > although it may be considered an example of the multiplexing sublayer of > the transport, as the methods used to make communication effective are > implemented in the application. >=20 >=20 >=20 > I pretty much agree, but I would consider UDP part of this layer. The > question here is what is the layer, not how the protocols work. > Applications request service with certain characteristics. And presumably layers can signal to layers above about what they can do, possibly as a time-varying function (e.g. 802.11b can change data rates on you). > The layer can > use any set of mechanisms it likes to provide that service. If the layer > below it is very reliable, then it may chose to use UDP for even a request > wanting a reliable transfer. So UDP is just a degenerate case and it does > carry necessary identfiiers, i.e. ports. >=20 >=20 > Session Layer: > As defined by ISO, the session layer manages user sessions and dialogues, > controls establishment and termination of logic links between users, and > reports upper layer errors. As defined by Xerox Network Systems, the > middleware application Courier provided a Remote Procedure Call service in > which incoming sessions were all referred to Courier and transferred from > there to other applications a deemed appropriate through AAA policy and > parameter acquisition procedures. >=20 > Application Layer: > In the Internet, the application generally includes the ISO concept of the > presentation layer, which deals with encoding and deciding data. This is > the communication layer or program that directly serves > the user, whether directly or remotely. In a world of network coding or erasure coding wherein you may wish to select the coding based on path properties (or properties of multiple paths), I wonder if the presentation layer belongs where it once does (or maybe it is in >1 place). A related question goes to fragmentation types of functions which I am now convinced may be required for at least two orthogonal purposes: 1. MTU adaptation-- what IP does not, and 2. efficient utilization of network capacity (e.g. across multiple paths simultaneously). >=20 > By 1983, OSI had determined that the Session and Presentation Layers ... >=20 > What OSI did find was that applications required a common establishment > mechanism. All applications used the same application connection > establishment mechanism, called ACSE. This is needed to carry the > application naming information and probably initial security parameters. > If you don't have it then someone needs to understand the format of the > first message of every application protocol. This also allows one to avoid > the well-known socket stop-gap that the ARPANet had done to get ready for > the ICCC 72 demo. Its okay when you only have 3 applications but doesn't > really scale. >=20 > ACSE corresponds fairly closely to what is described as Session in other > schemes, such as XNS. (An aside: OSI saw application made of building > blocks called ASEs that were essentially modules of a protocol. ACSE was > an ASE that every application protocol included to create the application > connection. (There was also a Unit-Data version of ACSE as well.) Other > ASEs might be defined for common functions like one or two phase commit, > or ASEs specific to the application. These were bound by a "control > function" that maintained coordination and sequencing of the ASEs making > up an application protocol. It probably sounds more complicated than it > was. OSI basically saw application protocols as being constructed of > several modules.) Eventually, ACSE was modified to allow completely > general nesting of application protocols. Is it the case that this approach had all the modules as part of the 'network' achitecture, whereas most of the time now we just put them in programming libraries so we don't have to talk about them as part of the network? >=20 > If OSI had been left to its own devices, ACSE would probably have ended up > as the Session Layer. But with ITU usurping Session, this seemed to be the > easiest way around it. It wasn't really. If you look at the "functional > units" that were defined in the Session Layer, they are really just simple > ASEs. Other problems arise with having these functions in the Session > Layer when more complex applications are attempted but we won't go into > that here. Do you have a readable reference on this? >=20 > Also, if one goes back to our early discussions of "Session" in the early > days, the term reflects a narrow view we had of what computers were all > about in the 1970s. Had we pursued that I think it would have taken us > toward something more like Netware, which while one useful application > environment would be too narrow for the variety of things that need to be > supported. So it turns out that ACSE is probably what you want for the > general case and include specific ASEs if you need something more narrow. >=20 > So that is how Fred's characterization stacks up against what OSI was > thinking. Actually all of these are fairly traditional descriptions. And, > while not entirely "wrong," I think this view isn't quite right either and > a much simpler scheme is possible. Yeah, sort of sounds like it, although where the 'system boundary' is here (see last comment) might be different [?] Cheers, - Kevin _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 20:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsZs-0002iA-TD; Tue, 21 Mar 2006 20:56:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsZr-0002i5-9D for architecture-discuss@ietf.org; Tue, 21 Mar 2006 20:55:59 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsZr-0006t9-0N for architecture-discuss@ietf.org; Tue, 21 Mar 2006 20:55:59 -0500 Received: from h-68-166-189-37.snvacaid.dynamic.covad.net ([68.166.189.37] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FLsZq-0001ab-00 for architecture-discuss@ietf.org; Tue, 21 Mar 2006 20:55:58 -0500 Message-ID: <000c01c64d54$231973a0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net><20060321150319.GA4560@sbrim-wxp01><15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> <20060322003455.GE11517@verdi> Subject: Re: [arch-d] Layers (was Re: Defining terms) Date: Tue, 21 Mar 2006 17:58:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "John Leslie" > To: "Pekka Nikander" > Cc: > Sent: Tuesday, March 21, 2006 4:34 PM > Subject: Re: [arch-d] Layers (was Re: Defining terms) > > Pekka Nikander wrote: > > > > As far as I can see, real "layering" boundaries are formed by whom > > the protocol is used to communicate with. > > This should be a good way to look at it. It used to be that layer > one talked to the same wire, layer two talked to a network connected > by wires, and layer three talked to anything on the network of > networks. > > It's becoming more difficult to think that way. We now are asked > to accept that layer one may be the "ether" carrying radio waves. We > generally think of layer two as including "ethernets" connected only > by switches (which actually behave quite differently than a network > connected by wires). And layer three now suffers from any number of > "middleboxes" such as NATs. ... Another way to think of a layer is in terms of its interface definitions. A layer provides a set of services. A protocol is defined in terms of syntax and procedures which, when implemented, carry out those services. However, a protocol may need to use some services (e.g., send bits) of another layer, which by convention we speak of as being "lower" in the "stack." An important point is that any layer capable of providing the necessary services could, in some configuration or another, make sense as a "service provider" for some upper layer protocol. This is exactly what we see in tunneling, VPNs, etc. The only protocols that don't need the services of a "lower" layer are those of the physical layer, and even in this case one may have reason to implement something simulating a particular physical layer, in order to satisfy the service requirements of some higher protocol. The "classical" layers are just convenient packages of services that have proven useful, and, in a chicken-and-egg way, have served to characterize the protocols used to implement those services. The ones most interesting here still end up being - hop-to-hop (data link) - hop-by-hop (network) - endsysteminterface-to-endsysteminterface (transport) - endsystem-to-endsystem (session) - application-to-application (application) Taking this view, it's perfectly reasonable to run an application protocol directly over an appropriate data link protocol in a point-to-point network, if that protocol provides the necessary services. (Or you can imagine pass-through services replacing all the intervening layers, but I think doing so reduces the generality of the approach.) A key point is that one can think of the binding between layers and protocols as something quite dynamic. With some protocols it works beautifully (we implemented this approach in the late 1980s) but gets ugly in the case of TCP/IP due to the way the headers are laid out. Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 21:11:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsoT-0003jk-FN; Tue, 21 Mar 2006 21:11:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsoS-0003jf-9f for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:11:04 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsoR-0007er-1I for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:11:04 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FLsoO-0000Fg-B1; Tue, 21 Mar 2006 18:11:00 -0800 Message-Id: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 02:20:02 +0100 To: "Bound, Jim" ,"Joe Touch" From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <936A4045C332714F975800409DE09240020298DE@tayexc14.americas .cpqcorp.net> References: <936A4045C332714F975800409DE09240020298DE@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7E347206 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 01:33 22/03/2006, Bound, Jim wrote: >Now that is very interesting view. I can go there but would like for it >to be other than just the two of us ---). Anyone not ok with this >suggestion? > >But at the end if we break compatibility with today it may never happen >for the right or wrong reasons. Thus we could spin and never get to >deployment of the idea. I think not. Because there is no real architecture RFC. Even RFC 1958 is more recipes for good design. Also because a good architectural solution should support the convergence of the existing technologies. We all know/want it. Also because this architecture is to deliver communications within the same digital ecosystem. By definition there will be bridges. The practical test of credibility will be the ROI of a transition. We want a model which will last. It cannot depend on the engineering solutions it is to replace. Retro-compatibility with passed limitations cannot be the base of a brillant future. jfc >Again that is ok with me too. > >/jim > > > -----Original Message----- > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Sent: Tuesday, March 21, 2006 1:42 PM > > To: Joe Touch > > Cc: architecture-discuss@ietf.org > > Subject: Re: [arch-d] Defining terms > > > > At 17:46 21/03/2006, Joe Touch wrote: > > > > >See RFC 3884 for the differences ;-) > > > > I suggest that discussing architecture (to also have confusion with > > "configurations") means never alluding to an RFC, ISO standard, etc. > > Because they talk of a specific and past approach. > > jfc > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 21:15:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLssr-0006kM-CS; Tue, 21 Mar 2006 21:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLssp-0006kH-M1 for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:15:35 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsso-0007vU-Cw for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:15:35 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A4F5E86AFC; Tue, 21 Mar 2006 21:15:31 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-Id: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> Date: Tue, 21 Mar 2006 21:15:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day > Now of course, this collection of users can also cooperate to do > something and provide a black box to their users. > So now, if these are not layers what are they? pancakes? waffles? > I would contend that layers are a means of organizing functionality The problem with layers is that are a simplification of reality - and, moreover, a simplification that rapidly becomes stultifying and confusing. The reality of the subsystem/protocol dependency graph, in real networks, is too complex to be captured with the simple ordered layer model. As one example, look at BGP. It's used for passing around routing info - so it's part of the inter-network layer, right? Yes, but, it uses TCP. So it's above the transport layer, right? "Does not compute! Does not compute!" Or what about those things that open a PPP link over a TCP connection? Similarly confusing. What's really important, for a system architect, is the subsystem dependency graph. Anything which confuses that representation is non-optimal - and an ordered layer model definitely counts. To put it another way, layers may a fine device for introducing basic networking concepts to beginning students, but they are really a bad idea for use by anyone past the level of "initial introduction". To mangle one of my favourite military axioms, "Beginners think in layers, everyone else thinks in subsystem dependency graphs." > So we have a collection of things in different systems all cooperating > with some amount of shared state and doing it in some black box to hide > the complexity from the user of the black box. Right - and this touches on a point I like to rant about, which is that too often: In drawing block diagrams, people treat "the part of subsystem X in machine A and "the part of subsystem X in machine B" as more distantly related than "the part of subsystem X in machine A" and "the part of subsystem Y in machine A". In other words, they tend to draw diagrams in which the main boxes are machine A and machine B, with maybe little sub-boxes inside those boxes for subsystems X and Y. However, when you're trying to understand the subsystem dependency issues, this makes those dependencies much harder to see. The other kind of diagram, in which the main boxes are subsystems X, Y, etc are much rarer - alas. > Although, if you *need* a boundary for some reason, some place a layer > boundary is a good place to do it, if you have chosen your layers > wisely. A layer boundary is, in many ways, just a subsystem interface definition. Of course, anytime you break a system up into subsystems, the issue of where you put the boundaries, and what info is passed across them - that is (to me) the heart of architecture. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 21:22:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLszb-00039y-Tj; Tue, 21 Mar 2006 21:22:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsza-00039s-6n for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:22:34 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLszZ-0008AC-1P for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:22:34 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D5E6E86AFC; Tue, 21 Mar 2006 21:22:32 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-Id: <20060322022232.D5E6E86AFC@mercury.lcs.mit.edu> Date: Tue, 21 Mar 2006 21:22:32 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Leslie > "Routing" is two almost-unrelated things: generating a path which > "should work" vs. passing packets to another router "closer" to the > destination. Which is why a lot of router geeks use the term "forwarding" to refer to the actual handling of user data packets, and reserve the term "routing" for all activity related to finding paths (i.e. running the routing protocol, entering the results in the routing table, etc). > The IP address, BTW, _defines_ endpoints for layer three. Terminology alert: the term "endpoint" is overloaded, and has other meanings too (but you knew that, I expect). Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 21:25:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLt2q-0005Jb-RP; Tue, 21 Mar 2006 21:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLt2p-0005JW-F6 for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:25:55 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLt2o-0008Db-9E for architecture-discuss@ietf.org; Tue, 21 Mar 2006 21:25:55 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1EEF986AFC; Tue, 21 Mar 2006 21:25:54 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms Message-Id: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> Date: Tue, 21 Mar 2006 21:25:54 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "JFC (Jefsey) Morfin" > this architecture is to deliver communications within the same digital > ecosystem. .. The practical test of credibility will be the ROI of a > transition. Just out of interest, is there anyone out there who can distinguish Jefsey's email from the output of a buzz-phrase generator? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 21 23:44:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvDA-0006Wk-VP; Tue, 21 Mar 2006 23:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvD9-0006Sc-3T for architecture-discuss@ietf.org; Tue, 21 Mar 2006 23:44:43 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvD7-0004LM-Mk for architecture-discuss@ietf.org; Tue, 21 Mar 2006 23:44:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2M4idun022199; Wed, 22 Mar 2006 06:44:40 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 06:44:03 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 06:44:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Wed, 22 Mar 2006 06:44:00 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0AE@esebe100.NOE.Nokia.com> In-Reply-To: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNVe2KZRU+mkFpRHaLQE7z9g9g7QAFP4gQ From: To: , , X-OriginalArrivalTime: 22 Mar 2006 04:44:01.0170 (UTC) FILETIME=[3D496F20:01C64D6B] X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org JFC, >We want a model which will last. It cannot depend on the=20 >engineering solutions it is to replace. Retro-compatibility=20 >with passed limitations cannot be the base of a brillant future. We want a model that over comes the problem areas of today and can be made to (inter)work with the existing stuff. This is engineering. Nothing lasts forever, and if you plan to have such a solution, mostly likely, it will be horribly over-engineered and miss it's window of opportunity. I think we have some idea of what is broken, and so the next architecture is one that should solve those problems in a coherent and straight-forward manner. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 00:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvyG-00031d-86; Wed, 22 Mar 2006 00:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLvyE-00031Y-Vf for architecture-discuss@ietf.org; Wed, 22 Mar 2006 00:33:22 -0500 Received: from mx.freeshell.org ([192.94.73.21] helo=sdf.lonestar.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLvyD-0006Nn-MK for architecture-discuss@ietf.org; Wed, 22 Mar 2006 00:33:22 -0500 Received: from sdf.lonestar.org (IDENT:locks@otaku.freeshell.org [192.94.73.2]) by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id k2M5WwW3026631; Wed, 22 Mar 2006 05:32:58 GMT Received: (from locks@localhost) by sdf.lonestar.org (8.13.1/8.12.8/Submit) id k2M5WwM0015543; Wed, 22 Mar 2006 05:32:58 GMT Date: Wed, 22 Mar 2006 05:32:58 +0000 (UTC) From: Alexis Turner X-X-Sender: locks@otaku.freeshell.org To: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0AE@esebe100.NOE.Nokia.com> Message-ID: References: <1AA39B75171A7144A73216AED1D7478D0186A0AE@esebe100.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: subbies@redheadedstepchild.org List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I believe a less "buzz-laden" but just as meaningful way to make Jefsey's point is that the current Internet is nothing but a series of patches building upon endless series of patches. At some point, engineering a system that is held together by tape and string and ever-conflicting protocols becomes an excercise in both futility and stubborness - an excercise which can hardly be called engineering. It is at that point that the system designers must take a step back, learn from their mistakes, and start over from the beginning. Who on this list would realistically disagree with that? Can we honestly say the current system is not broken as hell? If we continue to insist on making something that works with the current system, the predecessors will remain broken. This is Jefsey's point, pure and simple. -Alexis On Wed, 22 Mar 2006 john.loughney@nokia.com wrote: ::JFC, :: ::>We want a model which will last. It cannot depend on the ::>engineering solutions it is to replace. Retro-compatibility ::>with passed limitations cannot be the base of a brillant future. :: ::We want a model that over comes the problem areas of today and ::can be made to (inter)work with the existing stuff. This is ::engineering. Nothing lasts forever, and if you plan to have ::such a solution, mostly likely, it will be horribly over-engineered ::and miss it's window of opportunity. :: ::I think we have some idea of what is broken, and so the next ::architecture is one that should solve those problems in a coherent ::and straight-forward manner. :: ::John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 08:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Vz-00075D-NR; Wed, 22 Mar 2006 08:36:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Vy-0006yv-Ek for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:42 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Vx-0007W2-88 for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:42 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FM3Vv-0007iD-Np; Wed, 22 Mar 2006 05:36:40 -0800 Message-Id: <6.2.3.4.2.20060322124005.07812120@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 14:36:23 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> References: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3C0F73B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 03:15 22/03/2006, Noel Chiappa wrote: >To put it another way, layers may a fine device for introducing basic >networking concepts to beginning students, but they are really a bad idea for >use by anyone past the level of "initial introduction". To mangle one of my >favourite military axioms, "Beginners think in layers, everyone else thinks >in subsystem dependency graphs." To put it in another way, layers are terms of reference that permits architects with different visions to understand (interface, converge) each others - and to check their own consistency. They are to describe the underlying reality, not the proposed solutions. The role of an architect is to curb reality to make it beautiful and efficient (what we often phrase KISSS - simple, stupid, scalable). jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 08:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3W2-00078r-Tm; Wed, 22 Mar 2006 08:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3W1-00078C-Rq for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:45 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3W0-0007W9-LS for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:45 -0500 Received: from i03m-212-195-148-From architecture-discuss-bounces@ietf.org Wed Mar 22 08:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Vz-00075D-NR; Wed, 22 Mar 2006 08:36:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3Vy-0006yv-Ek for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:42 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3Vx-0007W2-88 for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:42 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FM3Vv-0007iD-Np; Wed, 22 Mar 2006 05:36:40 -0800 Message-Id: <6.2.3.4.2.20060322124005.07812120@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 14:36:23 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Defining terms In-Reply-To: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> References: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3C0F73B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 03:15 22/03/2006, Noel Chiappa wrote: >To put it another way, layers may a fine device for introducing basic >networking concepts to beginning students, but they are really a bad idea for >use by anyone past the level of "initial introduction". To mangle one of my >favourite military axioms, "Beginners think in layers, everyone else thinks >in subsystem dependency graphs." To put it in another way, layers are terms of reference that permits architects with different visions to understand (interface, converge) each others - and to check their own consistency. They are to describe the underlying reality, not the proposed solutions. The role of an architect is to curb reality to make it beautiful and efficient (what we often phrase KISSS - simple, stupid, scalable). jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 08:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3W2-00078r-Tm; Wed, 22 Mar 2006 08:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3W1-00078C-Rq for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:45 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3W0-0007W9-LS for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:36:45 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FM3Vz-0007iD-Ix; Wed, 22 Mar 2006 05:36:44 -0800 Message-Id: <6.2.3.4.2.20060322141816.059352c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 14:30:12 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> References: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3C0F73B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 03:25 22/03/2006, Noel Chiappa wrote: > > From: "JFC (Jefsey) Morfin" > > > this architecture is to deliver communications within the same digital > > ecosystem. .. The practical test of credibility will be the ROI of a > > transition. > >Just out of interest, is there anyone out there who can distinguish Jefsey's >email from the output of a buzz-phrase generator? Very fun. Just out of interet is there anyone out there who can distinguish from the ITEF/IAB's outputs the generation of a new network technology? The selection of the quote is significant. Its seems that users' usages of their common digital ecosystem, expected returns and deployment/transitions economical feasibility criteria are seldom considered on this list. However they are the points which will decide of any deployment ... and of the future salaries of the contributors of this list. Do we live in two worlds apart? Or are you still young enough to nurture utopias? Anyway we seem to be several interested in your routing proposition. It would be great if you had an URL. Thank you! jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss 209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FM3Vz-0007iD-Ix; Wed, 22 Mar 2006 05:36:44 -0800 Message-Id: <6.2.3.4.2.20060322141816.059352c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 14:30:12 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa),architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> References: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-3C0F73B6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 03:25 22/03/2006, Noel Chiappa wrote: > > From: "JFC (Jefsey) Morfin" > > > this architecture is to deliver communications within the same digital > > ecosystem. .. The practical test of credibility will be the ROI of a > > transition. > >Just out of interest, is there anyone out there who can distinguish Jefsey's >email from the output of a buzz-phrase generator? Very fun. Just out of interet is there anyone out there who can distinguish from the ITEF/IAB's outputs the generation of a new network technology? The selection of the quote is significant. Its seems that users' usages of their common digital ecosystem, expected returns and deployment/transitions economical feasibility criteria are seldom considered on this list. However they are the points which will decide of any deployment ... and of the future salaries of the contributors of this list. Do we live in two worlds apart? Or are you still young enough to nurture utopias? Anyway we seem to be several interested in your routing proposition. It would be great if you had an URL. Thank you! jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 08:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3ek-0003mX-2t; Wed, 22 Mar 2006 08:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3ej-0003mD-4q for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:45:45 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3ef-00080I-On for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:45:45 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 25BB334264; Wed, 22 Mar 2006 08:45:39 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 08:45:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Wed, 22 Mar 2006 08:45:36 -0500 Message-ID: <936A4045C332714F975800409DE0924002029A02@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNVeCNv+PkVvN8Sx+MyffHERGagwAYMi/Q From: "Bound, Jim" To: "JFC (Jefsey) Morfin" , "Joe Touch" X-OriginalArrivalTime: 22 Mar 2006 13:45:38.0741 (UTC) FILETIME=[E7593E50:01C64DB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think we can agree to disagree and move forward. See John Loughney's mail I fully agree with John. Not saying we should not think out of the box but to put forth any new Internet archicture components without a transition is not wise. This will come up again but suggest we move forward with idea generation from all the bright people on this list. Best, /jim=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]=20 > Sent: Tuesday, March 21, 2006 8:20 PM > To: Bound, Jim; Joe Touch > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] Defining terms >=20 > At 01:33 22/03/2006, Bound, Jim wrote: >=20 > >Now that is very interesting view. I can go there but would=20 > like for it > >to be other than just the two of us ---). Anyone not ok with this > >suggestion? > > > >But at the end if we break compatibility with today it may=20 > never happen > >for the right or wrong reasons. Thus we could spin and never get to > >deployment of the idea. >=20 > I think not. Because there is no real architecture RFC. Even RFC 1958=20 > is more recipes for good design. > Also because a good architectural solution should support the=20 > convergence of the existing technologies. We all know/want it. > Also because this architecture is to deliver communications within=20 > the same digital ecosystem. By definition there will be bridges. The=20 > practical test of credibility will be the ROI of a transition. >=20 > We want a model which will last. It cannot depend on the engineering=20 > solutions it is to replace. Retro-compatibility with passed=20 > limitations cannot be the base of a brillant future. > jfc >=20 >=20 >=20 >=20 > >Again that is ok with me too. > > > >/jim > > > > > -----Original Message----- > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > Sent: Tuesday, March 21, 2006 1:42 PM > > > To: Joe Touch > > > Cc: architecture-discuss@ietf.org > > > Subject: Re: [arch-d] Defining terms > > > > > > At 17:46 21/03/2006, Joe Touch wrote: > > > > > > >See RFC 3884 for the differences ;-) > > > > > > I suggest that discussing architecture (to also have=20 > confusion with > > > "configurations") means never alluding to an RFC, ISO=20 > standard, etc. > > > Because they talk of a specific and past approach. > > > jfc > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > > >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 08:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3kl-0008C2-Ea; Wed, 22 Mar 2006 08:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM3kk-0008Bx-Od for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:51:58 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM3kk-0008GR-HS for architecture-discuss@ietf.org; Wed, 22 Mar 2006 08:51:58 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4936286AF1; Wed, 22 Mar 2006 08:51:58 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms Message-Id: <20060322135158.4936286AF1@mercury.lcs.mit.edu> Date: Wed, 22 Mar 2006 08:51:58 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Alexis Turner > the current Internet is nothing but a series of patches building upon > endless series of patches. At some point, engineering a system that is > held together by tape and string .. becomes an excercise in both > futility and stubborness .. > Who on this list would realistically disagree with that? Can we > honestly say the current system is not broken as hell? Basically nobody (maybe nobody at all) disagrees with that. The problem arrives when you get to the next step: > It is at that point that the system designers must take a step back, > learn from their mistakes, and start over from the beginning. > ... > If we continue to insist on making something that works with the > current system, the predecessors will remain broken. I'm not sure if quite as many agree with this position (that a re-think is needed), but that's not the issue. The problem comes when you consider any non-incremental change - and moreover consider *how to get it adopted widely*. It's relatively easy for me (or any number of other talented system architects) to sit back, reflect on what went wrong, and what we've learned, and come up with cool new architectures. (Been there, done that, as have several others.) It's also relatively easy for me (or any number of other talented engineers) to figure out an interoperable way to deploy this wonderful new architecture. (Been there, done that too.) What nobody has ever figured out a good way to do is get such a new architecture actually deployed, i.e. get community consensus that this wonderful new architecture is the way to go. By definition, any non-incremental change represents something of a leap into the dark - and a system this size, and in widespread production use, contains a lot of people who have the kidney-output-fluid scared out of them by the concept of large jumps into the dark. Plus to which there will be large fractions of people who say "oh, that's a bad idea, we need to do this other thing instead" - and of course, the more radical the change, the more likely there are to be people (smart people, people with experience) who have a different view of what the Right Thing is. Look at how difficult it is for something as simple as HIP to get any traction - and even now, it's still pretty much a fringe thing, which will take many years, if ever, to really catch on widely and ubiquitously. Now multiply the difficulty of doing anything that relatively minor by an exponential factor for anything major - e.g. a whole new routing architecture. (Been there too...) I wrote a longer screed on this issue a month or two back, in reply to Tony Li (can't be bothered to dig up a URL for it, sorry - gotta run) - you might want to re-read that for a longer discussion of this problem. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 11:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6AL-0003o4-BH; Wed, 22 Mar 2006 11:26:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6AK-0003nz-5Q for architecture-discuss@ietf.org; Wed, 22 Mar 2006 11:26:32 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6AI-0006Kq-SC for architecture-discuss@ietf.org; Wed, 22 Mar 2006 11:26:32 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58492212C59; Wed, 22 Mar 2006 18:26:29 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6E0AB212C4C; Wed, 22 Mar 2006 18:26:28 +0200 (EET) In-Reply-To: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> References: <20060322022554.1EEF986AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Defining terms Date: Wed, 22 Mar 2006 10:26:24 -0600 To: Noel Chiappa X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > Just out of interest, is there anyone out there who can distinguish > Jefsey's > email from the output of a buzz-phrase generator? While we all know Jefsey's problems in expressing himself, I for one think that at least here he is contributing, most of the time. Sure, I cannot make sense of all of his messages, but I do find interesting points in them every now and then. At minimum, the real world *is* out there with all of its societal and enconomic problems, and Jefsey keeps reminding us about that, in his convoluted way. So, whatever my word is worth, I'd hate to see him banned from this list just because he thinks differently from the majority and has known difficulties in expression. [Provided, of course, that he keeps to the charter just as we all try to do, but that should be clear without explicitly stating it.] So, please let us move back to the currently ongoing, fairly interesting architecture bashing, and try to avoid this kind of meta discussion. --Pekka _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 11:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6eg-0000ok-2n; Wed, 22 Mar 2006 11:57:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6ee-0000oU-Bl for architecture-discuss@ietf.org; Wed, 22 Mar 2006 11:57:52 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6ed-00086g-SB for architecture-discuss@ietf.org; Wed, 22 Mar 2006 11:57:52 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 01BAA212C59 for ; Wed, 22 Mar 2006 18:57:51 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6BC7C212C4C for ; Wed, 22 Mar 2006 18:57:50 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <20060322135158.4936286AF1@mercury.lcs.mit.edu> References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 22 Mar 2006 10:57:48 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [arch-d] IETF, architectural vision, and adoption (was something else) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > What nobody has ever figured out a good way to do is get such a new > architecture actually deployed, i.e. get community consensus that this > wonderful new architecture is the way to go. ... > > Look at how difficult it is for something as simple as HIP to get any > traction - and even now, it's still pretty much a fringe thing, > which will > take many years, if ever, to really catch on widely and > ubiquitously. Now > multiply the difficulty of doing anything that relatively minor by an > exponential factor for anything major - e.g. a whole new routing > architecture. (Been there too...) I could not agree more. To gain more perspective to this, I found it very interesting to hear from Dave Clark last night that we (the IETF) have had these problems at least since 1992. Being a relative newcomer to the IETF (my first IETF was in 1997 and only 2001 I started to come to these events even semi-regularly), I have had great illusions of the IETF leading the Internet to the future and the IAB doing real work in its role of the architectural oversight. However, what I can say from my limited experience to being in the IAB, many of the IAB members are painfully aware of the difficulties related to IAB's architectural role. Personally, given my current stand, I would go as far as suggesting that the IAB should be renamed to be the Internet Activities Board, if for no other reason to remove the illusion that they were _doing_ anything substantial on the longer-term architectural issues. Yes, the IAB could _facilitate_ architectural work, and in a way they are (we were) doing that by creating this list. It remains to be seen what the new IAB decides to do. Scaling back to more technical issues, what I find encouraging is that HIP version 1 is now basically done. The drafts are ready, waiting for security area review, and we found a volunteer for that. There are three interoperating open source implementations. Some non- research projects are starting to adopt HIP. If this is anyhow going along Geoffrey Moore's Chasm model, HIP is now entering early adoption phase and some people are looking for the first pins to bowl over. Sure, the chasm is still ahead and HIP may never get over it, but at least it is affecting people's thinking in SHIM6, BTNS, and some other working groups. Hence, it looks like that medium-scale architectural work (such as HIP) is not complete waste of time, even at the IETF. It just requires a number years to have any effect; in HIP's case the idea is now about 7-8 years old. So, my still-untested recipe for architectural work seems to have the following ingredients: 1. Prepare to _continuously_ work on it for at least 5 years; 10 years might be more realistic. 2. Try to gain enough of social traction early on so that the work continues even when the first leaders tire. 3. Do not hope the IETF leadership to lead. They are too busy preserving, conserving, and struggling with the inevitable power games. What you can ask for, though, is a little bit of footing to use as a marketing ground within the IETF and/or IRTF. 4. Early on, try to understand the assets out there and plan for piecewise deployment. This seems to be where HIP may still trip. Even if we have thought about this quite a lot, it looks like both updating the stack and adding infrastructure (at least records to the DNS) at the same time is just too much. Opportunistic HIP may have better prospects, but it hasn't been completed yet. 5. Remember the list of issues that kill the next big thing: - works badly with NATs - 80% solution already available - needs a kernel change - requires updating routers or other network boxes - requires new infrastructure - requires changing existing applications - no business benefit for the players - lot of research papers before its deployed - lengthy standardization effort before its deployed - not configurable by normal users (i.e., needs any configuration) - cannot be used until everyone has it While you cannot do meaningful architectural changes without ticking some of these boxes, trying to avoid them may pay off. --Pekka _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 12:05:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6mG-0006fS-J2; Wed, 22 Mar 2006 12:05:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6mF-0006fN-Vr for architecture-discuss@ietf.org; Wed, 22 Mar 2006 12:05:43 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6mE-0008VO-LX for architecture-discuss@ietf.org; Wed, 22 Mar 2006 12:05:43 -0500 Received: from [128.9.176.34] (c1-vpn4.isi.edu [128.9.176.34]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2MH5Iw11453; Wed, 22 Mar 2006 09:05:18 -0800 (PST) Message-ID: <442183C8.9060508@isi.edu> Date: Wed, 22 Mar 2006 09:05:12 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms References: <936A4045C332714F975800409DE09240020298DE@tayexc14.americas.cpqcorp.net> <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> In-Reply-To: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org JFC (Jefsey) Morfin wrote: > At 01:33 22/03/2006, Bound, Jim wrote: > >> Now that is very interesting view. I can go there but would like for it >> to be other than just the two of us ---). Anyone not ok with this >> suggestion? >> >> But at the end if we break compatibility with today it may never happen >> for the right or wrong reasons. Thus we could spin and never get to >> deployment of the idea. > > I think not. Because there is no real architecture RFC. Perhaps, though the standards doc together, esp. 1122-1123, 791, 793, and a few more, do constitute an architecture even if sometimes implicit. However, this is not the context in which I cited the RFC. I noted 3884 only in the reference to the discussion on IP-in-IP vs IPsec tunnels, noting that the distinction between the two is addressed there. While I agree that we should not confine ourselves to existing architectures or backward compatibility, there are broader principles at work, notably the need to keep firewall, tunneling, forwarding/routing, and security services sufficiently independent as to be interoperable. Those lessons can either be learned from the existing architecture or repeated. Joe _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 12:48:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7RI-0002dP-H9; Wed, 22 Mar 2006 12:48:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7RH-0002Xi-K1 for architecture-discuss@ietf.org; Wed, 22 Mar 2006 12:48:07 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5hP-0004fF-KS for architecture-discuss@ietf.org; Wed, 22 Mar 2006 10:56:39 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FM5Qm-0003ZS-HO for architecture-discuss@ietf.org; Wed, 22 Mar 2006 10:39:33 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 60099343A2; Wed, 22 Mar 2006 10:39:43 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 10:39:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Wed, 22 Mar 2006 10:39:26 -0500 Message-ID: <936A4045C332714F975800409DE0924002029B53@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNt9o/IQQrQfEgSrqw3g0WV953gAADtFqw From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 22 Mar 2006 15:39:28.0127 (UTC) FILETIME=[CDFAD8F0:01C64DC6] X-Spam-Score: -2.0 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Much wisdom from Noel and I agree 100% Very hard stuff to do though but I think we can if we keep this wisdom as background process in our minds. /jim > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Wednesday, March 22, 2006 8:52 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] Defining terms >=20 > > From: Alexis Turner >=20 > > the current Internet is nothing but a series of patches=20 > building upon > > endless series of patches. At some point, engineering a=20 > system that is > > held together by tape and string .. becomes an excercise in both > > futility and stubborness ..=20 > > Who on this list would realistically disagree with that? Can we > > honestly say the current system is not broken as hell? >=20 > Basically nobody (maybe nobody at all) disagrees with that.=20 > The problem > arrives when you get to the next step: >=20 > > It is at that point that the system designers must take=20 > a step back, > > learn from their mistakes, and start over from the beginning. > > ... > > If we continue to insist on making something that works with the > > current system, the predecessors will remain broken. >=20 > I'm not sure if quite as many agree with this position (that=20 > a re-think is > needed), but that's not the issue. The problem comes when you=20 > consider any > non-incremental change - and moreover consider *how to get it adopted > widely*. >=20 > It's relatively easy for me (or any number of other talented system > architects) to sit back, reflect on what went wrong, and what=20 > we've learned, > and come up with cool new architectures. (Been there, done=20 > that, as have > several others.) It's also relatively easy for me (or any=20 > number of other > talented engineers) to figure out an interoperable way to deploy this > wonderful new architecture. (Been there, done that too.) >=20 >=20 > What nobody has ever figured out a good way to do is get such a new > architecture actually deployed, i.e. get community consensus that this > wonderful new architecture is the way to go. By definition, any > non-incremental change represents something of a leap into=20 > the dark - and a > system this size, and in widespread production use, contains=20 > a lot of people > who have the kidney-output-fluid scared out of them by the=20 > concept of large > jumps into the dark. >=20 > Plus to which there will be large fractions of people who say=20 > "oh, that's a > bad idea, we need to do this other thing instead" - and of=20 > course, the more > radical the change, the more likely there are to be people=20 > (smart people, > people with experience) who have a different view of what the=20 > Right Thing is. >=20 > Look at how difficult it is for something as simple as HIP to get any > traction - and even now, it's still pretty much a fringe=20 > thing, which will > take many years, if ever, to really catch on widely and=20 > ubiquitously. Now > multiply the difficulty of doing anything that relatively minor by an > exponential factor for anything major - e.g. a whole new routing > architecture. (Been there too...) >=20 >=20 > I wrote a longer screed on this issue a month or two back, in=20 > reply to Tony > Li (can't be bothered to dig up a URL for it, sorry - gotta=20 > run) - you might > want to re-read that for a longer discussion of this problem. >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 12:58:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7ba-0002FE-65; Wed, 22 Mar 2006 12:58:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7bY-0002Ay-Ja for architecture-discuss@ietf.org; Wed, 22 Mar 2006 12:58:44 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7bX-0001jM-7D for architecture-discuss@ietf.org; Wed, 22 Mar 2006 12:58:44 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA19944; Wed, 22 Mar 2006 11:58:32 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2MHwWb15484; Wed, 22 Mar 2006 09:58:32 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 09:58:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Wed, 22 Mar 2006 09:58:28 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584765@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <20060321234652.GD11517@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNQcEJGt+KCwOBTSaxaylF4wIhBQAl10FA From: "Fleischman, Eric" To: "John Leslie" , "Bound, Jim" X-OriginalArrivalTime: 22 Mar 2006 17:58:28.0957 (UTC) FILETIME=[398080D0:01C64DDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org From: John Leslie [mailto:john@jlc.net]=20 >Tunneling doesn't break the abstraction: it merely confuses the=20 >folks who try to visualize the whole system and think there's=20 >something wrong when a layer-four procedure is used to implement=20 >a layer-two function. The abstraction still works fine: the=20 >layer-three built on top of that tunnel need know nothing about=20 >how the layer-two is actually implemented over a layer-four tunnel. Tunneling usually makes network management more difficult: the reason for a failure within a "black boxed entity" is harder to discern -- and fix. For large deployments, which are inherently difficult to manage because of scale and device diversity, this added difficulty can be very onerous indeed.=20 Configuration management is a difficult problem for which better tools are definitely needed. Tunneling exacerbates this difficulty. Tunneling often also has performance implications related to latency and capacity consumption. Nevertheless, tunneling has become very prevelent in today's networks. Nothing is for free.=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 13:03:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7g6-0004Zu-1P; Wed, 22 Mar 2006 13:03:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7g5-0004ZK-5W for architecture-discuss@ietf.org; Wed, 22 Mar 2006 13:03:25 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7g3-00021t-RF for architecture-discuss@ietf.org; Wed, 22 Mar 2006 13:03:25 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA25807; Wed, 22 Mar 2006 12:03:22 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2MI3L906006; Wed, 22 Mar 2006 12:03:22 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 10:03:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] RE: Defining terms Date: Wed, 22 Mar 2006 10:03:17 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584766@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] RE: Defining terms Thread-Index: AcZNQPXSBJKYgQbYS2aIFmtMs9ayagAAE7YQACZQ5oA= From: "Fleischman, Eric" To: "Fall, Kevin" , X-OriginalArrivalTime: 22 Mar 2006 18:03:18.0580 (UTC) FILETIME=[E6217740:01C64DDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This observation has been historically useful for designing mechanisms to convey applications devised for non-IP protocol stacks over IP: e.g., RFC 1001, RFC 1002, RFC 1006, the IBM Multi-Protocol Transport Networking (MPTN) protocol suite, etc. -----Original Message----- From: Fall, Kevin [mailto:kevin.fall@intel.com]=20 Sent: Tuesday, March 21, 2006 5:12 PM To: architecture-discuss@ietf.org Subject: [arch-d] RE: Defining terms One of the things we have been interested in is when the session layer's state is persistent and when multiple transports (across different protocol families) can be used, perhaps simultaneously. More specifically, one can imagine a "socket" type of abstraction that is neither protocol family dependent and whose "socket buffer" contents are retained across (e.g.) reboots and long-term to moderate-term interruptions. In a world in which cell phones are arguably going to be the most numerous hosts on the Internet (when they are connected to the Internet, that is), the heterogeneity and persistence become I think more compelling than they have been in the past. Thinking along these lines brings up the question as to whether the app interface to a would-be session layer looks more VC-like or more message/packet-like. I think there are arguments for both. When beginning to undertake a high-level networking architecture discussion it seems appropriate to consider what you want 'your network' to ultimately do. Several folks on this list have begun to suggest this. I think that is an interesting conversation by itself, before you get into layering (primarily an implementation techique, imho). _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 13:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7sE-0006I5-FE; Wed, 22 Mar 2006 13:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7sC-0006HL-Ph for architecture-discuss@ietf.org; Wed, 22 Mar 2006 13:15:56 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7sC-0002lq-GK for architecture-discuss@ietf.org; Wed, 22 Mar 2006 13:15:56 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA09727; Wed, 22 Mar 2006 12:15:30 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k2MIFTb17694; Wed, 22 Mar 2006 10:15:29 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Mar 2006 10:15:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Wed, 22 Mar 2006 10:15:22 -0800 Message-ID: <474EEBD229DF754FB83D256004D0210802584767@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZNVeOdjayTHqjZTNaHg9203u83MgAhRYKg From: "Fleischman, Eric" To: "JFC \(Jefsey\) Morfin" , "Bound, Jim" , "Joe Touch" X-OriginalArrivalTime: 22 Mar 2006 18:15:23.0185 (UTC) FILETIME=[96076A10:01C64DDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I spent most of the Vancouver IETF asking IETF luminaries whether there was a current IP architecture or not. I didn't encounter a single person, including conversations with the IAB, that didn't state that the Internet/IP doesn't currently have an architecture but rather is only an ad hoc assemblage of technologies and techniques today.=20 What I learned is that because IP doesn't currently have an architecture, none of the questions for which I was seeking an answer (or at least a basis for resolving technical differences I was having with others), could be answered in terms of references to agreed upon architectural precepts since no such architecture currently exists.=20 >From where I stand, this is a very serious state of affairs. I fear that Steve Deering's many warnings to our community (e.g., about the dangers of a "fat IP layer") during the late 90s have come true. -----Original Message----- From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]=20 Sent: Tuesday, March 21, 2006 5:20 PM To: Bound, Jim; Joe Touch Cc: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms At 01:33 22/03/2006, Bound, Jim wrote: >Now that is very interesting view. I can go there but would like for=20 >it to be other than just the two of us ---). Anyone not ok with this=20 >suggestion? > >But at the end if we break compatibility with today it may never happen >for the right or wrong reasons. Thus we could spin and never get to=20 >deployment of the idea. I think not. Because there is no real architecture RFC. Even RFC 1958=20 is more recipes for good design. Also because a good architectural solution should support the=20 convergence of the existing technologies. We all know/want it. Also because this architecture is to deliver communications within=20 the same digital ecosystem. By definition there will be bridges. The=20 practical test of credibility will be the ROI of a transition. We want a model which will last. It cannot depend on the engineering=20 solutions it is to replace. Retro-compatibility with passed=20 limitations cannot be the base of a brillant future. jfc >Again that is ok with me too. > >/jim > > > -----Original Message----- > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Sent: Tuesday, March 21, 2006 1:42 PM > > To: Joe Touch > > Cc: architecture-discuss@ietf.org > > Subject: Re: [arch-d] Defining terms > > > > At 17:46 21/03/2006, Joe Touch wrote: > > > > >See RFC 3884 for the differences ;-) > > > > I suggest that discussing architecture (to also have confusion with > > "configurations") means never alluding to an RFC, ISO standard, etc. > > Because they talk of a specific and past approach. jfc > > > > > > _______________________________________________ > > Architecture-discuss mailing list Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 14:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8mK-0003Wa-1x; Wed, 22 Mar 2006 14:13:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8mI-0003Vi-2I for architecture-discuss@ietf.org; Wed, 22 Mar 2006 14:13:54 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8mH-0005uq-Pd for architecture-discuss@ietf.org; Wed, 22 Mar 2006 14:13:54 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FM8mC-0003b0-Qg for architecture-discuss@ietf.org; Wed, 22 Mar 2006 11:13:52 -0800 Message-Id: <6.2.3.4.2.20060322160610.0479c2a0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Mar 2006 20:13:31 +0100 To: From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <936A4045C332714F975800409DE0924002029A02@tayexc14.americas .cpqcorp.net> References: <936A4045C332714F975800409DE0924002029A02@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-BE03C93 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:45 22/03/2006, Bound, Jim wrote: >I think we can agree to disagree and move forward. See John Loughney's >mail I fully agree with John. Not saying we should not think out of the >box but to put forth any new Internet archicture components without a >transition is not wise. This will come up again but suggest we move >forward with idea generation from all the bright people on this list. I am afraid I was not clear enough. I do not think that transitions should not be considered. I think they are not a real problem. This is because: 1. every propositon deals with the same digital ecosystem. This implies some built-in compatibility. 2. transitions are a matter of cost (financial and operational). New propositions will not be seriously considered if the returns of the transition costs are not acceptable. The corollary is that if a new architecture is worth the cost of change, it MAY go through. IMHO the priority is the best network "value" (I documented the formula I use). Backward compatibility and transition considerations should come after. We should keep in mind that incremental changes are replacements. So, this is the same situation as when we created the international system. And when we implemented its next architectures. The Internet is the third architecture of the international network. We consider the fourth one now. So we have experience. We figured out already three times to successfully deploy a change. At 14:51 22/03/2006, Noel Chiappa wrote: >What nobody has ever figured out a good way to do is get such a new >architecture actually deployed, i.e. get community consensus that this >wonderful new architecture is the way to go. This is another way to say the same thing. But it shows the usual error (ex. IPv6, IDNA, etc.). This is to consider that "global" means a single community, instead of "every communitie together". There is no way to find a consensus involving everyone. Architectural transitions are not engineering evolutions. They call for (virtual) gateways between the community of the users of the new architecture and the community of the users of the old architecure. There is a buil-in consensus in the first one. There are mixed feelings in the other one. The ROI obtained by the first community is the only/main motivation of the second community. Taking this for "buzz-word" having no place here can be understood. But it may be the answer to the question why brillant propositions did not appeal on wallets. NB. Gateways can be virtual - either because the old architecture is/is made hybrid and supports both. - or because they are between two layers. For example: what is above is now and below is not. It seems that the lack of formal Internet architecture makes both these virtual splits difficult. This would only leave physical split (the network of the networks). I think there is a layer where it is possible to have a "layer virual gateway" whatever the technology. By the same token it could help supporting convergence. This is between 7th (application) and what I call 8th (interapplication) layers. In internet architecture interapplication layer could be termed a "smart edge" (or smart plug). Located where OPES should be. If you consider the 8th layer as a shim between the user agent and the network, - for the network it is AN (Internet) end - for the user it is THE (possibly multitechnology, multilink) networking end. ("plug" may speak better than "end"). This opens many new architectural and transition possibilities. One is the welding several network end to end connections into a single link. This permits what I name ONES (open network extended services): several "end" OPES can be netted to a same ONES. It would permit to bring an apparent network core intelligence (ONES) to a standard end to end system (or several ones acting in parallel - ex. back-up). This also pemits easy transitions: the operations of layer 8th and above is independent from layer 1-7 architectural evolution. This makes the user independent from the underlying technology. (I initially explained that I am interested in brainware and usage aspects (what I call layer 8th/12th - where the decision making wallets are)). jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 14:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8vg-0007ot-Cs; Wed, 22 Mar 2006 14:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkyR-0001OH-8e for architecture-discuss@ietf.org; Tue, 21 Mar 2006 12:48:51 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkyP-0001Om-VI for architecture-discuss@ietf.org; Tue, 21 Mar 2006 12:48:51 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032117484901400c0m8he>; Tue, 21 Mar 2006 17:48:49 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060320142202.GC49978@verdi> References: <275A0A63-24B7-479C-A9AB-D9B37773C751@cisco.com> <20060307142105.GA588@sbrim-wxp01> <20060320142202.GC49978@verdi> Date: Tue, 21 Mar 2006 12:48:39 -0500 To: John Leslie , Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-Mailman-Approved-At: Wed, 22 Mar 2006 14:23:35 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org For starters, you might take a look at the concept of connection in delta-t. At 9:22 -0500 2006/03/20, John Leslie wrote: >Scott W Brim wrote: >> On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote: >> >>> I would therefore define a "session" as the shared state in the end >>> systems and in the network, whatever it may be, which directly or >>> indirectly reflects the state of two or more communicating >>> applications. In Flow RED (http://www.icir.org/floyd/red.html#flow), >>> this would include information stored in network nodes, and it >>> generally includes keys associated with security associations, >>> sequence numbers etc in TCP and SCTP, and the various addresses that >>> are used by endpoints in a multihomed route. >> >> Elsewhere people have come up with the concept that a "session" is a >> relationship -- not a pipe, not a flow of packets -- created to align >> state information. To do so it may use one or multiple communication >> events. A successful session could be as simple as "are you there?" >> with a response. > > I see a benefit to thinking of "session" as a relationship between >endpoints. I'm not quite sure either Fred or Scott have stated this >distinctly enough. > > Fred is talking "shared state" which, I suppose, is correct; but it >tends to direct our attention to details of connection(s) which I think >deserve to be considered a different layer. IMHO, "session" may or >may not imply an ordering in information transmitted over different >connections. > > Scott talks of a "session" being "created to align state information." >I do not see that either as the "purpose" of a "session" or even a >necessary function of a "session". IMHO, a "session" should identify >endpoints which are processes invoked by users without regard to the >path over which information will flow between them. > > (Whether or not a "session" implies ordering of data communicated >might well be implementation-dependent.) > >> Neither is a session the state information itself. I think these >> terms will be more useful in the future if you distinguish the >> relationship between the endpoints -- the "session" -- from the >> "session state" which reflects the relationship in the participants >> and intermediate nodes. > > I agree with Scott. > >> How is a session different from a connection? Just barely. > > I think we can draw a fairly clear distinction, actually. > > A "connection" is something maintained in a fully automated manner, >without messy interactions. Our network must find a way to route packets >from one end to the other. Thus, the endpoints of a connection must be >machine-comprehensible addresses, most often globally unique. > > A "session" is something created in response to human action. In >all likelihood, it depends upon rather messy DNS processes to resolve >to IP addresses which routers can use. If conditions change so that >those IP addresses no longer serve the necessary function, the human(s) >creating the "session" would generally prefer that some further DNS >magic makes the change transparent. > >> A TCP "connection" can be used by HTTP for one exchange, then allowed >> to lie fallow, then used for a different one. > > Agreed. > >> That's one "flow" from the point of view of the network but multiple >> communications events from the point of view of the applications. > > True, but in practice all the communications events are likely to >represent the same "session". > >> One possible difference between session and connection might be that >> in a connection the participating endpoints are the same for all >> communication flows, while in a "session" involving multiple >> communication events, different parties could be involved in different >> ones. > > I think I've missed Scott's point here. > > "Participating endpoints" could mean a number of things. IMHO, we >can correctly talk of "participating endpoints" for both "connections" >and "sessions", and mean quite different things. > >> You don't buy it? In that case, really, the only difference I know of >> is that "connection" is used for lower layers, L4 and below, while >> "session" is used for L5 and above. > > Alas! We can't accept that kind of definition. ;^( > >-- >John Leslie > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 14:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8vg-0007oo-79; Wed, 22 Mar 2006 14:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiYk-0006D5-RH for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:14:10 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiYj-0003Hz-JU for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:14:10 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060321151407m1200jl1k0e>; Tue, 21 Mar 2006 15:14:08 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060321150319.GA4560@sbrim-wxp01> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> Date: Tue, 21 Mar 2006 10:13:58 -0500 To: Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 22 Mar 2006 14:23:35 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >On Mon, Mar 20, 2006 09:52:07AM -0500, John Day allegedly wrote: >> At 9:37 -0500 2006/03/20, Bound, Jim wrote: >> >Perfect example where L2 and L3 are meaningless at least to me. >> >> Layer 2 and 3 as traditionally described have very different scopes. >> This is a very significant difference. > >Some confusion comes from an assumption of coupling of functionality >and protocol, while in fact protocols, particularly connectionless >ones, are reusable in different roles. For example we can see IP as >part of both the traditional L2 and L3 in some access networks. >(Please don't ask me to define access network :-p.) Could you elaborate? I have no clue what you are talking about. ;-) A case can be made that IP is a subnet access protocol since that is what its addresses name. I have always found it amusing that Ethernet addresses potentially had more scope than IP addresses. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 14:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8vj-00080C-0a; Wed, 22 Mar 2006 14:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlCg-0002K9-Aq for architecture-discuss@ietf.org; Tue, 21 Mar 2006 13:03:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjiz-0006F3-JH for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:28:49 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLjUC-0001nA-Te for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:13:33 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032116133101400c54aae>; Tue, 21 Mar 2006 16:13:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> Date: Tue, 21 Mar 2006 11:08:42 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Layers (was Re: Defining terms) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 22 Mar 2006 14:23:35 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366913287==" Errors-To: architecture-discuss-bounces@ietf.org --===============0366913287== Content-Type: multipart/alternative; boundary="============_-1069164887==_ma============" --============_-1069164887==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >Other, perhaps less appreciated phenomena that seem to require >layering are mobility and multi-path communication. Mobility >requires indirection: you have to have separate stable identifiers >(so that you can name your peer) and dynamic, location specific >identifiers. From an architectural point of view, supporting such >indirection within a single name space seems to lead to messy >problems. Having two distinct name spaces leads to cleaner >solutions, but at the same time create a new layer. More or less >the same applies to multi-path communication, but in the spatial >rather than temporal dimension. I suggest you read this, if you haven't: Saltzer, Jerry. "On the Naming and Binding of Network Destinations" in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. It contains most everything you need. The problem in the Internet is it is missing half of the minimum required addressing architecture. Tends to make things difficult. >From that point of view, Mobile IP is a good example of what happens >when you add mobility without modifying your layering. Mobility is not really a big problem, just dynamic multi-homing. Take care, John --============_-1069164887==_ma============ Content-Type: text/html; charset="us-ascii" Re: [arch-d] Layers (was Re: Defining terms)
Other, perhaps less appreciated phenomena that seem to require layering are mobility and multi-path communication.  Mobility requires indirection:  you have to have separate stable identifiers (so that you can name your peer) and dynamic, location specific identifiers.  From an architectural point of view, supporting such indirection within a single name space seems to lead to messy problems.  Having two distinct name spaces leads to cleaner solutions, but at the same time create a new layer.  More or less the same applies to multi-path communication, but in the spatial rather than temporal dimension.

I suggest you read this, if you haven't:

Saltzer, Jerry. "On the Naming and Binding of Network Destinations" in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498.

It contains most everything you need.  The problem in the Internet is it is missing half of the minimum required addressing architecture.  Tends to make things difficult.

From that point of view, Mobile IP is a good example of what happens when you add mobility without modifying your layering.

Mobility is not really a big problem, just dynamic multi-homing.

Take care,
John
--============_-1069164887==_ma============-- --===============0366913287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0366913287==-- From architecture-discuss-bounces@ietf.org Wed Mar 22 14:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8vg-0007oo-79; Wed, 22 Mar 2006 14:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiYk-0006D5-RH for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:14:10 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLiYj-0003Hz-JU for architecture-discuss@ietf.org; Tue, 21 Mar 2006 10:14:10 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060321151407m1200jl1k0e>; Tue, 21 Mar 2006 15:14:08 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060321150319.GA4560@sbrim-wxp01> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> Date: Tue, 21 Mar 2006 10:13:58 -0500 To: Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 22 Mar 2006 14:23:35 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >On Mon, Mar 20, 2006 09:52:07AM -0500, John Day allegedly wrote: >> At 9:37 -0500 2006/03/20, Bound, Jim wrote: >> >Perfect example where L2 and L3 are meaningless at least to me. >> >> Layer 2 and 3 as traditionally described have very different scopes. >> This is a very significant difference. > >Some confusion comes from an assumption of coupling of functionality >and protocol, while in fact protocols, particularly connectionless >ones, are reusable in different roles. For example we can see IP as >part of both the traditional L2 and L3 in some access networks. >(Please don't ask me to define access network :-p.) Could you elaborate? I have no clue what you are talking about. ;-) A case can be made that IP is a subnet access protocol since that is what its addresses name. I have always found it amusing that Ethernet addresses potentially had more scope than IP addresses. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Mar 22 14:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8vj-00080C-0a; Wed, 22 Mar 2006 14:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLlCg-0002K9-Aq for architecture-discuss@ietf.org; Tue, 21 Mar 2006 13:03:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjiz-0006F3-JH for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:28:49 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLjUC-0001nA-Te for architecture-discuss@ietf.org; Tue, 21 Mar 2006 11:13:33 -0500 Received: from [10.0.1.14] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032116133101400c54aae>; Tue, 21 Mar 2006 16:13:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> Date: Tue, 21 Mar 2006 11:08:42 -0500 To: Pekka Nikander , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Layers (was Re: Defining terms) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 22 Mar 2006 14:23:35 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366913287==" Errors-To: architecture-discuss-bounces@ietf.org --===============0366913287== Content-Type: multipart/alternative; boundary="============_-1069164887==_ma============" --============_-1069164887==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >Other, perhaps less appreciated phenomena that seem to require >layering are mobility and multi-path communication. Mobility >requires indirection: you have to have separate stable identifiers >(so that you can name your peer) and dynamic, location specific >identifiers. From an architectural point of view, supporting such >indirection within a single name space seems to lead to messy >problems. Having two distinct name spaces leads to cleaner >solutions, but at the same time create a new layer. More or less >the same applies to multi-path communication, but in the spatial >rather than temporal dimension. I suggest you read this, if you haven't: Saltzer, Jerry. "On the Naming and Binding of Network Destinations" in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. It contains most everything you need. The problem in the Internet is it is missing half of the minimum required addressing architecture. Tends to make things difficult. >From that point of view, Mobile IP is a good example of what happens >when you add mobility without modifying your layering. Mobility is not really a big problem, just dynamic multi-homing. Take care, John --============_-1069164887==_ma============ Content-Type: text/html; charset="us-ascii" Re: [arch-d] Layers (was Re: Defining terms)
Other, perhaps less appreciated phenomena that seem to require layering are mobility and multi-path communication.  Mobility requires indirection:  you have to have separate stable identifiers (so that you can name your peer) and dynamic, location specific identifiers.  From an architectural point of view, supporting such indirection within a single name space seems to lead to messy problems.  Having two distinct name spaces leads to cleaner solutions, but at the same time create a new layer.  More or less the same applies to multi-path communication, but in the spatial rather than temporal dimension.

I suggest you read this, if you haven't:

Saltzer, Jerry. "On the Naming and Binding of Network Destinations" in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498.

It contains most everything you need.  The problem in the Internet is it is missing half of the minimum required addressing architecture.  Tends to make things difficult.

From that point of view, Mobile IP is a good example of what happens when you add mobility without modifying your layering.

Mobility is not really a big problem, just dynamic multi-homing.

Take care,
John
--============_-1069164887==_ma============-- --===============0366913287== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0366913287==-- From architecture-discuss-bounces@ietf.org Wed Mar 22 14:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM92i-0006TZ-I5; Wed, 22 Mar 2006 14:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM92h-0006TO-Cr for architecture-discuss@ietf.org; Wed, 22 Mar 2006 14:30:51 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM92g-0006Vp-5W for architecture-discuss@ietf.org; Wed, 22 Mar 2006 14:30:51 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2006 14:30:50 -0500 X-IronPort-AV: i="4.03,119,1141621200"; d="scan'208"; a="84738759:sNHT28498776" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2MJUnVU025791 for ; Wed, 22 Mar 2006 14:30:49 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 14:30:49 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 14:30:49 -0500 Date: Wed, 22 Mar 2006 13:30:31 -0600 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060322193030.GL5936@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> <474EEBD229DF754FB83D256004D0210802584767@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474EEBD229DF754FB83D256004D0210802584767@XCH-NW-6V1.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 22 Mar 2006 19:30:49.0420 (UTC) FILETIME=[1FE010C0:01C64DE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Wed, Mar 22, 2006 10:15:22AM -0800, Fleischman, Eric allegedly wrote: > I spent most of the Vancouver IETF asking IETF luminaries whether there > was a current IP architecture or not. I didn't encounter a single > person, including conversations with the IAB, that didn't state that the > Internet/IP doesn't currently have an architecture but rather is only an > ad hoc assemblage of technologies and techniques today. The IETF has architectural *principles*, plus building blocks, and in my experience explicitly avoids too much restriction of instantiation of those principles. This is a mixed blessing. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 08:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQ0H-0004xS-ER; Thu, 23 Mar 2006 08:37:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQ0F-0004xN-Ve for architecture-discuss@ietf.org; Thu, 23 Mar 2006 08:37:27 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQ0F-0002Pc-Nb for architecture-discuss@ietf.org; Thu, 23 Mar 2006 08:37:27 -0500 Received: from s73602 (dhcp-wireless-133-229.ietf65.org[130.129.133.229]) by comcast.net (sccrmhc14) with SMTP id <2006032313372701400bmt21e>; Thu, 23 Mar 2006 13:37:27 +0000 Message-ID: <01c301c64e7e$a18b3ae0$e5858182@china.huawei.com> From: "Spencer Dawkins" To: References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> Subject: Re: [arch-d] IETF, architectural vision, and adoption (was something else) Date: Thu, 23 Mar 2006 07:35:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Pekka, This was a terrifically helpful posting. Thank you for sending it. Spencer >> What nobody has ever figured out a good way to do is get such a new >> architecture actually deployed, i.e. get community consensus that this >> wonderful new architecture is the way to go. ... >> >> Look at how difficult it is for something as simple as HIP to get any >> traction - and even now, it's still pretty much a fringe thing, >> which will >> take many years, if ever, to really catch on widely and >> ubiquitously. Now >> multiply the difficulty of doing anything that relatively minor by an >> exponential factor for anything major - e.g. a whole new routing >> architecture. (Been there too...) > > I could not agree more. > > To gain more perspective to this, I found it very interesting to hear > from Dave Clark last night that we (the IETF) have had these problems > at least since 1992. Being a relative newcomer to the IETF (my first > IETF was in 1997 and only 2001 I started to come to these events even > semi-regularly), I have had great illusions of the IETF leading the > Internet to the future and the IAB doing real work in its role of the > architectural oversight. > > However, what I can say from my limited experience to being in the > IAB, many of the IAB members are painfully aware of the difficulties > related to IAB's architectural role. Personally, given my current > stand, I would go as far as suggesting that the IAB should be renamed > to be the Internet Activities Board, if for no other reason to remove > the illusion that they were _doing_ anything substantial on the > longer-term architectural issues. Yes, the IAB could _facilitate_ > architectural work, and in a way they are (we were) doing that by > creating this list. It remains to be seen what the new IAB decides > to do. > > Scaling back to more technical issues, what I find encouraging is > that HIP version 1 is now basically done. The drafts are ready, > waiting for security area review, and we found a volunteer for that. > There are three interoperating open source implementations. Some non- > research projects are starting to adopt HIP. If this is anyhow going > along Geoffrey Moore's Chasm model, HIP is now entering early > adoption phase and some people are looking for the first pins to bowl > over. Sure, the chasm is still ahead and HIP may never get over it, > but at least it is affecting people's thinking in SHIM6, BTNS, and > some other working groups. Hence, it looks like that medium-scale > architectural work (such as HIP) is not complete waste of time, even > at the IETF. It just requires a number years to have any effect; in > HIP's case the idea is now about 7-8 years old. > > So, my still-untested recipe for architectural work seems to have the > following ingredients: > > 1. Prepare to _continuously_ work on it for at least 5 years; 10 > years might be more realistic. > > 2. Try to gain enough of social traction early on so that the work > continues even when the first leaders tire. > > 3. Do not hope the IETF leadership to lead. They are too busy > preserving, conserving, and struggling with the inevitable power > games. What you can ask for, though, is a little bit of footing to > use as a marketing ground within the IETF and/or IRTF. > > 4. Early on, try to understand the assets out there and plan for > piecewise deployment. This seems to be where HIP may still trip. > Even if we have thought about this quite a lot, it looks like both > updating the stack and adding infrastructure (at least records to the > DNS) at the same time is just too much. Opportunistic HIP may have > better prospects, but it hasn't been completed yet. > > 5. Remember the list of issues that kill the next big thing: > - works badly with NATs > - 80% solution already available > - needs a kernel change > - requires updating routers or other network boxes > - requires new infrastructure > - requires changing existing applications > - no business benefit for the players > - lot of research papers before its deployed > - lengthy standardization effort before its deployed > - not configurable by normal users (i.e., needs any configuration) > - cannot be used until everyone has it > While you cannot do meaningful architectural changes without ticking > some of these boxes, trying to avoid them may pay off. > > --Pekka _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 09:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQbB-0000JK-Ek; Thu, 23 Mar 2006 09:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQbA-0000JF-6G for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:15:36 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQb8-0004eI-AI for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:15:36 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k2NEFXtO007265; Thu, 23 Mar 2006 06:15:33 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k2NEFTAM007264; Thu, 23 Mar 2006 06:15:29 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 23 Mar 2006 06:15:29 -0800 From: David Meyer To: Pekka Nikander Subject: Re: [arch-d] IETF, architectural vision, and adoption (was something else) Message-ID: <20060323141529.GA6985@1-4-5.net> References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0554400419==" Errors-To: architecture-discuss-bounces@ietf.org --===============0554400419== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 22, 2006 at 10:57:48AM -0600, Pekka Nikander wrote: > >What nobody has ever figured out a good way to do is get such a new > >architecture actually deployed, i.e. get community consensus that this > >wonderful new architecture is the way to go. ... > > > >Look at how difficult it is for something as simple as HIP to get any > >traction - and even now, it's still pretty much a fringe thing, =20 > >which will > >take many years, if ever, to really catch on widely and =20 > >ubiquitously. Now > >multiply the difficulty of doing anything that relatively minor by an > >exponential factor for anything major - e.g. a whole new routing > >architecture. (Been there too...) >=20 > I could not agree more. >=20 > To gain more perspective to this, I found it very interesting to hear =20 > from Dave Clark last night that we (the IETF) have had these problems =20 > at least since 1992. Being a relative newcomer to the IETF (my first =20 > IETF was in 1997 and only 2001 I started to come to these events even =20 > semi-regularly), I have had great illusions of the IETF leading the =20 > Internet to the future and the IAB doing real work in its role of the =20 > architectural oversight. I don't know if I'd call mine "illusions", but me too. > However, what I can say from my limited experience to being in the =20 > IAB, many of the IAB members are painfully aware of the difficulties =20 > related to IAB's architectural role. Personally, given my current =20 > stand, I would go as far as suggesting that the IAB should be renamed =20 > to be the Internet Activities Board, if for no other reason to remove =20 > the illusion that they were _doing_ anything substantial on the =20 > longer-term architectural issues. =20 I couldn't disagree more. The IAB has a large role in the operational aspects of the IETF; RFC 2850 designs it this way. However, the IAB is also constituted in such a way that it can *facilitate* long term architectural work. That it hasn't happened to date is a different matter, which IMO is a function of what the folks on the IAB are trying to accomplish. As you (and many on this list) know, some of us on the IAB are trying to push some more *architectural* agendas. > Yes, the IAB could _facilitate_ =20 > architectural work, and in a way they are (we were) doing that by =20 > creating this list. It remains to be seen what the new IAB decides =20 > to do. s/could/is/=20 I admit its a slow, frustrating and difficult process, and that there are deep wounds that surround that the IAB's role is in all of this. And as you know, I've been trying to education people about this (since I didn't really understand this when I came to the IAB; see e.g., http://www.1-4-5.net/~dmm/talks/NANOG35/iab). > So, my still-untested recipe for architectural work seems to have the =20 > following ingredients: >=20 > 1. Prepare to _continuously_ work on it for at least 5 years; 10 =20 > years might be more realistic. Totally. > 2. Try to gain enough of social traction early on so that the work =20 > continues even when the first leaders tire. Yep. > 3. Do not hope the IETF leadership to lead. They are too busy =20 > preserving, conserving, and struggling with the inevitable power =20 > games. What you can ask for, though, is a little bit of footing to =20 > use as a marketing ground within the IETF and/or IRTF. While I'm not good with authority of any kind (shocking to you all, I know), I find this statement not only unfair, but it also forms a kind of ad hominem attack on the I*. Yes there are politics (inevitable when humans are involved, it seems), but really, this kind comment is out of scope and inappropriate. And BTW, you might also want to disclose your conflict(s) of interest on this point; that would give your readers the context they need to interpret your comments. That being said, one of the many things I've learned during my year in "IETF leadership" (IAB in my case, but I've also been lucky enough to be liaison to the IESG, so I get to see into that process a bit as well) is that the I* is populated by some very hard working people who, for the most part, sincerely care about the Internet and its future. In any event, yes, there are politics, etc, but notwithstanding that, if you want to get something done, you (i). Have to actually do something (ii). Be willing to take some chances Both are difficult in the best of circumstances, and the challenges are only exacerbated in a volunteer organization like the IETF. So yes, the IETF can be frustrating at times (what isn't), but my sense is that there's a lot more that's good about the IETF than bad. And BTW, one can complain all day. That's not going to help the IETF, or the larger Internet community. OTOH, working towards our shared goals will.=20 So how about leaving this kind of poison behind and focusing on our shared goals? Dave --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEIq2BORgD1qCZ2KcRAnVOAJ4zK5pYCnRSHRb/c3kbdU2rfnHr3gCfTisg VXZigT+zRf8GSrYQGva1wVY= =BK/G -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- --===============0554400419== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0554400419==-- From architecture-discuss-bounces@ietf.org Thu Mar 23 09:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQm0-0001UU-CB; Thu, 23 Mar 2006 09:26:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQly-0001La-8c for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:26:46 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQlw-00058M-SR for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:26:46 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k2NEQiod007489; Thu, 23 Mar 2006 06:26:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) id k2NEQiCr007488; Thu, 23 Mar 2006 06:26:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 23 Mar 2006 06:26:44 -0800 From: David Meyer To: Pekka Nikander Subject: Re: [arch-d] IETF, architectural vision, and adoption (was something else) Message-ID: <20060323142644.GA7426@1-4-5.net> References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> <20060323141529.GA6985@1-4-5.net> Mime-Version: 1.0 In-Reply-To: <20060323141529.GA6985@1-4-5.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1243496175==" Errors-To: architecture-discuss-bounces@ietf.org --===============1243496175== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > As you (and many on this > list) know, some of us on the IAB are trying to push some > more *architectural* agendas. Looking at the way I phrased this, I would have rather I said something more like: "the IAB is pursuing many *architectural* agendas." The reason I wanted to make this clarification is that (i). The IAB is very much concerned about the architectrual direction (and evolution) of the Internet Architecture, and =20 (ii). The IAB uses consensus based decision making Dave =09 --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEIrAkORgD1qCZ2KcRAu1qAJ0ZDvTUPdy9E3W0Anu9S4lA4xqw9ACfXU5m s2ekS+4H5DenOiyhxz0oWXk= =1yIY -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- --===============1243496175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1243496175==-- From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdX-00079p-Rz; Thu, 23 Mar 2006 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQTV-0003DD-B4 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:07:41 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQTU-0004Bf-Tc for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:07:41 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060323140739m1200jiglte>; Thu, 23 Mar 2006 14:07:39 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060321234652.GD11517@verdi> References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> <20060321234652.GD11517@verdi> Date: Thu, 23 Mar 2006 09:01:59 -0500 To: John Leslie , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Running a little behind. >Bound, Jim wrote: >> >> I think we should for a moment imagine a world without layer but as >> modules. Really that is how the actual code is and not in layers. Sure >> IP packet gets parsed before TCP, and TCP makes decisions before passing >> data, as example here only, but is that layers or as Noel states >> modules? > > Let's not forget that layers are an abstraction, intended to limit >the complexity which any one process needs to deal with. If we do layers >correctly, every process can ignore most of what's happening at lower >layers as well as everything happening at higher layers. Agreed. > Tunneling doesn't break the abstraction: it merely confuses the folks >who try to visualize the whole system and think there's something wrong >when a layer-four procedure is used to implement a layer-two function. Disagree. There is nothing wrong with both layer 2 and layer 4 having the same functions, because they are performing the same function over different scopes. >The abstraction still works fine: the layer-three built on top of that >tunnel need know nothing about how the layer-two is actually implemented >over a layer-four tunnel. I prefer to think of tunneling as a somewhat "bad" short cut. It is what happens when you try to use only part of a layer without bringing along the rest of its machinery. Generally, it creates as many problems as it solves. > It's true that implementation may blend layers and implement the >combined layers as modules. This doesn't break the abstraction either >(unless the implementation is buggy). I used to write implementations >like that, when processing cycles were expensive. The implementor can >still think of layers even if the implementation isn't layered. Absolutely. Layer boundaries only have to be "real" if the implementation happens to need a boundary somewhere. > > As far as the edge doing routing I think that is the wrong question? >> Once a packet has a destination path it should be move to that path? >> That is done with routing. > > "Routing" is two almost-unrelated things: generating a path which >"should work" vs. passing packets to another router "closer" to the >destination. Both of these get arbitrarily complex as topology changes. >(And, believe me, it does!) The abstraction says that passing packets >from router to router exists in a layer separate from encoding bits >(a lower layers) and also separate from establishing and tearing down >"connections" (a higher layer). Actually, I would say routing is 3 distinct tasks: exchanging information about connectivity and other information, calculating connectivity based on what you have collected, and then choosing a next hop/path based on the calculation and the other info. > > The other "routing" function is quite a different matter; and might >as well be considered out-of-band communications. > >> Now finding the most optimal path at a point on a network is fine any >> time whether at the edge or within the core. So I think this may be a >> moot point. > > Agreed. It is mostly orthogonal to our layering model. > >> Also should we define what we mean by the "edge". > > A bit late to start that... ;^) > >> Also is the only reason we use "layers" for the IP Reference Model >> because OSI did? > > No. > >> If so that was a bad reason? > > It wouldn't have been a bad reason. > > We have formed an abstraction we call "layers" totally separate from >what OSI called "layers". That the two have converged at all over the >years is, IMHO, a good thing. > >> ... but end-to-end to me is routers only get to forward based on the >> IP address > > "End-to-end" IMHO means that we didn't want routers guessing what >something at layer four or above wanted to do with the data: we wanted >routers doing a simple-minded task that was easy for layer four to >model; and that layer four would do all the worrying about anything >beyond that simple model that it might need. > > This has led to things like the Web just happening, without any >waiting for routers to learn how to serve the needs of browsers and >servers better. (We certainly know now how to serve those needs >better; but most folks prefer that the Web happened when it did.) > > The IP address, BTW, _defines_ endpoints for layer three. The fact >that it serves any other purpose is immaterial to layer three. That is a bit nebulous. IP addresses define layer 3 points of attachment, which is the same as a layer 2 protocol machine. > > and end-to-end cannot be possible unless each client on either end >> of the commo both have a globally routable source and destination >> address. > > Fully agree. (That's pretty much the definition of layer three...) Actually disagree. A transport protocol can operate end to end over relays that change addresses. TCP can't, but in general a transport protocol can. > > Changing the IP address in a header breaks end-to-end. Only with TCP. > Um... I'd really like to agree. (I hate NATs.) NATs only appear to cause pain because we currently have half an addressing architecture. NATs merely create multiple layer 3s of different scope. Just like we have multiple layer 2s of different scope. > But actually, NATs kludge the actual layer three so that it looks >just like a layer three to unsuspecting layer-four processes, despite >having been thoroughly broken in the middle. Thus end-to-end still >works (mostly). yep. See above. > (BTW, NATs could be much cleaner and less buggy if we kept "session" >endpoint addressing entirely separate from level-three IP addressing.) ABSOLUTELY. Thank you for saying this. Actually it isn't session so much as application. To paraphrase Bucky Fuller, NATs only break broken architectures. If we had a full addressing architecture it wouldn't be a problem. I have often described applications passing IP addresses as similar to a JAVA program passing absolute pointers. ;-) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdX-00079f-Gx; Thu, 23 Mar 2006 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMNg6-0006HL-KK for architecture-discuss@ietf.org; Thu, 23 Mar 2006 06:08:30 -0500 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMNg5-0004qO-AQ for architecture-discuss@ietf.org; Thu, 23 Mar 2006 06:08:30 -0500 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 11:08:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 11:07:08 -0000 Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316A36@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZN5N4ItOV6MrWeSeGhlCW5K1X8KAAhQ9ap From: To: , X-OriginalArrivalTime: 23 Mar 2006 11:08:28.0078 (UTC) FILETIME=[1CA604E0:01C64E6A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878748456==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0878748456== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64E6A.1C778363" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64E6A.1C778363 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] said on Wed 2006-03-22 = 19:13: > I am afraid I was not clear enough. No change there, then. L. ------_=_NextPart_001_01C64E6A.1C778363 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [arch-d] Defining terms

JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] said on = Wed 2006-03-22 19:13:
> I am afraid I was not clear enough.

No change there, then.

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>

------_=_NextPart_001_01C64E6A.1C778363-- --===============0878748456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0878748456==-- From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdY-0007A9-HN; Thu, 23 Mar 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMR6C-0008MO-1D for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:47:40 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMR6B-0005UE-OK for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:47:40 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006032314472801300efvlje>; Thu, 23 Mar 2006 14:47:39 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.3.4.2.20060322160610.0479c2a0@mail.jefsey.com> References: <936A4045C332714F975800409DE0924002029A02@tayexc14.americas.cpqcorp.net> <6.2.3.4.2.20060322160610.0479c2a0@mail.jefsey.com> Date: Thu, 23 Mar 2006 09:37:33 -0500 To: "JFC (Jefsey) Morfin" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I completely agree with Jefsey on this. But I do have one question. If the Internet is the 3rd architecture, what were the other 2? ARPANet and CYCLADES? Take care, John At 20:13 +0100 2006/03/22, JFC (Jefsey) Morfin wrote: >At 14:45 22/03/2006, Bound, Jim wrote: >>I think we can agree to disagree and move forward. See John Loughney's >>mail I fully agree with John. Not saying we should not think out of the >>box but to put forth any new Internet archicture components without a >>transition is not wise. This will come up again but suggest we move >>forward with idea generation from all the bright people on this list. > >I am afraid I was not clear enough. I do not think that transitions >should not be considered. I think they are not a real problem. This >is because: >1. every propositon deals with the same digital ecosystem. This >implies some built-in compatibility. >2. transitions are a matter of cost (financial and operational). New >propositions will not be seriously considered if the returns of the >transition costs are not acceptable. The corollary is that if a new >architecture is worth the cost of change, it MAY go through. > >IMHO the priority is the best network "value" (I documented the >formula I use). Backward compatibility and transition considerations >should come after. We should keep in mind that incremental changes >are replacements. So, this is the same situation as when we created >the international system. And when we implemented its next >architectures. The Internet is the third architecture of the >international network. We consider the fourth one now. So we have >experience. We figured out already three times to successfully >deploy a change. > >At 14:51 22/03/2006, Noel Chiappa wrote: >>What nobody has ever figured out a good way to do is get such a new >>architecture actually deployed, i.e. get community consensus that this >>wonderful new architecture is the way to go. > >This is another way to say the same thing. But it shows the usual >error (ex. IPv6, IDNA, etc.). This is to consider that "global" >means a single community, instead of "every communitie together". >There is no way to find a consensus involving everyone. > >Architectural transitions are not engineering evolutions. They call >for (virtual) gateways between the community of the users of the new >architecture and the community of the users of the old architecure. >There is a buil-in consensus in the first one. There are mixed >feelings in the other one. The ROI obtained by the first community >is the only/main motivation of the second community. Taking this for >"buzz-word" having no place here can be understood. But it may be >the answer to the question why brillant propositions did not appeal >on wallets. > >NB. Gateways can be virtual >- either because the old architecture is/is made hybrid and supports both. >- or because they are between two layers. For example: what is above >is now and below is not. > >It seems that the lack of formal Internet architecture makes both >these virtual splits difficult. This would only leave physical split >(the network of the networks). > >I think there is a layer where it is possible to have a "layer >virual gateway" whatever the technology. By the same token it could >help supporting convergence. This is between 7th (application) and >what I call 8th (interapplication) layers. In internet architecture >interapplication layer could be termed a "smart edge" (or smart >plug). Located where OPES should be. > >If you consider the 8th layer as a shim between the user agent and >the network, >- for the network it is AN (Internet) end >- for the user it is THE (possibly multitechnology, multilink) networking end. >("plug" may speak better than "end"). > >This opens many new architectural and transition possibilities. One >is the welding several network end to end connections into a single >link. This permits what I name ONES (open network extended >services): several "end" OPES can be netted to a same ONES. It would >permit to bring an apparent network core intelligence (ONES) to a >standard end to end system (or several ones acting in parallel - ex. >back-up). This also pemits easy transitions: the operations of layer >8th and above is independent from layer 1-7 architectural evolution. >This makes the user independent from the underlying technology. > >(I initially explained that I am interested in brainware and usage >aspects (what I call layer 8th/12th - where the decision making >wallets are)). >jfc > > > > > > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdX-00079p-Rz; Thu, 23 Mar 2006 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQTV-0003DD-B4 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:07:41 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQTU-0004Bf-Tc for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:07:41 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060323140739m1200jiglte>; Thu, 23 Mar 2006 14:07:39 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060321234652.GD11517@verdi> References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> <20060321234652.GD11517@verdi> Date: Thu, 23 Mar 2006 09:01:59 -0500 To: John Leslie , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Running a little behind. >Bound, Jim wrote: >> >> I think we should for a moment imagine a world without layer but as >> modules. Really that is how the actual code is and not in layers. Sure >> IP packet gets parsed before TCP, and TCP makes decisions before passing >> data, as example here only, but is that layers or as Noel states >> modules? > > Let's not forget that layers are an abstraction, intended to limit >the complexity which any one process needs to deal with. If we do layers >correctly, every process can ignore most of what's happening at lower >layers as well as everything happening at higher layers. Agreed. > Tunneling doesn't break the abstraction: it merely confuses the folks >who try to visualize the whole system and think there's something wrong >when a layer-four procedure is used to implement a layer-two function. Disagree. There is nothing wrong with both layer 2 and layer 4 having the same functions, because they are performing the same function over different scopes. >The abstraction still works fine: the layer-three built on top of that >tunnel need know nothing about how the layer-two is actually implemented >over a layer-four tunnel. I prefer to think of tunneling as a somewhat "bad" short cut. It is what happens when you try to use only part of a layer without bringing along the rest of its machinery. Generally, it creates as many problems as it solves. > It's true that implementation may blend layers and implement the >combined layers as modules. This doesn't break the abstraction either >(unless the implementation is buggy). I used to write implementations >like that, when processing cycles were expensive. The implementor can >still think of layers even if the implementation isn't layered. Absolutely. Layer boundaries only have to be "real" if the implementation happens to need a boundary somewhere. > > As far as the edge doing routing I think that is the wrong question? >> Once a packet has a destination path it should be move to that path? >> That is done with routing. > > "Routing" is two almost-unrelated things: generating a path which >"should work" vs. passing packets to another router "closer" to the >destination. Both of these get arbitrarily complex as topology changes. >(And, believe me, it does!) The abstraction says that passing packets >from router to router exists in a layer separate from encoding bits >(a lower layers) and also separate from establishing and tearing down >"connections" (a higher layer). Actually, I would say routing is 3 distinct tasks: exchanging information about connectivity and other information, calculating connectivity based on what you have collected, and then choosing a next hop/path based on the calculation and the other info. > > The other "routing" function is quite a different matter; and might >as well be considered out-of-band communications. > >> Now finding the most optimal path at a point on a network is fine any >> time whether at the edge or within the core. So I think this may be a >> moot point. > > Agreed. It is mostly orthogonal to our layering model. > >> Also should we define what we mean by the "edge". > > A bit late to start that... ;^) > >> Also is the only reason we use "layers" for the IP Reference Model >> because OSI did? > > No. > >> If so that was a bad reason? > > It wouldn't have been a bad reason. > > We have formed an abstraction we call "layers" totally separate from >what OSI called "layers". That the two have converged at all over the >years is, IMHO, a good thing. > >> ... but end-to-end to me is routers only get to forward based on the >> IP address > > "End-to-end" IMHO means that we didn't want routers guessing what >something at layer four or above wanted to do with the data: we wanted >routers doing a simple-minded task that was easy for layer four to >model; and that layer four would do all the worrying about anything >beyond that simple model that it might need. > > This has led to things like the Web just happening, without any >waiting for routers to learn how to serve the needs of browsers and >servers better. (We certainly know now how to serve those needs >better; but most folks prefer that the Web happened when it did.) > > The IP address, BTW, _defines_ endpoints for layer three. The fact >that it serves any other purpose is immaterial to layer three. That is a bit nebulous. IP addresses define layer 3 points of attachment, which is the same as a layer 2 protocol machine. > > and end-to-end cannot be possible unless each client on either end >> of the commo both have a globally routable source and destination >> address. > > Fully agree. (That's pretty much the definition of layer three...) Actually disagree. A transport protocol can operate end to end over relays that change addresses. TCP can't, but in general a transport protocol can. > > Changing the IP address in a header breaks end-to-end. Only with TCP. > Um... I'd really like to agree. (I hate NATs.) NATs only appear to cause pain because we currently have half an addressing architecture. NATs merely create multiple layer 3s of different scope. Just like we have multiple layer 2s of different scope. > But actually, NATs kludge the actual layer three so that it looks >just like a layer three to unsuspecting layer-four processes, despite >having been thoroughly broken in the middle. Thus end-to-end still >works (mostly). yep. See above. > (BTW, NATs could be much cleaner and less buggy if we kept "session" >endpoint addressing entirely separate from level-three IP addressing.) ABSOLUTELY. Thank you for saying this. Actually it isn't session so much as application. To paraphrase Bucky Fuller, NATs only break broken architectures. If we had a full addressing architecture it wouldn't be a problem. I have often described applications passing IP addresses as similar to a JAVA program passing absolute pointers. ;-) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdX-00079f-Gx; Thu, 23 Mar 2006 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMNg6-0006HL-KK for architecture-discuss@ietf.org; Thu, 23 Mar 2006 06:08:30 -0500 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMNg5-0004qO-AQ for architecture-discuss@ietf.org; Thu, 23 Mar 2006 06:08:30 -0500 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 11:08:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 11:07:08 -0000 Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316A36@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZN5N4ItOV6MrWeSeGhlCW5K1X8KAAhQ9ap From: To: , X-OriginalArrivalTime: 23 Mar 2006 11:08:28.0078 (UTC) FILETIME=[1CA604E0:01C64E6A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878748456==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0878748456== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64E6A.1C778363" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64E6A.1C778363 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] said on Wed 2006-03-22 = 19:13: > I am afraid I was not clear enough. No change there, then. L. ------_=_NextPart_001_01C64E6A.1C778363 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [arch-d] Defining terms

JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] said on = Wed 2006-03-22 19:13:
> I am afraid I was not clear enough.

No change there, then.

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>

------_=_NextPart_001_01C64E6A.1C778363-- --===============0878748456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0878748456==-- From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdY-0007A9-HN; Thu, 23 Mar 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMR6C-0008MO-1D for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:47:40 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMR6B-0005UE-OK for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:47:40 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc13) with ESMTP id <2006032314472801300efvlje>; Thu, 23 Mar 2006 14:47:39 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.3.4.2.20060322160610.0479c2a0@mail.jefsey.com> References: <936A4045C332714F975800409DE0924002029A02@tayexc14.americas.cpqcorp.net> <6.2.3.4.2.20060322160610.0479c2a0@mail.jefsey.com> Date: Thu, 23 Mar 2006 09:37:33 -0500 To: "JFC (Jefsey) Morfin" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I completely agree with Jefsey on this. But I do have one question. If the Internet is the 3rd architecture, what were the other 2? ARPANet and CYCLADES? Take care, John At 20:13 +0100 2006/03/22, JFC (Jefsey) Morfin wrote: >At 14:45 22/03/2006, Bound, Jim wrote: >>I think we can agree to disagree and move forward. See John Loughney's >>mail I fully agree with John. Not saying we should not think out of the >>box but to put forth any new Internet archicture components without a >>transition is not wise. This will come up again but suggest we move >>forward with idea generation from all the bright people on this list. > >I am afraid I was not clear enough. I do not think that transitions >should not be considered. I think they are not a real problem. This >is because: >1. every propositon deals with the same digital ecosystem. This >implies some built-in compatibility. >2. transitions are a matter of cost (financial and operational). New >propositions will not be seriously considered if the returns of the >transition costs are not acceptable. The corollary is that if a new >architecture is worth the cost of change, it MAY go through. > >IMHO the priority is the best network "value" (I documented the >formula I use). Backward compatibility and transition considerations >should come after. We should keep in mind that incremental changes >are replacements. So, this is the same situation as when we created >the international system. And when we implemented its next >architectures. The Internet is the third architecture of the >international network. We consider the fourth one now. So we have >experience. We figured out already three times to successfully >deploy a change. > >At 14:51 22/03/2006, Noel Chiappa wrote: >>What nobody has ever figured out a good way to do is get such a new >>architecture actually deployed, i.e. get community consensus that this >>wonderful new architecture is the way to go. > >This is another way to say the same thing. But it shows the usual >error (ex. IPv6, IDNA, etc.). This is to consider that "global" >means a single community, instead of "every communitie together". >There is no way to find a consensus involving everyone. > >Architectural transitions are not engineering evolutions. They call >for (virtual) gateways between the community of the users of the new >architecture and the community of the users of the old architecure. >There is a buil-in consensus in the first one. There are mixed >feelings in the other one. The ROI obtained by the first community >is the only/main motivation of the second community. Taking this for >"buzz-word" having no place here can be understood. But it may be >the answer to the question why brillant propositions did not appeal >on wallets. > >NB. Gateways can be virtual >- either because the old architecture is/is made hybrid and supports both. >- or because they are between two layers. For example: what is above >is now and below is not. > >It seems that the lack of formal Internet architecture makes both >these virtual splits difficult. This would only leave physical split >(the network of the networks). > >I think there is a layer where it is possible to have a "layer >virual gateway" whatever the technology. By the same token it could >help supporting convergence. This is between 7th (application) and >what I call 8th (interapplication) layers. In internet architecture >interapplication layer could be termed a "smart edge" (or smart >plug). Located where OPES should be. > >If you consider the 8th layer as a shim between the user agent and >the network, >- for the network it is AN (Internet) end >- for the user it is THE (possibly multitechnology, multilink) networking end. >("plug" may speak better than "end"). > >This opens many new architectural and transition possibilities. One >is the welding several network end to end connections into a single >link. This permits what I name ONES (open network extended >services): several "end" OPES can be netted to a same ONES. It would >permit to bring an apparent network core intelligence (ONES) to a >standard end to end system (or several ones acting in parallel - ex. >back-up). This also pemits easy transitions: the operations of layer >8th and above is independent from layer 1-7 architectural evolution. >This makes the user independent from the underlying technology. > >(I initially explained that I am interested in brainware and usage >aspects (what I call layer 8th/12th - where the decision making >wallets are)). >jfc > > > > > > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdX-00079k-Mu; Thu, 23 Mar 2006 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQA5-0004q3-GK for architecture-discuss@ietf.org; Thu, 23 Mar 2006 08:47:37 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQA2-0002l1-Tp for architecture-discuss@ietf.org; Thu, 23 Mar 2006 08:47:35 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060323134728011002s12qe>; Thu, 23 Mar 2006 13:47:28 +0000 Mime-Version: 1.0 Message-Id: Date: Thu, 23 Mar 2006 08:39:08 -0500 To: architecture-discuss@ietf.org From: John Day Subject: Fwd: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Oops. Forgot to send this to the whole list. > >> > From: Alexis Turner >> >> > the current Internet is nothing but a series of patches building upon >> > endless series of patches. At some point, engineering a system that is >> > held together by tape and string .. becomes an excercise in both >> > futility and stubborness .. >> > Who on this list would realistically disagree with that? Can we >> > honestly say the current system is not broken as hell? >> >>Basically nobody (maybe nobody at all) disagrees with that. The problem >>arrives when you get to the next step: >> >> > It is at that point that the system designers must take a step back, >> > learn from their mistakes, and start over from the beginning. >> > ... >> > If we continue to insist on making something that works with the >> > current system, the predecessors will remain broken. >> >>I'm not sure if quite as many agree with this position (that a re-think is >>needed), but that's not the issue. The problem comes when you consider any >>non-incremental change - and moreover consider *how to get it adopted >>widely*. >> >>It's relatively easy for me (or any number of other talented system >>architects) to sit back, reflect on what went wrong, and what we've learned, >>and come up with cool new architectures. (Been there, done that, as have >>several others.) It's also relatively easy for me (or any number of other >>talented engineers) to figure out an interoperable way to deploy this >>wonderful new architecture. (Been there, done that too.) > > A word of caution: While we all know that getting something >adopted is important and an easy effective transition is very >important, worrying too much about it too early is precisely what >got us in the fix we are in. We need to figure out where things >need to go. In some sense, it would be good to throw "caution" to >the wind and be a little idealistic, knowing full well we will never >get there. Once we understand what that is we can better understand >the many steps that it will take to move in that direction. To >worry about transition too much at this stage would be giving up >before we begin. > >Committees even one like this will behave conservatively if left to >their own devices. My experience is that often more can be >accomplished than a committee believes is possible. If we start at >this early stage putting up subtle boundaries, we will end up with >YABA (Yet Another Band-Aid). > >Perhaps the reason that something as simple as HIP has trouble >getting traction is that it doesn't do enough. The age-old problem >that there is not sufficient benefit to warrant fast adoption. >Perhaps its sights were set too low. > >Given what several people (Eric, Alexis, etc) on this list have said >about the lack of an architecture and the current "stuff" being a >collection of band-aids, in some sense we need to determine what the >logical principles behind building internets are before we start >worrying about what architecture the Internet should have and how we >expect to transition to it. It is a scary thought, but it sounds >like we are a long way from starting to work on the problem we need >to solve. > >To some extent, I think this is reflected in current textbooks. >Browse through one, consider how much of what is there is reporting >what is done and how much are the underlying principles that would >allow one to do a good job developing a new protocol or >architecture. They are mostly at the level of vocational-ed, not >university. > >Yes, we have to make a successful transition and it has to be >practical and it has to address real problems people want to solve. >But even pushing on that now is going to yield more of the same. > >Sorry, >John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdY-00079u-0p; Thu, 23 Mar 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQdF-0000yY-OJ for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:17:45 -0500 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQdE-0004mY-B5 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:17:45 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <20060323141739012007nr2re>; Thu, 23 Mar 2006 14:17:43 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060322003455.GE11517@verdi> References: <936A4045C332714F975800409DE0924001FD23BE@tayexc14.americas.cpqcorp.net> <20060321150319.GA4560@sbrim-wxp01> <15F14882-6314-488F-84E1-77314AE5A43B@nomadiclab.com> <20060322003455.GE11517@verdi> Date: Thu, 23 Mar 2006 09:09:36 -0500 To: John Leslie , Pekka Nikander From: John Day Subject: Re: [arch-d] Layers (was Re: Defining terms) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >> Other, perhaps less appreciated phenomena that seem to require >> layering are mobility and multi-path communication. > > I quite agree these would benefit from adding layer(s). > >> Mobility requires indirection: you have to have separate stable >> identifiers (so that you can name your peer) and dynamic, location >> specific identifiers. > > I agree we need stable identifiers; I'm not sure "indirection" is the only option for deriving location-specific identifiers. > > From an architectural point of view, supporting such indirection >> within a single name space seems to lead to messy problems. > > Agreed. > >> Having two distinct name spaces leads to cleaner solutions, but at >> the same time create a new layer. More or less the same applies to >> multi-path communication, but in the spatial rather than temporal >> dimension. > > Agreed. > >> From that point of view, Mobile IP is a good example of what happens >> when you add mobility without modifying your layering. > > Ouch! ;^) Actually mobility and multipath require a full addressing architecture. It is not so much a problem of not enough layers as not enough naming and addressing. According to Salzter, half of what we need is missing. Ouch, Ouch. ;-) John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdY-00079z-6B; Thu, 23 Mar 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQmj-0001h6-RZ for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:27:33 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQmj-000595-Hy for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:27:33 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060323142731m13005kgn0e>; Thu, 23 Mar 2006 14:27:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> References: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> Date: Thu, 23 Mar 2006 09:25:10 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 21:15 -0500 2006/03/21, Noel Chiappa wrote: > > From: John Day > > > Now of course, this collection of users can also cooperate to do > > something and provide a black box to their users. > > So now, if these are not layers what are they? pancakes? waffles? > > I would contend that layers are a means of organizing functionality > >The problem with layers is that are a simplification of reality - and, >moreover, a simplification that rapidly becomes stultifying and confusing. Then you don't have the layers right. >The reality of the subsystem/protocol dependency graph, in real networks, is >too complex to be captured with the simple ordered layer model. > >As one example, look at BGP. It's used for passing around routing info - so >it's part of the inter-network layer, right? Yes, but, it uses TCP. So it's Is it? What is its scope? >above the transport layer, right? "Does not compute! Does not compute!" Or No. There is no rule that says a protocol and the layer it is used in are fixed. Protocols are means to providing certain kinds of coordination. I can use any protocol in any layer where it does what I need done. Sure it computes. >what about those things that open a PPP link over a TCP connection? Similarly >confusing. Not in the least. In fact, they show a deep understanding of what network architecture is all about. >What's really important, for a system architect, is the subsystem dependency >graph. Anything which confuses that representation is non-optimal - and an >ordered layer model definitely counts. Yep. > >To put it another way, layers may a fine device for introducing basic >networking concepts to beginning students, but they are really a bad idea for >use by anyone past the level of "initial introduction". To mangle one of my >favourite military axioms, "Beginners think in layers, everyone else thinks >in subsystem dependency graphs." Then you haven't gotten your layers organized right. When they are, they not only work but they do more things than we are currently doing and do them well and easily. C'mon Noel, I know you better than this. Step back and look carefully. Use all of these as data. Consider what the data is telling us. > > > So we have a collection of things in different systems all cooperating > > with some amount of shared state and doing it in some black box to hide > > the complexity from the user of the black box. > >Right - and this touches on a point I like to rant about, which is that too >often: In drawing block diagrams, people treat "the part of subsystem X in >machine A and "the part of subsystem X in machine B" as more distantly >related than "the part of subsystem X in machine A" and "the part of >subsystem Y in machine A". In other words, they tend to draw diagrams in >which the main boxes are machine A and machine B, with maybe little sub-boxes >inside those boxes for subsystems X and Y. However, when you're trying to >understand the subsystem dependency issues, this makes those dependencies >much harder to see. The other kind of diagram, in which the main boxes are >subsystems X, Y, etc are much rarer - alas. > Indeed they do. This (as you know) is usually to indicate the degree of coupling. modules in the same system are generally more tight coupled than those that are not. At the very least modules in the same system can coordinate with a test-and-set. > > Although, if you *need* a boundary for some reason, some place a layer > > boundary is a good place to do it, if you have chosen your layers > > wisely. > >A layer boundary is, in many ways, just a subsystem interface definition. > >Of course, anytime you break a system up into subsystems, the issue of where >you put the boundaries, and what info is passed across them - that is (to me) >the heart of architecture. Most definitely. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:26:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSdY-0007A4-Bw; Thu, 23 Mar 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMQwN-0007IN-5x for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:37:31 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMQwM-0005JG-Nj for architecture-discuss@ietf.org; Thu, 23 Mar 2006 09:37:31 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060323143729m13005qdkje>; Thu, 23 Mar 2006 14:37:29 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060322135158.4936286AF1@mercury.lcs.mit.edu> References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> Date: Thu, 23 Mar 2006 09:33:06 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: RE: [arch-d] Defining terms X-Spam-Score: 0.5 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-Mailman-Approved-At: Thu, 23 Mar 2006 11:26:10 -0500 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635395502==" Errors-To: architecture-discuss-bounces@ietf.org --===============0635395502== Content-Type: multipart/alternative; boundary="============_-1068997849==_ma============" --============_-1068997849==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:51 -0500 2006/03/22, Noel Chiappa wrote: > > From: Alexis Turner > > > the current Internet is nothing but a series of patches building upon > > endless series of patches. At some point, engineering a system that is > > held together by tape and string .. becomes an excercise in both > > futility and stubborness .. > > Who on this list would realistically disagree with that? Can we > > honestly say the current system is not broken as hell? > >Basically nobody (maybe nobody at all) disagrees with that. The problem >arrives when you get to the next step: > > > It is at that point that the system designers must take a step back, > > learn from their mistakes, and start over from the beginning. > > ... > > If we continue to insist on making something that works with the > > current system, the predecessors will remain broken. > >I'm not sure if quite as many agree with this position (that a re-think is >needed), but that's not the issue. The problem comes when you consider any >non-incremental change - and moreover consider *how to get it adopted >widely*. That depends on whether we are engineers or scientists. If we are scientists and honest with ourselves, we need to honestly look at what our experience is telling us. The guidelines for science (according to Newton) are 1. Nature is essentially simple; therefore, we should not introduce more hypotheses than are sufficient and necessary for the explanation of observed facts. This is a hypothesis, or rule, of simplicity and verae causae. 2. Hence, as far as possible, similar effects must be assigned to the same cause. This is a principle of uniformity of nature. 3. Properties common to all those bodies within reach of our experiments are assumed (even if only tentatively) as pertaining to all bodies in general. This is a reformulation of the first two hypotheses and is needed for forming universals. 4. Propositions in science obtained by wide induction are to be regarded as exactly or approximately true until phenomena or experiments show that they may be corrected or are liable to exceptions. This principle states that propositions induced on the basis of experiment should not be confuted merely by proposing contrary hypotheses. paraphrased from Newton's Principia 1726 by Gerald Holton in Thematic Origins of Scientific Thought And while we deal in the nether land between nature and mathematics I think these apply. Over the last 30 years we have accrued quite a lot of experience. I contend that no one working on this was stupid. So what they have found and what they did tell us something about the structure we are trying to find. We just haven't teased out what that nice elegant structure is yet. So what is the data telling us. Take care, John --============_-1068997849==_ma============ Content-Type: text/html; charset="us-ascii" RE: [arch-d] Defining terms
At 8:51 -0500 2006/03/22, Noel Chiappa wrote:
    > From: Alexis Turner <subbies@redheadedstepchild.org>

    > the current Internet is nothing but a series of patches building upon
    > endless series of patches. At some point, engineering a system that is
    > held together by tape and string .. becomes an excercise in both
    > futility and stubborness ..
    > Who on this list would realistically disagree with that? Can we
    > honestly say the current system is not broken as hell?

Basically nobody (maybe nobody at all) disagrees with that. The problem
arrives when you get to the next step:

    > It is at that point that the system designers must take a step back,
    > learn from their mistakes, and start over from the beginning.
    > ...
    > If we continue to insist on making something that works with the
    > current system, the predecessors will remain broken.

I'm not sure if quite as many agree with this position (that a re-think is
needed), but that's not the issue. The problem comes when you consider any
non-incremental change - and moreover consider *how to get it adopted
widely*.

That depends on whether we are engineers or scientists.  If we are scientists and honest with ourselves, we need to honestly look at what our experience is telling us.  The guidelines for science (according to Newton) are

1.  Nature is essentially simple; therefore, we should not introduce more hypotheses than are sufficient and necessary for the explanation of observed facts.  This is a hypothesis, or rule, of simplicity and verae causae.

2.  Hence, as far as possible, similar effects must be assigned to the same cause.  This is a principle of uniformity of nature.

3.  Properties common to all those bodies within reach of our experiments are assumed (even if only tentatively) as pertaining to all bodies in general.  This is a reformulation of the first two hypotheses and is needed for forming universals.

4.  Propositions in science obtained by wide induction are to be regarded as exactly or approximately true until phenomena or experiments show that they may be corrected or are liable to exceptions.  This principle states that propositions induced on the basis of experiment should not be confuted merely by proposing contrary hypotheses.

paraphrased from Newton's Principia 1726
by Gerald Holton
in Thematic Origins of Scientific Thought

And while we deal in the nether land between nature and mathematics I think these apply.  Over the last 30 years we have accrued quite a lot of experience.  I contend that no one working on this was stupid.  So what they have found and what they did tell us something about the structure we are trying to find.  We just haven't teased out what that nice elegant structure is yet.  So what is the data telling us.

Take care,
John
--============_-1068997849==_ma============-- --===============0635395502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============0635395502==-- From architecture-discuss-bounces@ietf.org Thu Mar 23 11:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSnD-0004A3-CL; Thu, 23 Mar 2006 11:36:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSnB-00047b-P7 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:36:09 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSnB-0002Rv-BH for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:36:09 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1FCC0212C59; Thu, 23 Mar 2006 18:36:08 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 34374212C4C; Thu, 23 Mar 2006 18:36:07 +0200 (EET) In-Reply-To: <20060323141529.GA6985@1-4-5.net> References: <20060322135158.4936286AF1@mercury.lcs.mit.edu> <20060323141529.GA6985@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v746.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A6D10DB-2F84-4707-8000-5899989D1E09@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] IETF, architectural vision, and adoption (was something else) Date: Thu, 23 Mar 2006 10:36:04 -0600 To: David Meyer X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave, I don't want to dive into this rat hole too deeply, but we seem to have a very different view of what is "doing" vs. "facilitating", or what "long-term" means. I wouldn't call *anything* I did or we did while I was at the IAB as *doing* logn-term architectural _work_. Putting together the much needed bad traffic workshop, working specifying on what are open architectural issues, or clarifying existing architectural principles, is not what I would call long-term architectural work. I would call all that facilitating or, at best, short-term architectural work. To clarify, I am not saying that the IAB is not doing good work. It is. The work it is doing is _MUCH_ needed. But from my personal point of view, I could not see the IAB _doing_ or _leading_ any long- term architectural work. And, based on my experience, I think it should NOT. That's why I suggest renaming it back to be the Activities board instead of being the Architecture board. Had I known what the IAB really is, I had never accepted the nomination, because I cannot do the kind of work the IAB does. I am a researcher and maybe an architect, and my ability to raise consensus when there are political or company undertones is nil or negative. Had the IAB name not contained the Architecture word, I might not have had those illusions I did. Now, this discussion does not belong to this list but to the IETF discuss list, if anywhere. The only reason why I send this message out is that I am still pretty annoyed by the IAB members claiming they are doing architectural work and, very understandably, not doing what I would call such work. So, a terminology issue perhaps, but unfortunately one that makes me quite emotional. --Pekka _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:53:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT42-0001fp-Gg; Thu, 23 Mar 2006 11:53:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT41-0001fk-Mw for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:53:33 -0500 Received: from [64.233.182.189] (helo=nproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMT40-000357-Dx for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:53:33 -0500 Received: by nproxy.gmail.com with SMTP id a27so296341nfc for ; Thu, 23 Mar 2006 08:53:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F0TQFlCmkdvj8IM4FpY8vIQKb9WhEksg1LSJuTArXVpvGLvRbxRss5b6MIR5YK+XK3VloGO9I+abDFihNE/BeMkAZ6JXezRZrYO+z9Lp9fi9QM1vWZIehymO05bRMNJ62181otmXU8ck3Dw4jHIwX5bd9G9CvTCf+HDIlkqXNH4= Received: by 10.48.207.20 with SMTP id e20mr575673nfg; Thu, 23 Mar 2006 08:53:30 -0800 (PST) Received: by 10.48.231.19 with HTTP; Thu, 23 Mar 2006 08:53:30 -0800 (PST) Message-ID: <84a612dd0603230853v2ecb5ed0qfe4144d82b7be0d0@mail.gmail.com> Date: Thu, 23 Mar 2006 16:53:30 +0000 From: "Mark Handley" To: "Bound, Jim" Subject: Re: [arch-d] Defining terms In-Reply-To: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 3/20/06, Bound, Jim wrote: > I think we should for a moment imagine a world without layer but as > modules. Really that is how the actual code is and not in layers. Sure > IP packet gets parsed before TCP, and TCP makes decisions before passing > data, as example here only, but is that layers or as Noel states > modules? I made one attempt to do this a few years ago with Role-Based Architecture: http://www.cs.ucl.ac.uk/staff/M.Handley/papers/rba-hotnets.ps The idea was not to layer functionality, but to address it to agents that performed specific roles. In this way, you could address boxes along the path (such as firewalls, etc) and in the end-systems without specifically knowing of their existence in advance. Is this the sort of thing you're thinking about? - Mark _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 11:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT6B-00036G-3u; Thu, 23 Mar 2006 11:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMT6A-00035F-4G for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:55:46 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMT66-0003Fs-PE for architecture-discuss@ietf.org; Thu, 23 Mar 2006 11:55:46 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 2DF3D340E9; Thu, 23 Mar 2006 11:55:42 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 11:55:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 11:55:38 -0500 Message-ID: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOlod8wVbusCN0T4O7N/s97pE+IgAA/OEA From: "Bound, Jim" To: "John Day" , "Noel Chiappa" , X-OriginalArrivalTime: 23 Mar 2006 16:55:42.0049 (UTC) FILETIME=[9EA9B510:01C64E9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, all opinions are important and there is no gospel for layers or architecture. I hear you but several of us who have lived this too simply don't agree. Noel is spot on. /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, March 23, 2006 9:25 AM > To: Noel Chiappa; architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Defining terms >=20 > At 21:15 -0500 2006/03/21, Noel Chiappa wrote: > > > From: John Day > > > > > Now of course, this collection of users can also=20 > cooperate to do > > > something and provide a black box to their users. > > > So now, if these are not layers what are they?=20 > pancakes? waffles? > > > I would contend that layers are a means of organizing=20 > functionality > > > >The problem with layers is that are a simplification of=20 > reality - and, > >moreover, a simplification that rapidly becomes stultifying=20 > and confusing. >=20 > Then you don't have the layers right. >=20 > >The reality of the subsystem/protocol dependency graph, in=20 > real networks, is > >too complex to be captured with the simple ordered layer model. > > > >As one example, look at BGP. It's used for passing around=20 > routing info - so > >it's part of the inter-network layer, right? Yes, but, it=20 > uses TCP. So it's >=20 > Is it? What is its scope? >=20 > >above the transport layer, right? "Does not compute! Does=20 > not compute!" Or >=20 > No. There is no rule that says a protocol and the layer it is used=20 > in are fixed. Protocols are means to providing certain kinds of=20 > coordination. I can use any protocol in any layer where it does what=20 > I need done. Sure it computes. >=20 > >what about those things that open a PPP link over a TCP=20 > connection? Similarly > >confusing. >=20 > Not in the least. In fact, they show a deep understanding of what=20 > network architecture is all about. >=20 > >What's really important, for a system architect, is the=20 > subsystem dependency > >graph. Anything which confuses that representation is=20 > non-optimal - and an > >ordered layer model definitely counts. >=20 > Yep. >=20 > > > >To put it another way, layers may a fine device for introducing basic > >networking concepts to beginning students, but they are=20 > really a bad idea for > >use by anyone past the level of "initial introduction". To=20 > mangle one of my > >favourite military axioms, "Beginners think in layers,=20 > everyone else thinks > >in subsystem dependency graphs." >=20 > Then you haven't gotten your layers organized right. When they are,=20 > they not only work but they do more things than we are currently=20 > doing and do them well and easily. >=20 > C'mon Noel, I know you better than this. Step back and look=20 > carefully. Use all of these as data. Consider what the data is=20 > telling us. >=20 > > > > > So we have a collection of things in different=20 > systems all cooperating > > > with some amount of shared state and doing it in some=20 > black box to hide > > > the complexity from the user of the black box. > > > >Right - and this touches on a point I like to rant about,=20 > which is that too > >often: In drawing block diagrams, people treat "the part of=20 > subsystem X in > >machine A and "the part of subsystem X in machine B" as more=20 > distantly > >related than "the part of subsystem X in machine A" and "the part of > >subsystem Y in machine A". In other words, they tend to draw=20 > diagrams in > >which the main boxes are machine A and machine B, with maybe=20 > little sub-boxes > >inside those boxes for subsystems X and Y. However, when=20 > you're trying to > >understand the subsystem dependency issues, this makes those=20 > dependencies > >much harder to see. The other kind of diagram, in which the=20 > main boxes are > >subsystems X, Y, etc are much rarer - alas. > > >=20 > Indeed they do. This (as you know) is usually to indicate the degree=20 > of coupling. modules in the same system are generally more tight=20 > coupled than those that are not. At the very least modules in the=20 > same system can coordinate with a test-and-set. >=20 > > > Although, if you *need* a boundary for some reason,=20 > some place a layer > > > boundary is a good place to do it, if you have chosen=20 > your layers > > > wisely. > > > >A layer boundary is, in many ways, just a subsystem=20 > interface definition. > > > >Of course, anytime you break a system up into subsystems,=20 > the issue of where > >you put the boundaries, and what info is passed across them=20 > - that is (to me) > >the heart of architecture. >=20 > Most definitely. >=20 > Take care, > John >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 12:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTsK-0004FS-CA; Thu, 23 Mar 2006 12:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTsJ-0004FN-Gz for architecture-discuss@ietf.org; Thu, 23 Mar 2006 12:45:31 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTsI-0005Tw-7T for architecture-discuss@ietf.org; Thu, 23 Mar 2006 12:45:31 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C6562E0435; Thu, 23 Mar 2006 12:45:27 -0500 (EST) Date: Thu, 23 Mar 2006 12:45:27 -0500 From: John Leslie To: "Bound, Jim" Subject: Re: [arch-d] Defining terms Message-ID: <20060323174527.GI11517@verdi> References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org, Noel Chiappa , John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: > To: "John Day" , > > John, all opinions are important and there is no gospel for layers or > architecture. I hear you but several of us who have lived this too > simply don't agree. We need to put _some_ effort into seeking consensus... > Noel is spot on. Umm... Noel really _isn't_ spot-on in his BGP example... >> At 21:15 -0500 2006/03/21, Noel Chiappa wrote: >> >>> As one example, look at BGP. It's used for passing around >>> routing info - so it's part of the inter-network layer, right? That really doesn't follow. BGP is a "routing" protocol, in the Routing Area sense. To Routing Area folks, "routing" is generating path information and passing _some_ of that path information toward forwarding engines. I don't mean to insult folks familiar with Routing Area terminology, but I expect some folks on this list aren't familiar with it. Recall, John Day sees three pieces called "routing": ] ] Actually, I would say routing is 3 distinct tasks: ] exchanging information about connectivity and other information, ] calculating connectivity based on what you have collected, ] and then choosing a next hop/path based on the calculation and ] the other info. and I don't think he even referred to the function I mentioned which many folks call "routing" but Routing Area folks call "forwarding": ] ]> passing packets to another router "closer" to the destination. (It doesn't help that even Routing Area folks use the term "router" to refer to a box which does "forwarding".) Of all of these, only the last, "forwarding", one in any sense deserves to be called "part of the inter-network layer". The others may or may not deserve to be called "necessary to" the inter- network area, but that would not make them "part of" it. Noel certainly knows that BGP is not "forwarding", even if every box he may have seen it implemented in also does forwarding ( I venture no guess as to whether that condition is true). What functions go in a box is engineering, not architecture. What functions are implemented in a box _cannot_ determine their architectural purpose. >>> Yes, but, it uses TCP. So it's above the transport layer, right? This statement at least makes sense. The BGP routing function can be considered "above" the transport layer. But we have no need to enter that argument. From an architectural standpoint, we should see "exchanging information about connectivity" as a network function which is out-of-band to the inter-network layer, and the rest of "routing" (in the Routing Area usage) as not network functions at all. >>> "Does not compute! Does not compute!" Repeating a statement doesn't make it true. John Day is right: >> No. There is no rule that says a protocol and the layer it is used >> in are fixed. Protocols are means to providing certain kinds of >> coordination. I can use any protocol in any layer where it does what >> I need done. Sure it computes. John Day and I are perhaps thinking from an academic standpoint. Noel may be thinking from an engineering standpoint (or not, YMMV). But all of us should be _trying_ to think from an architectural standpoint. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 14:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVXW-0005pp-9Z; Thu, 23 Mar 2006 14:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVXU-0005od-D1 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 14:32:08 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVVZ-00017J-Ta for architecture-discuss@ietf.org; Thu, 23 Mar 2006 14:30:14 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 73962340AB; Thu, 23 Mar 2006 14:30:13 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:30:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 14:30:01 -0500 Message-ID: <936A4045C332714F975800409DE092400206CCF6@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOnEgGzlzb5vJQQfyivlwbkFXHvwAE88aw From: "Bound, Jim" To: "John Day" , "Noel Chiappa" , X-OriginalArrivalTime: 23 Mar 2006 19:30:03.0491 (UTC) FILETIME=[2EE99B30:01C64EB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I don't think so John but lets go play mine is bigger than yours offline. 1978 at this end. offline /jim=20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, March 23, 2006 12:06 PM > To: Bound, Jim; John Day; Noel Chiappa; architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] Defining terms >=20 > At 11:55 -0500 2006/03/23, Bound, Jim wrote: > >John, all opinions are important and there is no gospel for layers or > >architecture. I hear you but several of us who have lived this too > >simply don't agree. Noel is spot on. > >/jim >=20 >=20 > Jim, I have been living with this far longer than you have. And it=20 > would appear spent far more time thinking about it. I sense that=20 > Noel is just discouraged. ;-) >=20 > As I pointed out the other day, you can argue it all you want. There=20 > is some sort of distributed black box involved here and there is no=20 > way to escape it. So you may as well learn to live with it.=20 > However, it is not clear that layers we came up with in the early 70s=20 > were in fact layers we should have. We hadn't seen much of the=20 > problem space then. Any more than the layers of an OS today follow=20 > the layers of Dijkstra's THE paper. >=20 > I contend there is a solution that recognizes layers, is simple,=20 > elegant and solves many problems. There is lots of data. As=20 > Kettering says, one must learn to listen to the problem. The=20 > statement of every problem contains its solutions. >=20 > Take care, > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 14:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVrF-0004pV-Bg; Thu, 23 Mar 2006 14:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVrE-0004pO-LQ for architecture-discuss@ietf.org; Thu, 23 Mar 2006 14:52:32 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVrB-0002H2-BF for architecture-discuss@ietf.org; Thu, 23 Mar 2006 14:52:32 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 0089C3408A; Thu, 23 Mar 2006 14:52:28 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:52:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 14:52:15 -0500 Message-ID: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOoZuZwUTd1ThcT2K0M0Ah+jNmkQAET6yg From: "Bound, Jim" To: "John Leslie" X-OriginalArrivalTime: 23 Mar 2006 19:52:19.0111 (UTC) FILETIME=[4B010B70:01C64EB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: John Day , architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Valid point but I took the BGP more as abstraction to define a layer called routing for discussion. IP model don't call out a routing layer. Forwarding is different than extraplation of routes and discovery clearly. More important to your mail yes we need to find consensus but only rough consensus to keep moving once that is achieved. But then we get to the running code part :--) /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Thursday, March 23, 2006 12:45 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org; Noel Chiappa; John Day > Subject: Re: [arch-d] Defining terms >=20 > Bound, Jim wrote: > > To: "John Day" , > >=20 > > John, all opinions are important and there is no gospel for=20 > layers or > > architecture. I hear you but several of us who have lived this too > > simply don't agree. >=20 > We need to put _some_ effort into seeking consensus... >=20 > > Noel is spot on. >=20 > Umm... Noel really _isn't_ spot-on in his BGP example... >=20 > >> At 21:15 -0500 2006/03/21, Noel Chiappa wrote: > >>=20 > >>> As one example, look at BGP. It's used for passing around > >>> routing info - so it's part of the inter-network layer, right? >=20 > That really doesn't follow. >=20 > BGP is a "routing" protocol, in the Routing Area sense. >=20 > To Routing Area folks, "routing" is generating path information and > passing _some_ of that path information toward forwarding engines. >=20 > I don't mean to insult folks familiar with Routing Area=20 > terminology, > but I expect some folks on this list aren't familiar with it. >=20 > Recall, John Day sees three pieces called "routing": > ]=20 > ] Actually, I would say routing is 3 distinct tasks: > ] exchanging information about connectivity and other information, > ] calculating connectivity based on what you have collected, > ] and then choosing a next hop/path based on the calculation and > ] the other info. >=20 > and I don't think he even referred to the function I mentioned which > many folks call "routing" but Routing Area folks call "forwarding": > ]=20 > ]> passing packets to another router "closer" to the destination. >=20 > (It doesn't help that even Routing Area folks use the term "router" > to refer to a box which does "forwarding".) >=20 > Of all of these, only the last, "forwarding", one in any sense > deserves to be called "part of the inter-network layer". The others > may or may not deserve to be called "necessary to" the inter- > network area, but that would not make them "part of" it. >=20 > Noel certainly knows that BGP is not "forwarding", even if every > box he may have seen it implemented in also does forwarding ( I > venture no guess as to whether that condition is true). >=20 > What functions go in a box is engineering, not architecture. > What functions are implemented in a box _cannot_ determine their > architectural purpose. >=20 > >>> Yes, but, it uses TCP. So it's above the transport layer, right? >=20 > This statement at least makes sense. The BGP routing function > can be considered "above" the transport layer. >=20 > But we have no need to enter that argument. From an architectural > standpoint, we should see "exchanging information about connectivity" > as a network function which is out-of-band to the inter-network layer, > and the rest of "routing" (in the Routing Area usage) as not network > functions at all. >=20 > >>> "Does not compute! Does not compute!" >=20 > Repeating a statement doesn't make it true. John Day is right: >=20 > >> No. There is no rule that says a protocol and the layer=20 > it is used=20 > >> in are fixed. Protocols are means to providing certain kinds of=20 > >> coordination. I can use any protocol in any layer where=20 > it does what=20 > >> I need done. Sure it computes. >=20 > John Day and I are perhaps thinking from an academic standpoint. > Noel may be thinking from an engineering standpoint (or not, YMMV). > But all of us should be _trying_ to think from an architectural > standpoint. >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 15:15:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWDg-0004lw-0R; Thu, 23 Mar 2006 15:15:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWDe-0004lr-MX for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:15:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWDc-0003j8-6s for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:15:42 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2006 12:15:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,123,1141632000"; d="scan'208"; a="24310416:sNHT24107732" 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 k2NKFdWe025632 for ; Thu, 23 Mar 2006 15:15:39 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 15:15:39 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 15:15:39 -0500 Date: Thu, 23 Mar 2006 14:15:11 -0600 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060323201507.GT5936@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <936A4045C332714F975800409DE0924001FD2362@tayexc14.americas.cpqcorp.net> <20060321234652.GD11517@verdi> <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060322021531.A4F5E86AFC@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 23 Mar 2006 20:15:39.0557 (UTC) FILETIME=[8DBC2550:01C64EB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Tue, Mar 21, 2006 09:15:31PM -0500, Noel Chiappa allegedly wrote: > As one example, look at BGP. It's used for passing around routing > info - so it's part of the inter-network layer, right? Yes, but, it > uses TCP. So it's above the transport layer, right? "Does not > compute! Does not compute!" Or what about those things that open a > PPP link over a TCP connection? Similarly confusing. There is a layer network which provides (at least) IP packet service. It can run over other layer networks (e.g. SDH). BGP is part of the control plane of this layer network, while the usual packet forwarding functions are in the forwarding plane. The transport functions which both packet forwarding and BGP take advantage of can be viewed as being in both planes -- they are functions, and functions can perform in multiple planes (and even multiple layer networks). Just because a BGP "session" takes advantage of the same forwarding functions as a forwarding plane capability does does not put BGP "in" or "above" anything in the forwarding plane. The planes are orthogonal. swb Lengthy Skippable Background Appendix: The layer network concept comes out of ITU-T SG15. Each layer network has its own identifier space for the points between which it moves data, and can include multiple classic OSI "layers". ATM provides a layer network, and can have 4 layers (more?). IP can have its own set of OSI layers and run over ATM. The following excerpt comes from http://www.niven-jenkins.co.uk/An%20introduction%20to%20functional%20architecture.pdf As noted in G.805, the term layer (or layer network) is used by both G.805, G.809 and X.200 when describing and decomposing a given layer network stack. However, layer networks defined using functional modelling (as described by G.805 and G.809) should not be confused with the layers of the OSI Model (ITU-T Recommendation X.200). Each layer in the OSI model can only offer a specific service and the protocols defined at each layer perform a specific function corresponding to that layer. For example the OSI transport layer (Layer 4) accepts data from the OSI session layer, and passes it onto the OSI network layer providing an end-to-end delivery service. In contrast, each layer network in a functional model based on G.805 or G.809 offers the equivalent services to OSI layers 1, 2 and 3 (although one or more of OSI layers 1, 2 or 3 maybe non-existent for some layer network technologies), in other words functional models based on G.805 and G.809 provide the transport of information (bits/frames) between inputs and outputs. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 15:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWFc-0006UB-6K; Thu, 23 Mar 2006 15:17:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWFa-0006P6-Gd for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:17:42 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWFZ-0003rg-9y for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:17:42 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2006 12:17:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,123,1141632000"; d="scan'208"; a="24311047:sNHT22022000" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2NKHfVU010537 for ; Thu, 23 Mar 2006 15:17:41 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 15:17:40 -0500 Received: from cisco.com ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 15:17:40 -0500 Date: Thu, 23 Mar 2006 14:17:04 -0600 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060323201704.GL4752@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 23 Mar 2006 20:17:40.0667 (UTC) FILETIME=[D5EC10B0:01C64EB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Thu, Mar 23, 2006 02:52:15PM -0500, Bound, Jim allegedly wrote: > Valid point but I took the BGP more as abstraction to define a layer > called routing for discussion. IP model don't call out a routing layer. > Forwarding is different than extraplation of routes and discovery > clearly. Planes are your friend. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 15:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWS5-00023p-CA; Thu, 23 Mar 2006 15:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWS3-00023j-8C for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:30:35 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMWS1-0004Kn-Tx for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:30:35 -0500 Received: (qmail 27195 invoked from network); 23 Mar 2006 20:28:13 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.4 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 23 Mar 2006 20:28:13 -0000 Received: from LIPC ([192.168.1.179]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 12:29:25 -0800 From: "Tony Li" To: "'John Leslie'" , "'Bound, Jim'" Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 12:29:21 -0800 Message-ID: <004801c64eb8$77f8c960$b301a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZOoZfKHw2tyCfFSPqC63L0XtIvKwAFf1Sw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <20060323174527.GI11517@verdi> X-OriginalArrivalTime: 23 Mar 2006 20:29:26.0153 (UTC) FILETIME=[7A6CAF90:01C64EB8] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'John Day' , architecture-discuss@ietf.org, 'Noel Chiappa' X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >>> Yes, but, it uses TCP. So it's above the transport layer, right? > > This statement at least makes sense. The BGP routing function > can be considered "above" the transport layer. > > But we have no need to enter that argument. From an architectural > standpoint, we should see "exchanging information about connectivity" > as a network function which is out-of-band to the inter-network layer, > and the rest of "routing" (in the Routing Area usage) as not network > functions at all. I think that we're having a bit of miscommunication here. At the risk of speaking for Noel... BGP is certainly part of the routing function. Within the conventional "layering" that is normally discussed, it is always placed within the internetworking layer, along with all of the rest of routing. The fact that BGP uses a transport protocol that actually exists at a higher layer is certainly a layering violation to those who are pedantic about layering. However, I suspect that Noel is not one of those people and is NOT defending the pedantic layerists. Quite the opposite: his point is that layering is an obsolete concept and adhering to it excludes an important and beneficial part of the architectural solution space. Good architecture is partitioning functionality into a loosely coupled DAG. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 15:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWW8-0003ZO-W5; Thu, 23 Mar 2006 15:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWW6-0003ZJ-W5 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:34:46 -0500 Received: from iceblock01.tropos.com ([12.108.168.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMWW5-0004W6-KD for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:34:46 -0500 Received: (qmail 27619 invoked from network); 23 Mar 2006 20:32:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.4 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 23 Mar 2006 20:32:25 -0000 Received: from LIPC ([192.168.1.179]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 12:33:38 -0800 From: "Tony Li" To: "'John Day'" , "'JFC \(Jefsey\) Morfin'" , Subject: RE: [arch-d] Defining terms Date: Thu, 23 Mar 2006 12:33:34 -0800 Message-ID: <004901c64eb9$0f44c800$b301a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZOlyjo+D26duQpRnypa4kvNWMj/AAIVokA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: X-OriginalArrivalTime: 23 Mar 2006 20:33:38.0469 (UTC) FILETIME=[10D10D50:01C64EB9] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > But I do have one question. If the Internet is the 3rd architecture, > what were the other 2? > > ARPANet and CYCLADES? Nit: The ARPANet was architecturally identical to the Internet that we know today. The only small changes that we've made are to replace some of the specific protocols in certain subsystems (i.e., EGP -> BGP) and some tweaks (e.g., subnetting). No significant architectural changes have been made since 1/1/83. My TIP for the day, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 16:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXiZ-0005dZ-W8; Thu, 23 Mar 2006 16:51:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXiZ-0005dU-B8 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 16:51:43 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMXiY-0008Qj-23 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 16:51:43 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2006 13:51:41 -0800 X-IronPort-AV: i="4.03,123,1141632000"; d="scan'208"; a="317291627:sNHT31186188" Received: from cisco.com (vaf-lnx1.cisco.com [171.71.142.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2NLpf7T020013; Thu, 23 Mar 2006 13:51:41 -0800 (PST) Received: from vaf-lnx1.cisco.com (vaf-lnx1 [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k2NLluYH000571; Thu, 23 Mar 2006 13:47:56 -0800 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.12.11/8.12.11/Submit) id k2NLlurC000569; Thu, 23 Mar 2006 13:47:56 -0800 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Thu, 23 Mar 2006 13:47:56 -0800 From: Vince Fuller To: tony.li@tony.li Subject: Re: [arch-d] Defining terms Message-ID: <20060323214756.GA452@vaf-lnx1.cisco.com> References: <004901c64eb9$0f44c800$b301a8c0@tropos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901c64eb9$0f44c800$b301a8c0@tropos.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > But I do have one question. If the Internet is the 3rd architecture, > > what were the other 2? > > > > ARPANet and CYCLADES? > > Nit: > > The ARPANet was architecturally identical to the Internet that we know > today. The only small changes that we've made are to replace some of > the specific protocols in certain subsystems (i.e., EGP -> BGP) and some > tweaks (e.g., subnetting). No significant architectural changes have > been made since 1/1/83. Not to disagree too strongly, especially with a nit, but that kind of depends on what you define as "the ARPANET". After 1/1/83, when the IP protocol suite was mandated on the ARPANET (and, imho, the "Internet" was born), the ARPANET became one subnet of it (the first "backbone network" as it were) and thus used the same architecture. Prior to 1/1/83, the ARPANET architecture was built on other protocols, such as NCP and X.25 transport, GGP and EGP routing protocols, etc., that were quite different than the IP suite. More fundamentally, the ARPANET was not a "network of networks". Other networks (such as CSNET, BITNET, et al) did have mail gateways to reach the ARPANET but there were no common transport or end-to-end inter-network communication. (yes, I have been doing this stuff way too long... veteran of the NCP-to-TCP transition with the scars to show for it... on 1/1/83, I ran the only TOPS-20 system that had both a DECNET DN20 and an ARPANET/NCP AN20; needless to say, the TCP/IP implementation was "not ready for prime time" and did not play well in such an environment... :-) --Vince _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 18:03:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYpr-0004bA-Cc; Thu, 23 Mar 2006 18:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYpp-0004b5-Q4 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 18:03:17 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYpo-00033o-Jb for architecture-discuss@ietf.org; Thu, 23 Mar 2006 18:03:17 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 47B2F86AEA; Thu, 23 Mar 2006 18:03:16 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Defining terms Message-Id: <20060323230316.47B2F86AEA@mercury.lcs.mit.edu> Date: Thu, 23 Mar 2006 18:03:16 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Tony Li" > The ARPANet was architecturally identical to the Internet that we know > today. Ah, no, at least for the classic ARPANET, which was significantly different. For one thing, the reliability (including timeouts and retransmissions) were the responsibility of the network, not the hosts. For another thing, the congestion control was also the responsibiity of the network - it could actually physically stop hosts from sending data (whether they wanted to stop or not) if the network became overloaded. There may be other really significant differences, but those are two, right off the top of my head. > No significant architectural changes have been made since 1/1/83. Well, yes and no - it all depends on how you define "significant". Things like VJCC are elaborations of algorithms within the existing framework, not changes thereto, and don't count. However, the addition of subnetting was an architectural change of some note, since it got hosts totally out of the business of understanding anything about addressing, other than the "on my network/not on my network" divide. Ditto for DiffServ, which by adding multiple forwarding queues, etc, changes the basic service model somewhat. Some of the security stuff might be classified as an architectural change, althogh I'd have to think about it, since we did have security stuff in the TCP stack before then. HIP, with its new namespace for end-end, probably counts as an architectural change, but it's not widely adopted. NAT, which is now extremely widely deployed, and without which the network could not survive, is certainly an architectural change (albeit an incredibly kludgy and bad one). The transition from GGP to the EGP/BGP group is an architectural change, because it breaks up the network into areas of discrete control, something which the GGP generation of stuff didn't provide. Etc, etc... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Mar 23 18:12:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYyS-00053r-Gm; Thu, 23 Mar 2006 18:12:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYyR-00053m-5Y for architecture-discuss@ietf.org; Thu, 23 Mar 2006 18:12:11 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYyP-0003PB-V0 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 18:12:11 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C7FB986AEA; Thu, 23 Mar 2006 18:12:09 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-Id: <20060323231209.C7FB986AEA@mercury.lcs.mit.edu> Date: Thu, 23 Mar 2006 18:12:09 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Vince Fuller > that kind of depends on what you define as "the ARPANET". Good point. > After 1/1/83, when the IP protocol suite was mandated on the ARPANET > (and, imho, the "Internet" was born) I would beg to differ with that date, because prior to 1/1/83 people were using the Internet for real services, e.g. mail and file transfer to various hosts connected to local area networks, hosts which had no ARPANet connection. However, it is certainly true that which date should be considered The Date is a matter of some dispute... > Prior to 1/1/83, the ARPANET architecture was built on other protocols, > such as NCP and X.25 transport, GGP and EGP routing protocols, etc., > that were quite different than the IP suite. Ah, GGP and EGP *were* IP protocols. The ARPANet itself used two generations of routing protocol, both completely hidden from the hosts, and implemented inside the BBN supplied IMP code. The first was a destination-vector design, and the second a link-state system; both had load-dependent functionality. Also, X.25 was just a host interface option; internally, it was supported by tweaks to the IMP-IMP protocols which were already there to support the 1822 Host-Host basic data carrying protocol. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 00:48:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMf9r-0006TI-3N; Fri, 24 Mar 2006 00:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMf9p-0006T5-Ik for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:48:21 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMf9m-0006IK-1J for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:48:21 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 935A834426; Fri, 24 Mar 2006 00:48:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 00:48:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 00:48:15 -0500 Message-ID: <936A4045C332714F975800409DE092400206CF7E@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOtXpVL33h1dz3SYq/Wfhxm3rdjgAT5FQw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 24 Mar 2006 05:48:17.0648 (UTC) FILETIME=[8CC0C700:01C64F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Thursday, March 23, 2006 3:08 PM > To: Bound, Jim; John Leslie > Cc: John Day; architecture-discuss@ietf.org; Noel Chiappa > Subject: RE: [arch-d] Defining terms >=20 > At 14:52 -0500 2006/03/23, Bound, Jim wrote: > >Valid point but I took the BGP more as abstraction to define a layer > >called routing for discussion. IP model don't call out a=20 > routing layer. > >Forwarding is different than extraplation of routes and discovery > >clearly. >=20 > But we are trying to *find* the right model. We can't let the fact=20 > that the IP model doesn't call out a routing layer affect our view.=20 I don't think that was being done it was a discussion regarding what is implemented in some cases today simply as part of the discussion. That in my view helps with what can be done tomorrow. > The IP model may be wrong, or not quite right. I for one have not on any mail made such a judgement. Making it better to me is the key objective. For me this is not about right or wrong. I don't like that we have lost the end-to-end model on the Internet. > It was assuming that=20 > it was right that got us where we are. We have to find what is really=20 > going on. Once we understand that, then we can worry about how to=20 > engineer it. Agreed but as I said above that is how I "perceived" the discussion and comment. >=20 > As you tell kids when they are doing their math homework: Don't skip=20 > steps. It will only get you in trouble. ;-) (Always hated it when my=20 > father told me that.) Agree and I think what is now is part of the steps at various points within the discussion. >=20 > > > >More important to your mail yes we need to find consensus=20 > but only rough > >consensus to keep moving once that is achieved. But then we=20 > get to the > >running code part :--) >=20 > Ahh, yes science by popularity. Wonder how often that has=20 > been the case. I cannot parse how you came up with science by popularity from my comment. If you beleive rough consensus is popularity then I guess that is a point. The alternative is elitism and that I find vulgar, and my view is kings should have heads chopped off :--), so support the rough consensus. I don't think you were speaking of running code as that is cleary important and has nothing to do with popularity, and more about proof of concept. =20 >=20 > rough consensus applies to electro-political engineering.=20 We can agree to disagree, but I am pretty sure this list and the IETF support and will continue to support rough consensus. > I didn't=20 > realize that was the domain of this discussion. I thought this was a=20 > more scientific inquiry. Science must follow the data regardless of=20 > how unpopular it may be. Well I could remind all Philosophy is the Mother of All Sciences, but I won't. Part of scientific inquiry is analysis, and part of analysis is discussion, censoring discussion to suit any one individuals needs is probably not going to happen in the IETF or in most forums I work in unless it is an elitist group and then I usually leave because I don't find that type of crowd very respectful to others and I don't deal well with disrespect nor put up with it as one human on the planet, we all have our limitations. Best, /jim >=20 > Take care, > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 00:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfAp-0006zw-5U; Fri, 24 Mar 2006 00:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfAn-0006zk-Ga for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:49:21 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMfAj-0006Jh-6Q for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:49:21 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 1922B3443D; Fri, 24 Mar 2006 00:49:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 00:49:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 00:49:13 -0500 Message-ID: <936A4045C332714F975800409DE092400206CF7F@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOtpSpMnjocQyoQT2lFRIVk9bZDQAUBNUg From: "Bound, Jim" To: "Scott W Brim" , X-OriginalArrivalTime: 24 Mar 2006 05:49:17.0148 (UTC) FILETIME=[B037C1C0:01C64F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Good analysis. /jim=20 > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com]=20 > Sent: Thursday, March 23, 2006 3:15 PM > To: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > On Tue, Mar 21, 2006 09:15:31PM -0500, Noel Chiappa allegedly wrote: > > As one example, look at BGP. It's used for passing around routing > > info - so it's part of the inter-network layer, right? Yes, but, it > > uses TCP. So it's above the transport layer, right? "Does not > > compute! Does not compute!" Or what about those things that open a > > PPP link over a TCP connection? Similarly confusing. >=20 > There is a layer network which provides (at least) IP packet service. > It can run over other layer networks (e.g. SDH). BGP is part of the > control plane of this layer network, while the usual packet forwarding > functions are in the forwarding plane. The transport functions which > both packet forwarding and BGP take advantage of can be viewed as > being in both planes -- they are functions, and functions can perform > in multiple planes (and even multiple layer networks). Just because a > BGP "session" takes advantage of the same forwarding functions as a > forwarding plane capability does does not put BGP "in" or "above" > anything in the forwarding plane. The planes are orthogonal. =20 >=20 > swb >=20 > Lengthy Skippable Background Appendix: The layer network concept comes > out of ITU-T SG15. Each layer network has its own identifier space > for the points between which it moves data, and can include multiple > classic OSI "layers". ATM provides a layer network, and can have 4 > layers (more?). IP can have its own set of OSI layers and run over > ATM. The following excerpt comes from > http://www.niven-jenkins.co.uk/An%20introduction%20to%20functi > onal%20architecture.pdf >=20 > As noted in G.805, the term layer (or layer network) is used by > both G.805, G.809 and X.200 when describing and decomposing a > given layer network stack. However, layer networks defined using > functional modelling (as described by G.805 and G.809) should not > be confused with the layers of the OSI Model (ITU-T Recommendation > X.200). Each layer in the OSI model can only offer a specific > service and the protocols defined at each layer perform a specific > function corresponding to that layer. For example the OSI > transport layer (Layer 4) accepts data from the OSI session layer, > and passes it onto the OSI network layer providing an end-to-end > delivery service. In contrast, each layer network in a functional > model based on G.805 or G.809 offers the equivalent services to > OSI layers 1, 2 and 3 (although one or more of OSI layers 1, 2 or > 3 maybe non-existent for some layer network technologies), in > other words functional models based on G.805 and G.809 provide the > transport of information (bits/frames) between inputs and outputs. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 00:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfB1-00074M-D7; Fri, 24 Mar 2006 00:49:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfB0-00074H-7z for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:49:34 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMfAv-0006Jw-V8 for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:49:34 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id D3C8934426; Fri, 24 Mar 2006 00:49:29 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 00:49:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 00:49:26 -0500 Message-ID: <936A4045C332714F975800409DE092400206CF80@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOttqJJI4O2dZVRqiGWrcpRBO6+gAT9gsA From: "Bound, Jim" To: "Scott W Brim" , X-OriginalArrivalTime: 24 Mar 2006 05:49:29.0929 (UTC) FILETIME=[B7D5FB90:01C64F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I agree. /jim=20 > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com]=20 > Sent: Thursday, March 23, 2006 3:17 PM > To: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > On Thu, Mar 23, 2006 02:52:15PM -0500, Bound, Jim allegedly wrote: > > Valid point but I took the BGP more as abstraction to define a layer > > called routing for discussion. IP model don't call out a=20 > routing layer. > > Forwarding is different than extraplation of routes and discovery > > clearly. >=20 > Planes are your friend. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 00:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfEi-0005yO-Ry; Fri, 24 Mar 2006 00:53:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfEh-0005yJ-2O for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:53:23 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMfEe-0006SQ-OG for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:53:23 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1ADFA340A9; Fri, 24 Mar 2006 00:53:21 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 00:53:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 00:53:17 -0500 Message-ID: <936A4045C332714F975800409DE092400206CF81@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOoZfKHw2tyCfFSPqC63L0XtIvKwAFf1SwABPPrxA= From: "Bound, Jim" To: , "John Leslie" X-OriginalArrivalTime: 24 Mar 2006 05:53:20.0164 (UTC) FILETIME=[41110E40:01C64F07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: John Day , architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org That is how I took it too. And I agree it will get in the way to think to strictly in terms of layers. Might be that at the physical and link layer to violate those layers (or planes I I like planes analysis too) for hardware processing reasons is not optimal, but there is research even looking at doing that now. See IEEE ETA paper I sent some time ago to the list. /jim=20 > -----Original Message----- > From: Tony Li [mailto:tli@tropos.com]=20 > Sent: Thursday, March 23, 2006 3:29 PM > To: 'John Leslie'; Bound, Jim > Cc: architecture-discuss@ietf.org; 'Noel Chiappa'; 'John Day' > Subject: RE: [arch-d] Defining terms >=20 > =20 >=20 > > >>> Yes, but, it uses TCP. So it's above the transport layer, right? > >=20 > > This statement at least makes sense. The BGP routing function > > can be considered "above" the transport layer. > >=20 > > But we have no need to enter that argument. From an architectural > > standpoint, we should see "exchanging information about=20 > connectivity" > > as a network function which is out-of-band to the=20 > inter-network layer, > > and the rest of "routing" (in the Routing Area usage) as not network > > functions at all. >=20 >=20 > I think that we're having a bit of miscommunication here. At the risk > of speaking for Noel... =20 >=20 > BGP is certainly part of the routing function. Within the=20 > conventional > "layering" that is normally discussed, it is always placed within the > internetworking layer, along with all of the rest of routing.=20 > The fact > that BGP uses a transport protocol that actually exists at a higher > layer is certainly a layering violation to those who are=20 > pedantic about > layering. >=20 > However, I suspect that Noel is not one of those people and is NOT > defending the pedantic layerists. Quite the opposite: his=20 > point is that > layering is an obsolete concept and adhering to it excludes=20 > an important > and beneficial part of the architectural solution space. Good > architecture is partitioning functionality into a loosely coupled DAG. >=20 > Tony >=20 >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 00:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfHp-0007N4-QT; Fri, 24 Mar 2006 00:56:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMfHo-0007Mz-6k for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:56:36 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMfHj-0006aA-RE for architecture-discuss@ietf.org; Fri, 24 Mar 2006 00:56:36 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id AE5543416A; Fri, 24 Mar 2006 00:56:33 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 00:56:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 00:56:29 -0500 Message-ID: <936A4045C332714F975800409DE092400206CF82@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZOzf++2tQaL13/SuGsTxZymjpdWwAOY4LA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 24 Mar 2006 05:56:31.0679 (UTC) FILETIME=[B337ECF0:01C64F07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This is good scientific inquiry to note the past from those that were there and important to the list for analysis. Thanks to all of you, /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, March 23, 2006 6:03 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] Defining terms >=20 > > From: "Tony Li" >=20 > > The ARPANet was architecturally identical to the=20 > Internet that we know > > today. >=20 > Ah, no, at least for the classic ARPANET, which was=20 > significantly different. >=20 > For one thing, the reliability (including timeouts and=20 > retransmissions) were > the responsibility of the network, not the hosts. For another=20 > thing, the > congestion control was also the responsibiity of the network=20 > - it could > actually physically stop hosts from sending data (whether=20 > they wanted to stop > or not) if the network became overloaded. >=20 > There may be other really significant differences, but those=20 > are two, right > off the top of my head. >=20 >=20 > > No significant architectural changes have been made=20 > since 1/1/83. >=20 > Well, yes and no - it all depends on how you define "significant". >=20 > Things like VJCC are elaborations of algorithms within the existing > framework, not changes thereto, and don't count. >=20 > However, the addition of subnetting was an architectural=20 > change of some note, > since it got hosts totally out of the business of=20 > understanding anything > about addressing, other than the "on my network/not on my=20 > network" divide. > Ditto for DiffServ, which by adding multiple forwarding=20 > queues, etc, changes > the basic service model somewhat. >=20 > Some of the security stuff might be classified as an=20 > architectural change, > althogh I'd have to think about it, since we did have=20 > security stuff in the > TCP stack before then. HIP, with its new namespace for=20 > end-end, probably > counts as an architectural change, but it's not widely adopted. >=20 > NAT, which is now extremely widely deployed, and without=20 > which the network > could not survive, is certainly an architectural change=20 > (albeit an incredibly > kludgy and bad one). >=20 > The transition from GGP to the EGP/BGP group is an=20 > architectural change, > because it breaks up the network into areas of discrete=20 > control, something > which the GGP generation of stuff didn't provide. >=20 > Etc, etc... >=20 > Noel >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 08:39:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmVK-0000g4-Ee; Fri, 24 Mar 2006 08:39:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMmVJ-0000fz-A5 for architecture-discuss@ietf.org; Fri, 24 Mar 2006 08:39:01 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMmVJ-0008BF-1L for architecture-discuss@ietf.org; Fri, 24 Mar 2006 08:39:01 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FMmVH-00077b-9m; Fri, 24 Mar 2006 05:38:59 -0800 Message-Id: <6.2.3.4.2.20060324133511.054d2ce0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 24 Mar 2006 14:26:13 +0100 To: John Day , From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-77F14237 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Further to my response to John Day on the three International Network technologies, I count Tymnet I and Tymnet II as a single architecture. They were however worlds apart. It seems from private comments received that a few still remember Tymnet, but only know the early days and Tymnet I. Tymnet I was an home made timesharing oriented system. It had been enhanced on experience. It was initially close to the Tymshare Operating System which supported network functions. Tymnet II was a totally different solution. It was built on ISIS - a network wide operating system managing Tymnet II machines. It offered backward compatibility to Tymnet I as a foriegn technology. It permitted a incredible architectural versatility and a quasi illimited ability to support different architectures and services. However much of the possbilities of Tymnet - alternative routing, daisy chaining, user's choice of the routing strategy, filtering, statistics, externets, virtual gateways, etc - depended on a centralised supervision. The system was reliable but not designed for datagrams (however it was [and the architecture still is] a leader in credit card transaction). Connectionless datagrams were fully implemented in Tymnet III, with many new additional features and services. This was (as far as my own epxerience goes) interrupted by the purchase of the Tymshare corporation and the progressive disbanding of the Tymnet management and R&D. The way Tymnet II was used internationally (national gateways and networks, multinational private networks) was very different from the domestic operations. This shown the huge capacities of the concepts. I never coded a Tymnet program, but the speed of the deliveries of new services and the experimented total lack of bugs (except some wrong parametering by field engineers) shows the high level of QA; and the relative programing simplicity insured by the ISIS architecture. This being said I have no experience of the Tymnet protocols and architectures when submitted to heavy traffic. However we supported stop-TV, compressed TV and compressed international phone links without degradation. Tymnet I was an access solution with proprietary high speed host to host services. Tymnet II was a full valued added virtual circuit switch multilateral system. Tymnet III was a fully distributed user-centric service-oriented fast, secure, sure, scalable architecture. I was actually an internal Tymnet technology user with complex needs (to address monopolies requirements, to implement extended services and to deploy the multinational services). Our initial demands permitted further on to swiftly and smartly address domestic security and load management issues. As a result we had the attention and the support of R&D. Snce then, I never read any new network technology proposition which would deliver as much as what Tymnet III would have delivered. However, past glory of a technology ignored by most is not the point. Neither the way its protocols worked. What is of interest is the experience of the services it delivered, and the public adopted. And the architecture which permitted it to be accepted by nearly one hundred sovereign or independent entities in a multilplicty of real/virtual network designs and changes.This to support the paying (on traffic/connect time basis) international users of a catenet counting millions of users and interconnecting all the existing technologies. Also to deploy three versions, two technlogies (its own one and OSI), two adressing systems (name space and numeric addressing - in a way similar to HIP), to introduce a third technology (Internet) within 10 years time. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 10:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo9G-0004XM-U3; Fri, 24 Mar 2006 10:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMo9F-0004XC-JI for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:24:21 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMo9C-0004Hl-6I for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:24:21 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A7E3534631; Fri, 24 Mar 2006 10:24:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 10:24:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Fri, 24 Mar 2006 10:24:15 -0500 Message-ID: <936A4045C332714F975800409DE092400206D14A@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZPVAR3x+7Bg2aiT2m9BjGLW7un7gAAgx3g From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 24 Mar 2006 15:24:17.0746 (UTC) FILETIME=[042D3B20:01C64F57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org No disagreements with the below I see your point better now. Thanks for taking time with the response. Yes I have looked at VJs new stuff and agree its not entirely a new idea or circular buffers, did not know that about Multics, and interesting. Also yes for verification running code can be lazy just to get proof of concept, I would suggest it is lazy evaulation of programming to see if stuff works. I don't write code anymore but I still read it occasionally. Speaking of changes. I had to review the Grid Globus Toolkit for day job and IPv6 Forum and pulled over entire 10 MB (at the time) source pool. I jumped into all the java, xml, et al. and I said oh my great-spirit I am glad I am not a programmer anymore :--) But I did find what I was looking for so it was useful exercise. thx /jim > -----Original Message----- > From: John Day [mailto:jeanjour@comcast.net]=20 > Sent: Friday, March 24, 2006 10:02 AM > To: Bound, Jim; John Day; John Leslie > Cc: architecture-discuss@ietf.org; Noel Chiappa > Subject: RE: [arch-d] Defining terms >=20 > At 0:48 -0500 2006/03/24, Bound, Jim wrote: > > > > > >> -----Original Message----- > >> From: John Day [mailto:jeanjour@comcast.net] > >> Sent: Thursday, March 23, 2006 3:08 PM > >> To: Bound, Jim; John Leslie > >> Cc: John Day; architecture-discuss@ietf.org; Noel Chiappa > >> Subject: RE: [arch-d] Defining terms > >> > >> At 14:52 -0500 2006/03/23, Bound, Jim wrote: > >> >Valid point but I took the BGP more as abstraction to=20 > define a layer > >> >called routing for discussion. IP model don't call out a > >> routing layer. > >> >Forwarding is different than extraplation of routes and discovery > >> >clearly. > >> > >> But we are trying to *find* the right model. We can't=20 > let the fact > >> that the IP model doesn't call out a routing layer affect=20 > our view. > > > >I don't think that was being done it was a discussion=20 > regarding what is > >implemented in some cases today simply as part of the=20 > discussion. That > >in my view helps with what can be done tomorrow. > > > >> The IP model may be wrong, or not quite right. > > > >I for one have not on any mail made such a judgement. =20 > Making it better > >to me is the key objective. For me this is not about right=20 > or wrong. I > >don't like that we have lost the end-to-end model on the Internet. >=20 > Well, right or wrong here is used to mean a good theory that fits the=20 > data and makes good predictions, i.e. when you try to do things=20 > hadn't thought about it helps rather than gets in the way. >=20 > We have lost the end-to-end model because we had half an addressing=20 > architecture. >=20 > To follow Alexis comment the other day, we basically have an=20 > unfinished demo on our hands. ;-) >=20 > > > It was assuming that > >> it was right that got us where we are. We have to find=20 > what is really > >> going on. Once we understand that, then we can worry about how to > >> engineer it. > > > >Agreed but as I said above that is how I "perceived" the=20 > discussion and > >comment. > > > >> > >> As you tell kids when they are doing their math homework:=20 > Don't skip > >> steps. It will only get you in trouble. ;-) (Always hated=20 > it when my > >> father told me that.) > > > >Agree and I think what is now is part of the steps at various points > >within the discussion. > > > >> > >> > > >> >More important to your mail yes we need to find consensus > >> but only rough > >> >consensus to keep moving once that is achieved. But then we > >> get to the > >> >running code part :--) > >> > >> Ahh, yes science by popularity. Wonder how often that has > >> been the case. > > > >I cannot parse how you came up with science by popularity from my > >comment. If you beleive rough consensus is popularity then I=20 > guess that > >is a point. The alternative is elitism and that I find=20 > vulgar, and my > >view is kings should have heads chopped off :--), so support=20 > the rough > >consensus. >=20 > Science is elitist, not democratic. It goes with evidence and proof.=20 > It is normally the case that what becomes the "right" answer was not=20 > a view held by the majority of scientists, let alone the majority of=20 > the population. In fact, it is almost expected that science shows=20 > that our intuitions about things are usually wrong. ;-) Damned=20 > embarrassing! >=20 > Now that said, all models/theories in science are working=20 > assumptions. None are True. Our job is always to try to prove them=20 > wrong. >=20 > >I don't think you were speaking of running code as that is cleary > >important and has nothing to do with popularity, and more=20 > about proof of > >concept. >=20 > Yea, no I wasn't. But running code has its concerns as well. Of=20 > course, it is good to ensure that it works and can be done. But I=20 > often worry that given natural laziness, it limits the range of=20 > implementation strategies that get tried. Have you seen Jacobsen's=20 > recent stuff on improving TCP that seems to indicate that everyone=20 > was just doing what Berkeley did which was pretty much what Multics=20 > did and it wasn't the best way? Also running code has the tendency=20 > to become the spec again limiting variety but these are nits. >=20 > > > > >> rough consensus applies to electro-political engineering. > > > >We can agree to disagree, but I am pretty sure this list and the IETF > >support and will continue to support rough consensus. >=20 > The problem in the IETF isn't rough consensus per se. All standards=20 > committees I have ever been in use it at the working group level.=20 > The problem in the IETF is that they have an organization without=20 > checks and balances on the individual. This doesn't mean that what=20 > comes out doesn't work, it means that the process is open to=20 > manipulation and is exploited. The dynamics of representative=20 > organizations should go on elsewhere. >=20 > > > I didn't > >> realize that was the domain of this discussion. I=20 > thought this was a > >> more scientific inquiry. Science must follow the data=20 > regardless of > >> how unpopular it may be. > > > >Well I could remind all Philosophy is the Mother of All=20 > Sciences, but I > >won't. Part of scientific inquiry is analysis, and part of=20 > analysis is > >discussion, censoring discussion to suit any one individuals needs is > >probably not going to happen in the IETF or in most forums I work in > >unless it is an elitist group and then I usually leave=20 > because I don't > >find that type of crowd very respectful to others and I=20 > don't deal well > >with disrespect nor put up with it as one human on the planet, we all > >have our limitations. >=20 > I think a tyranny of the majority is more likely. Often in science,=20 > the new idea is quite unpopular. Consider how long the idea that=20 > continents moved was around before the bulk of the community came to=20 > the idea. No, scientific inquiry is an odd bird. >=20 > Take care, > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 13:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrD4-0007EG-3l; Fri, 24 Mar 2006 13:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrD2-0007E6-9K for architecture-discuss@ietf.org; Fri, 24 Mar 2006 13:40:28 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMrD0-0005Yp-0X for architecture-discuss@ietf.org; Fri, 24 Mar 2006 13:40:28 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FMrCt-0002HZ-Ul; Fri, 24 Mar 2006 10:40:24 -0800 Message-Id: <6.2.3.4.2.20060324191451.078baeb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 24 Mar 2006 19:15:12 +0100 To: John Day , From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-77F14237; boundary="=======AVGMAIL-44243CF5235E=======" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.2 (/) X-Scan-Signature: aec2475b197ed9c8908117d8fbf9ee2e Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --=======AVGMAIL-44243CF5235E======= Content-Type: multipart/alternative; boundary="=====================_26206993==.ALT"; x-avg-checked=avg-ok-77F14237 --=====================_26206993==.ALT Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-77F14237 Content-Transfer-Encoding: 8bit At 15:37 23/03/2006, John Day wrote: >I completely agree with Jefsey on this. >But I do have one question. If the Internet is the 3rd >architecture, what were the other 2? >ARPANet and CYCLADES? This post is long. It could be the basis of a Draft if others joined to gather and report the passed experiences we could jointly table on. To be of use I thought necessary to introduce the answer with some references, including historic architectural experience. I tried to keep it limited to what I think of (key?) interest today. I tell what I saw/made. I took some decisions because I was in charge. I was not a geek but at a key position. I learned from that position. I only try here to pass what I learned, in the hope it may help. Until 1998 I only known "the Internet" from outside. If I am incorrect or if I miss infos, thanks to correct me. History is not an easy task. If people who shared into some of this, I would be glad to get their own inputs. Thanks. jfc Response: ARPANET and Cyclades were experimental networks which only developed locally. ARPANET in the USA and Cyclades at INRIA in France. You all know about ARPANET. Cyclades was conducted by Louis Pouzin. John Day pointed out some technical influences. From what I understand Louis Pouzin hired consulting services from ARPANET when he started the project in 1972, hence cross-polinization. I would like to underline I talked of the "International Network" and therefore of architectures of global deployment and operations. In that case the protocol becomes potentially global. But this is a consequence, not the root of the architecture. What counts first are the purpose and the basic concepts. To quote some concepts this community is familiar with: network concatenation, addressing, naming, routing, end-to-end, multitechnology, etc But there are others this community is not familiar with or has not commonly defined yet. This is where passed experience may help illustrating them, and understanding if they may serve the future. Louis Pouzin When considering a revamp of the network architecture, I think worth to spend lines on Louis Pouzin first. I wished to propose him for the ISOC award last year. He is the one who matches the best my own vision. Many supported the project, but Vint Cerf pointed out that his contribution was wider than the Internet, and not oriented towards the Internet community (the focus of this ISOC award, Vint created)- he proposed some other good ideas to pay Louis the tribute he deserves. The lack of knowledge of Louis' founding proposition may be our main problem today - missing the very conceptual roots of our technology. I first met Louis in 5/78. Vint wrote great things about him. We created together Eurolinc for a European Multilingual Internet (first Chair was Jean-Louis Grangé of his Cyclades team). He was quite active and influent at the WSIS. And an advisor of European and International instances. Louis invented the prompt, the script, the mail (developed by Tom Van Vleck), the datagram as it is today (IP windowing). In our today area obviously Louis' most important contribution is the "catenet" concept. Vint applied it in http://www.isi.edu/in-notes/ien/ien48.txt to introduce the Internet: "THE CATENET MODEL FOR INTERNETWORKING, July 1978, The Catenet Model for Internetworking - Introduction - The term "catenet" was introduced by L. Pouzin in 1974 in his early paper on packet network interconnection [1]. The U.S. DARPA research project on this subject has adopted the term to mean roughly "the collection of packet networks which are connected together.". Brian Carpenter Louis Pouzin's concepts were well understood by Brian Carpenter. He wrote a key consideration enlarging Vint's vision. I think important to quote it as I consider this text of IETF culture is the nearest from my own experience and vision. Even if Brian might dispute it. "When the catenet concept (a network of networks) was first described by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 1974 [CATENET], a clear assumption was that a single logical address space would cover the whole catenet (or Internet as we now know it). This applied not only to the early TCP/IP Internet, but also to the Xerox PUP design, the OSI connectionless network design, XNS, and numerous other proprietary network architectures. "This concept had two clear consequences - packets could flow essentially unaltered throughout the network, and their source and destination addresses could be used as unique labels for the end systems." "The first of these consequences is not absolute. In practice changes can be made to packets in transit. Some of these are reversible at the destination (such as fragmentation and compression). Others may be irreversible (such as changing type of service bits or decrementing a hop limit), but do not seriously obstruct the end-to-end principle of Section 2.1. However, any change made to a packet in transit that requires per-flow state information to be kept at an intermediate point would violate the fate-sharing aspect of the end-to-end principle." "The second consequence, using addresses as unique labels, was in a sense a side-effect of the catenet concept. However, it was a side-effect that came to be highly significant. The uniqueness and durability of addresses have been exploited in many ways, in particular by incorporating them in transport identifiers". We discuss the transition to new technologies. I said that an architectural transition was the interconnection of a new community of users. This text gives many clues from the very "inside" of the current internet on how to address this situation. Let me add that, from my brainware + user-centric + extended services (network services to the content) point of view, I read catenet as "the networks of the network of the networks" (cf. conclusion). IMHO this is the - long, long delayed - evolution of the architecture we need. Tymnet Now, I can address the question. The International Network really started a few years before Vint's IEN 48 proposition. Larry Roberts had created a commercial network service named Telenet, using BBN machines. They had applied to the FCC for a public operator licence. To force an FCC decision they threaten to sue those who operated a public packet switch service without a licence. There were two of them: Tymnet and Uninet. Tymnet had issued the first packet-switch service bill (we would name it an ISP today) on Feb, 28th, 1972. It was the affiliated network of Tymshare Inc., the third US timesharing service, with affiliates in UK, France, Belgium, Germany and Japan. At that time it offered domestic and international access to more than one hundred information databases, banks, corporations and specialised services. Its CEO, Bill Combs, and Tom O'Rourke, Tymshare Chair, found its was a good idea. They also applied for a licence. FCC gave both a temporary nationwide Value-Added-Network licence. Tymnet used names and addresses: FCC also gave Tymnet responsibility for the namespace. Tymnet negotiated interconnections - along with FCC and ITU rules - with the US International Record Carriers (first ITT, RCA and WUI) and to transfer its foreign users and services to the foreign monopolies. Bob Tréhin had to "sovereignise parts of an existing network" (1977). This was very much like what need to do today after, Tunis and China started with Chinese Names, without balkanising the Internet. He was assisted by Joe Rinde who designed the Tymnet core system. Bob introduced the "root name" principle (http://jefsey.com/rootname.pdf). This compartimented the network into "externets" ("external network look-alike, possibly within the same network, possibly through a virtual gateway" - the term came later on, when discussing Internet 'external networks' interconnects - RFC 920). When we met Louis Pouzin to hook Cyclades in 5/78, the International Network "catenated" already the French, British, German, Belgium, Swiss, Italian, Spanish, Dutch public externets. They had a local gateways, their own registry, their independent management, stats, accounting, etc. an interconnect (through Tymnet and the IRCs) to Telenet and Uninet networks. We also supported the ESA (European Space Agency) private net. ARPANET was indirectly connected in several places, including in Versailles for Ichbiah's development of ADA during the next year. The initial Tymnet I, architecture was replaced on the end of the 70s by Tymnet II and ISIS a networked OS offering huge possibilities. Tymnet from then on opened every new US international relation and most multinational relations until 1986. We operated 90% of the International traffic (foreign end) and 100% of the US international traffic. I opened the first foreign/foreign relation (Belgium/Netherlands) and hooked the first large Tymnet International private network (at Philips - where "com" and "net" where created and then pasted everywhere). Bob Tréhin implemented the Swedish Public Network, while Telenet built PSS the UK network. Germany then opened their Northern Telecom Datex-P. The French Transpac soon became the largest network in the world, quickly reaching one million users, and then 80% of the French people by mid-80s, with Minitel. We teamed with many for experimentation in the US and in Paris. Web like applications were developed using stop-TV, local TV, etc. Tymshare hired Doug Engelbart (I tried to implement his "Augment" solutions on my international new machines, but we found that networking "extends" services [and errors :-)], far far more than it "augments" people's IQ. The next generation systems we experimented included local proxy databases for image, text, etc. and content oriented extended services. Tymnet III was specified from this accumulated field proven experience. The Extended Network System model was worked on. I have not read yet a proposition which offered something which was not easy with Tymnet III, ISIS II and the new generation of Tymnet Engines under test. Tymnet having been purchased by McDonnell Douglas, we progressively disbanded. The status of the International Network, mainly under Tymnet technology, when the Internet was created is documented at http://intlnet.org/intlhist.htm . A service description is at http://intlnet.org/intl84.htm (my draft for the document we distributed). Tymnet brought the support of global communications from nil to millions of users. OSI Tymnet technology supported smart interfaces or services in the network nodes (named "slots"). Located at the "edge" as we would say today, they permitted to support any other technology (DECNET, SNA, SWIFT, OSI, etc ..). Along with one of the possibilities described in RFC 2775, it transmitted protocols metadata separately from data. Tymnet had introduced the virtual circuit concept [as a secure "pipe" - no spoofing permitted]: it was actually a reliable virtual circuit switch. It used internode multiplexed packets: offering impressive end to end keyboard echoing at no extra load/cost. There was a proportional decrease of the resulting overhead with the traffic load. Liaisons were fast and efficient (for the time). This permitted to translate protocols, and to provide TCP/IP-X.25 liaisons for example. The initial architecture was not datagram oriented (Tymnet was however intensively used for credit card transactions). The architectural evolution underway would have progressively lead to their full support, while keeping the speed, security and surety benefits. We therefore soon became the main (and quasi only) international implementors of OSI of the time. First X.25 and then X.75 once we had stabilised common parameters with PTTs through an operator/user club. We established X.75 real or virtual links to all the operators and X.25/PAD local support, operating a catalog of more than 40 X.25/75 brands. This lead me to create and deploy (with Dominique Marchand) the X.121 addressing scheme of all "our" countries externets - everyone but an handful. We treated them as numeric addresses, numbers or names, depending on the used architecture (OSI, Telephone/Teletext/Fax or Tymnet). Tymnet was later on purchased by BT and standardised to X.75. OSI brought the International Network to one hundred million users. Mostly in Europe and Japan. It supported Videotext, etc. Internet End 1983 the DoD asked Tymnet to interface the ARPANET Internet. This was for international connections, local virtual links to some Universities and remote public access and out-dial (Tymnet at that time had 500 access/out-dial (to private hosts/PC) nodes nationwide). We announced TCP/IP support in Dec. 83. The technical dialog was with our "Federal" office (probably until mid-84?). I supervised all the interconnects being responsible for International operations for naming and addressing compatibility. We had two main issues: naming and tunnelling (I made the mistake not to press for addressing, otherwise we would be IPv6 for a long). 1. the target was to provide a tunnel with Internet foreign communities (standard "virtual circuit" - or a "pipe") at better price than a dedicated line or/and as a back-up for dedicated lines. This was called "refilling". It was also to provide access to DoD and State Department personnel when travelling, and to Embassies. Refilling had been actively explored by Jack McDonnell (Chair of TNS Inc.) and was mostly used by private international telex operators (another architecture partly supported). For this reason, refilers were named after ISO 3166 Alpha2 [telex codes] (Public services registries were named after ISO 3166 Alpha3 [Radio codes]). This created the ccTLDs as documented in RFC 920. IP clusters were easily supported this way when introduced in 1986 - if I am correct - in Wien. The path was TCP/IP to the Gateway, Tymnet Protocol to the X.25/PAD service of Radio Austria 2. International naming was then left to right, one single string (root-name [TLD] + network-name [domain name] + local-name [3rd+LD]). This was less flexible than the right to left doted format. But it permitted a direct support of X.121 (DNIC+Numbers) and Out-dial (local telephone numbers). Internet was reluctant to change their inner naming to the international naming: the number of networks they had to concatenate was large, and this made the caller to decide the routing (via Internet or via a gateway when this was possible). So they came from "name" to "name.arpa" to train everyone. Then to "name.com" through the Gateway. We first only checked if there was a "." in the name to accept the call, reversing the order. But this created a problem with IP addresses. We asked that names would come from the Internet with a final dot ("dot-root") and checked it. We also decided that all numeric names would not be changed. Internet has now brought the International Network to one billion user. We now look for the approach which will rise usage to 10 billions people and stations. Some resulting experience Among other (this is just a rushed mail) I think this shows from experience: - the user is the decision maker. The QoS they get and the respect of the user (operator) needs/decision/interests makes the adherence and the decision. When we talk of market acceptance, we only say "if users think they get enough for their money". If they poorly understand a brilliant concept, it will not fly. What flies is are rustic, simple, secure solutions which works and people understand. In fact, the network is not what the designers designed, but what the users think/want it is. If both do not match, forget about it! - This is important because it means that the IAB/IETF is _not_ in charge of the future network (which should be backward compatible) and has the divine right to design it, based upon a TCP/IP+. It means that we all are in competition to deliver something appealing to the next generation people. There is no exclusive of situation. If I fought (and globally won) toughly the RFC 3066 Bis proposition to get a consensus I was denied and they now challenge, it was because it concerns the core of the Multilingual Generalised NGN (MGN). A proposition that people will _refuse_, killing the chances of any IETF new architecture proposition. - packet massaging on the plug to plug interoperability path is not a violation of the "end to end" concept, nor of the [more interesting to the user] brain to brain interintelligibility one. - we need to go one step further, accomplishing the whole catenet vision. o "the networks" is the hardware oriented infrastructure which supports the convergence. o "the network of the networks" is the software oriented superstructure we live with. o "the networks of the network of the networks" is the brainware oriented metastructure where the network architecture evolution has to deliver. etc. --=====================_26206993==.ALT Content-Type: text/html; charset=iso-8859-1; x-avg-checked=avg-ok-77F14237 Content-Transfer-Encoding: 8bit At 15:37 23/03/2006, John Day wrote:

I completely agree with Jefsey on this.
But I do have one question.  If the Internet is the 3rd architecture, what were the other 2?
ARPANet and CYCLADES?

This post is long. It could be the basis of a Draft if others joined to gather and report the passed experiences we could jointly table on.

To be of use I thought necessary to introduce the answer with some references, including historic architectural experience. I tried to keep it limited to what I think of (key?) interest today. I tell what I saw/made. I took some decisions because I was in charge. I was not a geek but at a key position. I learned from that position. I only try here to pass what I learned, in the hope it may help. Until 1998 I only known "the Internet" from outside. If I am incorrect or if I miss infos, thanks to correct me. History is not an easy task. If people who shared into some of this, I would be glad to get their own inputs. Thanks.

jfc

Response:

ARPANET and Cyclades were experimental networks which only developed locally. ARPANET in the USA and Cyclades at INRIA in France. You all know about ARPANET. Cyclades was conducted by Louis Pouzin. John Day pointed out some technical influences. From what I understand Louis Pouzin hired consulting services from ARPANET when he started the project in 1972, hence cross-polinization.

I would like to underline I talked of the "International Network" and therefore of architectures of global deployment and operations. In that case the protocol becomes potentially global. But this is a consequence, not the root of the architecture. What counts first are the purpose and the basic concepts. To quote some concepts this community is familiar with: network concatenation, addressing, naming, routing, end-to-end, multitechnology, etc  But there are others this community is not familiar with or has not commonly defined yet. This is where passed experience may help illustrating them, and understanding if they may serve the future. 


Louis Pouzin

When considering a revamp of the network architecture, I think worth to spend lines on Louis Pouzin first. I wished to propose him for the ISOC award last year. He is the one who matches the best my own vision. Many supported the project, but Vint Cerf pointed out that his contribution was wider than the Internet, and not oriented towards the Internet community (the focus of this ISOC award, Vint created)- he proposed some other good ideas to pay Louis the tribute he deserves. The lack of knowledge of Louis' founding proposition may be our main problem today - missing the very conceptual roots of our technology. I first met Louis in 5/78. Vint wrote great things about him. We created together Eurolinc for a European Multilingual Internet (first Chair was Jean-Louis Grangé of his Cyclades team). He was quite active and influent at the WSIS. And an advisor of European and International instances.

Louis invented the prompt, the script, the mail (developed by Tom Van Vleck), the datagram as it is today (IP windowing). In our today area obviously Louis' most important contribution is the "catenet" concept. Vint applied it in http://www.isi.edu/in-notes/ien/ien48.txt to introduce the  Internet: "THE CATENET MODEL FOR INTERNETWORKING, July 1978, The Catenet Model for Internetworking - Introduction - The term "catenet" was introduced by L. Pouzin in 1974 in his early paper on packet network interconnection [1].  The U.S. DARPA research project on this subject has adopted the term to mean roughly "the collection of packet networks which are connected together.".


Brian Carpenter

Louis Pouzin's concepts were well understood by Brian Carpenter. He wrote a key consideration enlarging Vint's vision. I think important to quote it as I consider this text of IETF culture is the nearest from my own experience and vision. Even if Brian might dispute it.

"When the catenet concept (a network of networks) was first described by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 1974 [CATENET], a clear assumption was that a single logical address space would cover the whole catenet (or Internet as we now know it). This applied not only to the early TCP/IP Internet, but also to the Xerox PUP design, the OSI connectionless network design, XNS, and numerous other proprietary network architectures.

"This concept had two clear consequences - packets could flow essentially unaltered throughout the network, and their source and destination addresses could be used as unique labels for the end systems."

"The first of these consequences is not absolute.  In practice changes can be made to packets in transit. Some of these are reversible at   the destination (such as fragmentation and compression). Others may be irreversible (such as changing type of service bits or decrementing a hop limit), but do not seriously obstruct the end-to-end principle of Section 2.1. However, any change made to a packet in transit that requires per-flow state information to be kept at an intermediate point would violate the fate-sharing aspect of the end-to-end principle."

"The second consequence, using addresses as unique labels, was in a sense a side-effect of the catenet concept. However, it was a side-effect that came to be highly significant. The uniqueness and durability of addresses have been exploited in many ways, in particular by incorporating them in transport identifiers".

We discuss the transition to new technologies. I said that an architectural transition was the interconnection of a new community of users. This text gives many clues from the very "inside" of the current internet on how to address this situation. Let me add that, from my brainware + user-centric + extended services (network services to the content) point of view, I read catenet as "the networks of the network of the networks" (cf. conclusion). IMHO this is the - long, long delayed - evolution of the architecture we need.


Tymnet

Now, I can address the question. The International Network really started a few years before Vint's IEN 48 proposition. Larry Roberts had created a commercial network service named Telenet, using BBN machines. They had applied to the FCC for a public operator licence. To force an FCC decision they threaten to sue those who operated a public packet switch service without a licence. There were two of them: Tymnet and Uninet.

Tymnet had issued the first packet-switch service bill (we would name it an ISP today) on Feb, 28th, 1972. It was the affiliated network of Tymshare Inc., the third US timesharing service, with affiliates in UK, France, Belgium, Germany and Japan. At that time it offered domestic and international access to more than one hundred information databases, banks, corporations and specialised services. Its CEO, Bill Combs, and Tom O'Rourke, Tymshare Chair, found its was a good idea. They also applied for a licence. FCC gave both a temporary nationwide Value-Added-Network licence. Tymnet used names and addresses: FCC also gave Tymnet responsibility for the namespace. Tymnet negotiated interconnections - along with FCC and ITU rules - with the US International Record Carriers (first ITT, RCA and WUI) and to transfer its foreign users and services to the foreign monopolies.

Bob Tréhin had to "sovereignise parts of an existing network" (1977). This was very much like what need to do today after, Tunis and China started with Chinese Names, without balkanising the Internet. He was assisted by Joe Rinde who designed the Tymnet core system. Bob introduced the "root name" principle ( http://jefsey.com/rootname.pdf). This compartimented the network into "externets" ("external network look-alike, possibly within the same network, possibly through a virtual gateway" - the term came later on, when discussing Internet 'external networks' interconnects - RFC 920). When we met Louis Pouzin to hook Cyclades in 5/78, the International Network "catenated" already the French, British, German, Belgium, Swiss, Italian, Spanish, Dutch public externets. They had a local gateways, their own registry, their independent management, stats, accounting, etc. an interconnect (through Tymnet and the IRCs) to Telenet and Uninet networks. We also supported the ESA (European Space Agency) private net. ARPANET was indirectly connected in several places, including in Versailles for Ichbiah's development of ADA during the next year.

The initial Tymnet I, architecture was replaced on the end of the 70s by Tymnet II and ISIS a networked OS offering huge possibilities. Tymnet from then on opened every new US international relation and most multinational relations until 1986. We operated 90% of the International traffic (foreign end) and 100% of the US international traffic. I opened the first foreign/foreign relation (Belgium/Netherlands) and hooked the first large Tymnet International private network (at Philips - where "com" and "net" where created and then pasted everywhere). Bob Tréhin implemented the Swedish Public Network, while Telenet built PSS the UK network. Germany then opened their Northern Telecom Datex-P. The French Transpac soon became the largest network in the world, quickly reaching one million users, and then 80% of the French people by mid-80s, with Minitel. We teamed with many for experimentation in the US and in Paris. Web like applications were developed using stop-TV, local TV, etc. Tymshare hired Doug Engelbart (I tried to implement his "Augment" solutions on my international new machines, but we found that networking "extends" services [and errors :-)], far far more than it "augments" people's IQ. The next generation systems we experimented included local proxy databases for image, text, etc. and content oriented extended services.

Tymnet III was specified from this accumulated field proven experience. The Extended Network System model was worked on. I have not  read yet a proposition which offered something which was not easy with Tymnet III, ISIS II and the new generation of Tymnet Engines under test. Tymnet having been purchased by McDonnell Douglas, we progressively disbanded. The status of the International Network, mainly under Tymnet technology, when the Internet was created is documented at http://intlnet.org/intlhist.htm . A service description is at http://intlnet.org/intl84.htm (my draft for the document we distributed). Tymnet brought the support of global communications from nil to millions of users.


OSI

Tymnet technology supported smart interfaces or services in the network nodes (named "slots"). Located at the "edge" as we would say today, they permitted to support any other technology (DECNET, SNA, SWIFT, OSI, etc ..). Along with one of the possibilities described in RFC 2775, it transmitted protocols metadata separately from data. Tymnet had introduced the virtual circuit concept [as a secure "pipe" - no spoofing permitted]: it was actually a reliable virtual circuit switch. It used internode multiplexed packets: offering impressive end to end  keyboard echoing at no extra load/cost. There was a proportional decrease of the resulting overhead with the traffic load. Liaisons were fast and efficient (for the time). This permitted to translate protocols, and to provide TCP/IP-X.25 liaisons for example. The initial architecture was not datagram oriented (Tymnet was however intensively used for credit card transactions). The architectural evolution underway would have progressively lead to their full support, while keeping the speed, security and surety benefits.

We therefore soon became the main (and quasi only) international implementors of OSI of the time. First X.25 and then X.75 once we had stabilised common parameters with PTTs through an operator/user club. We established X.75 real or virtual links to all the operators and X.25/PAD local support, operating a catalog of more than 40 X.25/75 brands. This lead me to create and deploy (with Dominique Marchand) the X.121 addressing scheme of all "our" countries externets - everyone but an handful. We treated them as numeric addresses, numbers or names, depending on the used architecture (OSI, Telephone/Teletext/Fax  or Tymnet).

Tymnet was later on purchased by BT and standardised to X.75. OSI brought the International Network to one hundred million users. Mostly in Europe and Japan. It supported Videotext, etc.


Internet

End 1983 the DoD asked Tymnet to interface the ARPANET Internet. This was for international connections, local virtual links to some Universities and remote public access and out-dial (Tymnet at that time had 500 access/out-dial (to private hosts/PC) nodes nationwide). We announced TCP/IP support in Dec. 83. The technical dialog was with our "Federal" office (probably until mid-84?). I supervised all the interconnects being responsible for International operations for naming and addressing compatibility.

We had two main issues: naming and tunnelling (I made the mistake not to press for addressing, otherwise we would be IPv6 for a long).

1. the target was to provide a tunnel with Internet foreign communities (standard "virtual circuit" - or a "pipe") at better price than a dedicated line or/and as a back-up for dedicated lines. This was called "refilling". It was also to provide access to DoD and State Department personnel when travelling, and to Embassies. Refilling had been actively explored by Jack McDonnell (Chair of TNS Inc.) and was mostly used by private international telex operators (another architecture partly supported). For this reason, refilers were named after ISO 3166 Alpha2 [telex codes] (Public services registries were named after ISO 3166 Alpha3 [Radio codes]). This created the ccTLDs as documented in RFC 920.

IP clusters were easily supported this way when introduced in 1986 - if I am correct - in Wien. The path was TCP/IP to the Gateway, Tymnet Protocol to the X.25/PAD service of Radio Austria

2. International naming was then left to right, one single string (root-name [TLD] + network-name [domain name] + local-name [3rd+LD]). This was less flexible than the right to left doted format. But it permitted a direct support of X.121 (DNIC+Numbers) and Out-dial (local telephone numbers). Internet was reluctant to change their inner naming to the international naming: the  number of networks they had to concatenate was large, and this made the caller to decide the routing (via Internet or via a gateway when this was possible). So they came from "name" to "name.arpa" to train everyone. Then to "name.com" through the Gateway. We first only checked if there was a "." in the name to accept the call, reversing the order. But this created a problem with IP addresses. We asked that names would come from the Internet with a final dot ("dot-root") and checked it. We also decided that all numeric names would not be changed.

Internet has now brought the International Network to one billion user. We now look for the approach which will rise usage to 10 billions people and stations.


Some resulting experience

Among other (this is just a rushed mail) I think this shows from experience:

- the user is the decision maker. The QoS they get and the respect of the user (operator) needs/decision/interests makes the adherence and the decision. When we talk of market acceptance, we only say "if users think they get enough for their money". If they poorly understand a brilliant concept, it will not fly. What flies is are rustic, simple, secure solutions which works and people understand. In fact, the network is not what the designers designed, but what the users think/want it is. If both do not match, forget about it!

- This is important because it means that the IAB/IETF is _not_ in charge of the future network (which should be backward compatible) and has the divine right to design it, based upon a TCP/IP+. It means that we all are in competition to deliver something appealing to the next generation people. There is no exclusive of situation. If I fought (and globally won) toughly the RFC 3066 Bis proposition to get a consensus I was denied and they now challenge, it was because it concerns the core of the Multilingual Generalised NGN (MGN). A proposition that people will _refuse_, killing the chances of any IETF new architecture proposition.

- packet massaging on the plug to plug interoperability path is not a violation of the "end to end" concept, nor of the [more interesting to the user] brain to brain interintelligibility one.

- we need to go one step further, accomplishing the whole catenet vision.
  o "the networks" is the hardware oriented infrastructure which supports the convergence.
  o "the network of the networks" is the software oriented superstructure we live with.
  o "the networks of the network of the networks" is the brainware oriented metastructure where the network architecture evolution has to deliver.

etc.

--=====================_26206993==.ALT-- --=======AVGMAIL-44243CF5235E======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --=======AVGMAIL-44243CF5235E=======-- From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuaf-0002S9-HB; Fri, 24 Mar 2006 17:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWkh-0001bf-OD for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:49:51 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWkf-0004wb-G7 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:49:51 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060323204934m13005mviee>; Thu, 23 Mar 2006 20:49:45 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <004901c64eb9$0f44c800$b301a8c0@tropos.com> References: <004901c64eb9$0f44c800$b301a8c0@tropos.com> Date: Thu, 23 Mar 2006 15:48:46 -0500 To: , "'John Day'" , "'JFC \(Jefsey\) Morfin'" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:33 -0800 2006/03/23, Tony Li wrote: > > >> But I do have one question. If the Internet is the 3rd architecture, >> what were the other 2? >> >> ARPANet and CYCLADES? > >Nit: > >The ARPANet was architecturally identical to the Internet that we know >today. The only small changes that we've made are to replace some of >the specific protocols in certain subsystems (i.e., EGP -> BGP) and some >tweaks (e.g., subnetting). No significant architectural changes have >been made since 1/1/83. Actually, it wasn't. The ARPANet had more in common with X.25 until Type 3 messages were defined. And even then most of the time Type 3 wasn't used. The Internet made the big shift to pure connectionless. By 75 or so, I think we had all mentally adopted the model that was completely in place by 83, but it took until 83 for it to be a reality. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuag-0002SJ-Rn; Fri, 24 Mar 2006 17:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoAg-0007sa-El for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:25:50 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoAe-0004L0-7S for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:25:50 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <20060324152542012007jh2ke>; Fri, 24 Mar 2006 15:25:47 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060323201704.GL4752@sbrim-wxp01> References: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> <20060323201704.GL4752@sbrim-wxp01> Date: Fri, 24 Mar 2006 10:22:38 -0500 To: Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:17 -0600 2006/03/23, Scott W Brim wrote: >On Thu, Mar 23, 2006 02:52:15PM -0500, Bound, Jim allegedly wrote: >> Valid point but I took the BGP more as abstraction to define a layer >> called routing for discussion. IP model don't call out a routing layer. >> Forwarding is different than extraplation of routes and discovery >> clearly. > >Planes are your friend. ;-) Good one. You know, I have to admit that planes make me uncomfortable. Perhaps it is just a knee-jerk reaction because they come from the telephony "beads-on-a-string" model of the world. They do describe where this stuff sits in one sense. But I have to admit adopting "beads-on-a-string" concepts makes me nervous, given the models that have come out of that tradition. Perhaps it is just too many years in the debate over connection and connectionless. It does have more the feel of natural history than science. (Robert MacArther, a biologist, contrasted natural history as describing what is there, whereas science makes predictions.) I get the feeling that planes have the same property. Some of us who were involved in the old ARPANet always felt that part of the reason it was so successful was because it was done by OS guys not telecom guys. And I have to admit, I have had more success working through problems by going back to OS ideas and metaphors than anything else. Is it more than just different ways to draw the same picture? Probably not. But the OS model tends to make predictions that I don't find with planes or "beads-on-a-string." Perhaps we should give that some consideration. It certainly has served us well over the years. Take care, John A postscript on CO/CL. I do believe that both are necessary. My own characterization is that connectionless is preferred when traffic density is low and more stochastic. Connections when traffic density is high and more deterministic. This would seem to imply that traffic is more connectionless toward the edge and more connection like toward the backbone. (This is assuming all other things being equal, i.e. error and flow control are not a concern. When would you choose co vs cl purely for its own properties. And of course, this is not an iron-clad rule just a general characterization.) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuag-0002SE-Ly; Fri, 24 Mar 2006 17:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnoJ-0000I5-IZ for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:02:43 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMnoJ-00038j-91 for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:02:43 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060324150237011002vf1se>; Fri, 24 Mar 2006 15:02:37 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206CF7E@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206CF7E@tayexc14.americas.cpqcorp.net> Date: Fri, 24 Mar 2006 10:02:27 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 0:48 -0500 2006/03/24, Bound, Jim wrote: > > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Thursday, March 23, 2006 3:08 PM >> To: Bound, Jim; John Leslie >> Cc: John Day; architecture-discuss@ietf.org; Noel Chiappa >> Subject: RE: [arch-d] Defining terms >> >> At 14:52 -0500 2006/03/23, Bound, Jim wrote: >> >Valid point but I took the BGP more as abstraction to define a layer >> >called routing for discussion. IP model don't call out a >> routing layer. >> >Forwarding is different than extraplation of routes and discovery >> >clearly. >> >> But we are trying to *find* the right model. We can't let the fact >> that the IP model doesn't call out a routing layer affect our view. > >I don't think that was being done it was a discussion regarding what is >implemented in some cases today simply as part of the discussion. That >in my view helps with what can be done tomorrow. > >> The IP model may be wrong, or not quite right. > >I for one have not on any mail made such a judgement. Making it better >to me is the key objective. For me this is not about right or wrong. I >don't like that we have lost the end-to-end model on the Internet. Well, right or wrong here is used to mean a good theory that fits the data and makes good predictions, i.e. when you try to do things hadn't thought about it helps rather than gets in the way. We have lost the end-to-end model because we had half an addressing architecture. To follow Alexis comment the other day, we basically have an unfinished demo on our hands. ;-) > > It was assuming that >> it was right that got us where we are. We have to find what is really >> going on. Once we understand that, then we can worry about how to >> engineer it. > >Agreed but as I said above that is how I "perceived" the discussion and >comment. > >> >> As you tell kids when they are doing their math homework: Don't skip >> steps. It will only get you in trouble. ;-) (Always hated it when my >> father told me that.) > >Agree and I think what is now is part of the steps at various points >within the discussion. > >> >> > >> >More important to your mail yes we need to find consensus >> but only rough >> >consensus to keep moving once that is achieved. But then we >> get to the >> >running code part :--) >> >> Ahh, yes science by popularity. Wonder how often that has >> been the case. > >I cannot parse how you came up with science by popularity from my >comment. If you beleive rough consensus is popularity then I guess that >is a point. The alternative is elitism and that I find vulgar, and my >view is kings should have heads chopped off :--), so support the rough >consensus. Science is elitist, not democratic. It goes with evidence and proof. It is normally the case that what becomes the "right" answer was not a view held by the majority of scientists, let alone the majority of the population. In fact, it is almost expected that science shows that our intuitions about things are usually wrong. ;-) Damned embarrassing! Now that said, all models/theories in science are working assumptions. None are True. Our job is always to try to prove them wrong. >I don't think you were speaking of running code as that is cleary >important and has nothing to do with popularity, and more about proof of >concept. Yea, no I wasn't. But running code has its concerns as well. Of course, it is good to ensure that it works and can be done. But I often worry that given natural laziness, it limits the range of implementation strategies that get tried. Have you seen Jacobsen's recent stuff on improving TCP that seems to indicate that everyone was just doing what Berkeley did which was pretty much what Multics did and it wasn't the best way? Also running code has the tendency to become the spec again limiting variety but these are nits. > > >> rough consensus applies to electro-political engineering. > >We can agree to disagree, but I am pretty sure this list and the IETF >support and will continue to support rough consensus. The problem in the IETF isn't rough consensus per se. All standards committees I have ever been in use it at the working group level. The problem in the IETF is that they have an organization without checks and balances on the individual. This doesn't mean that what comes out doesn't work, it means that the process is open to manipulation and is exploited. The dynamics of representative organizations should go on elsewhere. > > I didn't >> realize that was the domain of this discussion. I thought this was a >> more scientific inquiry. Science must follow the data regardless of >> how unpopular it may be. > >Well I could remind all Philosophy is the Mother of All Sciences, but I >won't. Part of scientific inquiry is analysis, and part of analysis is >discussion, censoring discussion to suit any one individuals needs is >probably not going to happen in the IETF or in most forums I work in >unless it is an elitist group and then I usually leave because I don't >find that type of crowd very respectful to others and I don't deal well >with disrespect nor put up with it as one human on the planet, we all >have our limitations. I think a tyranny of the majority is more likely. Often in science, the new idea is quite unpopular. Consider how long the idea that continents moved was around before the bulk of the community came to the idea. No, scientific inquiry is an odd bird. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuaf-0002S9-HB; Fri, 24 Mar 2006 17:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWkh-0001bf-OD for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:49:51 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWkf-0004wb-G7 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:49:51 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060323204934m13005mviee>; Thu, 23 Mar 2006 20:49:45 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <004901c64eb9$0f44c800$b301a8c0@tropos.com> References: <004901c64eb9$0f44c800$b301a8c0@tropos.com> Date: Thu, 23 Mar 2006 15:48:46 -0500 To: , "'John Day'" , "'JFC \(Jefsey\) Morfin'" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:33 -0800 2006/03/23, Tony Li wrote: > > >> But I do have one question. If the Internet is the 3rd architecture, >> what were the other 2? >> >> ARPANet and CYCLADES? > >Nit: > >The ARPANet was architecturally identical to the Internet that we know >today. The only small changes that we've made are to replace some of >the specific protocols in certain subsystems (i.e., EGP -> BGP) and some >tweaks (e.g., subnetting). No significant architectural changes have >been made since 1/1/83. Actually, it wasn't. The ARPANet had more in common with X.25 until Type 3 messages were defined. And even then most of the time Type 3 wasn't used. The Internet made the big shift to pure connectionless. By 75 or so, I think we had all mentally adopted the model that was completely in place by 83, but it took until 83 for it to be a reality. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuag-0002SJ-Rn; Fri, 24 Mar 2006 17:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoAg-0007sa-El for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:25:50 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoAe-0004L0-7S for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:25:50 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc12) with ESMTP id <20060324152542012007jh2ke>; Fri, 24 Mar 2006 15:25:47 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060323201704.GL4752@sbrim-wxp01> References: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> <20060323201704.GL4752@sbrim-wxp01> Date: Fri, 24 Mar 2006 10:22:38 -0500 To: Scott W Brim , architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:17 -0600 2006/03/23, Scott W Brim wrote: >On Thu, Mar 23, 2006 02:52:15PM -0500, Bound, Jim allegedly wrote: >> Valid point but I took the BGP more as abstraction to define a layer >> called routing for discussion. IP model don't call out a routing layer. >> Forwarding is different than extraplation of routes and discovery >> clearly. > >Planes are your friend. ;-) Good one. You know, I have to admit that planes make me uncomfortable. Perhaps it is just a knee-jerk reaction because they come from the telephony "beads-on-a-string" model of the world. They do describe where this stuff sits in one sense. But I have to admit adopting "beads-on-a-string" concepts makes me nervous, given the models that have come out of that tradition. Perhaps it is just too many years in the debate over connection and connectionless. It does have more the feel of natural history than science. (Robert MacArther, a biologist, contrasted natural history as describing what is there, whereas science makes predictions.) I get the feeling that planes have the same property. Some of us who were involved in the old ARPANet always felt that part of the reason it was so successful was because it was done by OS guys not telecom guys. And I have to admit, I have had more success working through problems by going back to OS ideas and metaphors than anything else. Is it more than just different ways to draw the same picture? Probably not. But the OS model tends to make predictions that I don't find with planes or "beads-on-a-string." Perhaps we should give that some consideration. It certainly has served us well over the years. Take care, John A postscript on CO/CL. I do believe that both are necessary. My own characterization is that connectionless is preferred when traffic density is low and more stochastic. Connections when traffic density is high and more deterministic. This would seem to imply that traffic is more connectionless toward the edge and more connection like toward the backbone. (This is assuming all other things being equal, i.e. error and flow control are not a concern. When would you choose co vs cl purely for its own properties. And of course, this is not an iron-clad rule just a general characterization.) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuag-0002SE-Ly; Fri, 24 Mar 2006 17:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMnoJ-0000I5-IZ for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:02:43 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMnoJ-00038j-91 for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:02:43 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc11) with ESMTP id <20060324150237011002vf1se>; Fri, 24 Mar 2006 15:02:37 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206CF7E@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206CF7E@tayexc14.americas.cpqcorp.net> Date: Fri, 24 Mar 2006 10:02:27 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 0:48 -0500 2006/03/24, Bound, Jim wrote: > > >> -----Original Message----- >> From: John Day [mailto:jeanjour@comcast.net] >> Sent: Thursday, March 23, 2006 3:08 PM >> To: Bound, Jim; John Leslie >> Cc: John Day; architecture-discuss@ietf.org; Noel Chiappa >> Subject: RE: [arch-d] Defining terms >> >> At 14:52 -0500 2006/03/23, Bound, Jim wrote: >> >Valid point but I took the BGP more as abstraction to define a layer >> >called routing for discussion. IP model don't call out a >> routing layer. >> >Forwarding is different than extraplation of routes and discovery >> >clearly. >> >> But we are trying to *find* the right model. We can't let the fact >> that the IP model doesn't call out a routing layer affect our view. > >I don't think that was being done it was a discussion regarding what is >implemented in some cases today simply as part of the discussion. That >in my view helps with what can be done tomorrow. > >> The IP model may be wrong, or not quite right. > >I for one have not on any mail made such a judgement. Making it better >to me is the key objective. For me this is not about right or wrong. I >don't like that we have lost the end-to-end model on the Internet. Well, right or wrong here is used to mean a good theory that fits the data and makes good predictions, i.e. when you try to do things hadn't thought about it helps rather than gets in the way. We have lost the end-to-end model because we had half an addressing architecture. To follow Alexis comment the other day, we basically have an unfinished demo on our hands. ;-) > > It was assuming that >> it was right that got us where we are. We have to find what is really >> going on. Once we understand that, then we can worry about how to >> engineer it. > >Agreed but as I said above that is how I "perceived" the discussion and >comment. > >> >> As you tell kids when they are doing their math homework: Don't skip >> steps. It will only get you in trouble. ;-) (Always hated it when my >> father told me that.) > >Agree and I think what is now is part of the steps at various points >within the discussion. > >> >> > >> >More important to your mail yes we need to find consensus >> but only rough >> >consensus to keep moving once that is achieved. But then we >> get to the >> >running code part :--) >> >> Ahh, yes science by popularity. Wonder how often that has >> been the case. > >I cannot parse how you came up with science by popularity from my >comment. If you beleive rough consensus is popularity then I guess that >is a point. The alternative is elitism and that I find vulgar, and my >view is kings should have heads chopped off :--), so support the rough >consensus. Science is elitist, not democratic. It goes with evidence and proof. It is normally the case that what becomes the "right" answer was not a view held by the majority of scientists, let alone the majority of the population. In fact, it is almost expected that science shows that our intuitions about things are usually wrong. ;-) Damned embarrassing! Now that said, all models/theories in science are working assumptions. None are True. Our job is always to try to prove them wrong. >I don't think you were speaking of running code as that is cleary >important and has nothing to do with popularity, and more about proof of >concept. Yea, no I wasn't. But running code has its concerns as well. Of course, it is good to ensure that it works and can be done. But I often worry that given natural laziness, it limits the range of implementation strategies that get tried. Have you seen Jacobsen's recent stuff on improving TCP that seems to indicate that everyone was just doing what Berkeley did which was pretty much what Multics did and it wasn't the best way? Also running code has the tendency to become the spec again limiting variety but these are nits. > > >> rough consensus applies to electro-political engineering. > >We can agree to disagree, but I am pretty sure this list and the IETF >support and will continue to support rough consensus. The problem in the IETF isn't rough consensus per se. All standards committees I have ever been in use it at the working group level. The problem in the IETF is that they have an organization without checks and balances on the individual. This doesn't mean that what comes out doesn't work, it means that the process is open to manipulation and is exploited. The dynamics of representative organizations should go on elsewhere. > > I didn't >> realize that was the domain of this discussion. I thought this was a >> more scientific inquiry. Science must follow the data regardless of >> how unpopular it may be. > >Well I could remind all Philosophy is the Mother of All Sciences, but I >won't. Part of scientific inquiry is analysis, and part of analysis is >discussion, censoring discussion to suit any one individuals needs is >probably not going to happen in the IETF or in most forums I work in >unless it is an elitist group and then I usually leave because I don't >find that type of crowd very respectful to others and I don't deal well >with disrespect nor put up with it as one human on the planet, we all >have our limitations. I think a tyranny of the majority is more likely. Often in science, the new idea is quite unpopular. Consider how long the idea that continents moved was around before the bulk of the community came to the idea. No, scientific inquiry is an odd bird. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuah-0002SO-14; Fri, 24 Mar 2006 17:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoM5-0005MX-8B for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:37:37 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoM5-0004v8-1Q for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:37:37 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032415373501400c53k5e>; Fri, 24 Mar 2006 15:37:36 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206D14A@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206D14A@tayexc14.americas.cpqcorp.net> Date: Fri, 24 Mar 2006 10:37:30 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:24 -0500 2006/03/24, Bound, Jim wrote: >No disagreements with the below I see your point better now. Thanks for >taking time with the response. Yes I have looked at VJs new stuff and >agree its not entirely a new idea or circular buffers, did not know that That was my reaction as well. I couldn't be sure, but was pretty sure we had not done it the way it was before VJ looked at it. ;-) >about Multics, and interesting. Also yes for verification running code >can be lazy just to get proof of concept, I would suggest it is lazy >evaulation of programming to see if stuff works. I don't write code Normally, I consider laziness a virtue! ;-) .i e. would rather sit around and think up an elegant simple solution than just barrel through it! ;-) >anymore but I still read it occasionally. Speaking of changes. I had >to review the Grid Globus Toolkit for day job and IPv6 Forum and pulled >over entire 10 MB (at the time) source pool. I jumped into all the >java, xml, et al. and I said oh my great-spirit I am glad I am not a >programmer anymore :--) But I did find what I was looking for so it was >useful exercise. Know what you mean. I am not sure there is much good code being written these days. Story from ancient past: We wrote an OS once entirely based on semaphores. Consequently, a task switch comes down to a single assignment statement. Basically, Top of Stack goes to PC counter. You enter P one stack and you exit in V on another and everything is either doing procedure entry/exit or doing P and V except that assignment statement. It was a really elegant piece of work. The standard procedure entry/exit did the save and restore for you, so there was really nothing else to do but change the PC. ;-) Since it was a DARPA project we had a code review with Vint, McKenzie, Tomlinson, Steve Crocker, Roland Bryant, Ollikanen, the usual cast of characters. When we got to explaining the semaphore code, they couldn't believe it. It took 3 hours of explanation, drawing out how the stack changed, etc and I am not sure they ever truly believed it even though the code was running. But then we had been using a Burroughs machine for 5 years at that point and we ate, drank and slept recursion. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuaf-0002Rz-60; Fri, 24 Mar 2006 17:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMUX4-0004wx-1w for architecture-discuss@ietf.org; Thu, 23 Mar 2006 13:27:38 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMUX3-00075U-Kl for architecture-discuss@ietf.org; Thu, 23 Mar 2006 13:27:37 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20060323182730m1100cbq8fe>; Thu, 23 Mar 2006 18:27:36 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060323174527.GI11517@verdi> References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> Date: Thu, 23 Mar 2006 13:20:25 -0500 To: John Leslie , "Bound, Jim" From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa , John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:45 -0500 2006/03/23, John Leslie wrote: >Bound, Jim wrote: >> To: "John Day" , >> >> John, all opinions are important and there is no gospel for layers or >> architecture. I hear you but several of us who have lived this too >> simply don't agree. > > We need to put _some_ effort into seeking consensus... > >> Noel is spot on. > > Umm... Noel really _isn't_ spot-on in his BGP example... > >>> At 21:15 -0500 2006/03/21, Noel Chiappa wrote: >>> >>>> As one example, look at BGP. It's used for passing around >>>> routing info - so it's part of the inter-network layer, right? > > That really doesn't follow. > > BGP is a "routing" protocol, in the Routing Area sense. > > To Routing Area folks, "routing" is generating path information and >passing _some_ of that path information toward forwarding engines. > > I don't mean to insult folks familiar with Routing Area terminology, >but I expect some folks on this list aren't familiar with it. > > Recall, John Day sees three pieces called "routing": >] >] Actually, I would say routing is 3 distinct tasks: >] exchanging information about connectivity and other information, >] calculating connectivity based on what you have collected, >] and then choosing a next hop/path based on the calculation and >] the other info. > >and I don't think he even referred to the function I mentioned which >many folks call "routing" but Routing Area folks call "forwarding": >] >]> passing packets to another router "closer" to the destination. > > (It doesn't help that even Routing Area folks use the term "router" >to refer to a box which does "forwarding".) Yes, you are absolutely right. I was considering "forwarding" as the output of the routing function. We do tend to get sloppy and talk about routing so much I think we sometimes forget that we do all of this calculation of routes just to get the next hop! Seems like quite a waste of effort. ;-) > > Of all of these, only the last, "forwarding", one in any sense >deserves to be called "part of the inter-network layer". The others >may or may not deserve to be called "necessary to" the inter- >network area, but that would not make them "part of" it. > > Noel certainly knows that BGP is not "forwarding", even if every >box he may have seen it implemented in also does forwarding ( I >venture no guess as to whether that condition is true). > > What functions go in a box is engineering, not architecture. >What functions are implemented in a box _cannot_ determine their >architectural purpose. > >>>> Yes, but, it uses TCP. So it's above the transport layer, right? > > This statement at least makes sense. The BGP routing function >can be considered "above" the transport layer. > > But we have no need to enter that argument. From an architectural >standpoint, we should see "exchanging information about connectivity" >as a network function which is out-of-band to the inter-network layer, >and the rest of "routing" (in the Routing Area usage) as not network >functions at all. Take all of this as data. What is the problem telling us? Are we using TCP as a transport protocol in the traditional sense or are we using it as an error control protocol in a layer with a different scope? What is the scope of TCP as used by BGP? Is it different from the scope of TCP used by say Telnet or FTP? If it is, then it is a different layer. > >>> "Does not compute! Does not compute!" > > Repeating a statement doesn't make it true. John Day is right: > >>> No. There is no rule that says a protocol and the layer it is used >>> in are fixed. Protocols are means to providing certain kinds of >>> coordination. I can use any protocol in any layer where it does what >>> I need done. Sure it computes. > > John Day and I are perhaps thinking from an academic standpoint. >Noel may be thinking from an engineering standpoint (or not, YMMV). >But all of us should be _trying_ to think from an architectural >standpoint. Don't know if it is academic or engineering. I would like to think it is scientific. ;-) More than once, I have found what people do is for good reason. They (we, I) may not understand the full implication of why it was done, but if you think long and hard and look at the problem deeply enough eventually it makes itself clear. So as I said before, assume that all of these people aren't stupid, but may not quite understand fully what has been proposed, but there is likely a grain of truth in it. The question is how does this grain fit in the total picture. Take care John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuah-0002SO-14; Fri, 24 Mar 2006 17:17:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoM5-0005MX-8B for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:37:37 -0500 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoM5-0004v8-1Q for architecture-discuss@ietf.org; Fri, 24 Mar 2006 10:37:37 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc14) with ESMTP id <2006032415373501400c53k5e>; Fri, 24 Mar 2006 15:37:36 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206D14A@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206D14A@tayexc14.americas.cpqcorp.net> Date: Fri, 24 Mar 2006 10:37:30 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:24 -0500 2006/03/24, Bound, Jim wrote: >No disagreements with the below I see your point better now. Thanks for >taking time with the response. Yes I have looked at VJs new stuff and >agree its not entirely a new idea or circular buffers, did not know that That was my reaction as well. I couldn't be sure, but was pretty sure we had not done it the way it was before VJ looked at it. ;-) >about Multics, and interesting. Also yes for verification running code >can be lazy just to get proof of concept, I would suggest it is lazy >evaulation of programming to see if stuff works. I don't write code Normally, I consider laziness a virtue! ;-) .i e. would rather sit around and think up an elegant simple solution than just barrel through it! ;-) >anymore but I still read it occasionally. Speaking of changes. I had >to review the Grid Globus Toolkit for day job and IPv6 Forum and pulled >over entire 10 MB (at the time) source pool. I jumped into all the >java, xml, et al. and I said oh my great-spirit I am glad I am not a >programmer anymore :--) But I did find what I was looking for so it was >useful exercise. Know what you mean. I am not sure there is much good code being written these days. Story from ancient past: We wrote an OS once entirely based on semaphores. Consequently, a task switch comes down to a single assignment statement. Basically, Top of Stack goes to PC counter. You enter P one stack and you exit in V on another and everything is either doing procedure entry/exit or doing P and V except that assignment statement. It was a really elegant piece of work. The standard procedure entry/exit did the save and restore for you, so there was really nothing else to do but change the PC. ;-) Since it was a DARPA project we had a code review with Vint, McKenzie, Tomlinson, Steve Crocker, Roland Bryant, Ollikanen, the usual cast of characters. When we got to explaining the semaphore code, they couldn't believe it. It took 3 hours of explanation, drawing out how the stack changed, etc and I am not sure they ever truly believed it even though the code was running. But then we had been using a Burroughs machine for 5 years at that point and we ate, drank and slept recursion. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuaf-0002Rz-60; Fri, 24 Mar 2006 17:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMUX4-0004wx-1w for architecture-discuss@ietf.org; Thu, 23 Mar 2006 13:27:38 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMUX3-00075U-Kl for architecture-discuss@ietf.org; Thu, 23 Mar 2006 13:27:37 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20060323182730m1100cbq8fe>; Thu, 23 Mar 2006 18:27:36 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060323174527.GI11517@verdi> References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> Date: Thu, 23 Mar 2006 13:20:25 -0500 To: John Leslie , "Bound, Jim" From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: architecture-discuss@ietf.org, Noel Chiappa , John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 12:45 -0500 2006/03/23, John Leslie wrote: >Bound, Jim wrote: >> To: "John Day" , >> >> John, all opinions are important and there is no gospel for layers or >> architecture. I hear you but several of us who have lived this too >> simply don't agree. > > We need to put _some_ effort into seeking consensus... > >> Noel is spot on. > > Umm... Noel really _isn't_ spot-on in his BGP example... > >>> At 21:15 -0500 2006/03/21, Noel Chiappa wrote: >>> >>>> As one example, look at BGP. It's used for passing around >>>> routing info - so it's part of the inter-network layer, right? > > That really doesn't follow. > > BGP is a "routing" protocol, in the Routing Area sense. > > To Routing Area folks, "routing" is generating path information and >passing _some_ of that path information toward forwarding engines. > > I don't mean to insult folks familiar with Routing Area terminology, >but I expect some folks on this list aren't familiar with it. > > Recall, John Day sees three pieces called "routing": >] >] Actually, I would say routing is 3 distinct tasks: >] exchanging information about connectivity and other information, >] calculating connectivity based on what you have collected, >] and then choosing a next hop/path based on the calculation and >] the other info. > >and I don't think he even referred to the function I mentioned which >many folks call "routing" but Routing Area folks call "forwarding": >] >]> passing packets to another router "closer" to the destination. > > (It doesn't help that even Routing Area folks use the term "router" >to refer to a box which does "forwarding".) Yes, you are absolutely right. I was considering "forwarding" as the output of the routing function. We do tend to get sloppy and talk about routing so much I think we sometimes forget that we do all of this calculation of routes just to get the next hop! Seems like quite a waste of effort. ;-) > > Of all of these, only the last, "forwarding", one in any sense >deserves to be called "part of the inter-network layer". The others >may or may not deserve to be called "necessary to" the inter- >network area, but that would not make them "part of" it. > > Noel certainly knows that BGP is not "forwarding", even if every >box he may have seen it implemented in also does forwarding ( I >venture no guess as to whether that condition is true). > > What functions go in a box is engineering, not architecture. >What functions are implemented in a box _cannot_ determine their >architectural purpose. > >>>> Yes, but, it uses TCP. So it's above the transport layer, right? > > This statement at least makes sense. The BGP routing function >can be considered "above" the transport layer. > > But we have no need to enter that argument. From an architectural >standpoint, we should see "exchanging information about connectivity" >as a network function which is out-of-band to the inter-network layer, >and the rest of "routing" (in the Routing Area usage) as not network >functions at all. Take all of this as data. What is the problem telling us? Are we using TCP as a transport protocol in the traditional sense or are we using it as an error control protocol in a layer with a different scope? What is the scope of TCP as used by BGP? Is it different from the scope of TCP used by say Telnet or FTP? If it is, then it is a different layer. > >>> "Does not compute! Does not compute!" > > Repeating a statement doesn't make it true. John Day is right: > >>> No. There is no rule that says a protocol and the layer it is used >>> in are fixed. Protocols are means to providing certain kinds of >>> coordination. I can use any protocol in any layer where it does what >>> I need done. Sure it computes. > > John Day and I are perhaps thinking from an academic standpoint. >Noel may be thinking from an engineering standpoint (or not, YMMV). >But all of us should be _trying_ to think from an architectural >standpoint. Don't know if it is academic or engineering. I would like to think it is scientific. ;-) More than once, I have found what people do is for good reason. They (we, I) may not understand the full implication of why it was done, but if you think long and hard and look at the problem deeply enough eventually it makes itself clear. So as I said before, assume that all of these people aren't stupid, but may not quite understand fully what has been proposed, but there is likely a grain of truth in it. The question is how does this grain fit in the total picture. Take care John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuaf-0002S4-Bj; Fri, 24 Mar 2006 17:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW68-0002gi-31 for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:07:56 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW66-0003MD-RB for architecture-discuss@ietf.org; Thu, 23 Mar 2006 15:07:56 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20060323200747m1100c42gde>; Thu, 23 Mar 2006 20:07:53 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> Date: Thu, 23 Mar 2006 15:07:41 -0500 To: "Bound, Jim" , "John Leslie" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: Noel Chiappa , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 14:52 -0500 2006/03/23, Bound, Jim wrote: >Valid point but I took the BGP more as abstraction to define a layer >called routing for discussion. IP model don't call out a routing layer. >Forwarding is different than extraplation of routes and discovery >clearly. But we are trying to *find* the right model. We can't let the fact that the IP model doesn't call out a routing layer affect our view. The IP model may be wrong, or not quite right. It was assuming that it was right that got us where we are. We have to find what is really going on. Once we understand that, then we can worry about how to engineer it. As you tell kids when they are doing their math homework: Don't skip steps. It will only get you in trouble. ;-) (Always hated it when my father told me that.) > >More important to your mail yes we need to find consensus but only rough >consensus to keep moving once that is achieved. But then we get to the >running code part :--) Ahh, yes science by popularity. Wonder how often that has been the case. rough consensus applies to electro-political engineering. I didn't realize that was the domain of this discussion. I thought this was a more scientific inquiry. Science must follow the data regardless of how unpopular it may be. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuae-0002Ru-SY; Fri, 24 Mar 2006 17:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTHb-0005Me-1b for architecture-discuss@ietf.org; Thu, 23 Mar 2006 12:07:35 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTHZ-00046f-Pp for architecture-discuss@ietf.org; Thu, 23 Mar 2006 12:07:35 -0500 Received: from [10.0.1.27] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc13) with ESMTP id <20060323170730m13005k77fe>; Thu, 23 Mar 2006 17:07:32 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> Date: Thu, 23 Mar 2006 12:05:52 -0500 To: "Bound, Jim" , "John Day" , "Noel Chiappa" , From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Fri, 24 Mar 2006 17:17:04 -0500 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:55 -0500 2006/03/23, Bound, Jim wrote: >John, all opinions are important and there is no gospel for layers or >architecture. I hear you but several of us who have lived this too >simply don't agree. Noel is spot on. >/jim Jim, I have been living with this far longer than you have. And it would appear spent far more time thinking about it. I sense that Noel is just discouraged. ;-) As I pointed out the other day, you can argue it all you want. There is some sort of distributed black box involved here and there is no way to escape it. So you may as well learn to live with it. However, it is not clear that layers we came up with in the early 70s were in fact layers we should have. We hadn't seen much of the problem space then. Any more than the layers of an OS today follow the layers of Dijkstra's THE paper. I contend there is a solution that recognizes layers, is simple, elegant and solves many problems. There is lots of data. As Kettering says, one must learn to listen to the problem. The statement of every problem contains its solutions. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Mar 24 19:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwZF-00085T-Ft; Fri, 24 Mar 2006 19:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwZE-00085O-Kz for architecture-discuss@ietf.org; Fri, 24 Mar 2006 19:23:44 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMwZD-0002nE-FA for architecture-discuss@ietf.org; Fri, 24 Mar 2006 19:23:44 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 5BA0CE0427; Fri, 24 Mar 2006 19:23:43 -0500 (EST) Date: Fri, 24 Mar 2006 19:23:43 -0500 From: John Leslie To: John Day Subject: Re: [arch-d] Defining terms Message-ID: <20060325002343.GK11517@verdi> References: <936A4045C332714F975800409DE092400206CD2D@tayexc14.americas.cpqcorp.net> <20060323201704.GL4752@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John Day wrote: > At 14:17 -0600 2006/03/23, Scott W Brim wrote: >> >> Planes are your friend. > > ;-) Good one. Could one of the folks who is saying layers are the wrong approach please try describing internetworking architecture in terms of planes? (I've been trying this exercise myself, and I'm afraid I'm failing kinda spectacularly...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Mar 25 08:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN9GM-0000fu-Mf; Sat, 25 Mar 2006 08:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN9GM-0000fo-4R for architecture-discuss@ietf.org; Sat, 25 Mar 2006 08:57:06 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN9GL-0000Bv-Sa for architecture-discuss@ietf.org; Sat, 25 Mar 2006 08:57:06 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FN9GE-0004Q8-HK; Sat, 25 Mar 2006 05:56:59 -0800 Message-Id: <6.2.3.4.2.20060324224526.07876230@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 25 Mar 2006 14:56:37 +0100 To: "john.loughney@nokia.com" ,, From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <1AA39B75171A7144A73216AED1D7478D0186A0AE@esebe100.NOE.Noki a.com> References: <6.2.3.4.2.20060322021230.0754feb0@mail.jefsey.com> <1AA39B75171A7144A73216AED1D7478D0186A0AE@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-74FD7426 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 11:51 22/03/2006, john.loughney@nokia.com wrote: >JFC, > > >We want a model which will last. It cannot depend on the > >engineering solutions it is to replace. Retro-compatibility > >with passed limitations cannot be the base of a brillant future. > >We want a model that over comes the problem areas of today and >can be made to (inter)work with the existing stuff. This is >engineering. Dear John, You are obviously correct in your definition of engineering and of what could be done. But is the matter here not architecture? It is a step further to address the situation. Take the Coliseum in Rome or the Pyramids. There is a lot of daily engineering to keep them in good shape. But their architecture lasts for twenty and forty centuries. But you are right: private buildings engineered at the same time, are long gone and replaced and may still have to be replaced. Hopefully in a better way each time. Now, there is certainly a choice to make: engineering fixes or architectural change. What is the best? What is the fastest? >Nothing lasts forever, and if you plan to have >such a solution, mostly likely, it will be horribly over-engineered >and miss it's window of opportunity. Examples I took, and experience, would show otherwise. Because their builder did want to please engineers, but to use engineers' help to please people. >I think we have some idea of what is broken, and so the next >architecture is one that should solve those problems in a coherent >and straight-forward manner. The next architecture should be the one which will not even know such problems may exist. This is why I prefer considering people needs. Usually permanent needs. I prefer to list them as services (people want services, not solutions). And to consider the network OS (and its resulting protocols - most probably plural) able to support these services. I am amazed that local nets are dealt with network OS and not the network of the network. This is why I kept refering to "usage architecture". But now I see that John Day used the word... In this process let disregard the solutions and protocols we know the weaknesses and conflicts. Let try to reduce the whole thing to the simplest proposition. Call them layers, modules, functions, building blocks, etc. there will be ways to reduce complexity and to measure their applied architectural consistency. Now, you will have an architectural framework. Where engineering may and have to develop. Both ways - down the layers for network engineering, and up for applications, procedures and parametering. Unfortunately I feel the Internet went the other way around. An engineering feasibility test, which lasted, patch after possibly conflicting patch. It works, but are we not hampered, delayed? I think we are, and for a long. hmmm... I talked a lot, now I listen what people on this list have to answer to the users of their deliberables like me. Cheers. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 27 10:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNteK-0000vr-AQ; Mon, 27 Mar 2006 10:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNteJ-0000vP-4z for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:28:55 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNteE-0003IZ-Te for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:28:55 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 799CE3428E; Mon, 27 Mar 2006 10:28:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 10:28:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Mon, 27 Mar 2006 10:28:47 -0500 Message-ID: <936A4045C332714F975800409DE092400206D77A@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZPomzZnUFLexxOTQ64pyBejVm9YACEESYQ From: "Bound, Jim" To: "John Leslie" , "John Day" X-OriginalArrivalTime: 27 Mar 2006 15:28:50.0054 (UTC) FILETIME=[25B96260:01C651B3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I am having same issue. But with progress. The planes help describe what we can call the layers. The modules is what lives within the planes. The layers are virtual abstractions to identify regions of planes. At least that is where I am at on this self-referential exercise, at least at this point because I believe in planes right now. Going to try to apply it to some of the IETF work I am going to do for shim6 and hip comparison the security models used. Viewing SCTP as a set of planes and TCP as a set of planes I believe the diff will provide knowledge of both. /jim=20 > -----Original Message----- > From: John Leslie [mailto:john@jlc.net]=20 > Sent: Friday, March 24, 2006 7:24 PM > To: John Day > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Defining terms >=20 > John Day wrote: > > At 14:17 -0600 2006/03/23, Scott W Brim wrote: > >> > >> Planes are your friend. > >=20 > > ;-) Good one. >=20 > Could one of the folks who is saying layers are the wrong approach > please try describing internetworking architecture in terms of planes? >=20 > (I've been trying this exercise myself, and I'm afraid I'm failing > kinda spectacularly...) >=20 > -- > John Leslie >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 27 10:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu6N-0001Tt-2O; Mon, 27 Mar 2006 10:57:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu6L-0001Tn-BD for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:57:53 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNu6K-0004Lk-SZ for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:57:53 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2RFrNQ02031; Mon, 27 Mar 2006 10:53:23 -0500 (EST) Received: from [127.0.0.1] ([47.130.24.250] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Mar 2006 10:57:47 -0500 Message-ID: <44280B6F.3010509@nortel.com> Date: Mon, 27 Mar 2006 10:57:35 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Day Subject: Re: [arch-d] Defining terms References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2006 15:57:47.0841 (UTC) FILETIME=[3186A310:01C651B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Noel Chiappa , architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I'm still trying to grasp what this discussion is really concerned with, but I think I can contribute a thought on the layering question. Taking BGP and TCP as an example, the problem is that each can have an impact on how the other operates. You have a cycle somewhere in your dependency graph. The reason for layering, if it could be achieved, is to assure consistency. However, it is still possible to have consistency even if your depedency graph has cycles. It's just harder to analyze and easier to break. John Day wrote: > At 12:45 -0500 2006/03/23, John Leslie wrote: > >> Bound, Jim wrote: >> >>> To: "John Day" , >>> >>> John, all opinions are important and there is no gospel for layers or >>> architecture. I hear you but several of us who have lived this too >>> simply don't agree. >> >> >> We need to put _some_ effort into seeking consensus... >> >>> Noel is spot on. >> >> >> Umm... Noel really _isn't_ spot-on in his BGP example... >> >>>> At 21:15 -0500 2006/03/21, Noel Chiappa wrote: >>>> >>>>> As one example, look at BGP. It's used for passing around >>>>> routing info - so it's part of the inter-network layer, right? >> >> >> That really doesn't follow. >> >> BGP is a "routing" protocol, in the Routing Area sense. >> >> To Routing Area folks, "routing" is generating path information and >> passing _some_ of that path information toward forwarding engines. >> >> I don't mean to insult folks familiar with Routing Area terminology, >> but I expect some folks on this list aren't familiar with it. >> >> Recall, John Day sees three pieces called "routing": >> ] >> ] Actually, I would say routing is 3 distinct tasks: >> ] exchanging information about connectivity and other information, >> ] calculating connectivity based on what you have collected, >> ] and then choosing a next hop/path based on the calculation and >> ] the other info. >> >> and I don't think he even referred to the function I mentioned which >> many folks call "routing" but Routing Area folks call "forwarding": >> ] >> ]> passing packets to another router "closer" to the destination. >> >> (It doesn't help that even Routing Area folks use the term "router" >> to refer to a box which does "forwarding".) > > > Yes, you are absolutely right. I was considering "forwarding" as the > output of the routing function. We do tend to get sloppy and talk about > routing so much I think we sometimes forget that we do all of this > calculation of routes just to get the next hop! Seems like quite a > waste of effort. ;-) > >> >> Of all of these, only the last, "forwarding", one in any sense >> deserves to be called "part of the inter-network layer". The others >> may or may not deserve to be called "necessary to" the inter- >> network area, but that would not make them "part of" it. >> >> Noel certainly knows that BGP is not "forwarding", even if every >> box he may have seen it implemented in also does forwarding ( I >> venture no guess as to whether that condition is true). >> >> What functions go in a box is engineering, not architecture. >> What functions are implemented in a box _cannot_ determine their >> architectural purpose. >> >>>>> Yes, but, it uses TCP. So it's above the transport layer, right? >> >> >> This statement at least makes sense. The BGP routing function >> can be considered "above" the transport layer. >> >> But we have no need to enter that argument. From an architectural >> standpoint, we should see "exchanging information about connectivity" >> as a network function which is out-of-band to the inter-network layer, >> and the rest of "routing" (in the Routing Area usage) as not network >> functions at all. > > > Take all of this as data. What is the problem telling us? Are we using > TCP as a transport protocol in the traditional sense or are we using it > as an error control protocol in a layer with a different scope? > > What is the scope of TCP as used by BGP? Is it different from the scope > of TCP used by say Telnet or FTP? If it is, then it is a different layer. > >> >>> "Does not compute! Does not compute!" >> >> Repeating a statement doesn't make it true. John Day is right: >> >>>> No. There is no rule that says a protocol and the layer it is used >>>> in are fixed. Protocols are means to providing certain kinds of >>>> coordination. I can use any protocol in any layer where it does what >>>> I need done. Sure it computes. >> >> >> John Day and I are perhaps thinking from an academic standpoint. >> Noel may be thinking from an engineering standpoint (or not, YMMV). >> But all of us should be _trying_ to think from an architectural >> standpoint. > > > Don't know if it is academic or engineering. I would like to think it > is scientific. ;-) More than once, I have found what people do is for > good reason. They (we, I) may not understand the full implication of > why it was done, but if you think long and hard and look at the problem > deeply enough eventually it makes itself clear. So as I said before, > assume that all of these people aren't stupid, but may not quite > understand fully what has been proposed, but there is likely a grain of > truth in it. The question is how does this grain fit in the total picture. > > Take care > John > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 27 14:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxUF-0001qM-Qr; Mon, 27 Mar 2006 14:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNuKB-0006Iv-Vf for architecture-discuss@ietf.org; Mon, 27 Mar 2006 11:12:11 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNuKA-0004z3-Nc for architecture-discuss@ietf.org; Mon, 27 Mar 2006 11:12:11 -0500 Received: from [10.0.1.38] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20060327161208m1100c3qo3e>; Mon, 27 Mar 2006 16:12:09 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <44280B6F.3010509@nortel.com> References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> <44280B6F.3010509@nortel.com> Date: Mon, 27 Mar 2006 11:09:25 -0500 To: "Tom-PT Taylor" , John Day From: John Day Subject: Re: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Mon, 27 Mar 2006 14:34:46 -0500 Cc: Noel Chiappa , architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:57 -0500 2006/03/27, Tom-PT Taylor wrote: >I'm still trying to grasp what this discussion is really concerned >with, but I think I can contribute a thought on the layering >question. Taking BGP and TCP as an example, the problem is that each >can have an impact on how the other operates. You have a cycle >somewhere in your dependency graph. > >The reason for layering, if it could be achieved, is to assure >consistency. However, it is still possible to have consistency even >if your depedency graph has cycles. It's just harder to analyze and >easier to break. Interesting idea. But remember TCP is not a layer. It is a protocol that provides certain mechanisms and can be used in any layer where those mechanisms are required. We should not associate particular protocols with particular layers. They make nice examples and we do it all the time. But we can't use it as the basis for what a layer is. The fact that BGP uses it would seem to be that because it operates over many relays and provides the necessary mechanisms. Perhaps if we notice that BGP is a sort of embedded application used to aid in managing communications, not a user level application like FTP, but an application protocol nonetheless. Hmmmm. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 27 14:34:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxUF-0001qH-M7; Mon, 27 Mar 2006 14:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu1A-0006T0-KF for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:52:32 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNu1A-0004DZ-BF for architecture-discuss@ietf.org; Mon, 27 Mar 2006 10:52:32 -0500 Received: from [10.0.1.38] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc12) with ESMTP id <20060327155230m1200jd2nqe>; Mon, 27 Mar 2006 15:52:30 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <936A4045C332714F975800409DE092400206D77A@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE092400206D77A@tayexc14.americas.cpqcorp.net> Date: Mon, 27 Mar 2006 10:52:21 -0500 To: "Bound, Jim" , "John Leslie" , "John Day" From: John Day Subject: RE: [arch-d] Defining terms Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-Mailman-Approved-At: Mon, 27 Mar 2006 14:34:46 -0500 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org It will be an interesting exercise to see what questions it answers. All my attempts to pursue that course lead right back to the "beads-on-a-string" model. TCP is such a monolithic whole, it is hard to see how one would decompose it into planes. (I assume we are talking about vertical planes, rather than horizontal ones.) I have found more advantage returning to our roots and using operating systems as a guide. Take care, John At 10:28 -0500 2006/03/27, Bound, Jim wrote: >I am having same issue. But with progress. The planes help describe >what we can call the layers. The modules is what lives within the >planes. The layers are virtual abstractions to identify regions of >planes. At least that is where I am at on this self-referential >exercise, at least at this point because I believe in planes right now. >Going to try to apply it to some of the IETF work I am going to do for >shim6 and hip comparison the security models used. Viewing SCTP as a >set of planes and TCP as a set of planes I believe the diff will provide >knowledge of both. > >/jim > >> -----Original Message----- >> From: John Leslie [mailto:john@jlc.net] >> Sent: Friday, March 24, 2006 7:24 PM >> To: John Day >> Cc: architecture-discuss@ietf.org >> Subject: Re: [arch-d] Defining terms >> >> John Day wrote: >> > At 14:17 -0600 2006/03/23, Scott W Brim wrote: >> >> >> >> Planes are your friend. >> > >> > ;-) Good one. >> >> Could one of the folks who is saying layers are the wrong approach >> please try describing internetworking architecture in terms of planes? >> >> (I've been trying this exercise myself, and I'm afraid I'm failing >> kinda spectacularly...) >> >> -- >> John Leslie >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Mar 27 14:58:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxrD-0006dX-9H; Mon, 27 Mar 2006 14:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNxrC-0006dS-05 for architecture-discuss@ietf.org; Mon, 27 Mar 2006 14:58:30 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNxrA-0006af-P5 for architecture-discuss@ietf.org; Mon, 27 Mar 2006 14:58:29 -0500 Received: from h-68-166-189-73.snvacaid.dynamic.covad.net ([68.166.189.73] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FNxr9-0004Zi-00 for architecture-discuss@ietf.org; Mon, 27 Mar 2006 14:58:28 -0500 Message-ID: <002601c651d9$3bf98840$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> <44280B6F.3010509@nortel.com> Subject: Re: [arch-d] Defining terms Date: Mon, 27 Mar 2006 12:01:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - The last few posts on "planes" and "layers" were just a little too abstract for me. Just to make sure we are talking about the same things, here's how I would characterize the differences: "Layers" are used to bound the scope of specification (and interactions) between communicating entities. The boundaries allow consistent definition of the services provided, the services needed, and the protocol interactions. "Planes", as in "control plane", "data plane", "management plane" are aspects (as in cross-cutting concerns) of layers. The interactions to accomplish these functions may be "in-band" for a protocol at a given layer, or may be carried out by some other protocol, even at another (commonly application) layer. For example, setting up routes through the network layer's management plane might be accomplished using an application layer protocol like SNMP or BGP. Thus, when we talk about a plane, we're talking about a subset of a layer's interfaces, and those elements of protocol needed to support it. "Modules" are units of implementation; the organization of modules may, to the extent that support for a particular protocol is implemented as a discreet entity, reflect layering. Their organization may also, due to the commonality of implementation interfaces, reflect the functional aspects of the various planes. Am I totally in the weeds? Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 28 10:03:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFjE-00012F-Cf; Tue, 28 Mar 2006 10:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOFjC-00011r-HZ for architecture-discuss@ietf.org; Tue, 28 Mar 2006 10:03:26 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOFjC-0006bI-3Y for architecture-discuss@ietf.org; Tue, 28 Mar 2006 10:03:26 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Mar 2006 17:03:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Defining terms Date: Tue, 28 Mar 2006 17:03:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Defining terms Thread-Index: AcZR2NYKvt/MdIUnRFOI03JdTWFTwwAn1K+g From: "LEVIS Pierre RD-CORE-CAE" To: X-OriginalArrivalTime: 28 Mar 2006 15:03:24.0848 (UTC) FILETIME=[C30B2B00:01C65278] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Following the exchange on this list with interest I would like to bring = up some comments: - A layered model should not be considered as something stalled and = rigid, where any digression would appear like a break in the model. = Tunnelling, layers in different orders, should appear as variations on = the reference model and normal behaviour, not as faults. That said, I = don't mean that any reorganisation is legitimate but only that it should = not been rejected just because it does not correspond to the reference = model per se. Without being pedantic, this is very much like language, = you have grammar that captures the usual way to express things and you = have great novelists and great poets that very often use variations from = the traditional rules. Would you say Shakespeare didn't write correct = English? because it simply didn't write the same way his contemporary = fellows used English in there daytime occupations? - I don't see the architectural problem for BGP to be upon TCP if it = needs to be. We find routing protocols in various places: RIP is on top = of UDP, OSPF is on top of IP. For me, no matter where the routing = protocol is, it is application layer in the sense that there is no layer = above. In any layered model, application is the top layer. The ultimate = purpose of any network exchange is to convey application data from a = source where it is generated, to a destination where it is handled. = There is nowhere such a statement as data application should be anything = but routing information. Applications are not only end-users = applications. - I'm very surprised to hear that IETF experts asked by Eric don't see = any IP architectue at all. I see at least one great architectural = principle: the network layer (or may be better internetwork, or = SubNetwork Independent Convergence Protocol for OSI buffs is = connectionless and provides a single service to the layers just = above(see the hourglass model proposed by Steve Deering). I guess TCP/IP = has no more and no less architecture than other challengers like OSI, = ATM, or UMTS. Making the statement that IP is only ad hoc assemblage of = technologies and techniques is reassuring IP opponents that pretend = their protocol stack is very cleverly and truly designed whereas TCP/IP = is something cheap and shapeless and don't understand that the current = Internet has been possible not despite IP but because of IP. -Layer, plane, module, well ! may be these can be helpful concepts but = be sure they don't only bring complexity. A concept is helpful only as = far as it helps resolving a specific problem. So if we want to bring a = new concept we should be able to show what the associated problem is and = how it resolves it. We should avoid defining terms just for the pleasure = of providing definitions. However I found in this list interesting = reasons raised to consider modules and not only layers, the problem = being layers don't correspond to implementation and don't provide enough = flexibility.=20 Pierre -----Message d'origine----- De : Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Envoy=E9 : lundi 27 mars 2006 22:01 =C0 : architecture-discuss@ietf.org Objet : Re: [arch-d] Defining terms Hi - The last few posts on "planes" and "layers" were just a little too = abstract for me. Just to make sure we are talking about the same things, here's how I = would characterize the differences: "Layers" are used to bound the scope of specification (and = interactions) between communicating entities. The boundaries allow consistent = definition of the services provided, the services needed, and the protocol = interactions. "Planes", as in "control plane", "data plane", "management plane" = are aspects (as in cross-cutting concerns) of layers. The interactions = to accomplish these functions may be "in-band" for a protocol at a = given layer, or may be carried out by some other protocol, even at another (commonly application) layer. For example, setting up routes = through the network layer's management plane might be accomplished using an application layer protocol like SNMP or BGP. Thus, when we talk about a plane, we're talking about a subset of a layer's interfaces, = and those elements of protocol needed to support it. "Modules" are units of implementation; the organization of modules = may, to the extent that support for a particular protocol is implemented = as a discreet entity, reflect layering. Their organization may also, due = to the commonality of implementation interfaces, reflect the functional aspects of the various planes.=20 Am I totally in the weeds? Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 28 11:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGqt-0003Gg-Ee; Tue, 28 Mar 2006 11:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOGqs-0003GW-9z for architecture-discuss@ietf.org; Tue, 28 Mar 2006 11:15:26 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOGqr-0001Bi-W3 for architecture-discuss@ietf.org; Tue, 28 Mar 2006 11:15:26 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Mar 2006 08:15:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,139,1141632000"; d="scan'208"; a="24631590:sNHT25488532" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2SGFPVU011331 for ; Tue, 28 Mar 2006 11:15:25 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Mar 2006 11:15:25 -0500 Received: from cisco.com ([10.86.242.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Mar 2006 11:15:25 -0500 Date: Tue, 28 Mar 2006 11:15:14 -0500 From: Scott W Brim To: architecture-discuss@ietf.org Subject: Re: [arch-d] Defining terms Message-ID: <20060328161507.GH5004@sbrim-wxp01> Mail-Followup-To: Scott W Brim , architecture-discuss@ietf.org References: <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <44280B6F.3010509@nortel.com> <002601c651d9$3bf98840$6401a8c0@oemcomputer> <936A4045C332714F975800409DE092400206CBA4@tayexc14.americas.cpqcorp.net> <20060323174527.GI11517@verdi> <44280B6F.3010509@nortel.com> <936A4045C332714F975800409DE092400206D77A@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002601c651d9$3bf98840$6401a8c0@oemcomputer> <44280B6F.3010509@nortel.com> <936A4045C332714F975800409DE092400206D77A@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 28 Mar 2006 16:15:25.0217 (UTC) FILETIME=[D22F2910:01C65282] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, Mar 27, 2006 10:28:47AM -0500, Bound, Jim allegedly wrote: > I am having same issue. But with progress. The planes help > describe what we can call the layers. The modules is what lives > within the planes. The layers are virtual abstractions to identify > regions of planes. At least that is where I am at on this > self-referential exercise, at least at this point because I believe > in planes right now. Going to try to apply it to some of the IETF > work I am going to do for shim6 and hip comparison the security > models used. Viewing SCTP as a set of planes and TCP as a set of > planes I believe the diff will provide knowledge of both. Noel and Tony are right that what is essential is functions and the relationships between them. Layers, layer networks and planes are handy ways to aggregate functions for discussion and when implementing, especially if there is money involved, but are not fundamental. "Modules" can function in more than one plane (example: all of the forwarding, control and management planes might use IP forwarding for communication), and in more than one layer (example: more than one layer can use the same authentication funtion). If you want to use the traditional plane view, I don't see how TCP can be a set of planes. TCP can be used by more than one plane. Is that what you mean? On Mon, Mar 27, 2006 12:01:25PM -0800, Randy Presuhn allegedly wrote: > The last few posts on "planes" and "layers" were just a little too > abstract for me. Just to make sure we are talking about the same > things, here's how I would characterize the differences: > > "Layers" are used to bound the scope of specification (and > interactions) between communicating entities. The boundaries > allow consistent definition of the services provided, the > services needed, and the protocol interactions. > > "Planes", as in "control plane", "data plane", "management > plane" are aspects (as in cross-cutting concerns) of layers. > The interactions to accomplish these functions may be "in-band" > for a protocol at a given layer, or may be carried out by some > other protocol, even at another (commonly application) layer. > For example, setting up routes through the network layer's > management plane might be accomplished using an application > layer protocol like SNMP or BGP. Thus, when we talk about a > plane, we're talking about a subset of a layer's interfaces, and > those elements of protocol needed to support it. > > "Modules" are units of implementation; the organization of > modules may, to the extent that support for a particular > protocol is implemented as a discreet entity, reflect layering. > Their organization may also, due to the commonality of > implementation interfaces, reflect the functional aspects of the > various planes. > > Am I totally in the weeds? I think so -- good enough for me anyway. However, I want to add one more thing: layer networks (distinct from layers). The anti-ITU crowd will flinch. Consider if you're running SIP over IP over ATM over SDH over DWDM. Each one of those has its own endpoint identifiers, does its own switching (classically a "network layer" function), potentially has its own control and reliability functions, etc. Each one has a number of classic "layers" in it -- ATM can even have a session layer -- and has one or more "planes" (if nothing else a data/forwarding plane). Finally we can stack them arbitrarily. We can run IP over ATM or ATM over IP, as long as we eventually get down to something physical at the bottom. These things are called layer networks. Dealing with real networks, I think it's a more useful concept than the classic layers. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 28 15:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOL0k-0004KE-Az; Tue, 28 Mar 2006 15:41:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOL0j-0004K6-7s for architecture-discuss@ietf.org; Tue, 28 Mar 2006 15:41:53 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOL0i-00069k-Rz for architecture-discuss@ietf.org; Tue, 28 Mar 2006 15:41:53 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FOL0h-0004KX-Jk; Tue, 28 Mar 2006 12:41:52 -0800 Message-Id: <6.2.3.4.2.20060328222949.070b1260@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 28 Mar 2006 22:38:14 +0200 To: "LEVIS Pierre RD-CORE-CAE" , From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-23163F14 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pierre, tout cela n'a d'intérêt que si cela aide. Le problème essentiel est de savoir vers quoi on veut que cela aide. Tout cela est encore de l'ingénierie de construction. Avant que de se demander si l'on met d'abord les parpaings, puis le ciment, puis l'appret, puis la peinture et quand on place les chassis des fenêtres, ou si on peut mettre du préfabriqué, ou des panneaux de fibre de verre, etc. il faudrait d'abord un architecte qui fasse un plan d'ensemble, basé sur un modèle général externe à l'application Interet, qui fait que l'on met d'abord des fondation, des murs, un toit. Ce qui manque à l'IAB c'est malheureusement cela. Ceci dit la notion de pile protocolaire (layers network) est la plus porteuse à mon avis car elle permet d'utiliser le réseau actuel pour tester et prédéployer le réseau futur. A ce niveau j'aimerais bien savoir où trouver de la doc sur le réseau des Douanes et de la Gendarmerie, ou les messageries d'Auchan, qui - à ce que je comprends - on empilé TCP/IP et OSI? Pour ne pas paraître idiot : je comprends que les planes sont en fait une vision fonctionnelle du réseau, comme on dit "sur le plan sécurité, sur le plan gestion, etc." Donc trés claire en francais. Ou me gourre-je ? Cordialement jfc At 17:06 28/03/2006, LEVIS Pierre RD-CORE-CAE wrote: > Following the exchange on this list with interest I would like to > bring up some comments: > >- A layered model should not be considered as something stalled and >rigid, where any digression would appear like a break in the model. >Tunnelling, layers in different orders, should appear as variations >on the reference model and normal behaviour, not as faults. That >said, I don't mean that any reorganisation is legitimate but only >that it should not been rejected just because it does not correspond >to the reference model per se. Without being pedantic, this is very >much like language, you have grammar that captures the usual way to >express things and you have great novelists and great poets that >very often use variations from the traditional rules. Would you say >Shakespeare didn't write correct English? because it simply didn't >write the same way his contemporary fellows used English in there >daytime occupations? > >- I don't see the architectural problem for BGP to be upon TCP if it >needs to be. We find routing protocols in various places: RIP is on >top of UDP, OSPF is on top of IP. For me, no matter where the >routing protocol is, it is application layer in the sense that there >is no layer above. In any layered model, application is the top >layer. The ultimate purpose of any network exchange is to convey >application data from a source where it is generated, to a >destination where it is handled. There is nowhere such a statement >as data application should be anything but routing information. >Applications are not only end-users applications. > >- I'm very surprised to hear that IETF experts asked by Eric don't >see any IP architectue at all. I see at least one great >architectural principle: the network layer (or may be better >internetwork, or SubNetwork Independent Convergence Protocol for OSI >buffs is connectionless and provides a single service to the layers >just above(see the hourglass model proposed by Steve Deering). I >guess TCP/IP has no more and no less architecture than other >challengers like OSI, ATM, or UMTS. Making the statement that IP is >only ad hoc assemblage of technologies and techniques is reassuring >IP opponents that pretend their protocol stack is very cleverly and >truly designed whereas TCP/IP is something cheap and shapeless and >don't understand that the current Internet has been possible not >despite IP but because of IP. > >-Layer, plane, module, well ! may be these can be helpful concepts >but be sure they don't only bring complexity. A concept is helpful >only as far as it helps resolving a specific problem. So if we want >to bring a new concept we should be able to show what the associated >problem is and how it resolves it. We should avoid defining terms >just for the pleasure of providing definitions. However I found in >this list interesting reasons raised to consider modules and not >only layers, the problem being layers don't correspond to >implementation and don't provide enough flexibility. > >Pierre > >-----Message d'origine----- >De : Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Envoyé : lundi 27 mars 2006 22:01 >À : architecture-discuss@ietf.org >Objet : Re: [arch-d] Defining terms > >Hi - > >The last few posts on "planes" and "layers" were just a little too >abstract for me. >Just to make sure we are talking about the same things, here's how I >would characterize the differences: > > "Layers" are used to bound the scope of specification (and interactions) > between communicating entities. The boundaries allow > consistent definition > of the services provided, the services needed, and the > protocol interactions. > > "Planes", as in "control plane", "data plane", "management plane" are > aspects (as in cross-cutting concerns) of layers. The interactions to > accomplish these functions may be "in-band" for a protocol at a given > layer, or may be carried out by some other protocol, even at another > (commonly application) layer. For example, setting up routes through > the network layer's management plane might be accomplished using > an application layer protocol like SNMP or BGP. Thus, when we talk > about a plane, we're talking about a subset of a layer's interfaces, and > those elements of protocol needed to support it. > > "Modules" are units of implementation; the organization of modules may, > to the extent that support for a particular protocol is implemented as a > discreet entity, reflect layering. Their organization may also, due to > the commonality of implementation interfaces, reflect the functional > aspects of the various planes. > >Am I totally in the weeds? > >Randy > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Mar 28 16:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLlZ-0008K8-FN; Tue, 28 Mar 2006 16:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOLlY-0008K3-3q for architecture-discuss@ietf.org; Tue, 28 Mar 2006 16:30:16 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOLlW-00005r-UN for architecture-discuss@ietf.org; Tue, 28 Mar 2006 16:30:16 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FOLlW-000657-0O; Tue, 28 Mar 2006 13:30:14 -0800 Message-Id: <6.2.3.4.2.20060328232559.06ef5040@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 28 Mar 2006 23:28:28 +0200 To: "LEVIS Pierre RD-CORE-CAE" , From: "JFC (Jefsey) Morfin" Subject: RE: [arch-d] Defining terms In-Reply-To: <6.2.3.4.2.20060328222949.070b1260@mail.jefsey.com> References: <6.2.3.4.2.20060328222949.070b1260@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-23163F14 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 22:38 28/03/2006, JFC (Jefsey) Morfin wrote: >Pierre, >tout cela n'a d'intérêt que si cela aide. apologies. This mail was supposed to be personal. For those who read French, there were possibly (if correct) helpful clarifications about "planes" and "layers network" based upon French locutions. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss