From sacadmin Mon Jan 24 10:39:50 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OIdnac025830 for ; Mon, 24 Jan 2005 10:39:50 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2) with ESMTP id j0OIcrOn020601; Mon, 24 Jan 2005 13:38:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j0OIcrZJ020598; Mon, 24 Jan 2005 13:38:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16885.16573.839575.286856@gargle.gargle.HOWL> Date: Mon, 24 Jan 2005 13:38:53 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Bruce.Curtis@Sun.COM Subject: 2005/038 Network Layer 7 Cache X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO I'm sponsoring this fast-track request for Bruce Curtis. The timer is set for 01/31/2005. (We'd like to get it closed out on the 26th, so please comment as soon as possible.) Overview ======== RFE 6209091 NL7C (Network Layer 7 Cache) proposes to complete the integration of NCA, LSARC/1998/373 Solaris Network Cache and Accelerator, into the kernel with a patch/micro release binding. Note, the integration of NCA into the kernel was started as part of the FireEngine project, PSARC/2002/433, with the implementation of NCA's protocol stack framework and IP/TCP design. NL7C completes the integration of NCA into the kernel by porting NCA's HTTP layer and object cache into the sockfs kernel module. NL7C maintains all of NCA's configuration, administration, and APIs such that the user will experience little change from previous releases with the stability level of the NCA interfaces remaining the same (Evolving). NL7C is targeted for an update of S10. NL7C's main benefit is the reduction of code as NL7C relies on the core protocol IP/TCP stack instead of a dedicated and duplicate stack. Note, the NCA protocol stack is removed. NL7C interposes on the sockfs/AF_INET/tcp control and data paths such that coordination with other projects in the sockfs space will be done as necessary, e.g. Clearwater (2003/146), Yellowdart (2003/182), and SDP (2004/298). Ndd === The nca kmod and driver remain for servicing of ndd ioctl()s from either ndd(1M) or other application ioctl() cals. Only the nca specific variables are serviced while all others "tcp_*" and "ip_*" variables return an obsoleted message referring the user to use the appropriate "/dev/tcp" or "/dev/ip" ndd variable. Future ====== Support for NCAS (NCA SSL, Secure Socket Layer) functionality as part of the Greyhoung project, PSARC/2002/557. Tentative plans call for additional L7 protocol support, e.g. ftp, to be explored. PSARC case(s) to be filed. NL7C configuration, administration, and programmatic interfaces, at which time NCA can be depreciated. Supporting Documentation ======================== See http://NL7C.eng.Sun.COM for additional details. -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Mon Jan 24 11:11:19 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OJBJac004695 for ; Mon, 24 Jan 2005 11:11:19 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0OJAKJd005620; Mon, 24 Jan 2005 14:10:20 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0OJAKvB025371; Mon, 24 Jan 2005 14:10:20 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id j0OJAKlu025370; Mon, 24 Jan 2005 14:10:20 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2005/038 Network Layer 7 Cache From: Bill Sommerfeld To: James Carlson Cc: psarc@sac.sfbay.sun.com, Bruce.Curtis@sun.com In-Reply-To: <16885.16573.839575.286856@gargle.gargle.HOWL> References: <16885.16573.839575.286856@gargle.gargle.HOWL> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1106593820.24995.41.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Mon, 24 Jan 2005 14:10:20 -0500 Status: RO On Mon, 2005-01-24 at 13:38, James Carlson wrote: > NL7C completes the integration of NCA into the kernel by porting NCA's > HTTP layer and object cache into the sockfs kernel module. I'd like to understand whether alternatives to welding NL7C to sockfs were considered. > NL7C's main benefit is the reduction of code as NL7C relies on the core > protocol IP/TCP stack instead of a dedicated and duplicate stack. Note, > the NCA protocol stack is removed. what sort of feature interactions do you expect between NL7C and IP stack features such as IPsec, IPMP, etc.,? > NL7C interposes on the sockfs/AF_INET/tcp control and data paths such > that coordination with other projects in the sockfs space will be done > as necessary, e.g. Clearwater (2003/146), Yellowdart (2003/182), and > SDP (2004/298). can you provide more details? > Supporting Documentation > ======================== > > See http://NL7C.eng.Sun.COM for additional details. what parts of this web site should be preserved as part of the case history? From sacadmin Mon Jan 24 11:34:25 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OJYOac005477 for ; Mon, 24 Jan 2005 11:34:25 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2) with ESMTP id j0OJXSk1020789; Mon, 24 Jan 2005 14:33:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j0OJXSYb020786; Mon, 24 Jan 2005 14:33:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16885.19848.460543.562628@gargle.gargle.HOWL> Date: Mon, 24 Jan 2005 14:33:28 -0500 From: James Carlson To: Bill Sommerfeld Cc: psarc@sac.sfbay.sun.com, Bruce.Curtis@sun.com Subject: Re: 2005/038 Network Layer 7 Cache In-Reply-To: Bill Sommerfeld's message of 24 January 2005 14:10:20 References: <16885.16573.839575.286856@gargle.gargle.HOWL> <1106593820.24995.41.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO [I'll let Brutus answer most of this, but ...] Bill Sommerfeld writes: > > NL7C's main benefit is the reduction of code as NL7C relies on the core > > protocol IP/TCP stack instead of a dedicated and duplicate stack. Note, > > the NCA protocol stack is removed. > > what sort of feature interactions do you expect between NL7C and IP stack features > such as IPsec, IPMP, etc.,? I think the right answer is "none" -- it rides atop the stack like an application would, and like NCA does today (albeit with its own personal stack). > > NL7C interposes on the sockfs/AF_INET/tcp control and data paths such > > that coordination with other projects in the sockfs space will be done > > as necessary, e.g. Clearwater (2003/146), Yellowdart (2003/182), and > > SDP (2004/298). > > can you provide more details? I _believe_ those things are implementation details. The architectural issue is that these projects are all touching the same things and need to be aware of each other. > > Supporting Documentation > > ======================== > > > > See http://NL7C.eng.Sun.COM for additional details. > > what parts of this web site should be preserved as part of the case history? An interesting question. The architecturally interesting points are just how NL7C tracks information (what sort of database) and how it manages storage. I've 'assumed' that this was just identical to whatever NCA used to do. If that's not true, that should probably be called out. -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Mon Jan 24 11:55:11 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OJtAac007804 for ; Mon, 24 Jan 2005 11:55:11 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0OJsECS001396; Mon, 24 Jan 2005 11:54:14 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0OJsESB019444; Mon, 24 Jan 2005 11:54:14 -0800 (PST) Message-Id: <200501241954.j0OJsESB019444@rotary.eng.sun.com> Date: Mon, 24 Jan 2005 11:54:14 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: sommerfeld@sun.com Cc: psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eGsdJbj746KBq4mbXuMWTg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Mon, 24 Jan 2005 14:10:20 -0500 Bill Sommerfeld wrote: > >On Mon, 2005-01-24 at 13:38, James Carlson wrote: >> NL7C completes the integration of NCA into the kernel by porting NCA's >> HTTP layer and object cache into the sockfs kernel module. > >I'd like to understand whether alternatives to welding NL7C to sockfs were >considered. > Alternatives were considered, e.g. as part of Clearwater an interpose on the fly could've been done but as Clearwater was shelfed ... taking NCA's http/tcp/ip design and implementing an http layer as part of the current FireEngine tcp/ip kmod. The welding of NCA functionality to sockfs was chosen as the best place to support an L7 cache. If in a future sockfs were socket interpose can be done the small amount of code used to do the weld can be replaced with the appropriate interpose code. >> NL7C's main benefit is the reduction of code as NL7C relies on the core >> protocol IP/TCP stack instead of a dedicated and duplicate stack. Note, >> the NCA protocol stack is removed. > >what sort of feature interactions do you expect between NL7C and IP stack features >such as IPsec, IPMP, etc.,? To NL7C a socket is a socket, it doesn't need to interact with IP. > >> NL7C interposes on the sockfs/AF_INET/tcp control and data paths such >> that coordination with other projects in the sockfs space will be done >> as necessary, e.g. Clearwater (2003/146), Yellowdart (2003/182), and >> SDP (2004/298). > >can you provide more details? > There are ~~ 300 lines of code changes such that if NCA is disabled (the default) then no change to control/data flow of a socket. If NCA is enabled then based on the NCA configuration (/etc/nca/ncaport.conf) specified ipaddr/port pairs or if the listen() socket is of AF_NCA then NL7C will interpose. An accept()ing socket is marked for NL7C interpose, subsequent read-side data is http parsed for cache lookup, in the case of a cache hit the response is generated without application interaction. In the case of a miss the socket is marked for cache fill and the request passed up to the application and subsequent write-side data is cached while being processed as normal by the sockfs code. In the case of a miss but not a request that NL7C is interested in then the socket NL7C state is cleared and the request/response is handled by the application. >> Supporting Documentation >> ======================== >> >> See http://NL7C.eng.Sun.COM for additional details. > >what parts of this web site should be preserved as part of the case history? > Brutus From sacadmin Mon Jan 24 13:16:41 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OLGfac016061 for ; Mon, 24 Jan 2005 13:16:41 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0OLFi5E140691; Mon, 24 Jan 2005 13:15:44 -0800 (PST) Subject: Re: 2005/038 Network Layer 7 Cache From: Darren J Moffat To: Bruce Curtis Cc: psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM In-Reply-To: <200501241954.j0OJsESB019444@rotary.eng.sun.com> References: <200501241954.j0OJsESB019444@rotary.eng.sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1106601344.22413.278.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 24 Jan 2005 13:15:44 -0800 Content-Transfer-Encoding: 7bit Status: RO Is it the intent of this project to continue using /etc/rc2.d/ncakmod and /etc/rc2.d/ncalogd to startup NCA ? I would have expected to see an SMF manifest defined and /etc/init.d/ncakmod left as a legacy interface (since it is defined in ncakmod(1) as an admin interface), hint hint for svc://network/nca -- Darren From sacadmin Mon Jan 24 14:01:00 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OM10ac021099 for ; Mon, 24 Jan 2005 14:01:00 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0OM03CS022512; Mon, 24 Jan 2005 14:00:03 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0OM03SB019608; Mon, 24 Jan 2005 14:00:03 -0800 (PST) Message-Id: <200501242200.j0OM03SB019608@rotary.eng.sun.com> Date: Mon, 24 Jan 2005 14:00:03 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Darren.Moffat@Sun.COM Cc: psarc@sac.sfbay.sun.com, James.D.Carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TlK/WqNaH03FpF32EAOEXg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO Content-Length: 605 On Mon, 24 Jan 2005 13:15:44 -0800 Darren J Moffat wrote: > >Is it the intent of this project to continue using /etc/rc2.d/ncakmod and /etc/rc2.d/ncalogd to startup NCA ? > >I would have expected to see an SMF manifest defined and /etc/init.d/ncakmod left as a legacy interface (since it is defined in ncakmod(1) as an admin interface), hint hint for svc://network/nca > >-- >Darren Yes, NCA/NL7C continues to use the /etc/init.d/nca* startup scripts. In the future prior to deprecating NCA NL7C admin interfaces will have to be implemented and will be based on SMF. Brutus From sacadmin Mon Jan 24 14:12:55 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OMCtac021991 for ; Mon, 24 Jan 2005 14:12:55 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0OMBv8p015785; Mon, 24 Jan 2005 17:11:57 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0OMBvwx026862; Mon, 24 Jan 2005 17:11:57 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id j0OMBvdp026861; Mon, 24 Jan 2005 17:11:57 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2005/038 Network Layer 7 Cache From: Bill Sommerfeld To: Bruce Curtis Cc: Darren.Moffat@sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com In-Reply-To: <200501242200.j0OM03SB019608@rotary.eng.sun.com> References: <200501242200.j0OM03SB019608@rotary.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1106604716.26513.67.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Mon, 24 Jan 2005 17:11:56 -0500 Status: RO On Mon, 2005-01-24 at 17:00, Bruce Curtis wrote: > Yes, NCA/NL7C continues to use the /etc/init.d/nca* startup scripts. > > In the future prior to deprecating NCA NL7C admin interfaces will have > to be implemented and will be based on SMF. huh? it should be trivial to write simple manifests around the parts of the existing nca scripts which are still relevant.. - Bill From sacadmin Mon Jan 24 14:33:31 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0OMXVac022348 for ; Mon, 24 Jan 2005 14:33:31 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0OMWYsd006060; Mon, 24 Jan 2005 14:32:34 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0OMWYSB019651; Mon, 24 Jan 2005 14:32:34 -0800 (PST) Message-Id: <200501242232.j0OMWYSB019651@rotary.eng.sun.com> Date: Mon, 24 Jan 2005 14:32:34 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: sommerfeld@sun.com Cc: Darren.Moffat@sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zuxRlr7OS72kvaa/nU/oTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Mon, 24 Jan 2005 17:11:56 -0500 Bill Sommerfeld wrote: > >On Mon, 2005-01-24 at 17:00, Bruce Curtis wrote: >> Yes, NCA/NL7C continues to use the /etc/init.d/nca* startup scripts. >> >> In the future prior to deprecating NCA NL7C admin interfaces will have >> to be implemented and will be based on SMF. > >huh? it should be trivial to write simple manifests around the parts of the existing >nca scripts which are still relevant.. > > - Bill > Ok, I could, just hadn't planned on it, this is a change outside of the scope of the NL7C RFE as it requires admin guide changes so it's a bit more than just writing a simple ... ? Brutus From sacadmin Tue Jan 25 04:31:07 2005 Received: from bu-ewat02-01.uk.sun.com (sm-ewat02-01 [129.156.199.2]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PCV6ac009256 for ; Tue, 25 Jan 2005 04:31:06 -0800 (PST) Received: from sr-ewat02-01 (sr-ewat02-01.UK.Sun.COM [129.156.199.4]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id j0PCTvZi010960; Tue, 25 Jan 2005 12:29:58 GMT Message-Id: <200501251229.j0PCTvZi010960@bu-ewat02-01.uk.sun.com> Date: Tue, 25 Jan 2005 12:29:57 +0000 (GMT) From: Blaise Sanouillet - Sun Microsystems Reply-To: Blaise Sanouillet - Sun Microsystems Subject: Re: 2005/038 Network Layer 7 Cache To: Bruce.Curtis@sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NT4nVrNStf/gG2Nkz9vc1Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_33 SunOS 5.10 sun4u sparc Status: RO What about zones? During the Zones bringup, we punted on NCA because making it work in a zone would involve reapplying the (largish) changes done in IP to NCA. But with this new design, it should work for free. So will running NL7C in a zone be supported? TCP exports a function-call interface tcp_reserved_port_*() to manipulate the reserved port list. It seems NCA is the sole consumer of this interface. I can't find any reference to it in the PSARC archives, the docs or the include files, however it's "public" according to this code comment: /* * The public interface for other modules to call to reserve a port range * in TCP. The caller passes in how large a port range it wants. TCP * will try to find a range and return it via lo_port and hi_port. This is * used by NCA's nca_conn_init. If it was never exposed outside of ON, and assuming NL7C removes the need for it, I'd like to see it removed by this case. Blaise >I'm sponsoring this fast-track request for Bruce Curtis. The timer is >set for 01/31/2005. (We'd like to get it closed out on the 26th, so >please comment as soon as possible.) From sacadmin Tue Jan 25 07:35:11 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PFZBac017818 for ; Tue, 25 Jan 2005 07:35:11 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PFYCCS002826; Tue, 25 Jan 2005 07:34:12 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PFYBSB020255; Tue, 25 Jan 2005 07:34:12 -0800 (PST) Message-Id: <200501251534.j0PFYBSB020255@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 07:34:12 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Blaise.Sanouillet@sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HjW4Y/7XRbSTrCTh6kvBzw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 12:29:57 +0000 (GMT) wrote: > >What about zones? During the Zones bringup, we punted on NCA because making it >work in a zone would involve reapplying the (largish) changes done in IP to NCA. >But with this new design, it should work for free. So will running NL7C in a >zone be supported? > NL7C like NCA uses config files in /etc/nca to specify which addr/port pairs to parse new connection data for an HTTP request (NL7C and NCA) and to spec log file size and name(s) so the backing kernel structures would have to be indexed by the zone id which they are not at present. In fact no check is currently done for which zone the ndd ioctl() is from. >TCP exports a function-call interface tcp_reserved_port_*() to manipulate the >reserved port list. It seems NCA is the sole consumer of this interface. I can't >find any reference to it in the PSARC archives, the docs or the include files, >however it's "public" according to this code comment: >/* > * The public interface for other modules to call to reserve a port range > * in TCP. The caller passes in how large a port range it wants. TCP > * will try to find a range and return it via lo_port and hi_port. This is > * used by NCA's nca_conn_init. > >If it was never exposed outside of ON, and assuming NL7C removes the need for >it, I'd like to see it removed by this case. I'll have to check within SNST about this as NCA may have been the only consumer of this but I'm not sure, I'll file a bug on it. Brutus > >Blaise > >>I'm sponsoring this fast-track request for Bruce Curtis. The timer is >>set for 01/31/2005. (We'd like to get it closed out on the 26th, so >>please comment as soon as possible.) From sacadmin Tue Jan 25 07:49:19 2005 Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PFnIac018252 for ; Tue, 25 Jan 2005 07:49:19 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.Holland.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j0PFmJE20268; Tue, 25 Jan 2005 16:48:19 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id j0PFmJMa014616; Tue, 25 Jan 2005 16:48:19 +0100 (MET) Message-Id: <200501251548.j0PFmJMa014616@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Blaise Sanouillet - Sun Microsystems cc: Bruce.Curtis@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com Subject: Re: 2005/038 Network Layer 7 Cache In-Reply-To: <200501251229.j0PCTvZi010960@bu-ewat02-01.uk.sun.com> References: <200501251229.j0PCTvZi010960@bu-ewat02-01.uk.sun.com> Date: Tue, 25 Jan 2005 16:48:18 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1118 >What about zones? During the Zones bringup, we punted on NCA because making it >work in a zone would involve reapplying the (largish) changes done in IP to NCA. >But with this new design, it should work for free. So will running NL7C in a >zone be supported? > >TCP exports a function-call interface tcp_reserved_port_*() to manipulate the >reserved port list. It seems NCA is the sole consumer of this interface. I can't >find any reference to it in the PSARC archives, the docs or the include files, >however it's "public" according to this code comment: >/* > * The public interface for other modules to call to reserve a port range > * in TCP. The caller passes in how large a port range it wants. TCP > * will try to find a range and return it via lo_port and hi_port. This is > * used by NCA's nca_conn_init. > >If it was never exposed outside of ON, and assuming NL7C removes the need for >it, I'd like to see it removed by this case. Well, I very much like NAT in ipfiloter to use a similar interface; currently NAT can assign ports which are free for the OS to use so conflicts may arise. Casper From sacadmin Tue Jan 25 07:54:44 2005 Received: from bu-ewat02-01.uk.sun.com (sm-ewat02-01 [129.156.199.2]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PFshac019355 for ; Tue, 25 Jan 2005 07:54:44 -0800 (PST) Received: from sr-ewat02-01 (sr-ewat02-01.UK.Sun.COM [129.156.199.4]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id j0PFrhZi005294; Tue, 25 Jan 2005 15:53:43 GMT Message-Id: <200501251553.j0PFrhZi005294@bu-ewat02-01.uk.sun.com> Date: Tue, 25 Jan 2005 15:53:43 +0000 (GMT) From: Blaise Sanouillet - Sun Microsystems Reply-To: Blaise Sanouillet - Sun Microsystems Subject: Re: 2005/038 Network Layer 7 Cache To: brutus@rotary.eng.sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /wPOmOLWvP5GrHrn1LOU3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_33 SunOS 5.10 sun4u sparc Status: RO >NL7C like NCA uses config files in /etc/nca to specify which addr/port pairs >to parse new connection data for an HTTP request (NL7C and NCA) and to spec >log file size and name(s) so the backing kernel structures would have to be >indexed by the zone id which they are not at present. In fact no check is >currently done for which zone the ndd ioctl() is from. OK so it won't work for free, but it should be pretty easy to do with zone-specific data. Can you file an RFE? >I'll have to check within SNST about this as NCA may have been the only >consumer of this but I'm not sure, I'll file a bug on it. Actually I was wrong, it was introduced by PSARC 2000/155 as Consolidation Private (-> the bundled IP filter could use it). As it may be used in the future it can be left where it is. Blaise From sacadmin Tue Jan 25 08:00:32 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PG0Wac020666 for ; Tue, 25 Jan 2005 08:00:32 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PFxXCS005929; Tue, 25 Jan 2005 07:59:33 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PFxXSB020289; Tue, 25 Jan 2005 07:59:33 -0800 (PST) Message-Id: <200501251559.j0PFxXSB020289@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 07:59:33 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Blaise.Sanouillet@sun.com, Casper.Dik@sun.com, kacheong.poon@sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rB3tF23baNvYy0VgrTDrlA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 16:48:18 +0100 Casper.Dik@sun.com wrote: > >>What about zones? During the Zones bringup, we punted on NCA because making it >>work in a zone would involve reapplying the (largish) changes done in IP to NCA. >>But with this new design, it should work for free. So will running NL7C in a >>zone be supported? >> >>TCP exports a function-call interface tcp_reserved_port_*() to manipulate the >>reserved port list. It seems NCA is the sole consumer of this interface. I can't >>find any reference to it in the PSARC archives, the docs or the include files, >>however it's "public" according to this code comment: >>/* >> * The public interface for other modules to call to reserve a port range >> * in TCP. The caller passes in how large a port range it wants. TCP >> * will try to find a range and return it via lo_port and hi_port. This is >> * used by NCA's nca_conn_init. >> >>If it was never exposed outside of ON, and assuming NL7C removes the need for >>it, I'd like to see it removed by this case. > >Well, I very much like NAT in ipfiloter to use a similar interface; >currently NAT can assign ports which are free for the OS to use so >conflicts may arise. > >Casper It was added to tcp.c on 2000.04.06 as: "4319681: Need TCP support to reserve ports" Instead of removing perhaps we need to ARC it ? Brutus From sacadmin Tue Jan 25 08:10:35 2005 Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PGAYac020903 for ; Tue, 25 Jan 2005 08:10:35 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.Holland.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j0PG9ZE27252; Tue, 25 Jan 2005 17:09:35 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id j0PG9ZMa016363; Tue, 25 Jan 2005 17:09:35 +0100 (MET) Message-Id: <200501251609.j0PG9ZMa016363@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bruce Curtis cc: Blaise.Sanouillet@sun.com, kacheong.poon@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com Subject: Re: 2005/038 Network Layer 7 Cache In-Reply-To: <200501251559.j0PFxXSB020289@rotary.eng.sun.com> References: <200501251559.j0PFxXSB020289@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 17:09:35 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 322 >It was added to tcp.c on 2000.04.06 as: > > "4319681: Need TCP support to reserve ports" > >Instead of removing perhaps we need to ARC it ? Think so; for NAT we also use this support for UDP. It can be an interface for private use of ipfilter but since that is kinda external this would be, uhm interesting. Casper From sacadmin Tue Jan 25 08:12:56 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PGCuac021212 for ; Tue, 25 Jan 2005 08:12:56 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PGBxuL003107 for ; Tue, 25 Jan 2005 08:11:59 -0800 (PST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0PGBxdt010770 for ; Tue, 25 Jan 2005 09:11:59 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IAV00D4MRNYZ7@edgemail1.Central.Sun.COM> for psarc@sac.sfbay.sun.com; Tue, 25 Jan 2005 09:11:59 -0700 (MST) Received: from chocolate-chip-cookie.dme.org ([192.18.209.155]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IAV005EQRNXUN@mail.sun.net> for psarc@sac.sfbay.sun.com; Tue, 25 Jan 2005 09:11:58 -0700 (MST) Date: Tue, 25 Jan 2005 08:12:07 -0800 From: David Edmondson Subject: Re: 2005/038 Network Layer 7 Cache In-reply-to: <200501251534.j0PFYBSB020255@rotary.eng.sun.com> Sender: David.Edmondson@sun.com To: Bruce Curtis Cc: Blaise.Sanouillet@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (powerpc-apple-darwin7.7.0) Lines: 14 References: <200501251534.j0PFYBSB020255@rotary.eng.sun.com> Status: RO * brutus@rotary.eng.sun.com [2005-01-25 07:34:12] > NL7C like NCA uses config files in /etc/nca to specify which > addr/port pairs to parse new connection data for an HTTP request > (NL7C and NCA) and to spec log file size and name(s) so the backing > kernel structures would have to be indexed by the zone id which they > are not at present. In fact no check is currently done for which > zone the ndd ioctl() is from. Does this imply that enabling NCA in one zone might allow it to steal traffic from another zone? dme. -- David Edmondson, Solaris Engineering, Sun Microsystems. From sacadmin Tue Jan 25 08:17:54 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PGHsac021335 for ; Tue, 25 Jan 2005 08:17:54 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PGGtCS008190; Tue, 25 Jan 2005 08:16:55 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PGGtSB020305; Tue, 25 Jan 2005 08:16:55 -0800 (PST) Message-Id: <200501251616.j0PGGtSB020305@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 08:16:55 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Blaise.Sanouillet@sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZOv214QyU4xzF4vaHCm71Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 15:53:43 +0000 (GMT) wrote: > >>NL7C like NCA uses config files in /etc/nca to specify which addr/port pairs >>to parse new connection data for an HTTP request (NL7C and NCA) and to spec >>log file size and name(s) so the backing kernel structures would have to be >>indexed by the zone id which they are not at present. In fact no check is >>currently done for which zone the ndd ioctl() is from. > >OK so it won't work for free, but it should be pretty easy to do with >zone-specific data. Can you file an RFE? > Yup, should be very straight forward, I'll file an RFE (as soon as this one is putbac). >>I'll have to check within SNST about this as NCA may have been the only >>consumer of this but I'm not sure, I'll file a bug on it. > >Actually I was wrong, it was introduced by PSARC 2000/155 as Consolidation >Private (-> the bundled IP filter could use it). As it may be used in the future >it can be left where it is. > >Blaise Brutus From sacadmin Tue Jan 25 08:45:55 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PGjtac022168 for ; Tue, 25 Jan 2005 08:45:55 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PGiusd015553; Tue, 25 Jan 2005 08:44:56 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PGitSB020364; Tue, 25 Jan 2005 08:44:56 -0800 (PST) Message-Id: <200501251644.j0PGitSB020364@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 08:44:56 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Casper.Dik@sun.com Cc: Blaise.Sanouillet@sun.com, kacheong.poon@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5PEzzD+mXhlQQUD8biuXPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 17:09:35 +0100 Casper.Dik@sun.com wrote: > >>It was added to tcp.c on 2000.04.06 as: >> >> "4319681: Need TCP support to reserve ports" >> >>Instead of removing perhaps we need to ARC it ? > >Think so; for NAT we also use this support for UDP. > >It can be an interface for private use of ipfilter but since that >is kinda external this would be, uhm interesting. > >Casper Yup, looks like we should revisit the API and it's commitment level Brutus From sacadmin Tue Jan 25 08:56:59 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PGuwac025842 for ; Tue, 25 Jan 2005 08:56:58 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PGu0sd017137; Tue, 25 Jan 2005 08:56:00 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PGtxSB020376; Tue, 25 Jan 2005 08:55:59 -0800 (PST) Message-Id: <200501251655.j0PGtxSB020376@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 08:55:59 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: dme@sun.com Cc: Blaise.Sanouillet@sun.com, psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: M3LEW9sy3LjzTjsbqZXAvg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 08:12:07 -0800 David Edmondson wrote: > >* brutus@rotary.eng.sun.com [2005-01-25 07:34:12] >> NL7C like NCA uses config files in /etc/nca to specify which >> addr/port pairs to parse new connection data for an HTTP request >> (NL7C and NCA) and to spec log file size and name(s) so the backing >> kernel structures would have to be indexed by the zone id which they >> are not at present. In fact no check is currently done for which >> zone the ndd ioctl() is from. > >Does this imply that enabling NCA in one zone might allow it to steal >traffic from another zone? > >dme. >-- >David Edmondson, Solaris Engineering, Sun Microsystems. Steal, no. There are a couple of issues, 1st the startup/admin/config as NL7C isn't zones enabled, I'll add a global zones only check for the initial putback (until I file an RFE to make NL7C zones enabled), 2nd subsequent bind() listen() calls for all zones will simply be matched against the ncaport.conf entries or if an AF_NCA socket be NL7C_ENABLED such that subsequent accept()s will be processed, all responses are cached in a single global cache. Brutus From sacadmin Tue Jan 25 09:11:11 2005 Received: from bu-ewat02-01.uk.sun.com (sm-ewat02-01 [129.156.199.2]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PHB9ac026157 for ; Tue, 25 Jan 2005 09:11:10 -0800 (PST) Received: from sr-ewat02-01 (sr-ewat02-01.UK.Sun.COM [129.156.199.4]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id j0PHABZi010328; Tue, 25 Jan 2005 17:10:11 GMT Message-Id: <200501251710.j0PHABZi010328@bu-ewat02-01.uk.sun.com> Date: Tue, 25 Jan 2005 17:10:11 +0000 (GMT) From: Blaise Sanouillet - Sun Microsystems Reply-To: Blaise Sanouillet - Sun Microsystems Subject: Re: 2005/038 Network Layer 7 Cache To: dme@sun.com, brutus@rotary.eng.sun.com Cc: psarc@sac.sfbay.sun.com, james.d.carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tFTccwsPoIdtJzb9F1TKMw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_33 SunOS 5.10 sun4u sparc Status: RO >Steal, no. > >There are a couple of issues, 1st the startup/admin/config as NL7C isn't >zones enabled, I'll add a global zones only check for the initial putback >(until I file an RFE to make NL7C zones enabled), 2nd subsequent bind() >listen() calls for all zones will simply be matched against the ncaport.conf >entries or if an AF_NCA socket be NL7C_ENABLED such that subsequent accept()s >will be processed, all responses are cached in a single global cache. So, if two zones have their own /var/apache/htdocs/index.html, could a client get zone B's index.html when fetching http://zoneA/index.html ? If so additional checks will be needed. Blaise From sacadmin Tue Jan 25 09:55:52 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PHtpac000655 for ; Tue, 25 Jan 2005 09:55:51 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2) with ESMTP id j0PHsnEb023576; Tue, 25 Jan 2005 12:54:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j0PHsnKX023573; Tue, 25 Jan 2005 12:54:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16886.34793.423389.373021@gargle.gargle.HOWL> Date: Tue, 25 Jan 2005 12:54:49 -0500 From: James Carlson To: Blaise Sanouillet - Sun Microsystems Cc: David.Edmondson@Sun.COM, brutus@rotary.eng.sun.com, psarc@sac.sfbay.sun.com Subject: Re: 2005/038 Network Layer 7 Cache In-Reply-To: Blaise Sanouillet - Sun Microsystems's message of 25 January 2005 17:10:11 References: <200501251710.j0PHABZi010328@bu-ewat02-01.uk.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Blaise Sanouillet - Sun Microsystems writes: > So, if two zones have their own /var/apache/htdocs/index.html, could a client > get zone B's index.html when fetching http://zoneA/index.html ? If so additional > checks will be needed. Current NCA 'open' code (I think *I* added this sometime very early in Kevlar) checks for the global zone, and bails out if not true. At least that semantic should be preserved, if the project compatibility issue isn't just repaired (by making NL7C zones-aware). -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Jan 25 09:59:58 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PHxwac000904 for ; Tue, 25 Jan 2005 09:59:58 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PHwnCS023880; Tue, 25 Jan 2005 09:58:49 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PHwmhK020526; Tue, 25 Jan 2005 09:58:48 -0800 (PST) Message-Id: <200501251758.j0PHwmhK020526@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 09:58:48 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: dme@Sun.COM, Blaise.Sanouillet@Sun.COM Cc: psarc@sac.sfbay.sun.com, james.d.carlson@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DqYDcUnhXBKoNQvdynquFg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 17:10:11 +0000 (GMT) wrote: >>Steal, no. >> >>There are a couple of issues, 1st the startup/admin/config as NL7C isn't >>zones enabled, I'll add a global zones only check for the initial putback >>(until I file an RFE to make NL7C zones enabled), 2nd subsequent bind() >>listen() calls for all zones will simply be matched against the ncaport.conf >>entries or if an AF_NCA socket be NL7C_ENABLED such that subsequent accept()s >>will be processed, all responses are cached in a single global cache. > >So, if two zones have their own /var/apache/htdocs/index.html, could a client >get zone B's index.html when fetching http://zoneA/index.html ? If so additional >checks will be needed. > >Blaise Shouldn't be a problem, the cache is URI based, i.e. host name based so only if 2 or more zones were to have the same hostname would there be an issue. But, if each zone were for example to use localhost as the hostname (i.e. not to be confused with the node name but isntead the httpd configured name) would this be a problem. I could make a very minor change to the URI cache to include a listen()er cookie (the listen()er socket's vnode pointer ?), or perhaps the zoneid, the 1st would be most secure ? Brutus From sacadmin Tue Jan 25 10:07:36 2005 Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PI7aac001484 for ; Tue, 25 Jan 2005 10:07:36 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail2sun.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PI6bCS025097; Tue, 25 Jan 2005 10:06:37 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PI6ahK020529; Tue, 25 Jan 2005 10:06:36 -0800 (PST) Message-Id: <200501251806.j0PI6ahK020529@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 10:06:36 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: Blaise.Sanouillet@Sun.COM, james.d.carlson@Sun.COM Cc: David.Edmondson@Sun.COM, brutus@rotary.eng.sun.com, psarc@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dKoOzhWG/RvkoIt/MVqRgQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 12:54:49 -0500 James Carlson wrote: > >Blaise Sanouillet - Sun Microsystems writes: >> So, if two zones have their own /var/apache/htdocs/index.html, could a client >> get zone B's index.html when fetching http://zoneA/index.html ? If so additional >> checks will be needed. > >Current NCA 'open' code (I think *I* added this sometime very early in >Kevlar) checks for the global zone, and bails out if not true. At >least that semantic should be preserved, if the project compatibility >issue isn't just repaired (by making NL7C zones-aware). > Ok, sorry for the confussion, thanks James for the clarification, missed in my port and in code reviews was the global zone check, so I will add the global zone only check for putback and file an RFE for making NL7C zones aware. Brutus From sacadmin Tue Jan 25 10:19:23 2005 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PIJMac002164 for ; Tue, 25 Jan 2005 10:19:22 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PIIIJd016952; Tue, 25 Jan 2005 13:18:18 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id j0PIIIJW002437; Tue, 25 Jan 2005 13:18:18 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id j0PIIHtT002436; Tue, 25 Jan 2005 13:18:17 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2005/038 Network Layer 7 Cache From: Bill Sommerfeld To: Bruce Curtis Cc: David.Edmondson@sun.com, Blaise.Sanouillet@sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com In-Reply-To: <200501251758.j0PHwmhK020526@rotary.eng.sun.com> References: <200501251758.j0PHwmhK020526@rotary.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1106677096.2345.0.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 25 Jan 2005 13:18:17 -0500 Status: RO On Tue, 2005-01-25 at 12:58, Bruce Curtis wrote: > Shouldn't be a problem, the cache is URI based, i.e. host name based so only > if 2 or more zones were to have the same hostname would there be an issue. "localhost". From sacadmin Tue Jan 25 10:32:14 2005 Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.11.21]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PIWEac002831 for ; Tue, 25 Jan 2005 10:32:14 -0800 (PST) Received: from rotary.eng.sun.com (rotary.SFBay.Sun.COM [129.146.86.107]) by engmail1mpk.Eng.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PIVEsd004777; Tue, 25 Jan 2005 10:31:14 -0800 (PST) Received: from rotary (rotary [129.146.86.107]) by rotary.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id j0PIVEhK020666; Tue, 25 Jan 2005 10:31:14 -0800 (PST) Message-Id: <200501251831.j0PIVEhK020666@rotary.eng.sun.com> Date: Tue, 25 Jan 2005 10:31:14 -0800 (PST) From: Bruce Curtis Reply-To: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache To: sommerfeld@sun.com Cc: David.Edmondson@sun.com, Blaise.Sanouillet@sun.com, psarc@sac.sfbay.sun.com, James.D.Carlson@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: O24yjyBZA6OecUn2AG4Zng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_32 SunOS 5.10 sun4u sparc Status: RO On Tue, 25 Jan 2005 13:18:17 -0500 Bill Sommerfeld wrote: > >On Tue, 2005-01-25 at 12:58, Bruce Curtis wrote: > >> Shouldn't be a problem, the cache is URI based, i.e. host name based so only >> if 2 or more zones were to have the same hostname would there be an issue. > >"localhost". > See previous reply on enforcing global zone only in which case no problem. For the RFE to be filed on making NL7C zone aware the solution to multiple "localhost" http hostnames is to add to the URI qualifier state and lookup either a zoneid or even stronger protection a listen()er id (e.g. vnode_t address). Brutus From sacadmin Tue Jan 25 11:25:22 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0PJPMac006941 for ; Tue, 25 Jan 2005 11:25:22 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0PJOPuL010517; Tue, 25 Jan 2005 11:24:25 -0800 (PST) Received: from [129.146.83.218] (shield.SFBay.Sun.COM [129.146.83.218]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id j0PJOL811519; Tue, 25 Jan 2005 11:24:21 -0800 (PST) Message-ID: <41F69CE8.4040606@sun.com> Date: Tue, 25 Jan 2005 11:24:24 -0800 From: Kacheong Poon Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Bruce Curtis Subject: Re: 2005/038 Network Layer 7 Cache References: <200501251559.j0PFxXSB020289@rotary.eng.sun.com> <200501251609.j0PG9ZMa016363@vaticaan.Holland.Sun.COM> In-Reply-To: <200501251609.j0PG9ZMa016363@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Casper.Dik@sun.com wrote: >>It was added to tcp.c on 2000.04.06 as: >> >> "4319681: Need TCP support to reserve ports" >> >>Instead of removing perhaps we need to ARC it ? > > > Think so; for NAT we also use this support for UDP. > > It can be an interface for private use of ipfilter but since that > is kinda external this would be, uhm interesting. When the PSARC case was filed in 2000, the only user was NCA. And this is still the case. There were some talks about using it by another ON module. But it was never materialized. The interface classification was consolidation private as it satisfied the need then. And there was no request for UDP use (it was supposed to be an RFE, which was never filed). If ipfilter wants to use it, the classification can be changed and UDP support added. -- K. Poon. kacheong.poon@sun.com From sacadmin Fri Jan 7 14:43:32 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j07MhWac011778 for ; Fri, 7 Jan 2005 14:43:32 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.89.31]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j07Mghh03753; Fri, 7 Jan 2005 14:42:43 -0800 (PST) Received: from jeckle (vpn-129-150-28-181.SFBay.Sun.COM [129.150.28.181]) by jurassic.eng.sun.com (8.13.2+Sun/8.13.2) with SMTP id j07MgVQp466640; Fri, 7 Jan 2005 14:42:37 -0800 (PST) Message-Id: <200501072242.j07MgVQp466640@jurassic.eng.sun.com> Date: Fri, 7 Jan 2005 12:46:56 -1000 (HST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: LSARC 2004/713 - GNOME 2.6 - Cinnabar Heavy - Was: Re: [Fwd: Re: [Fwd: JDS about box in Solaris 10 - is it approved?]] To: Joseph.Kowalski@Sun.COM, Brian.Cameron@Sun.COM Cc: Joseph.Kowalski@Sun.COM, Alan.Coopersmith@Sun.COM, Sin-Yaw.Wang@Sun.COM, Dan.Baigent@Sun.COM, Robert.Odea@Sun.COM, kalpesh.shah@wipro.com, balamurali.viswanathan@wipro.com, Karl.Gaffney@Sun.COM, lsarc@Sun.COM, sun-sac-foss-ext@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 57RkyT9YleLzUdmKQSLc0w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_73 SunOS 5.10 sun4u sparc Status: RO Content-Length: 1497 > From: Brian Cameron ... > Actually, I agree with you. Returning gnome-about so it just displays > the community list of contributors would be a reasonable change, for the > reasons you give. However, do note that some Sun employees are in the > community list as well. I don't think its a problem if there names have been "integrated" into the community list (legal might think otherwise - I donno). Hopefully, this is a reflection of work done on their personal time and not Sun's time. (I'll take a "don't ask, don't tell" view.) Pragmatically, if there is something wrong here, well,... too late.... The don't remove an external attribution policy *is* written down. > I think the reason that additional Sun > employees were added was because there were a number of people who > contribute at Sun who wanted their names added but weren't connected > enough with the code to know how to go about getting their names > added. Especially people in QA, docs, management, etc. The current > fork was an effort to help not make them feel left out, but it would > probably be better if people made more of an effort to get their names > into the community CVS if they want a personal attribute. Another problem with attribution lists (I discussed in private mail), is that you can never get the list right. Somebody will almays feel: "If Fred is listed, I should be listed!" (any resemblence to any real "Fred" on the list is purly coincidental). - jek3 From sacadmin Wed Jan 26 13:42:54 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0QLgsac005988 for ; Wed, 26 Jan 2005 13:42:54 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2) with ESMTP id j0QLfvRI028175; Wed, 26 Jan 2005 16:41:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.2+Sun/8.13.2/Submit) id j0QLfvNH028172; Wed, 26 Jan 2005 16:41:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16888.3749.135104.318709@gargle.gargle.HOWL> Date: Wed, 26 Jan 2005 16:41:57 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: Bruce.Curtis@Sun.COM Subject: 2005/038 Network Layer 7 Cache X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Here's the updated specification culled from the email record. The notable item here is that having an SMF manifest is listed as a future item (this case does not define an FMRI for the service), and the submitter will file an RFE for this. As discussed during ARC business today, the submitter would like to close as soon as possible on this. Please let me know by close of business today (Wednesday, January 26th) if you need more time. Overview ======== RFE 6209091 NL7C (Network Layer 7 Cache) proposes to complete the integration of NCA, LSARC/1998/373 Solaris Network Cache and Accelerator, into the kernel with a patch/micro release binding. Note, the integration of NCA into the kernel was started as part of the FireEngine project, PSARC/2002/433, with the implementation of NCA's protocol stack framework and IP/TCP design. NL7C completes the integration of NCA into the kernel by porting NCA's HTTP layer and object cache into the sockfs kernel module. NL7C maintains all of NCA's configuration, administration, and APIs such that the user will experience little change from previous releases with the stability level of the NCA interfaces remaining the same (Evolving). NL7C is targeted for an update of S10. NL7C's main benefit is the reduction of code as NL7C relies on the core protocol IP/TCP stack instead of a dedicated and duplicate stack. Note, the NCA protocol stack is removed. NL7C interposes on the sockfs/AF_INET/tcp control and data paths such that coordination with other projects in the sockfs space will be done as necessary, e.g. Clearwater (2003/146), Yellowdart (2003/182), and SDP (2004/298). NL7C does not have feature interactions with IPsec, IPMP, routing, or other basic networking components. It operates as a cache logically at the application layer. A socket is a socket. Like NCA, NL7C works only in the global zone, and this is enforced by the driver interfaces. A future project should address the Zones limitation. Ndd === The nca kmod and driver remain for servicing of ndd ioctl()s from either ndd(1M) or other application ioctl() cals. Only the nca specific variables are serviced while all others "tcp_*" and "ip_*" variables return an obsoleted message referring the user to use the appropriate "/dev/tcp" or "/dev/ip" ndd variable. Alternative Designs =================== Alternatives to installing into sockfs were considered, e.g. as part of Clearwater an interpose on the fly could've been done, but as Clearwater was shelved. This would have taken NCA's http/tcp/ip design and implementing an http layer as part of the current FireEngine tcp/ip kmod. The welding of NCA functionality to sockfs was chosen as the best place to support an L7 cache. If in a future sockfs were socket interpose can be done the small amount of code used to do the weld can be replaced with the appropriate interpose code. There are about 300 lines of code changes such that if NCA is disabled (the default), then no change to control/data flow of a socket. If NCA is enabled then, based on the NCA configuration (/etc/nca/ncaport.conf) specified ipaddr/port pairs or if the listen() socket is of AF_NCA, then NL7C will interpose. An accept()ing socket is marked for NL7C interpose, subsequent read-side data is http parsed for cache lookup, in the case of a cache hit the response is generated without application interaction. In the case of a miss, the socket is marked for cache fill and the request passed up to the application and subsequent write-side data is cached while being processed as normal by the sockfs code. In the case of a miss but not a request that NL7C is interested in then the socket NL7C state is cleared and the request/response is handled by the application. Future ====== Support for NCAS (NCA SSL, Secure Socket Layer) functionality as part of the Greyhoung project, PSARC/2002/557. Tentative plans call for additional L7 protocol support, e.g. ftp, to be explored. PSARC case(s) to be filed. NL7C configuration, administration, and programmatic interfaces, at which time NCA can be depreciated. NL7C should be enhanced to use SMF. NL7C should support web servers running in zones other than the global zone. Supporting Documentation ======================== See http://NL7C.eng.Sun.COM for additional details. (None of this material is normative for the case.) -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677