From owner-wrec@cs.utk.edu Wed Nov 1 16:37:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06369 for ; Wed, 1 Nov 2000 16:37:42 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA03290; Wed, 1 Nov 2000 16:31:12 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 1 Nov 2000 16:30:26 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA03092; Wed, 1 Nov 2000 16:30:25 -0500 (EST) Received: from mail-blue.research.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA03066; Wed, 1 Nov 2000 16:30:18 -0500 (EST) Received: from mail-blue.research.att.com (135.207.30.102 -> mail-blue.research.att.com) by cs.utk.edu (smtpshim v1.0); Wed, 1 Nov 2000 16:30:18 -0500 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 1E9374CE02 for ; Wed, 1 Nov 2000 16:30:07 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA18851 for ; Wed, 1 Nov 2000 16:30:02 -0500 (EST) From: michael rabinovich Received: (from misha@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id QAA21447 for wrec@cs.utk.edu; Wed, 1 Nov 2000 16:30:03 -0500 (EST) Date: Wed, 1 Nov 2000 16:30:03 -0500 (EST) Message-Id: <200011012130.QAA21447@fish-ha.research.att.com> To: wrec@cs.utk.edu Subject: Call for papers: 6th Web Caching and Content Delivery Workshop List-Unsubscribe: ---------------------------------------------------------------------- Sixth International Web Caching and Content Delivery Workshop Boston University, Boston, Massachusetts, USA June 20-22, 2001 http://www.cs.bu.edu/pub/wcw01 ---------------------------------------------------------------------- Overview -------- The International Workshop on Web Caching and Content Delivery (WCW) is a premiere technical meeting for researchers and practitioners interested in all aspects of content caching, distribution and delivery on the Internet. This year's meeting will be held in Boston (tentatively on the Boston University Campus) and will build on the successes of the five previous WCW meetings. We anticipate a strong technical program, exhibitions by leading vendors, and participation from leading researchers and practitioners in the field. Please refer to the various sections of this web site for more information. Important Deadlines and Dates ----------------------------- 2001/01/08: Submission of full technical papers 2001/02/12: Submission of R&D synopses and BOF proposals 2001/03/19: Acceptance of papers, synopses, and BOF proposals 2001/04/30: Camera-Ready copy of accepted papers and synopses 2001/06/20: Workshop starts! Call for Papers --------------- The 6th International Workshop on Web Caching and Content Delivery solicits technical papers as well as short synopses addressing various issues on the state-of-the-art in Web Caching and Content Distribution technologies. Topics of interest include (but are not limited to): + Web Caching Architectures + Cache Management Algorithms + Streaming Media Caching and Distribution + Application and Dynamic Content Caching + Consistency Management + Replication Strategies + Content Distribution Networks Architectures and Protocols + Workload Analysis and Characterization + Benchmarking + Content Peering and Alliances + Standardization/Interoperability Proposals (e.g. NECP, iCAP) + Deployment Experiences Submission Guidelines --------------------- Technical Papers Technical papers describing previously unpublished research results are solicited. Although we will give appropriate consideration to all submissions, we expect to favor submissions with new, if not entirely fleshed out, ideas over meticulous but incremental work. Paper manuscripts should not exceed 5,000 words, and should not have been previously published (or be under consideration for publication) in part or in full. Manuscripts must be submitted electronically in printable postscript or PDF form. All submissions will be reviewed by the Program Committee members for appropriateness to the workshop, for originality, and for technical merits. Accepted papers will be presented at the workshop and published in the workshop proceedings, which will appear as a special issue of a leading journal (details will be posted on the workshop's web page). The deadline for technical paper submissions is January 8, 2001. Details of the submission procedure will be posted on the workshop's web page in due time. Research and Development Synopses Short abstracts describing experiences with experimental or commercial systems or works in progress are solicited. Synopsis manuscripts should not exceed 10 double-spaced pages ( including figures and tables). Manuscripts must be submitted electronically in printable postscript or PDF form. All submissions will be reviewed by the Program Committee members for appropriateness to the workshop. Accepted synopses will be presented at the workshop and will be published in the workshop proceedings. The deadline for accepting research and development synopsis submissions is February 12, 2001. Details of the submission procedure will be posted on this page in due time. Proposals for Panel and BOF Sessions Proposals for Panels and BOF sessions are solicited. Please send proposals to the Program Committee co-chairs. The deadline for accepting research and development synopsis submissions is February 12, 2001. Workshop Organization --------------------- Program Committee Chairs: + Azer Bestavros (CS Dept, Boston University) + Michael Rabinovich (AT&T Research) Program Committee Members: + Virgilio Almeida (Federal University of Minas Gerais, Brazil) + Chet Birger (Adero Inc) + John Byers (CS Dept, Boston University) + Jeff Chase (CS Dept, Duke University) + Mark Crovella (Network Appliance & CS Dept, Boston University) + Arun Iyengar (IBM TJ Watson Research Center) + Mike Dahlin (University of Texas, Austin) + Balanchander Krishnamurthy (AT&T Research) + Steve McCanne (FastForward Networks) + Jeff Mogul (Compaq Western Research Lab) + Keith Ross (Eurocomm Institute) + Gary Tomlison (Entera Inc.) + Craig Wills (CS Dept, Worcester Polytechnic Institute) Steering Committee: + Pei Cao, Cisco + Valentino Cavalli, Terena + Peter Danzig, Akamai Technologies + John Martin, Network Appliance + Wojtek Sylwestrzak, Warsaw University + Duane Wessels, NLANR ---------------------------------------------------------------------- For updated information about the workshop please refer to the workshop's web page at http://www.cs.bu.edu/pub/wcw01 ---------------------------------------------------------------------- From owner-wrec@cs.utk.edu Fri Nov 3 15:16:00 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05212 for ; Fri, 3 Nov 2000 15:15:45 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA09565; Fri, 3 Nov 2000 15:11:04 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 3 Nov 2000 15:10:41 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA09530; Fri, 3 Nov 2000 15:10:41 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA09512; Fri, 3 Nov 2000 15:10:37 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Fri, 3 Nov 2000 15:10:38 -0500 Received: from icooper.equinix.com (tunnel2-9.corp.equinix.com [172.16.252.9]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id MAA05222; Fri, 3 Nov 2000 12:10:28 -0800 (PST) Message-Id: <5.0.0.25.2.20001103194204.00a8ddd0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 03 Nov 2000 20:10:26 +0000 To: wrec@cs.utk.edu From: Ian Cooper Subject: Candidate re-charter/new WG Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Now that we appear to have gotten to the end of the WREC work items (there will be a new version of the Known Problems document - just changing the order of things as an outcome of the Pittsburgh meeting - submitted in the next few days), we need to decide how to move on. Below is a candidate (re)charter to take WREC forward as the "Web Infrastructure" group (thanks to those who have given input of their varying types). As you'll see, the idea is to take on two work items that we believe are essential for web infrastructure going forward. There is some cross over with the invalidation protocol with the CDNP folks. Since such a protocol is applicable to both areas, and since the CDNP folks look to have plenty of other interesting things to work on, WREC/WEBI appears to be a good place to work on this essential issue. Likewise, there is some degree of cross over with the intermediary discovery protocol. In order to have some hope of moving away from interception proxy environments, we need to help user agents find intermediates (proxies, extensible proxies, surrogates). Given that this is an area where two proposed WGs (CDNP, OPES) would also have an interest, and since it doesn't appear to be directly in scope for either, we feel that WREC/WEBI is the best place for this. Why the name change? As (caching) proxies and surrogates become essential components in the web infrastructure we need to examine interactions between these systems. "Web Replication and Caching" doesn't seem a sufficiently descriptive group name. There also appears to be a general feeling of WREC=bad (and the name when spoken doesn't help any) that we'd like to try and move away from. At present it's not totally clear whether we should be going direct to a working group in San Diego, or whether we should go through a BoF stage to discuss the area and determine whether the group is necessary (and if not where the work items should be handled). Apologies for the short notice, but obviously we need to get an idea of what we're doing in time to request a meeting in San Diego. Truncating the distribution to the WREC list (the "webi" list has *not* been set up yet) would probably be a good idea. (I'd set a Reply-To but I don't know how to drive that part of my mail agent ;-) ) Comments please! --------------------------->8------------------------------------------- Web Infrastructure (webi) Co-chairs: Mark Nottingham Ian Cooper Mailing Lists: [TENTATIVE] General Discussion: webi@equinix.com To Subscribe: webi-request@equinix.com Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi Description of Working Group: This working group will address specific issues identified by the WREC working group in the world wide web infrastructure, providing generic mechanisms which are useful in several application domains (proxies, content delivery surrogates). Work items for this group will be: 1) An invalidation protocol to provide a strong cache coherence mechanism while avoiding the latency penalty of validation, usable in proxy as well as surrogate configurations. 2) An intermediate service discovery mechanism, consisting of: a) An intermediary service description format, which describes what services an intermediary or arbitrary group of intermediaries is willing to provide, and b) A discovery protocol for locating relevant service descriptions within a single administrative domain. Both components will take into consideration current practice, related work in the IETF, and a reasoned set of requirements, which will include the need to provide a reasonable alternative to interception proxies. Service discovery, and other issues pertaining to coordination between multiple administrative domains are explicitly out of scope of this group. Protocols associated with the provisioning of value added services, including the vectoring of adaptation requests to other devices, is also out of scope for this group. Goals and Milestones: Feb 01: Requirements document for intermediary discovery and description Feb 01: First draft invalidation protocol Mar 01: Meet at Minneapolis IETF Apr 01: First draft intermediary discovery protocol Jul 01: First draft intermediary description mechanism Aug 01: Meet at London IETF Dec 01: Invalidation protocol finalized Dec 01: Salt Lake City Jan 02: Intermediary discovery protocol finalized Mar 02: Intermediary description mechanism finalized Apr 02: Re-charter From owner-wrec@cs.utk.edu Fri Nov 3 16:38:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02687 for ; Fri, 3 Nov 2000 16:38:50 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA19042; Fri, 3 Nov 2000 16:34:43 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 3 Nov 2000 16:34:40 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA19008; Fri, 3 Nov 2000 16:34:39 -0500 (EST) Received: from thalia.fm.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA18976; Fri, 3 Nov 2000 16:34:35 -0500 (EST) Received: from thalia.fm.intel.com (132.233.247.11 -> thalia.fm.intel.com) by cs.utk.edu (smtpshim v1.0); Fri, 3 Nov 2000 16:34:36 -0500 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id VAA01279; Fri, 3 Nov 2000 21:35:45 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 03 Nov 2000 21:34:28 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Nov 2000 13:34:26 -0800 Message-ID: From: "Maciocco, Christian" To: wrec@cs.utk.edu, cdn@ops.ietf.org Subject: RE: Candidate re-charter/new WG Date: Fri, 3 Nov 2000 13:34:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA02687 Are these sessions/BOFs already scheduled? I didn't find anything at http://www.ietf.org/meetings/agenda.html Thanks Christian > -----Original Message----- > From: Ian Cooper [mailto:icooper@equinix.com] > Sent: Friday, November 03, 2000 12:10 PM > To: wrec@cs.utk.edu > Cc: Patrik Fältström; Ned Freed; cdn@ops.ietf.org; > ietf-openproxy@imc.org > Subject: Candidate re-charter/new WG > > > Now that we appear to have gotten to the end of the WREC work > items (there > will be a new version of the Known Problems document - just > changing the > order of things as an outcome of the Pittsburgh meeting - > submitted in the > next few days), we need to decide how to move on. > > Below is a candidate (re)charter to take WREC forward as the "Web > Infrastructure" group (thanks to those who have given input of their > varying types). As you'll see, the idea is to take on two > work items that > we believe are essential for web infrastructure going forward. > > There is some cross over with the invalidation protocol with the CDNP > folks. Since such a protocol is applicable to both areas, > and since the > CDNP folks look to have plenty of other interesting things to > work on, > WREC/WEBI appears to be a good place to work on this essential issue. > > Likewise, there is some degree of cross over with the intermediary > discovery protocol. In order to have some hope of moving away from > interception proxy environments, we need to help user agents find > intermediates (proxies, extensible proxies, surrogates). > Given that this > is an area where two proposed WGs (CDNP, OPES) would also > have an interest, > and since it doesn't appear to be directly in scope for > either, we feel > that WREC/WEBI is the best place for this. > > Why the name change? As (caching) proxies and surrogates > become essential > components in the web infrastructure we need to examine interactions > between these systems. "Web Replication and Caching" doesn't seem a > sufficiently descriptive group name. There also appears to > be a general > feeling of WREC=bad (and the name when spoken doesn't help > any) that we'd > like to try and move away from. > > At present it's not totally clear whether we should be going > direct to a > working group in San Diego, or whether we should go through a > BoF stage to > discuss the area and determine whether the group is necessary > (and if not > where the work items should be handled). > > Apologies for the short notice, but obviously we need to get > an idea of > what we're doing in time to request a meeting in San Diego. > Truncating the > distribution to the WREC list (the "webi" list has *not* been > set up yet) > would probably be a good idea. (I'd set a Reply-To but I > don't know how to > drive that part of my mail agent ;-) ) > > Comments please! > > > --------------------------->8--------------------------------- > ---------- > > Web Infrastructure (webi) > > Co-chairs: > Mark Nottingham > Ian Cooper > > Mailing Lists: [TENTATIVE] > General Discussion: webi@equinix.com > To Subscribe: webi-request@equinix.com > Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi > > Description of Working Group: > > This working group will address specific issues identified by > the WREC > working group in the world wide web infrastructure, providing generic > mechanisms which are useful in several application domains (proxies, > content delivery surrogates). > > Work items for this group will be: > > 1) An invalidation protocol to provide a strong cache > coherence mechanism > while avoiding the latency penalty of validation, usable > in proxy as well > as surrogate configurations. > > 2) An intermediate service discovery mechanism, consisting of: > > a) An intermediary service description format, which describes what > services an intermediary or arbitrary group of intermediaries is > willing to provide, and > > b) A discovery protocol for locating relevant service > descriptions within > a single administrative domain. > > Both components will take into consideration current > practice, related > work in the IETF, and a reasoned set of requirements, > which will include > the need to provide a reasonable alternative to > interception proxies. > > Service discovery, and other issues pertaining to > coordination between > multiple administrative domains are explicitly out of scope > of this group. > > Protocols associated with the provisioning of value added services, > including the vectoring of adaptation requests to other > devices, is also > out of scope for this group. > > > Goals and Milestones: > > Feb 01: Requirements document for intermediary discovery and > description > Feb 01: First draft invalidation protocol > Mar 01: Meet at Minneapolis IETF > Apr 01: First draft intermediary discovery protocol > Jul 01: First draft intermediary description mechanism > Aug 01: Meet at London IETF > Dec 01: Invalidation protocol finalized > Dec 01: Salt Lake City > Jan 02: Intermediary discovery protocol finalized > Mar 02: Intermediary description mechanism finalized > Apr 02: Re-charter > > > From owner-wrec@cs.utk.edu Fri Nov 3 19:32:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12370 for ; Fri, 3 Nov 2000 19:32:22 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA03652; Fri, 3 Nov 2000 19:27:09 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 3 Nov 2000 19:27:01 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA03617; Fri, 3 Nov 2000 19:27:00 -0500 (EST) Received: from mnot.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA03573; Fri, 3 Nov 2000 19:26:53 -0500 (EST) Received: from mnot.sanmateo.akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Fri, 3 Nov 2000 19:26:58 -0500 Received: by mnot.sanmateo.akamai.com (Postfix, from userid 20351) id 9A2085037; Fri, 3 Nov 2000 16:26:47 -0800 (PST) Date: Fri, 3 Nov 2000 16:26:47 -0800 From: Mark Nottingham To: "Maciocco, Christian" Cc: wrec@cs.utk.edu, cdn@ops.ietf.org Subject: Re: Candidate re-charter/new WG Message-ID: <20001103162646.I28582@akamai.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from christian.maciocco@intel.com on Fri, Nov 03, 2000 at 01:34:11PM -0800 List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by cs.utk.edu id TAA03652 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12370 No. All of them intend to meet in San Diego, but are still in various stages of the meeting request process (AFAIK). The immediate issue with WEBI is whether to request a WG and hence a WG meeting, or a BoF. Because WEBI's work is a direct outgrowth of WREC, it is possible to re-charter WREC into WEBI as a WG. OTOH, it might be more appropriate to request a BoF to determine interest in the work items listed, if it isn't clear that these are appropriate. We believe they are appropriate, neccessary and widely interesting work items, based on the output of WREC as well as other work in these areas. However, it would be Good if we could get clear statements of support (or dissent) for this charter from interested parties. Simple "yes, that seems like a good idea/no, don't go and do that" answers would be much appreciated; we just want to gather some amount of consensus going into this. On Fri, Nov 03, 2000 at 01:34:11PM -0800, Maciocco, Christian wrote: > Are these sessions/BOFs already scheduled? I didn't find anything at > http://www.ietf.org/meetings/agenda.html > > Thanks > Christian > > > -----Original Message----- > > From: Ian Cooper [mailto:icooper@equinix.com] > > Sent: Friday, November 03, 2000 12:10 PM > > To: wrec@cs.utk.edu > > Cc: Patrik Fältström; Ned Freed; cdn@ops.ietf.org; > > ietf-openproxy@imc.org > > Subject: Candidate re-charter/new WG > > > > > > Now that we appear to have gotten to the end of the WREC work > > items (there > > will be a new version of the Known Problems document - just > > changing the > > order of things as an outcome of the Pittsburgh meeting - > > submitted in the > > next few days), we need to decide how to move on. > > > > Below is a candidate (re)charter to take WREC forward as the "Web > > Infrastructure" group (thanks to those who have given input of their > > varying types). As you'll see, the idea is to take on two > > work items that > > we believe are essential for web infrastructure going forward. > > > > There is some cross over with the invalidation protocol with the CDNP > > folks. Since such a protocol is applicable to both areas, > > and since the > > CDNP folks look to have plenty of other interesting things to > > work on, > > WREC/WEBI appears to be a good place to work on this essential issue. > > > > Likewise, there is some degree of cross over with the intermediary > > discovery protocol. In order to have some hope of moving away from > > interception proxy environments, we need to help user agents find > > intermediates (proxies, extensible proxies, surrogates). > > Given that this > > is an area where two proposed WGs (CDNP, OPES) would also > > have an interest, > > and since it doesn't appear to be directly in scope for > > either, we feel > > that WREC/WEBI is the best place for this. > > > > Why the name change? As (caching) proxies and surrogates > > become essential > > components in the web infrastructure we need to examine interactions > > between these systems. "Web Replication and Caching" doesn't seem a > > sufficiently descriptive group name. There also appears to > > be a general > > feeling of WREC=bad (and the name when spoken doesn't help > > any) that we'd > > like to try and move away from. > > > > At present it's not totally clear whether we should be going > > direct to a > > working group in San Diego, or whether we should go through a > > BoF stage to > > discuss the area and determine whether the group is necessary > > (and if not > > where the work items should be handled). > > > > Apologies for the short notice, but obviously we need to get > > an idea of > > what we're doing in time to request a meeting in San Diego. > > Truncating the > > distribution to the WREC list (the "webi" list has *not* been > > set up yet) > > would probably be a good idea. (I'd set a Reply-To but I > > don't know how to > > drive that part of my mail agent ;-) ) > > > > Comments please! > > > > > > --------------------------->8--------------------------------- > > ---------- > > > > Web Infrastructure (webi) > > > > Co-chairs: > > Mark Nottingham > > Ian Cooper > > > > Mailing Lists: [TENTATIVE] > > General Discussion: webi@equinix.com > > To Subscribe: webi-request@equinix.com > > Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi > > > > Description of Working Group: > > > > This working group will address specific issues identified by > > the WREC > > working group in the world wide web infrastructure, providing generic > > mechanisms which are useful in several application domains (proxies, > > content delivery surrogates). > > > > Work items for this group will be: > > > > 1) An invalidation protocol to provide a strong cache > > coherence mechanism > > while avoiding the latency penalty of validation, usable > > in proxy as well > > as surrogate configurations. > > > > 2) An intermediate service discovery mechanism, consisting of: > > > > a) An intermediary service description format, which describes what > > services an intermediary or arbitrary group of intermediaries is > > willing to provide, and > > > > b) A discovery protocol for locating relevant service > > descriptions within > > a single administrative domain. > > > > Both components will take into consideration current > > practice, related > > work in the IETF, and a reasoned set of requirements, > > which will include > > the need to provide a reasonable alternative to > > interception proxies. > > > > Service discovery, and other issues pertaining to > > coordination between > > multiple administrative domains are explicitly out of scope > > of this group. > > > > Protocols associated with the provisioning of value added services, > > including the vectoring of adaptation requests to other > > devices, is also > > out of scope for this group. > > > > > > Goals and Milestones: > > > > Feb 01: Requirements document for intermediary discovery and > > description > > Feb 01: First draft invalidation protocol > > Mar 01: Meet at Minneapolis IETF > > Apr 01: First draft intermediary discovery protocol > > Jul 01: First draft intermediary description mechanism > > Aug 01: Meet at London IETF > > Dec 01: Invalidation protocol finalized > > Dec 01: Salt Lake City > > Jan 02: Intermediary discovery protocol finalized > > Mar 02: Intermediary description mechanism finalized > > Apr 02: Re-charter > > > > > > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Sat Nov 4 12:26:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15077 for ; Sat, 4 Nov 2000 12:26:25 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA24317; Sat, 4 Nov 2000 12:22:26 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 4 Nov 2000 12:22:14 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA24232; Sat, 4 Nov 2000 12:22:13 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA24186; Sat, 4 Nov 2000 12:22:11 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Sat, 4 Nov 2000 12:22:11 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 11A35B5; Sat, 4 Nov 2000 18:22:06 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22172; Sat, 4 Nov 2000 18:21:58 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: References: Date: Sat, 4 Nov 2000 12:19:25 -0500 To: "Maciocco, Christian" , wrec@cs.utk.edu, cdn@ops.ietf.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Candidate re-charter/new WG Cc: Leslie Daigle , Michael Mealling Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 13.34 -0800 00-11-03, Maciocco, Christian wrote: >Are these sessions/BOFs already scheduled? I didn't find anything at >http://www.ietf.org/meetings/agenda.html No firm scheduling yet. I have only got a request for BOF formaly from OPES people, but expect others to send me a request ASAP (please do so!). If you ask what day the meetings will be, the response is that I have reserved tuesday afternoon 4 1-hour slots for these three BOFs + one BOF on naming issues which spring from the URN/CNRP wgs in the IETF and the HANDLE/DOI projects outside of the IETF. So, tuesday afternoon is what I aim at for meetings on these topics. I explicitly wanted the meetings close to each other and not overlapping as it might happen that some tasks which at first end up at one meeting actually should be discussed in another. I.e. in some way one can see these 4 meetings as one really long one about web issues. Patrik From owner-wrec@cs.utk.edu Sat Nov 4 12:54:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15078 for ; Sat, 4 Nov 2000 12:26:25 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA24339; Sat, 4 Nov 2000 12:22:27 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 4 Nov 2000 12:22:15 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA24281; Sat, 4 Nov 2000 12:22:15 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA24220; Sat, 4 Nov 2000 12:22:12 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Sat, 4 Nov 2000 12:22:13 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 71AC2E8; Sat, 4 Nov 2000 18:22:11 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA22181; Sat, 4 Nov 2000 18:22:08 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: <20001103162646.I28582@akamai.com> References: <20001103162646.I28582@akamai.com> Date: Sat, 4 Nov 2000 12:19:27 -0500 To: Mark Nottingham , "Maciocco, Christian" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Candidate re-charter/new WG Cc: wrec@cs.utk.edu, cdn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 16.26 -0800 00-11-03, Mark Nottingham wrote: >The immediate issue with WEBI is whether to request a WG and hence a WG >meeting, or a BoF. Two different things: "create a wg" and "ask for a slot". The IESG will make this decision. You should: - Request a slot (which will end up being tuesday afternoon) - Send in the new charter and say it is an update (to me) IESG will decide if a BOF / new working group is needed, or if rechartering is the only thing which is needed. But, of course, as always, IESG is happy to recieve input on what the community things. Don't let this delay you creating an agenda for the meeting though. paf From owner-wrec@cs.utk.edu Sun Nov 5 04:07:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00624 for ; Sun, 5 Nov 2000 04:07:50 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA01439; Sun, 5 Nov 2000 04:03:49 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 04:03:40 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA01398; Sun, 5 Nov 2000 04:03:39 -0500 (EST) Received: from omega.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA01385; Sun, 5 Nov 2000 04:03:37 -0500 (EST) Received: from omega.cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 04:03:37 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA20976; Sun, 5 Nov 2000 01:03:11 -0800 (PST) Message-Id: <4.2.0.58.20001105000719.02331460@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 05 Nov 2000 01:06:23 -0700 To: Ian Cooper , wrec@cs.utk.edu From: Dan Li Subject: Re: Candidate re-charter/new WG Cc: Patrik =?iso-8859-1?Q?Fdltstrvm?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org In-Reply-To: <5.0.0.25.2.20001103194204.00a8ddd0@nemo.corp.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: I think it's a good idea to have a focused forum to get something done. A web cache invalidation protocol will bring much value to reverse proxies (surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is a good thing. Whatever WREC is bad for, I hope the execution of WEBI would remove any residue of that. At 08:10 PM 11/3/00 +0000, Ian Cooper wrote: >Now that we appear to have gotten to the end of the WREC work items (there >will be a new version of the Known Problems document - just changing the >order of things as an outcome of the Pittsburgh meeting - submitted in the >next few days), we need to decide how to move on. > >Below is a candidate (re)charter to take WREC forward as the "Web >Infrastructure" group (thanks to those who have given input of their >varying types). As you'll see, the idea is to take on two work items that >we believe are essential for web infrastructure going forward. > >There is some cross over with the invalidation protocol with the CDNP >folks. Since such a protocol is applicable to both areas, and since the >CDNP folks look to have plenty of other interesting things to work on, >WREC/WEBI appears to be a good place to work on this essential issue. > >Likewise, there is some degree of cross over with the intermediary >discovery protocol. In order to have some hope of moving away from >interception proxy environments, we need to help user agents find >intermediates (proxies, extensible proxies, surrogates). Given that this >is an area where two proposed WGs (CDNP, OPES) would also have an >interest, and since it doesn't appear to be directly in scope for either, >we feel that WREC/WEBI is the best place for this. > >Why the name change? As (caching) proxies and surrogates become essential >components in the web infrastructure we need to examine interactions >between these systems. "Web Replication and Caching" doesn't seem a >sufficiently descriptive group name. There also appears to be a general >feeling of WREC=bad (and the name when spoken doesn't help any) that we'd >like to try and move away from. > >At present it's not totally clear whether we should be going direct to a >working group in San Diego, or whether we should go through a BoF stage to >discuss the area and determine whether the group is necessary (and if not >where the work items should be handled). > >Apologies for the short notice, but obviously we need to get an idea of >what we're doing in time to request a meeting in San Diego. Truncating >the distribution to the WREC list (the "webi" list has *not* been set up >yet) would probably be a good idea. (I'd set a Reply-To but I don't know >how to drive that part of my mail agent ;-) ) > >Comments please! > > >--------------------------->8------------------------------------------- > >Web Infrastructure (webi) > >Co-chairs: > Mark Nottingham > Ian Cooper > >Mailing Lists: [TENTATIVE] > General Discussion: webi@equinix.com > To Subscribe: webi-request@equinix.com > Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi > >Description of Working Group: > >This working group will address specific issues identified by the WREC >working group in the world wide web infrastructure, providing generic >mechanisms which are useful in several application domains (proxies, >content delivery surrogates). > >Work items for this group will be: > >1) An invalidation protocol to provide a strong cache coherence mechanism > while avoiding the latency penalty of validation, usable in proxy as well > as surrogate configurations. > >2) An intermediate service discovery mechanism, consisting of: > > a) An intermediary service description format, which describes what > services an intermediary or arbitrary group of intermediaries is > willing to provide, and > > b) A discovery protocol for locating relevant service descriptions within > a single administrative domain. > > Both components will take into consideration current practice, related > work in the IETF, and a reasoned set of requirements, which will include > the need to provide a reasonable alternative to interception proxies. > >Service discovery, and other issues pertaining to coordination between >multiple administrative domains are explicitly out of scope of this group. > >Protocols associated with the provisioning of value added services, >including the vectoring of adaptation requests to other devices, is also >out of scope for this group. > > >Goals and Milestones: > >Feb 01: Requirements document for intermediary discovery and description >Feb 01: First draft invalidation protocol >Mar 01: Meet at Minneapolis IETF >Apr 01: First draft intermediary discovery protocol >Jul 01: First draft intermediary description mechanism >Aug 01: Meet at London IETF >Dec 01: Invalidation protocol finalized >Dec 01: Salt Lake City >Jan 02: Intermediary discovery protocol finalized >Mar 02: Intermediary description mechanism finalized >Apr 02: Re-charter > > From owner-wrec@cs.utk.edu Sun Nov 5 05:48:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28877 for ; Sun, 5 Nov 2000 05:48:09 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA10656; Sun, 5 Nov 2000 05:44:18 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 05:44:17 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA10634; Sun, 5 Nov 2000 05:44:16 -0500 (EST) Received: from piglet.dstc.edu.au (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA10606; Sun, 5 Nov 2000 05:44:10 -0500 (EST) Received: from piglet.dstc.edu.au (130.102.176.1 -> piglet.dstc.edu.au) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 05:44:11 -0500 Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id eA5Ahlc14391; Sun, 5 Nov 2000 20:43:47 +1000 (EST) Date: Sun, 5 Nov 2000 20:44:01 +1000 (EST) From: jason andrade To: Dan Li cc: wrec@cs.utk.edu Subject: Re: Candidate re-charter/new WG In-Reply-To: <4.2.0.58.20001105000719.02331460@omega> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Sun, 5 Nov 2000, Dan Li wrote: > I think it's a good idea to have a focused forum to get something done. A > web cache invalidation protocol will bring much value to reverse proxies > (surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is > a good thing. Apologies if this is an ignorant question, but where do mirror sites fit in the scheme of things.. are they just less sophisticated reverse proxies? I've been listening to wrec for a little while now and have never heard anyone mention them.. and will webi have anything to do / talk about them ? cheers, -jason From owner-wrec@cs.utk.edu Sun Nov 5 06:39:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28833 for ; Sun, 5 Nov 2000 06:39:42 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA14525; Sun, 5 Nov 2000 06:35:52 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 06:35:49 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA14503; Sun, 5 Nov 2000 06:35:49 -0500 (EST) Received: from fep01-svc.swip.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA14490; Sun, 5 Nov 2000 06:35:42 -0500 (EST) Received: from fep01-svc.swip.net (130.244.199.129 -> fep01.swip.net) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 06:35:42 -0500 Received: from henrik.localdomain ([212.151.181.32]) by fep01-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20001105113540.CCRS1845.fep01-svc.swip.net@henrik.localdomain>; Sun, 5 Nov 2000 12:35:40 +0100 Received: from henrik.localdomain (localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id MAA30253; Sun, 5 Nov 2000 12:35:50 +0100 Sender: hno@hem.passagen.se Message-ID: <3A054616.94C8885@hem.passagen.se> Date: Sun, 05 Nov 2000 12:35:50 +0100 From: Henrik Nordstrom X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.16-3 i586) MIME-Version: 1.0 To: jason andrade CC: Dan Li , wrec@cs.utk.edu Subject: Re: The concept of mirror sites References: Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28833 jason andrade wrote: > Apologies if this is an ignorant question, but where do mirror sites fit > in the scheme of things.. are they just less sophisticated reverse proxies? Good question. I thought mirrors was covered as one subset of the "surrogate" concept, but it seems this has been narrowed down to only cover "reverse proxies" and similar constructs, with a vague reference to something undefined called "delegates", or the wording is a bit too dim. If the goal is still that mirrors are one form of surrogates then perhaps the last sentence should be reworded and maybe moved down to the "reverse proxy" section... Change proposal: Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as a type of ^^^^^^^^^^^^ surrogates acting as caching http->http gateways to replicate ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the content. ^^^^^^^^^^^ -- Henrik Nordström From owner-wrec@cs.utk.edu Sun Nov 5 09:46:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18107 for ; Sun, 5 Nov 2000 09:46:42 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA25766; Sun, 5 Nov 2000 09:42:47 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 09:42:44 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA25742; Sun, 5 Nov 2000 09:42:44 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA25729; Sun, 5 Nov 2000 09:42:42 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 09:42:43 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 9110CF4; Sun, 5 Nov 2000 15:42:41 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA04681; Sun, 5 Nov 2000 15:42:38 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: References: Date: Sun, 5 Nov 2000 09:16:56 -0500 To: jason andrade , Dan Li From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Candidate re-charter/new WG Cc: wrec@cs.utk.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 20.44 +1000 00-11-05, jason andrade wrote: >Apologies if this is an ignorant question, but where do mirror sites fit >in the scheme of things.. are they just less sophisticated reverse proxies? Hope you have seen the _whole_ plan and not only the proposed charter for WEBI. If not, see below. paf > Michael Condry > Ian Cooper > Mark Day > Mark Nottingham > Hilarie Orman > > ---------------------- > > There are currently multiple proposals for IETF Applications Area working > groups related to Web transport/content distribution; WREC/WEBI, OPES and > CDNP. This discussion proposes deliniations between the groups, in order to > clarify their roles. > > Historically, WREC focused on caching and replication. WEBI is proposed to > replace WREC and slightly broaden its scope to include issues of general > import to intermediaries. WEBI work items will be distinguished by being > generic, in that they are not specific to one application domain (such as > content peering or value-added proxies). For example, invalidation > mechanisms and intermediate discovery protocols are of interest in multiple > applications. Note that if requirements for a particular application can not > be met by a general mechanism, it may be appropriate to define an > application-specific mechanism as well. WEBI might produce other groups as > workload requires. > > The Open Proxy Services architecture (OPES) allows for services to be > constructed "inside the network", allowing both the overlay of value-added > services and the introduction of a processing model in intermediaries. OPES > work items will be distinguished in that they involve definition and/or > support of value-added services on intermediaries. For example, this may > include a means of vectoring messages to "callout servers" and configuration > and managment of services, but should exclude general content routing > mechanisms. > > Content Distribution Network Peering (CDNP) defines a model and mechanisms > for the interconnection and cooperation of networks for content-related > tasks: direction (directing requests for content), distribution (moving > content out to surrogates) and accounting (tracking the delivery of content > from surrogates). A single network may have its own mechanisms for these > tasks, and WEBI may define or standardize elements of those mechanisms. CDNP > focuses on the interactions required for direction, distribution, and > accounting between two or more networks with different administrations, > where the networks are potentially using different local mechanisms for > > Within WREC/WEBI, OPES and CDNP are largely orthogonal. The groups > should cooperate in order to avoid conflicting specifications. From owner-wrec@cs.utk.edu Sun Nov 5 09:59:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25740 for ; Sun, 5 Nov 2000 09:59:52 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA27532; Sun, 5 Nov 2000 09:56:02 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 09:56:00 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA27510; Sun, 5 Nov 2000 09:56:00 -0500 (EST) Received: from laptop44 (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA27487; Sun, 5 Nov 2000 09:55:48 -0500 (EST) Received: from laptop44 (128.169.251.18 -> NCHM06A18.RMT.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 09:55:48 -0500 Message-ID: <001501c04738$c1b13250$0601a8c0@laptop44> From: "Micah Beck" To: "Henrik Nordstrom" , "jason andrade" Cc: "Dan Li" , References: <3A054616.94C8885@hem.passagen.se> Subject: Re: The concept of mirror sites Date: Sun, 5 Nov 2000 09:57:44 -0500 Organization: UT Computer Science Dept. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by cs.utk.edu id JAA27532 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25740 jason andrade wrote: > Apologies if this is an ignorant question, but where do mirror sites fit > in the scheme of things.. are they just less sophisticated reverse proxies? As someone who is very interested in mirroring technology as a form of content distribution, I would point out that mirrors have implementation issues which are different from reverse proxies, and that mirroring technology can be at least as sophisticated as a reverse proxy and offers some capabilities which are not offered by http->http gateways of any kind. Henrik Nordström wrote > I thought mirrors was covered as one subset of the "surrogate" concept, > but it seems this has been narrowed down to only cover "reverse proxies" > and similar constructs, with a vague reference to something undefined > called "delegates", or the wording is a bit too dim. > > If the goal is still that mirrors are one form of surrogates then > perhaps the last sentence should be reworded and maybe moved down to the > "reverse proxy" section... > > Change proposal: > > Devices commonly known as "reverse proxies" and "(origin) server > accelerators" are both more properly defined as a type of > ^^^^^^^^^^^^ > surrogates acting as caching http->http gateways to replicate > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the content. > ^^^^^^^^^^^ Depending on its policy and implementation, a mirror can be indistinguishable from a "reverse proxy" or "origin accellerator" so I believe mirrors should be included as a type of surrogate. If they are not, then the work I am most interested in will not be covered. Micah Beck From owner-wrec@cs.utk.edu Sun Nov 5 14:23:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07433 for ; Sun, 5 Nov 2000 14:23:57 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA23725; Sun, 5 Nov 2000 14:19:58 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 14:19:48 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA23681; Sun, 5 Nov 2000 14:19:48 -0500 (EST) Received: from atol.icm.edu.pl (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA23661; Sun, 5 Nov 2000 14:19:40 -0500 (EST) Received: from atol.icm.edu.pl (212.87.0.35 -> atol.icm.edu.pl) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 14:19:45 -0500 Received: from burza.icm.edu.pl ([148.81.208.198]:40619 "EHLO burza.icm.edu.pl" ident: "IDENT-NONSENSE") by atol.icm.edu.pl with ESMTP id ; Sun, 5 Nov 2000 20:19:29 +0100 Received: (from wojsyl@localhost) by burza.icm.edu.pl (8.9.3/8.9.3/rzm-2.6/icm) id UAA03743; Sun, 5 Nov 2000 20:19:25 +0100 (MET) From: Wojtek Sylwestrzak Message-Id: <200011051919.UAA03743@burza.icm.edu.pl> Subject: Re: The concept of mirror sites In-Reply-To: <001501c04738$c1b13250$0601a8c0@laptop44> from Micah Beck at "Nov 5, 2000 09:57:44 am" To: mbeck@cs.utk.edu (Micah Beck) Date: Sun, 5 Nov 2000 20:19:25 +0100 (MET) Cc: hno@hem.passagen.se, jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Organization: ICM, Warsaw University Address: Pawinskiego 5A, 02-106 Warszawa, Poland Reply-To: W.Sylwestrzak@icm.edu.pl X-PGP-Key-Fingerprint: AF C5 80 1C 7F EE 74 DB 5A F3 0B 54 AE 2F A4 99 X-Accept-Charset: ISO-8859-2 X-Mailer: ELM [version 2.4ME+ PL53 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > Change proposal: > > > > Devices commonly known as "reverse proxies" and "(origin) server > > accelerators" are both more properly defined as a type of > > ^^^^^^^^^^^^ > > surrogates acting as caching http->http gateways to replicate > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the content. > > ^^^^^^^^^^^ > > Depending on its policy and implementation, a mirror can be > indistinguishable from a "reverse proxy" or "origin accellerator" so I > believe mirrors should be included as a type of surrogate. If they are not, > then the work I am most interested in will not be covered. > > Micah Beck > I second on that. My other feeling though is, that we are too much tempted to cover mirrors and other (?) proxies with a single abstract notion and thus risk oversimplifying the mirrors issues. Remember the earlier discussion on how replication is different to mirroring ? (no, don't want to go there again). Just a comment. However I agree that we should not leave mirrors out, and perhaps consider them surrogates. Would it complicate anything ? --w From owner-wrec@cs.utk.edu Sun Nov 5 14:30:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10230 for ; Sun, 5 Nov 2000 14:30:36 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA24918; Sun, 5 Nov 2000 14:26:39 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 14:26:38 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA24896; Sun, 5 Nov 2000 14:26:38 -0500 (EST) Received: from atol.icm.edu.pl (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA24845; Sun, 5 Nov 2000 14:26:32 -0500 (EST) Received: from atol.icm.edu.pl (212.87.0.35 -> atol.icm.edu.pl) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 14:26:32 -0500 Received: from burza.icm.edu.pl ([148.81.208.198]:55469 "EHLO burza.icm.edu.pl" ident: "IDENT-NONSENSE") by atol.icm.edu.pl with ESMTP id ; Sun, 5 Nov 2000 20:26:08 +0100 Received: (from wojsyl@localhost) by burza.icm.edu.pl (8.9.3/8.9.3/rzm-2.6/icm) id UAA04173; Sun, 5 Nov 2000 20:26:06 +0100 (MET) From: Wojtek Sylwestrzak Message-Id: <200011051926.UAA04173@burza.icm.edu.pl> Subject: Re: Candidate re-charter/new WG In-Reply-To: from "Patrik [F_ltstr_m]" at "Nov 5, 2000 09:16:56 am" To: paf@cisco.com (Patrik [F_ltstr_m]) Date: Sun, 5 Nov 2000 20:26:06 +0100 (MET) Cc: jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Organization: ICM, Warsaw University Address: Pawinskiego 5A, 02-106 Warszawa, Poland Reply-To: W.Sylwestrzak@icm.edu.pl X-PGP-Key-Fingerprint: AF C5 80 1C 7F EE 74 DB 5A F3 0B 54 AE 2F A4 99 X-Accept-Charset: ISO-8859-2 X-Mailer: ELM [version 2.4ME+ PL53 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit > At 20.44 +1000 00-11-05, jason andrade wrote: > >Apologies if this is an ignorant question, but where do mirror sites fit > >in the scheme of things.. are they just less sophisticated reverse proxies? > > Hope you have seen the _whole_ plan and not only the proposed charter for WEBI. > > If not, see below. > > paf > Are you saying that mirroring fits both into CDNP and WEBI within the proposed plan ? We'd not like to have it lost somewhere in the middle. --w > > Content Distribution Network Peering (CDNP) defines a model and mechanisms > > for the interconnection and cooperation of networks for content-related > > tasks: direction (directing requests for content), distribution (moving > > content out to surrogates) and accounting (tracking the delivery of content > > from surrogates). A single network may have its own mechanisms for these > > tasks, and WEBI may define or standardize elements of those mechanisms. CDNP > > focuses on the interactions required for direction, distribution, and > > accounting between two or more networks with different administrations, > > where the networks are potentially using different local mechanisms for From owner-wrec@cs.utk.edu Sun Nov 5 16:00:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17489 for ; Sun, 5 Nov 2000 16:00:46 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA04169; Sun, 5 Nov 2000 15:56:16 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 15:56:02 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA04126; Sun, 5 Nov 2000 15:56:01 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA04111; Sun, 5 Nov 2000 15:55:54 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 15:55:54 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id C466EF4; Sun, 5 Nov 2000 21:55:48 +0100 (MET) Received: from [192.168.1.129] (ssh-sj1.cisco.com [171.68.225.134]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA01316; Sun, 5 Nov 2000 21:55:41 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@192.168.1.129 Message-Id: In-Reply-To: <200011051926.UAA04173@burza.icm.edu.pl> References: <200011051926.UAA04173@burza.icm.edu.pl> Date: Sun, 5 Nov 2000 15:55:14 -0500 To: Wojtek Sylwestrzak From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Candidate re-charter/new WG Cc: jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 20.26 +0100 00-11-05, Wojtek Sylwestrzak wrote: >Are you saying that mirroring fits both into CDNP and WEBI >within the proposed plan ? >We'd not like to have it lost somewhere in the middle. It is up to people on this mailing list to decide that. We run by consensus... I just wanted people to see what is currently written about all three proposals, in a consistent way, so I was sure that you know what is behind the three proposed charters. paf From owner-wrec@cs.utk.edu Sun Nov 5 21:19:00 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01112 for ; Sun, 5 Nov 2000 21:18:59 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA07377; Sun, 5 Nov 2000 21:14:10 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 21:13:56 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA07353; Sun, 5 Nov 2000 21:13:55 -0500 (EST) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA07339; Sun, 5 Nov 2000 21:13:53 -0500 (EST) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 21:13:53 -0500 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA23166; Sun, 5 Nov 2000 21:13:50 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABG10814; Sun, 5 Nov 2000 21:13:47 -0500 (EST) From: "Mark Day" To: "jason andrade" , "Dan Li" Cc: Subject: RE: Candidate re-charter/new WG Date: Sun, 5 Nov 2000 21:13:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Apologies if this is an ignorant question, but where do mirror sites fit > in the scheme of things.. are they just less sophisticated > reverse proxies? Apologies in turn if I now ask an ignorant question, but what aspect of mirror sites would you want to standardize? Answering that question in a little more detail may make it easier to determine where it should be discussed. Thanks in advance, --Mark Mark Stuart Day Senior Scientist Cisco Systems +1 (781) 663-8310 markday@cisco.com From owner-wrec@cs.utk.edu Sun Nov 5 21:33:25 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05700 for ; Sun, 5 Nov 2000 21:33:25 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA09304; Sun, 5 Nov 2000 21:28:34 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 21:28:29 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA09274; Sun, 5 Nov 2000 21:28:29 -0500 (EST) Received: from piglet.dstc.edu.au (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA09130; Sun, 5 Nov 2000 21:27:48 -0500 (EST) Received: from piglet.dstc.edu.au (130.102.176.1 -> piglet.dstc.edu.au) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 21:27:49 -0500 Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id eA62RKc23232; Mon, 6 Nov 2000 12:27:20 +1000 (EST) Date: Mon, 6 Nov 2000 12:27:34 +1000 (EST) From: jason andrade To: Mark Day cc: Dan Li , wrec@cs.utk.edu Subject: RE: Candidate re-charter/new WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Sun, 5 Nov 2000, Mark Day wrote: > > Apologies if this is an ignorant question, but where do mirror sites fit > > in the scheme of things.. are they just less sophisticated > > reverse proxies? > > Apologies in turn if I now ask an ignorant question, but what aspect of > mirror sites would you want to standardize? Answering that question in a > little more detail may make it easier to determine where it should be > discussed. i look after a couple of mirror sites and also look after some mirror distribution networks for archives. there's little to nothing in the way of standards for mirrors. there are a number of tools available and a loose `confederation' of mirror admins who exchange knowledge but that's about it. the wheel often gets re-invented in new and wonderful ways. from what i've seen WREC/WEBI seem to be able producing standards and it would have been useful to know if this could be applied to mirrors and if it clearly couldn't maybe there needs to be another forum for those sorts of discussions/work. apart from "raw" mirror sites, there's also been some work on redirect protocols being used into mirror sites and things like that are not well understood or deployed yet, which they might be if there was a clear way to implement them (or not as the case may be) as an example, not too many squid cache admins allow for close to gigabyte sized individual files in their archive, yet mirrors are sending terabytes of this kind of data around the net daily. -jason From owner-wrec@cs.utk.edu Sun Nov 5 22:15:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19838 for ; Sun, 5 Nov 2000 22:15:17 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA17364; Sun, 5 Nov 2000 22:11:02 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 22:10:56 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA17339; Sun, 5 Nov 2000 22:10:56 -0500 (EST) Received: from laptop44 (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA17286; Sun, 5 Nov 2000 22:10:41 -0500 (EST) Received: from laptop44 (128.169.251.18 -> NCHM06A18.RMT.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 22:10:41 -0500 Message-ID: <00ba01c0479f$6b61fd50$0601a8c0@laptop44> From: "Micah Beck" To: "jason andrade" , "Mark Day" Cc: "Dan Li" , References: Subject: Re: Candidate re-charter/new WG Date: Sun, 5 Nov 2000 22:12:38 -0500 Organization: UT Computer Science Dept. 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason Andrade wrote: > On Sun, 5 Nov 2000, Mark Day wrote: > > > > Apologies if this is an ignorant question, but where do mirror sites fit > > > in the scheme of things.. are they just less sophisticated > > > reverse proxies? > > > > Apologies in turn if I now ask an ignorant question, but what aspect of > > mirror sites would you want to standardize? Answering that question in a > > little more detail may make it easier to determine where it should be > > discussed. > > i look after a couple of mirror sites and also look after some mirror > distribution networks for archives. there's little to nothing in the > way of standards for mirrors. there are a number of tools available and > a loose `confederation' of mirror admins who exchange knowledge but that's > about it. the wheel often gets re-invented in new and wonderful ways. > > from what i've seen WREC/WEBI seem to be able producing standards and > it would have been useful to know if this could be applied to mirrors > and if it clearly couldn't maybe there needs to be another forum for > those sorts of discussions/work. > > apart from "raw" mirror sites, there's also been some work on redirect > protocols being used into mirror sites and things like that are not > well understood or deployed yet, which they might be if there was a > clear way to implement them (or not as the case may be) > > as an example, not too many squid cache admins allow for close to gigabyte > sized individual files in their archive, yet mirrors are sending terabytes > of this kind of data around the net daily. As Jason points out, mirror servers have the capability to create surrogates for services which are not easily replicated using current caching and CDN technology. Of particular interest to me is uncachable content generated by code executing on the mirror. Currently, creating a mirror site which includes such executable content is very difficult when the mirror is to be installed on a server that is not identical to the origin server. This is because of the absence of standards for the operating environment, language and API for executable code and the mechanisms by which such code is transmitted to the mirror server. This problem is very closely related to the problem of establishing standards for installing new services on an Extensible Proxy. Current CDN operators and ASPs seem happy to define proprietary mechanisms for creating mirrors of executable content, and will require that their customers conform to their proprietary APIs in order to take advantage of them. This is seen as a way of locking their customers into their particular server networks. As these APIs become more complex, interoperability will become impossible. Definition of some basic standards would at least allow some executable content (using only basic services that can be standardized) to operate across CDN and ASP server networks. Micah Beck From owner-wrec@cs.utk.edu Sun Nov 5 22:26:37 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22916 for ; Sun, 5 Nov 2000 22:26:32 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA20137; Sun, 5 Nov 2000 22:22:32 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 5 Nov 2000 22:22:30 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA20114; Sun, 5 Nov 2000 22:22:29 -0500 (EST) Received: from thalia.fm.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA20100; Sun, 5 Nov 2000 22:22:26 -0500 (EST) Received: from thalia.fm.intel.com (132.233.247.11 -> thalia.fm.intel.com) by cs.utk.edu (smtpshim v1.0); Sun, 5 Nov 2000 22:22:26 -0500 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id DAA08756; Mon, 6 Nov 2000 03:23:41 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 06 Nov 2000 03:22:24 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Sun, 5 Nov 2000 19:22:23 -0800 Message-ID: From: "Maciocco, Christian" To: "'wrec@cs.utk.edu'" , "'cdn@ops.ietf.org'" Subject: Intra vs Inter CDN Date: Sun, 5 Nov 2000 19:21:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" List-Unsubscribe: Sorry, I'm new to these lists and haven't read the minutes (yet). As per the paragraph below it looks like intra CDN issues will be dealt within WEBI while inter CDN ones will be dealt by CDNP. I think a lot of these elements (redirection, distribution, ...) will be a subset or have a lot in common between inter or intra CDN. Is there a desire to combine both inter and intra issues into the same group? (Beside having the same people follow both group). Thanks Christian > Content Distribution Network Peering (CDNP) defines a model and mechanisms > for the interconnection and cooperation of networks for content-related > tasks: direction (directing requests for content), distribution (moving > content out to surrogates) and accounting (tracking the delivery of content > from surrogates). A single network may have its own mechanisms for these > tasks, and WEBI may define or standardize elements of those mechanisms. CDNP > focuses on the interactions required for direction, distribution, and > accounting between two or more networks with different administrations, > where the networks are potentially using different local mechanisms for From owner-wrec@cs.utk.edu Mon Nov 6 01:04:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02829 for ; Mon, 6 Nov 2000 01:04:34 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10767; Mon, 6 Nov 2000 00:59:47 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 6 Nov 2000 00:59:29 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA10713; Mon, 6 Nov 2000 00:59:29 -0500 (EST) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA10695; Mon, 6 Nov 2000 00:59:23 -0500 (EST) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Mon, 6 Nov 2000 00:59:27 -0500 Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Sun, 5 Nov 2000 22:02:24 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Sun Nov 05 22:02:24 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 5 Nov 2000 21:57:41 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EA62@exchange.entera.com> From: Gary Tomlinson To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Wojtek Sylwestrzak Cc: jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Subject: RE: Candidate re-charter/new WG Date: Sun, 5 Nov 2000 21:57:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA02829 I don't see mirrors being something CDNP is likely to work on. CDNP is focused on the peering (interconnection) of CDNs, while surrogates (including mirrors in my definition) are network elements within CDNs themselves. Currently CDNP doesn't address intra CDN issues, and sees surrogates only in their abstract form. I see mirrors as possible work within WEBI. >-----Original Message----- >From: Patrik Fältström [mailto:paf@cisco.com] >Sent: Sunday, November 05, 2000 12:55 PM >To: Wojtek Sylwestrzak >Cc: jason@dstc.edu.au; lidan@cisco.com; wrec@cs.utk.edu >Subject: Re: Candidate re-charter/new WG > > >At 20.26 +0100 00-11-05, Wojtek Sylwestrzak wrote: >>Are you saying that mirroring fits both into CDNP and WEBI >>within the proposed plan ? >>We'd not like to have it lost somewhere in the middle. > >It is up to people on this mailing list to decide that. We run by consensus... > >I just wanted people to see what is currently written about all three >proposals, in a consistent way, so I was sure that you know what is >behind the three proposed charters. > > paf Gary From owner-wrec@cs.utk.edu Mon Nov 6 12:07:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25767 for ; Mon, 6 Nov 2000 12:07:26 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA19850; Mon, 6 Nov 2000 12:02:26 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 6 Nov 2000 12:02:11 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA19805; Mon, 6 Nov 2000 12:02:11 -0500 (EST) Received: from nemo.corp.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA19737; Mon, 6 Nov 2000 12:01:51 -0500 (EST) From: Received: from nemo.corp.equinix.com (207.20.85.154 -> somehost-2.equinix.net) by cs.utk.edu (smtpshim v1.0); Mon, 6 Nov 2000 12:01:51 -0500 Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id JAA08268; Mon, 6 Nov 2000 09:01:18 -0800 (PST) Message-Id: <200011061701.JAA08268@nemo.corp.equinix.com> Subject: Re: Candidate re-charter/new WG To: garyt@entera.com (Gary Tomlinson) Date: Mon, 6 Nov 2000 09:01:17 -0800 (PST) Cc: paf@cisco.com (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=), W.Sylwestrzak@icm.edu.pl (Wojtek Sylwestrzak), jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu In-Reply-To: <733880CDF866D3118C69005004D1701E0121EA62@exchange.entera.com> from "Gary Tomlinson" at Nov 05, 2000 09:57:41 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit > I don't see mirrors being something CDNP is likely to work on. CDNP is > focused on the peering (interconnection) of CDNs, I am a little uneasy with our use of the term "peering", because I think we run the risk of implying something about settlements we don't mean. There is a big chunk of the BGP crowd that still thinks of peering as meaning "traffic exchange without settlement". I think we want to talk about CDN traffic exchange and interworking, but I don't think we want to imply "without settlement". I don't want to start a big "rethink the name" effort, but I think it may be something that we should cover early in the BOF, just to eliminate any peering vs. transit discussions. regards, Ted From owner-wrec@cs.utk.edu Mon Nov 6 12:12:05 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27777 for ; Mon, 6 Nov 2000 12:12:04 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA21111; Mon, 6 Nov 2000 12:07:24 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 6 Nov 2000 12:07:23 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA21089; Mon, 6 Nov 2000 12:07:23 -0500 (EST) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA21050; Mon, 6 Nov 2000 12:07:17 -0500 (EST) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Mon, 6 Nov 2000 12:07:17 -0500 Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Mon, 6 Nov 2000 09:10:15 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Mon Nov 06 09:10:14 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 09:05:31 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EA6C@exchange.entera.com> From: Gary Tomlinson To: hardie@equinix.com, garyt@entera.com Cc: paf@cisco.com, W.Sylwestrzak@icm.edu.pl, jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Subject: RE: Candidate re-charter/new WG Date: Mon, 6 Nov 2000 09:05:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: Agreed. We've been struggling to come up with a better term. CDN Peering doesn't imply settlement free, in fact, the norm is quite the opposite. This could make for a good discussion in the BoF. Gary -----Original Message----- From: hardie@equinix.com [mailto:hardie@equinix.com] Sent: Monday, November 06, 2000 9:01 AM To: garyt@entera.com Cc: paf@cisco.com; W.Sylwestrzak@icm.edu.pl; jason@dstc.edu.au; lidan@cisco.com; wrec@cs.utk.edu Subject: Re: Candidate re-charter/new WG > I don't see mirrors being something CDNP is likely to work on. CDNP is > focused on the peering (interconnection) of CDNs, I am a little uneasy with our use of the term "peering", because I think we run the risk of implying something about settlements we don't mean. There is a big chunk of the BGP crowd that still thinks of peering as meaning "traffic exchange without settlement". I think we want to talk about CDN traffic exchange and interworking, but I don't think we want to imply "without settlement". I don't want to start a big "rethink the name" effort, but I think it may be something that we should cover early in the BOF, just to eliminate any peering vs. transit discussions. regards, Ted From owner-wrec@cs.utk.edu Mon Nov 6 13:42:03 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21524 for ; Mon, 6 Nov 2000 13:41:48 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA07410; Mon, 6 Nov 2000 13:36:50 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 6 Nov 2000 13:36:38 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA07345; Mon, 6 Nov 2000 13:36:37 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA07321; Mon, 6 Nov 2000 13:36:17 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 6 Nov 2000 13:36:22 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id EDF3E195; Mon, 6 Nov 2000 19:36:07 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA08862; Mon, 6 Nov 2000 19:36:05 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <733880CDF866D3118C69005004D1701E0121EA62@exchange.entera.com> References: <733880CDF866D3118C69005004D1701E0121EA62@exchange.entera.com> Date: Mon, 6 Nov 2000 10:25:13 -0800 To: Gary Tomlinson , Wojtek Sylwestrzak From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Candidate re-charter/new WG Cc: jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 21.57 -0800 00-11-05, Gary Tomlinson wrote: >I don't see mirrors being something CDNP is likely to work on. CDNP is >focused on the peering (interconnection) of CDNs, while surrogates >(including mirrors in my definition) are network elements within CDNs >themselves. Currently CDNP doesn't address intra CDN issues, and sees >surrogates only in their abstract form. I see your point. >I see mirrors as possible work within WEBI. And what you _really_ talk about are not (only) mirrors, but "network elements inside a CDN"? [Part from the specific functionality which the extensible proxy group will talk about] paf From owner-wrec@cs.utk.edu Mon Nov 6 22:35:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18512 for ; Mon, 6 Nov 2000 22:35:11 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA14245; Mon, 6 Nov 2000 22:29:46 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 6 Nov 2000 22:29:26 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA14198; Mon, 6 Nov 2000 22:29:25 -0500 (EST) Received: from raptor.ebuilt.net (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA14180; Mon, 6 Nov 2000 22:29:12 -0500 (EST) Received: from raptor.ebuilt.net (209.216.46.38) by cs.utk.edu (smtpshim v1.0); Mon, 6 Nov 2000 22:29:17 -0500 Received: FROM raptor.ebuilt.net BY raptor.ebuilt.net ; Mon Nov 06 19:27:16 2000 -0800 Received: by raptor with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 19:27:14 -0800 Message-ID: From: "Fielding, Roy" To: "'Ian Cooper'" , wrec@cs.utk.edu Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: RE: Candidate re-charter/new WG Date: Mon, 6 Nov 2000 19:27:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: > Below is a candidate (re)charter to take WREC forward as the "Web > Infrastructure" group (thanks to those who have given input of their > varying types). As you'll see, the idea is to take on two > work items that > we believe are essential for web infrastructure going forward. > > There is some cross over with the invalidation protocol with the CDNP > folks. ... > > Likewise, there is some degree of cross over with the intermediary > discovery protocol. ... If that is what you will be working on, please use a name that is specific to the work. Web infrastructure includes IP+TCP+HTTP+URI+DNS and a bunch of other things that are out of scope. I suggest you call it the "Web Intermediary" working group, since you are going to be talking about interoperability at the application level. And you can still call it WEBI. ....Roy From owner-wrec@cs.utk.edu Tue Nov 7 00:24:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23464 for ; Tue, 7 Nov 2000 00:24:53 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA23726; Tue, 7 Nov 2000 00:20:31 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 7 Nov 2000 00:20:08 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA23689; Tue, 7 Nov 2000 00:20:07 -0500 (EST) Received: from akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA23666; Tue, 7 Nov 2000 00:19:53 -0500 (EST) Received: from akamai.com (64.14.77.2 -> akafire-exodus.akamai.com) by cs.utk.edu (smtpshim v1.0); Tue, 7 Nov 2000 00:19:58 -0500 Received: from akamai.com (vwall3.kendall.akamai.com [172.24.40.127]) by akamai.com (8.10.1/8.10.1) with ESMTP id eA75Jm618238 for ; Tue, 7 Nov 2000 00:19:48 -0500 (EST) Received: from ssh-gw.sanmateo.akamai.com ([172.23.1.53]) by akamai.com (8.10.1/8.10.1) with ESMTP id eA75JQY18076; Tue, 7 Nov 2000 00:19:26 -0500 (EST) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id WAA01433; Mon, 6 Nov 2000 22:17:26 -0800 Date: Mon, 6 Nov 2000 22:17:26 -0800 From: Mark Nottingham To: "Fielding, Roy" Cc: "'Ian Cooper'" , wrec@cs.utk.edu, =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Ned Freed , cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: Re: Candidate re-charter/new WG Message-ID: <20001106221721.A1420@akamai.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fielding@eBuilt.com on Mon, Nov 06, 2000 at 07:27:01PM -0800 List-Unsubscribe: Interesting point. We were thinking application-level web infrastructure, which is confined to HTTP/URI; this is in the applications area, after all. That having been said, I don't have a particular objection to the meaning you propose, as I think it still encompasses what we intended. Ian? On Mon, Nov 06, 2000 at 07:27:01PM -0800, Fielding, Roy wrote: > > Below is a candidate (re)charter to take WREC forward as the "Web > > Infrastructure" group (thanks to those who have given input of their > > varying types). As you'll see, the idea is to take on two > > work items that > > we believe are essential for web infrastructure going forward. > > > > There is some cross over with the invalidation protocol with the CDNP > > folks. ... > > > > Likewise, there is some degree of cross over with the intermediary > > discovery protocol. ... > > If that is what you will be working on, please use a name that is > specific to the work. Web infrastructure includes IP+TCP+HTTP+URI+DNS > and a bunch of other things that are out of scope. I suggest you > call it the "Web Intermediary" working group, since you are going to > be talking about interoperability at the application level. And you > can still call it WEBI. > > ....Roy -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Thu Nov 9 15:08:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17428 for ; Thu, 9 Nov 2000 15:08:27 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA20993; Thu, 9 Nov 2000 15:03:25 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 15:02:25 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA20836; Thu, 9 Nov 2000 15:02:25 -0500 (EST) Received: from or1.inktomi.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA20780; Thu, 9 Nov 2000 15:02:11 -0500 (EST) Received: from or1.inktomi.com (209.131.48.34 -> or1.inktomi.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 15:02:12 -0500 Received: from inbox2.inktomi.com (inbox2.inktomi.com [209.131.48.29]) by or1.inktomi.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA00340 for ; Thu, 9 Nov 2000 12:02:53 -0800 (PST) Received: from c255838-a ([209.131.52.212]) by inbox2.inktomi.com (Netscape Messaging Server 4.1) with ESMTP id G3RWZ200.NBS; Thu, 9 Nov 2000 12:01:50 -0800 Message-Id: <4.2.0.58.20001109112341.00ba2540@inkt-3.inktomi.com> X-Sender: philr@inkt-3.inktomi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Nov 2000 12:01:44 -0800 To: hardie@equinix.com, garyt@entera.com (Gary Tomlinson) From: "Phil Rzewski" Subject: Re: Candidate re-charter/new WG Cc: paf@cisco.com (Patrik =?iso-8859-1?Q?Fdltstrvm?= ), W.Sylwestrzak@icm.edu.pl (Wojtek Sylwestrzak), jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu, cdn@ops.ietf.org In-Reply-To: <200011061701.JAA08268@nemo.corp.equinix.com> References: <733880CDF866D3118C69005004D1701E0121EA62@exchange.entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: As long as we're on the topic, I have similar concerns about the interchangeable use of the terms "CDN Peering" and "Content Peering", which seem to imply they're equivalent. It therefore comes down to the use of the term "CDN". There's once again a "crowd" that has been using the term in a particular way, in this case the crowd being industry. Outside of the IETF/draft communities, there's reasonably well-defined differences between what's been called CDNs, Hosters, and Access Providers. Now, doing a meticulous reading of [draft-day-cdnp-model-02], I get the impression that perhaps there's an attempt to categorize Access Provider cache deployments as being a degenerate form of CDN, but I think this might be a mistake because it would create a disconnect between industry terminology (which was established first) and standards terminology. For example, say a cable modem provider (CMP) puts caching proxies in each of several cable head ends. CMP informs their subscribers in each area of their local cache, and all subscribers explicitly configure their browsers. The CMP then creates a peering relationship with several CDNs to have content distributed into these caching proxies, and to provide logging information to those CDNs in return. This means there is distribution and accounting happening between the CMP and the peer CDNs. Therefore, the caching proxies take on a partial role as a "surrogates". So far, CMP's cache deployment has some traits of a CDN. However, there is "null" redirection (the cache in a subscriber's head end is defined as "good" for any content request). Also, the CMP is not operating a "relatively complex system encompassing multiple points of presence around the world" [draft-day-cdnp-model-02]. Each cable head end is an isolated and tightly-coupled relationship between the subscribers in that area and the cache. Anyway, without splitting hairs any further, I'd like to offer the thought that "Content Peering" as a general concept could safely be defined in terms of things like direction/distribution/accounting between entities (need a term... "Content Peering Entities"?). Then "CDN Peering" would be a specific type of Content Peering. That would allow for other types of Content Peering, such as that between an Access Provider and a CDN, as shown above. -- Phil At 09:01 AM 11/6/00 -0800, hardie@equinix.com wrote: > > I don't see mirrors being something CDNP is likely to work on. CDNP is > > focused on the peering (interconnection) of CDNs, > >I am a little uneasy with our use of the term "peering", because I >think we run the risk of implying something about settlements we don't >mean. There is a big chunk of the BGP crowd that still thinks of >peering as meaning "traffic exchange without settlement". I think we >want to talk about CDN traffic exchange and interworking, but I don't >think we want to imply "without settlement". > >I don't want to start a big "rethink the name" effort, but I think it >may be something that we should cover early in the BOF, just to >eliminate any peering vs. transit discussions. > > > regards, > Ted -- Phil Rzewski - Senior Architect - Inktomi Corporation 650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax) From owner-wrec@cs.utk.edu Thu Nov 9 15:12:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19287 for ; Thu, 9 Nov 2000 15:12:47 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA22162; Thu, 9 Nov 2000 15:08:36 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 15:08:36 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA22140; Thu, 9 Nov 2000 15:08:35 -0500 (EST) Received: from mail-blue.research.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA22107; Thu, 9 Nov 2000 15:08:29 -0500 (EST) Received: from mail-blue.research.att.com (135.207.30.102 -> mail-blue.research.att.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 15:08:29 -0500 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 41EF34CE27; Thu, 9 Nov 2000 15:08:28 -0500 (EST) Received: from douglux.research.att.com (root@douglux.research.att.com [135.207.26.106]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA16707; Thu, 9 Nov 2000 15:08:26 -0500 (EST) Received: from douglux.research.att.com (IDENT:douglis@localhost.localdomain [127.0.0.1]) by douglux.research.att.com (8.9.3/8.9.3) with ESMTP id PAA22725; Thu, 9 Nov 2000 15:08:26 -0500 Message-Id: <200011092008.PAA22725@douglux.research.att.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Fred Douglis To: "Phil Rzewski" Cc: hardie@equinix.com, garyt@entera.com (Gary Tomlinson), paf@cisco.com (Patrik =?iso-8859-1?Q?Fdltstrvm?= ), W.Sylwestrzak@icm.edu.pl (Wojtek Sylwestrzak), jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu, cdn@ops.ietf.org Subject: Content [Distribution Network] Peering (was Re: Candidate re-charter/new WG) In-reply-to: Your message of "Thu, 09 Nov 2000 12:01:44 PST." <4.2.0.58.20001109112341.00ba2540@inkt-3.inktomi.com> X-URI: http://www.research.att.com/~douglis/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Nov 2000 15:08:26 -0500 Sender: douglis@research.att.com List-Unsubscribe: Phil, You make a good point: "CDN Peering" may be too specific to cover the scenario you've described, unless one is generous with the definition of a CDN. However, I think "Content Peering" is a poor term, because we're not peering "content", we're peering entities that deliver content. (This is similar to the forwarding-versus-routing debate that has hit the cdn mailing list today). I'm not sure I have a third suggestion that I like more than these two, just that I think "Content Peering" is the wrong direction to take this. For now I would be inclined to include your scenario under the CDN framework. Fred From owner-wrec@cs.utk.edu Thu Nov 9 15:32:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26197 for ; Thu, 9 Nov 2000 15:32:15 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA26242; Thu, 9 Nov 2000 15:27:45 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 15:27:40 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA26217; Thu, 9 Nov 2000 15:27:39 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA26204; Thu, 9 Nov 2000 15:27:37 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 15:27:37 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA28104; Thu, 9 Nov 2000 12:26:37 -0800 (PST) Message-Id: <4.2.0.58.20001109122248.03489af0@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Nov 2000 12:29:37 -0700 To: Fred Douglis , "Phil Rzewski" From: Dan Li Subject: Re: Content [Distribution Network] Peering (was Re: Candidate re-charter/new WG) Cc: hardie@equinix.com, garyt@entera.com (Gary Tomlinson), paf@cisco.com (Patrik =?iso-8859-1?Q?Fdltstrvm?= ), W.Sylwestrzak@icm.edu.pl (Wojtek Sylwestrzak), jason@dstc.edu.au, wrec@cs.utk.edu, cdn@ops.ietf.org In-Reply-To: <200011092008.PAA22725@douglux.research.att.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: >For example, say a cable modem provider (CMP) puts caching proxies in each >of several cable head ends. CMP informs their subscribers in each area of >their local cache, and all subscribers explicitly configure their >browsers. The CMP then creates a peering relationship with several CDNs to >have content distributed into these caching proxies, and to provide >logging information to those CDNs in return. This means there is >distribution and accounting happening between the CMP and the peer CDNs. >Therefore, the caching proxies take on a partial role as a "surrogates". >So far, CMP's cache deployment has some traits of a CDN. However, there is >"null" redirection (the cache in a subscriber's head end is defined as >"good" for any content request). Also, the CMP is not operating a >"relatively complex system encompassing multiple points of presence around >the world" [draft-day-cdnp-model-02]. Each cable head end is an isolated >and tightly-coupled relationship between the subscribers in that area and >the cache. This is the "vertical peering" scenario, meaning a set of caches in one administrative domain without full-fledged CDN functionality can participate as leaves in a full-fludged CDN of another administrative domain. Technically, the protocol for vertical peering may be similar in many aspects to that used inside of a CDN. E.g., content preloading, invalidation, and accounting. Dan At 03:08 PM 11/9/00 -0500, Fred Douglis wrote: >Phil, > >You make a good point: "CDN Peering" may be too specific to cover the >scenario >you've described, unless one is generous with the definition of a CDN. > >However, I think "Content Peering" is a poor term, because we're not peering >"content", we're peering entities that deliver content. (This is similar to >the forwarding-versus-routing debate that has hit the cdn mailing list >today). > >I'm not sure I have a third suggestion that I like more than these two, just >that I think "Content Peering" is the wrong direction to take this. For >now I >would be inclined to include your scenario under the CDN framework. > >Fred From owner-wrec@cs.utk.edu Thu Nov 9 15:48:01 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01634 for ; Thu, 9 Nov 2000 15:47:31 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28983; Thu, 9 Nov 2000 15:42:46 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 15:42:43 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA28951; Thu, 9 Nov 2000 15:42:43 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28898; Thu, 9 Nov 2000 15:42:39 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 15:42:39 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 13:42:26 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 13:42:17 -0700 From: "Hilarie Orman" To: Cc: , Subject: Re: Content [Distribution Network] Peering (was Re: Candidatere-charter/new WG) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA01634 Perhaps "CDN Access Point" is a useful term for describing what "vertical peering" provides? And would "virtual" be more descriptive than "vertical"? Or "aggregated"? This is a vitally important part of the architecture, so getting the terminology right is worthwhile. Hilarie >>> Dan Li 11/09/00 12:29PM >>> >For example, say a cable modem provider (CMP) puts caching proxies in each >of several cable head ends. CMP informs their subscribers in each area of >their local cache, and all subscribers explicitly configure their >browsers. The CMP then creates a peering relationship with several CDNs to >have content distributed into these caching proxies, and to provide >logging information to those CDNs in return. This means there is >distribution and accounting happening between the CMP and the peer CDNs. >Therefore, the caching proxies take on a partial role as a "surrogates". >So far, CMP's cache deployment has some traits of a CDN. However, there is >"null" redirection (the cache in a subscriber's head end is defined as >"good" for any content request). Also, the CMP is not operating a >"relatively complex system encompassing multiple points of presence around >the world" [draft-day-cdnp-model-02]. Each cable head end is an isolated >and tightly-coupled relationship between the subscribers in that area and >the cache. This is the "vertical peering" scenario, meaning a set of caches in one administrative domain without full-fledged CDN functionality can participate as leaves in a full-fludged CDN of another administrative domain. Technically, the protocol for vertical peering may be similar in many aspects to that used inside of a CDN. E.g., content preloading, invalidation, and accounting. Dan At 03:08 PM 11/9/00 -0500, Fred Douglis wrote: >Phil, > >You make a good point: "CDN Peering" may be too specific to cover the >scenario >you've described, unless one is generous with the definition of a CDN. > >However, I think "Content Peering" is a poor term, because we're not peering >"content", we're peering entities that deliver content. (This is similar to >the forwarding-versus-routing debate that has hit the cdn mailing list >today). > >I'm not sure I have a third suggestion that I like more than these two, just >that I think "Content Peering" is the wrong direction to take this. For >now I >would be inclined to include your scenario under the CDN framework. > >Fred From owner-wrec@cs.utk.edu Thu Nov 9 16:08:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09443 for ; Thu, 9 Nov 2000 16:08:46 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA03110; Thu, 9 Nov 2000 16:04:37 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 16:04:29 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA03070; Thu, 9 Nov 2000 16:04:29 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA03050; Thu, 9 Nov 2000 16:04:28 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 16:04:28 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA04681; Thu, 9 Nov 2000 16:04:27 -0500 (EST) Message-Id: <200011092104.QAA04681@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: wrec@cs.utk.edu, cdn@ops.ietf.org Subject: regarding new working groups cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 09 Nov 2000 16:04:27 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: one thing that I think is essential in any new content-distribution work is to explicitly define roles and responsibilities - when an intermediary is introduced between the content-provider and the content-user, to which party is the intermediary responsible? (the same device might be used in either case, but intermediaries should be clear about whose instructions they are following) under no circumstances should content be altered, nor should stale content be delivered, except with explicit consent from at least one of the end parties. for example, we don't want to standardize a way to allow an ISP to alter or cache content except as intended by one of the end parties. finally, there need to be provisions for fault isolation and diagnosis, which probably requires (among other things) the ability to bypass intermediaries. Keith From owner-wrec@cs.utk.edu Thu Nov 9 16:36:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18577 for ; Thu, 9 Nov 2000 16:36:51 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA08388; Thu, 9 Nov 2000 16:32:21 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 16:32:17 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA08337; Thu, 9 Nov 2000 16:32:16 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA08317; Thu, 9 Nov 2000 16:32:10 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 16:32:15 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 14:31:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 14:31:50 -0700 From: "Hilarie Orman" To: , , , Cc: Subject: Re: regarding new working groups Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA18577 I think this is more of an issue for Extensible Proxies than the others. I'm in complete agreement on the fault isolation issue. For other things, while roles and responsibilities are ultimately important, binding agreements on paper are perfectly acceptable (i.e., they do not have to have an on-the-wire format). That being said, I'd like to see the IETF standardize on protocol representations of references to SLA's, contracts, etc., so that accounting systems could refer to the billing basis, the authorization agreeement, etc. It's not a perfect solution, but it's a start. Hilarie >>> Keith Moore 11/09/00 02:04PM >>> one thing that I think is essential in any new content-distribution work is to explicitly define roles and responsibilities - when an intermediary is introduced between the content-provider and the content-user, to which party is the intermediary responsible? (the same device might be used in either case, but intermediaries should be clear about whose instructions they are following) under no circumstances should content be altered, nor should stale content be delivered, except with explicit consent from at least one of the end parties. for example, we don't want to standardize a way to allow an ISP to alter or cache content except as intended by one of the end parties. finally, there need to be provisions for fault isolation and diagnosis, which probably requires (among other things) the ability to bypass intermediaries. Keith From owner-wrec@cs.utk.edu Thu Nov 9 16:41:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19777 for ; Thu, 9 Nov 2000 16:41:51 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA09412; Thu, 9 Nov 2000 16:37:30 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 16:37:29 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA09390; Thu, 9 Nov 2000 16:37:29 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA09370; Thu, 9 Nov 2000 16:37:27 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 16:37:27 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA04944; Thu, 9 Nov 2000 16:37:18 -0500 (EST) Message-Id: <200011092137.QAA04944@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hilarie Orman" cc: moore@cs.utk.edu, wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 14:31:50 MST." Date: Thu, 09 Nov 2000 16:37:18 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > I think this is more of an issue for Extensible Proxies than the > others. > > I'm in complete agreement on the fault isolation issue. For other > things, while roles and responsibilities are ultimately important, binding > agreements on paper are perfectly acceptable (i.e., they do not > have to have an on-the-wire format). I agree with this sentiment. I'm not trying to insist that the details of such agreements be made a part of the protocol (though it would be nice if we could do it, I suspect it would take a long time before we could find a good way to encode the needs of real users into a protocol) Keith From owner-wrec@cs.utk.edu Thu Nov 9 16:56:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23001 for ; Thu, 9 Nov 2000 16:56:15 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA12502; Thu, 9 Nov 2000 16:51:55 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 16:51:48 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA12450; Thu, 9 Nov 2000 16:51:47 -0500 (EST) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA12420; Thu, 9 Nov 2000 16:51:41 -0500 (EST) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 16:51:45 -0500 Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Thu, 9 Nov 2000 13:54:43 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Thu Nov 09 13:54:40 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 13:49:50 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> From: Gary Tomlinson To: Keith Moore , Hilarie Orman Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Thu, 9 Nov 2000 13:49:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: >>At 11/9/00 1:32PM Hilarie Orman wrote: >> I think this is more of an issue for Extensible Proxies than the >> others. >> >> I'm in complete agreement on the fault isolation issue. For other >> things, while roles and responsibilities are ultimately important, binding >> agreements on paper are perfectly acceptable (i.e., they do not >> have to have an on-the-wire format). >At November 9, 2000 1:37PM Keith Moore wrote: >I agree with this sentiment. I'm not trying to insist that the details >of such agreements be made a part of the protocol (though it would be >nice if we could do it, I suspect it would take a long time before we >could find a good way to encode the needs of real users into a protocol) I think there still exists a need for the content distribution & delivery providers to divulge their vested interests as well (paper is fine). Traditionally, the CDNs we know today represent the content provider's interests, while ISP's are likely to represent the consumer's interests. Gary From owner-wrec@cs.utk.edu Thu Nov 9 17:43:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05091 for ; Thu, 9 Nov 2000 17:43:34 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA18265; Thu, 9 Nov 2000 17:39:18 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 17:39:10 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA18230; Thu, 9 Nov 2000 17:39:09 -0500 (EST) Received: from mail-blue.research.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA18213; Thu, 9 Nov 2000 17:38:50 -0500 (EST) Received: from mail-blue.research.att.com (135.207.30.102 -> mail-blue.research.att.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 17:38:54 -0500 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 34AEF4CE15; Thu, 9 Nov 2000 17:38:48 -0500 (EST) Received: from douglux.research.att.com (root@douglux.research.att.com [135.207.26.106]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA22457; Thu, 9 Nov 2000 17:38:47 -0500 (EST) Received: from douglux.research.att.com (IDENT:douglis@localhost.localdomain [127.0.0.1]) by douglux.research.att.com (8.9.3/8.9.3) with ESMTP id RAA23582; Thu, 9 Nov 2000 17:38:47 -0500 Message-Id: <200011092238.RAA23582@douglux.research.att.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Fred Douglis To: wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org Subject: BOF scheduling X-URI: http://www.research.att.com/~douglis/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Nov 2000 17:38:47 -0500 Sender: douglis@research.att.com List-Unsubscribe: I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-wrec@cs.utk.edu Thu Nov 9 17:54:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07288 for ; Thu, 9 Nov 2000 17:53:30 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA19965; Thu, 9 Nov 2000 17:49:17 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 17:49:16 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA19942; Thu, 9 Nov 2000 17:49:15 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA19926; Thu, 9 Nov 2000 17:49:13 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 17:49:13 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 15:49:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 15:49:06 -0700 From: "Hilarie Orman" To: , , , Subject: Re: BOF scheduling Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07288 Has me worried too, but CDNP has different Area Directors than the others, and those AD's are taking a less aggressive approach to putting approved things into actual agenda spots. Hilarie >>> Fred Douglis 11/09/00 03:38PM >>> I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-wrec@cs.utk.edu Thu Nov 9 17:58:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08508 for ; Thu, 9 Nov 2000 17:58:53 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA21224; Thu, 9 Nov 2000 17:54:58 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 17:54:52 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA21123; Thu, 9 Nov 2000 17:54:51 -0500 (EST) Received: from thalia.fm.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA21082; Thu, 9 Nov 2000 17:54:45 -0500 (EST) Received: from thalia.fm.intel.com (132.233.247.11 -> thalia.fm.intel.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 17:54:48 -0500 Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id WAA10088; Thu, 9 Nov 2000 22:51:56 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 09 Nov 2000 22:50:39 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 14:50:37 -0800 Message-ID: From: "Condry, Michael W" To: "'Fred Douglis'" , wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org Cc: "'paf@cisco.com'" Subject: RE: BOF scheduling Date: Thu, 9 Nov 2000 14:50:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" List-Unsubscribe: I do not have the time for OPES yet. I suspect that Patrik will be careful in no conflicts with these groups. -----Original Message----- From: Fred Douglis [mailto:douglis@research.att.com] Sent: Thursday, November 09, 2000 2:39 PM To: wrec@cs.utk.edu; cdn@ops.ietf.org; ietf-openproxy@imc.org Subject: BOF scheduling I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since so many of us are likely to be interested in CDNP, WEBI, and the openproxy work (I forget their acronym), I wondered if anyone has any insight into how closely these three will be scheduled? I have visions of having to go to SD for a whole week to attend, primarily, these 3 meetings. I know there are a zillion constraints and everyone has their pet groups, but it seems this intersection must be so common that I hope it will ultimately result in close proximity. The fact that one appeared in the schedule while the others didn't have me worried a bit. (See http://www.ietf.cnri.reston.va.us/meetings/agenda.html for details.) With fingers crossed, Fred From owner-wrec@cs.utk.edu Thu Nov 9 18:05:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09888 for ; Thu, 9 Nov 2000 18:05:17 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA22846; Thu, 9 Nov 2000 18:01:13 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 18:01:12 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA22819; Thu, 9 Nov 2000 18:01:11 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA22754; Thu, 9 Nov 2000 18:01:02 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 18:01:02 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 86B0995; Fri, 10 Nov 2000 00:00:57 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11678; Fri, 10 Nov 2000 00:00:55 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <200011092238.RAA23582@douglux.research.att.com> References: <200011092238.RAA23582@douglux.research.att.com> Date: Thu, 9 Nov 2000 14:54:54 -0800 To: Fred Douglis , wrec@cs.utk.edu, cdn@ops.ietf.org, ietf-openproxy@imc.org From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 17.38 -0500 00-11-09, Fred Douglis wrote: >I noticed the latest IETF agenda scheduled CDNP for Tuesday afternoon. Since >so many of us are likely to be interested in CDNP, WEBI, and the openproxy >work (I forget their acronym), I wondered if anyone has any insight into how >closely these three will be scheduled? Very close -- if possible. paf From owner-wrec@cs.utk.edu Thu Nov 9 18:05:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09935 for ; Thu, 9 Nov 2000 18:05:27 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA22918; Thu, 9 Nov 2000 18:01:21 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 18:01:21 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA22896; Thu, 9 Nov 2000 18:01:20 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA22791; Thu, 9 Nov 2000 18:01:10 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 18:01:10 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id BC5F0D7; Fri, 10 Nov 2000 00:01:05 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA11683; Fri, 10 Nov 2000 00:01:00 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 9 Nov 2000 15:00:25 -0800 To: "Hilarie Orman" , , , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Cc: Ned Freed Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 15.49 -0700 00-11-09, Hilarie Orman wrote: >Has me worried too, but CDNP has different Area Directors than the >others, and those AD's are taking a less aggressive approach to >putting approved things into actual agenda spots. Different Area Directors? BOF's end up on the agenda as soon as: 1 People have sent requests to agenda@ietf.org and responsible AD 2 AD has said ok to the BOF 3 Agenda people have managed to sync (1) and (2) above The IETF conference is one week long. From monday morning to friday lunch. The idea with having all wg's the same week is that people working normally with one topic _SHOULD_ participate in other meetings aswell. For example, people interested in what happens in the area of these mailing lists probably should look very closely what happens in the space of the IDN working group, aswell as CNRP and other URI/HTTP related wg's. Saying "I only want to be there for my meeting and then go home, so please let me know exactly when the meeting will be" is not an argument which works. Patrik Faltstrom Co-Area Director, Applications Area From owner-wrec@cs.utk.edu Thu Nov 9 18:16:32 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12331 for ; Thu, 9 Nov 2000 18:16:18 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA25490; Thu, 9 Nov 2000 18:12:12 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 18:12:01 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA25433; Thu, 9 Nov 2000 18:12:00 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA25383; Thu, 9 Nov 2000 18:11:47 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 18:11:52 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 55116119; Fri, 10 Nov 2000 00:11:46 +0100 (MET) Received: from [171.70.85.33] (dhcp-2sjc13-85-33.cisco.com [171.70.85.33]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA12597; Fri, 10 Nov 2000 00:11:41 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Thu, 9 Nov 2000 15:11:33 -0800 To: "Hilarie Orman" , , , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: BOF scheduling Cc: Ned Freed Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12331 At 15.00 -0800 00-11-09, Patrik Fältström wrote: >The IETF conference is one week long. From monday morning to friday >lunch. The idea with having all wg's the same week is that people >working normally with one topic _SHOULD_ participate in other >meetings aswell. And, if it is the case that you have an hour or a day or so when there is no interesting meeting, I am sure (based on the discussion on these mailing lists) that you together can find some corner in the hotel and discuss more things face 2 face which you don't have time to talk about during the meeting itself. paf From owner-wrec@cs.utk.edu Thu Nov 9 19:21:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26767 for ; Thu, 9 Nov 2000 19:21:19 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA03804; Thu, 9 Nov 2000 19:16:54 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 19:16:47 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA03782; Thu, 9 Nov 2000 19:16:46 -0500 (EST) Received: from akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA03765; Thu, 9 Nov 2000 19:16:41 -0500 (EST) Received: from akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 19:16:41 -0500 Received: from akamai.com (vwall1.sanmateo.akamai.com [172.23.1.71]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA0E1i12778; Thu, 9 Nov 2000 16:14:01 -0800 (PST) Received: from marjorie.sanmateo.akamai.com (IDENT:root@marjorie.sanmateo.akamai.com [172.23.1.15]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA0AF512711; Thu, 9 Nov 2000 16:10:15 -0800 (PST) Received: (from mnot@localhost) by marjorie.sanmateo.akamai.com (8.9.3/8.9.3) id QAA16293; Thu, 9 Nov 2000 16:16:49 -0800 Date: Thu, 9 Nov 2000 16:16:49 -0800 From: Mark Nottingham To: Gary Tomlinson Cc: Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups Message-ID: <20001109161648.A16140@akamai.com> References: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com>; from garyt@entera.com on Thu, Nov 09, 2000 at 01:49:50PM -0800 List-Unsubscribe: I agree with the sentiment, but not that ISPs represent consumers' interests; generally, I find that they represent their own, with consumers' as a distant second. Especially regarding caching. I'm glad that people are talking about these issues; HTTP is AFAIK unique as a transport protocol, in that it allows relaxation of semantic transparency without explicit permission of the client or server. This will cause problems if we just jump in (although some already are!) Also, may be good to try and involve the W3C, as relaxing semantic transparency potentially affects many things there (P3P, semantic web, etc) On Thu, Nov 09, 2000 at 01:49:50PM -0800, Gary Tomlinson wrote: > > >>At 11/9/00 1:32PM Hilarie Orman wrote: > >> I think this is more of an issue for Extensible Proxies than the > >> others. > >> > >> I'm in complete agreement on the fault isolation issue. For other > >> things, while roles and responsibilities are ultimately important, > binding > >> agreements on paper are perfectly acceptable (i.e., they do not > >> have to have an on-the-wire format). > > >At November 9, 2000 1:37PM Keith Moore wrote: > >I agree with this sentiment. I'm not trying to insist that the details > >of such agreements be made a part of the protocol (though it would be > >nice if we could do it, I suspect it would take a long time before we > >could find a good way to encode the needs of real users into a protocol) > > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. > > Gary -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Thu Nov 9 19:37:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00374 for ; Thu, 9 Nov 2000 19:37:52 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA05813; Thu, 9 Nov 2000 19:33:33 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 19:33:27 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA05790; Thu, 9 Nov 2000 19:33:26 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA05767; Thu, 9 Nov 2000 19:33:10 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 19:33:10 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 09 Nov 2000 17:32:58 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Thu, 09 Nov 2000 17:32:56 -0700 From: "Hilarie Orman" To: , Cc: , , Subject: Re: regarding new working groups Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA00374 Agreed. It's nice when service providers find that their own economic interests don't conflict with their customers', but that's nothing to bank on. For this forum, what we can do is to have requirements for API's that allow user/publisher configuration of policy options (and to define the embodiment of those options). Hilarie >>> Mark Nottingham 11/09/00 05:16PM >>> I agree with the sentiment, but not that ISPs represent consumers' interests; generally, I find that they represent their own, with consumers' as a distant second. Especially regarding caching. From owner-wrec@cs.utk.edu Thu Nov 9 20:49:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17102 for ; Thu, 9 Nov 2000 20:49:14 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA12935; Thu, 9 Nov 2000 20:44:52 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 20:44:44 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA12910; Thu, 9 Nov 2000 20:44:44 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA12889; Thu, 9 Nov 2000 20:44:43 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 20:44:43 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id UAA05957; Thu, 9 Nov 2000 20:44:18 -0500 (EST) Message-Id: <200011100144.UAA05957@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Nottingham cc: Gary Tomlinson , Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 16:16:49 PST." <20001109161648.A16140@akamai.com> Date: Thu, 09 Nov 2000 20:44:18 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > I agree with the sentiment, but not that ISPs represent consumers' > interests; generally, I find that they represent their own, with consumers' > as a distant second. Especially regarding caching. I see the same thing, and I find it extremely disquieting. This is why I say that intermediaries must act on explicit instructions (whether or not part of the on-the-wire protocol) from at least one of the end parties > I'm glad that people are talking about these issues; HTTP is AFAIK unique as > a transport protocol, in that it allows relaxation of semantic transparency > without explicit permission of the client or server. I don't immediately see how HTTP permits this by itself; it's the idea that the network can interpose intermediaries in the HTTP conversation (whether via interception proxies or via auto-discovery mechanisms that find intermediaries without authorization of either the content provider or the content user) that seems to cause the problems. at any rate, it needs to be stopped. Keith From owner-wrec@cs.utk.edu Thu Nov 9 21:10:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21969 for ; Thu, 9 Nov 2000 21:10:01 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA15647; Thu, 9 Nov 2000 21:05:46 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 21:05:44 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA15624; Thu, 9 Nov 2000 21:05:44 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA15603; Thu, 9 Nov 2000 21:05:43 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 21:05:43 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA06202; Thu, 9 Nov 2000 21:05:39 -0500 (EST) Message-Id: <200011100205.VAA06202@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Gary Tomlinson cc: Keith Moore , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Thu, 09 Nov 2000 13:49:50 PST." <733880CDF866D3118C69005004D1701E0121EAD9@exchange.entera.com> Date: Thu, 09 Nov 2000 21:05:39 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. I beg to differ; the ISPs generally represent their own interests when they interfere with the communications between a content provider and the content user. (e.g. by imposing non-voluntary caches, adding advertising, changing data formats) IETF should not sanction such practices. Keith From owner-wrec@cs.utk.edu Thu Nov 9 22:02:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07147 for ; Thu, 9 Nov 2000 22:02:41 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA20801; Thu, 9 Nov 2000 21:58:10 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 21:57:56 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA20748; Thu, 9 Nov 2000 21:57:56 -0500 (EST) Received: from akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA20716; Thu, 9 Nov 2000 21:57:41 -0500 (EST) Received: from akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 21:57:41 -0500 Received: from akamai.com (vwall3.sanmateo.akamai.com [172.23.1.73]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA2t0i15263 for ; Thu, 9 Nov 2000 18:55:00 -0800 (PST) Received: from marjorie.sanmateo.akamai.com (IDENT:root@marjorie.sanmateo.akamai.com [172.23.1.15]) by akamai.com (8.10.1/8.10.1) with ESMTP id eAA2sv515256; Thu, 9 Nov 2000 18:54:57 -0800 (PST) Received: (from mnot@localhost) by marjorie.sanmateo.akamai.com (8.9.3/8.9.3) id TAA29439; Thu, 9 Nov 2000 19:01:32 -0800 Date: Thu, 9 Nov 2000 19:01:32 -0800 From: Mark Nottingham To: Fred Douglis Cc: Phil Rzewski , hardie@equinix.com, Gary Tomlinson , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m_?= , Wojtek Sylwestrzak , jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu, cdn@ops.ietf.org Subject: Re: Content [Distribution Network] Peering (was Re: Candidate re-charter/new WG) Message-ID: <20001109190131.A28620@akamai.com> References: <4.2.0.58.20001109112341.00ba2540@inkt-3.inktomi.com> <200011092008.PAA22725@douglux.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200011092008.PAA22725@douglux.research.att.com>; from douglis@research.att.com on Thu, Nov 09, 2000 at 03:08:26PM -0500 List-Unsubscribe: Stepping back a little bit, it might be useful to explore the relationship between "content" (a term that has recently been used a lot, but is poorly defined) to "resource", as used by the W3C (e.g., URI, etc.). "Content" might be defined as the bits that are shoved around on the wire; "Resource" is the service, and describes a higher-level concept. Anything with a URI is a resource. See http://www.w3.org/Architecture/Terms.html Also, Jeff Mogul's discussion of resource/entity/variant/instance in section three of http://www.ietf.org/internet-drafts/draft-mogul-http-delta-07.txt might be relevant as well. I haven't thought deeply about this, and I'm not suggesting that we call them "Resource Distribution Networks" (yet!), but the bandying about of 'content' without a solid definition has disturbed me for a while. On Thu, Nov 09, 2000 at 03:08:26PM -0500, Fred Douglis wrote: > Phil, > > You make a good point: "CDN Peering" may be too specific to cover the scenario > you've described, unless one is generous with the definition of a CDN. > > However, I think "Content Peering" is a poor term, because we're not peering > "content", we're peering entities that deliver content. (This is similar to > the forwarding-versus-routing debate that has hit the cdn mailing list today). > > I'm not sure I have a third suggestion that I like more than these two, just > that I think "Content Peering" is the wrong direction to take this. For now I > would be inclined to include your scenario under the CDN framework. > > Fred > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Thu Nov 9 23:40:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07053 for ; Thu, 9 Nov 2000 23:40:07 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA29790; Thu, 9 Nov 2000 23:35:50 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 9 Nov 2000 23:35:44 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA29738; Thu, 9 Nov 2000 23:35:43 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA29721; Thu, 9 Nov 2000 23:35:42 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 9 Nov 2000 23:35:42 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA07296; Thu, 9 Nov 2000 23:35:00 -0500 (EST) Message-Id: <200011100435.XAA07296@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Mark Nottingham cc: Fred Douglis , Phil Rzewski , hardie@equinix.com, Gary Tomlinson , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m_?= , Wojtek Sylwestrzak , jason@dstc.edu.au, lidan@cisco.com, wrec@cs.utk.edu, cdn@ops.ietf.org Subject: Re: Content [Distribution Network] Peering (was Re: Candidate re-charter/new WG) In-reply-to: Your message of "Thu, 09 Nov 2000 19:01:32 PST." <20001109190131.A28620@akamai.com> Date: Thu, 09 Nov 2000 23:35:00 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > I haven't thought deeply about this, and I'm not suggesting that we call > them "Resource Distribution Networks" (yet!), but the bandying about of > 'content' without a solid definition has disturbed me for a while. I tend to think in terms of distributed systems that implement a service which might or might not be available at multiple locations on the network. The service implements one or more named resources each of which whose function might or might not be to provide (static or dynamic) content. For this and other reasons it's useful to separate the problem of how one maps from a resource name to a location on the network, from the problem of how one actually makes the service available at multiple locations with a reasonable degree of consistency (for that service). If the service more-or-less passively provides content, this is a very different problem than if the service absorbs content, or if it involves substantial interaction. But a passive content replication service can still be a useful substrate in implementing a more dynamic service - provided the services are layered correctly. (we should avoid thinking of services as inhernetly being the sources of content...they can as easily be sinks) Keith From owner-wrec@cs.utk.edu Fri Nov 10 00:17:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18121 for ; Fri, 10 Nov 2000 00:17:14 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA03367; Fri, 10 Nov 2000 00:13:15 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 00:13:13 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA03343; Fri, 10 Nov 2000 00:13:13 -0500 (EST) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA03321; Fri, 10 Nov 2000 00:12:48 -0500 (EST) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 00:12:48 -0500 Received: from havoc.entera.com ([206.165.109.130]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with SMTP id com for ; Thu, 9 Nov 2000 21:15:48 -0800 Received: FROM exchange.entera.com BY havoc.entera.com ; Thu Nov 09 21:15:40 2000 -0800 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Nov 2000 21:10:49 -0800 Message-ID: <733880CDF866D3118C69005004D1701E0121EAEA@exchange.entera.com> From: Gary Tomlinson To: moore@cs.utk.edu, Gary Tomlinson Cc: Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Thu, 9 Nov 2000 21:10:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: >> I think there still exists a need for the content distribution & delivery >> providers to divulge their vested interests as well (paper is fine). >> Traditionally, the CDNs we know today represent the content provider's >> interests, while ISP's are likely to represent the consumer's interests. > >I beg to differ; the ISPs generally represent their own interests >when they interfere with the communications between a content >provider and the content user. (e.g. by imposing non-voluntary >caches, adding advertising, changing data formats) > >IETF should not sanction such practices. > Fair enough assessment on current ISP practices. Nonetheless, CDNs as we know them do represent provider interests, and somebody may emerge to represent consumer interests (I know of some infomediary startups that would like to). My main point is, there are multiple entities representing various interests involved with intermediary infrastructure. Gary From owner-wrec@cs.utk.edu Fri Nov 10 05:05:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06283 for ; Fri, 10 Nov 2000 05:05:46 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA21176; Fri, 10 Nov 2000 05:01:50 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 05:01:47 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA21154; Fri, 10 Nov 2000 05:01:46 -0500 (EST) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA21137; Fri, 10 Nov 2000 05:01:45 -0500 (EST) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 05:01:45 -0500 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id FAA18801; Fri, 10 Nov 2000 05:00:39 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABI01103; Fri, 10 Nov 2000 05:00:34 -0500 (EST) From: "Mark Day" To: , "Mark Nottingham" Cc: "Gary Tomlinson" , "Hilarie Orman" , , , Subject: RE: regarding new working groups Date: Fri, 10 Nov 2000 05:00:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200011100144.UAA05957@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 7bit > > I'm glad that people are talking about these issues; HTTP is > AFAIK unique as > > a transport protocol, in that it allows relaxation of semantic > transparency > > without explicit permission of the client or server. > > I don't immediately see how HTTP permits this by itself; it's the idea > that the network can interpose intermediaries in the HTTP conversation > (whether via interception proxies or via auto-discovery mechanisms > that find intermediaries without authorization of either the > content provider or the content user) that seems to cause the problems. > > at any rate, it needs to be stopped. I confess that I am now confused as to whether we are talking about (a) an issue to keep in mind as we define the tasks of the BOFs/WGs, or (b) a problem and associated technical solution to be discussed in one or more of those groups, or (c) a problem and associated political/legal solution If it's (a), we can all agree that this is a good issue to keep in mind, and then keep it in mind. If it's (b), I need a little more explanation of what the proposed technical approach is because I don't understand it yet. It it's (c), then I need a little more explanation of the relationship between what the IETF can do and the political/legal changes required, because I don't understand that yet. Thanks, --Mark From owner-wrec@cs.utk.edu Fri Nov 10 05:33:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17822 for ; Fri, 10 Nov 2000 05:33:34 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA26512; Fri, 10 Nov 2000 05:29:42 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 05:29:40 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA26490; Fri, 10 Nov 2000 05:29:40 -0500 (EST) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA26475; Fri, 10 Nov 2000 05:29:38 -0500 (EST) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 05:29:38 -0500 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id FAA18844; Fri, 10 Nov 2000 05:29:03 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABI01130; Fri, 10 Nov 2000 05:28:56 -0500 (EST) From: "Mark Day" To: "Phil Rzewski" , , "Gary Tomlinson" Cc: =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bSA=?= , "Wojtek Sylwestrzak" , , , , Subject: RE: Candidate re-charter/new WG Date: Fri, 10 Nov 2000 05:29:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.2.0.58.20001109112341.00ba2540@inkt-3.inktomi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 7bit > As long as we're on the topic, I have similar concerns about the > interchangeable use of the terms "CDN Peering" and "Content > Peering", which > seem to imply they're equivalent. I think we started out with "content peering" and subsequently decided the "content" part was technically inaccurate, so we changed to talking about "CDN peering". I think we've recently decided in design team discussions that the "peering" part is also technically inaccurate, so we might be better off calling it "CDN interoperation" or "content distribution internetworking." But the CDNP acronym has become a handy shorthand for people, so it didn't seem vital to do another name change right away. Whatever we call it, I'd like to get the definitions and names right so that you feel comfortable that your scenario is included within what we're discussing in CDNP. You're absolutely right that your scenario is not between two CDNs, but I think that it's an example of what we'd like to be covered. It still has two distinct but cooperating administrative domains, and it still has the issues of how to distribute, cache, and serve content in the context of that cooperation across different admin domains. --Mark Mark Stuart Day Senior Scientist Cisco Systems +1 (781) 663-8310 markday@cisco.com From owner-wrec@cs.utk.edu Fri Nov 10 09:09:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08066 for ; Fri, 10 Nov 2000 09:09:48 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA12627; Fri, 10 Nov 2000 09:05:12 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 09:05:06 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA12585; Fri, 10 Nov 2000 09:05:04 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA12562; Fri, 10 Nov 2000 09:05:01 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 09:05:01 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA01877; Fri, 10 Nov 2000 09:04:59 -0500 (EST) Message-Id: <200011101404.JAA01877@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Day" cc: moore@cs.utk.edu, "Mark Nottingham" , "Gary Tomlinson" , "Hilarie Orman" , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Fri, 10 Nov 2000 05:00:44 EST." Date: Fri, 10 Nov 2000 09:04:58 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > I confess that I am now confused as to whether we are talking about > (a) an issue to keep in mind as we define the tasks of the BOFs/WGs, or > (b) a problem and associated technical solution to be discussed in one or > more of those groups, or > (c) a problem and associated political/legal solution it could be any of these. but for the purpose of the current discussion, I mentioned it because I thought it might be useful input to the drafting of WG charters. sorry for not being clearer about that. Keith From owner-wrec@cs.utk.edu Fri Nov 10 13:29:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09888 for ; Fri, 10 Nov 2000 13:29:26 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA17294; Fri, 10 Nov 2000 13:25:09 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 13:24:59 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA17232; Fri, 10 Nov 2000 13:24:58 -0500 (EST) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA17170; Fri, 10 Nov 2000 13:24:44 -0500 (EST) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 13:24:44 -0500 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA20837; Fri, 10 Nov 2000 13:24:01 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id ABL00419; Fri, 10 Nov 2000 13:24:00 -0500 (EST) From: "Mark Day" To: Cc: , Subject: Proposed charter for CDNP working group Date: Fri, 10 Nov 2000 13:24:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a heavily revised version of what I sent to the IESG as a placeholder almost 2 months ago. Comments and suggested edits are welcome. I have suggested an unorthodox and rather aggressive schedule, involving parallel development of requirements and protocols. This is partly because of my experience that many important requirements issues don't get raised until people are thinking the protocols through. I think a parallel approach is challenging but doable, but others may well disagree. The current proposed agenda for the CDNP BOF includes an allocation of roughly half our time for discussing the charter. --Mark Content Distribution Network Peering (cdnp) Chair: Mark Day Applications Area Directors: Ned Freed Patrik Faltstrom Applications Area Advisor: Patrik Faltstrom Mailing lists: General discussion: cdn@ops.ietf.org To subscribe: cdn-request@ops.ietf.org Archive: ftp://ops.ietf.org/pub/lists/cdn.* Description of Working Group: The goal of this working group is to define protocols to allow the interoperation of separately-administered content distribution networks (CDNs). A CDN is an architecture of Web-based network elements, arranged for efficient delivery of digital content. The first important use of CDNs was for the distribution of heavily-requested graphic files (such as GIF files on the home pages of popular servers). However, both in principle and increasingly in practice, a CDN can support the delivery of any digital content -- including various forms of streaming media. A number of CDN services have been built and offered commercially. In addition, a number of hardware and software vendors have developed products that enable the construction of a CDN with "off-the-shelf" parts. The proliferation of CDNs and CDN capabilities gives rise to interest in interconnecting CDNs and finding ways for distinct CDNs to cooperate for better overall service A CDN has some combination of a mapping system, a content-delivery system, a distribution system, and an accounting system. In some cases, the "system" may be implemented by very simple components or techniques. The content-delivery system consists of a set of "surrogate" servers that deliver copies of content to sets of users. The mapping system consists of mechanisms that move a client request toward a rendezvous with a surrogate. The distribution system consists of mechanisms that move content from the origin server to the surrogates. An effective CDN arranges the request/content rendezvous to take place at a surrogate that is "well suited" to a given client. Finally, the accounting system records and aggregates information necessary for allocating costs to customers of the CDN. The working group will define requirements and protocol specifications for three kinds of peering: 1. Mapping peering (the interoperation of mapping systems) 2. Distribution peering (the interoperation of distribution systems) and 3. Accounting peering (the interoperation of accounting systems) As preparation for that task, various internet-drafts have been submitted, describing: -- a proposed vocabulary for the problem domain -- a description of some CDN interoperation scenarios -- a proposed set of requirements for accounting -- a proposed architecture for CDN interoperation -- a summary description of known mechanisms for mapping in use today Goals and Milestones December 2000: BOF meets, discusses existing drafts. Editors chosen for requirement documents, protocol documents. February 1, 2001: First drafts of requirements, protocols due on mailing list. March 1, 2001: Last call for vocabulary, scenarios, architecture documents (incorporating changes from requirements process) April 2001: WG meets at IETF meeting to discuss requirements issues, protocol experience June 1, 2001: New requirements, protocol docs incorporating discussions from meeting July 1, 2001: Last call for requirements. August 2001: WG meets at IETF to discuss protocol issues. October 1, 2001: Last call for protocols. December 2001: WG meets at IETF to close. Internet Drafts: http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02.txt http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-01.txt [Plus "known-mechanisms" draft coming soon] From owner-wrec@cs.utk.edu Fri Nov 10 14:18:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29709 for ; Fri, 10 Nov 2000 14:18:32 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA24484; Fri, 10 Nov 2000 14:10:50 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 10 Nov 2000 14:10:44 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA24461; Fri, 10 Nov 2000 14:10:43 -0500 (EST) Received: from sundns.transnexus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA24441; Fri, 10 Nov 2000 14:10:32 -0500 (EST) Received: from sundns.transnexus.com (63.210.64.108) by cs.utk.edu (smtpshim v1.0); Fri, 10 Nov 2000 14:10:32 -0500 Received: from stephen.transnexus.com ([192.168.1.198]) by sundns.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29214; Fri, 10 Nov 2000 19:09:43 GMT Message-Id: <5.0.0.25.2.20001110140433.00a84be0@mail.transnexus.com> X-Sender: sthomas@mail.transnexus.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 10 Nov 2000 14:09:27 -0500 To: From: Stephen Thomas Subject: Re: Proposed charter for CDNP working group Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 01:24 PM 2000-11-10 -0500, Mark Day wrote: >This is a heavily revised version of what I sent to the IESG as a >placeholder almost 2 months ago. Comments and suggested edits are welcome. Just a minor tweak below >[...] Finally, the accounting system records and >aggregates information necessary for allocating costs to customers of the >CDN. I'd suggest that accounting metrics ought to be useful for a lot of reasons other than allocating costs. Depending on what ends up being accounted, content providers, for example, may want to use these metrics to gauge audience size, end user demographics, page "stickiness," etc.. Stephen ____________________________________________________________________ Stephen Thomas +1 404 872 4887 TransNexus, Chief Technical Officer stephen.thomas@transnexus.com From owner-wrec@cs.utk.edu Mon Nov 13 10:45:05 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29954 for ; Mon, 13 Nov 2000 10:45:04 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA06008; Mon, 13 Nov 2000 10:39:39 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 10:37:24 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA05662; Mon, 13 Nov 2000 10:37:23 -0500 (EST) Received: from thalia.fm.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA05629; Mon, 13 Nov 2000 10:37:16 -0500 (EST) Received: from thalia.fm.intel.com (132.233.247.11 -> thalia.fm.intel.com) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 10:37:17 -0500 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id PAA27845; Mon, 13 Nov 2000 15:38:30 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 15:37:13 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 07:37:10 -0800 Message-ID: From: "Condry, Michael W" To: "'Keith Moore'" , Gary Tomlinson Cc: Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: RE: regarding new working groups Date: Mon, 13 Nov 2000 07:37:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: Defining the IETF's role is a tough call. Some folks live with the Advertising to get service they could not otherwise have... -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Thursday, November 09, 2000 6:06 PM To: Gary Tomlinson Cc: Keith Moore; Hilarie Orman; wrec@cs.utk.edu; ietf-openproxy@imc.org; cdn@ops.ietf.org Subject: Re: regarding new working groups > I think there still exists a need for the content distribution & delivery > providers to divulge their vested interests as well (paper is fine). > Traditionally, the CDNs we know today represent the content provider's > interests, while ISP's are likely to represent the consumer's interests. I beg to differ; the ISPs generally represent their own interests when they interfere with the communications between a content provider and the content user. (e.g. by imposing non-voluntary caches, adding advertising, changing data formats) IETF should not sanction such practices. Keith From owner-wrec@cs.utk.edu Mon Nov 13 12:44:09 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14774 for ; Mon, 13 Nov 2000 12:44:08 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA22136; Mon, 13 Nov 2000 12:39:45 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 12:38:18 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA21924; Mon, 13 Nov 2000 12:38:18 -0500 (EST) Received: from ganymede.or.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA21906; Mon, 13 Nov 2000 12:38:16 -0500 (EST) Received: from ganymede.or.intel.com (134.134.248.3 -> ganymede.or.intel.com) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 12:38:16 -0500 Received: from condrysony.intel.com (sonylaptop.jf.intel.com [134.134.159.198]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with ESMTP id JAA13383; Mon, 13 Nov 2000 09:38:04 -0800 (PST) Message-Id: <5.0.0.25.2.20001113093509.009f2540@FMSMSX63.fm.intel.com> X-Sender: mwcondry@FMSMSX63.fm.intel.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 13 Nov 2000 09:35:31 -0800 To: "Mark Day" , From: "Michael W. Condry" Subject: Re: Proposed charter for CDNP working group Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Is this an Applications or Ops? At 01:24 PM 11/10/00 -0500, Mark Day wrote: >This is a heavily revised version of what I sent to the IESG as a >placeholder almost 2 months ago. Comments and suggested edits are welcome. > >I have suggested an unorthodox and rather aggressive schedule, involving >parallel development of requirements and protocols. This is partly because >of my experience that many important requirements issues don't get raised >until people are thinking the protocols through. I think a parallel >approach is challenging but doable, but others may well disagree. > >The current proposed agenda for the CDNP BOF includes an allocation of >roughly half our time for discussing the charter. > >--Mark > >Content Distribution Network Peering (cdnp) > >Chair: >Mark Day > >Applications Area Directors: >Ned Freed >Patrik Faltstrom > >Applications Area Advisor: >Patrik Faltstrom > >Mailing lists: >General discussion: cdn@ops.ietf.org >To subscribe: cdn-request@ops.ietf.org >Archive: ftp://ops.ietf.org/pub/lists/cdn.* > >Description of Working Group: > >The goal of this working group is to define protocols to allow the >interoperation of separately-administered content distribution networks >(CDNs). > >A CDN is an architecture of Web-based network elements, arranged for >efficient delivery of digital content. The first important use of CDNs was >for the distribution of heavily-requested graphic files (such as GIF files >on the home pages of popular servers). However, both in principle and >increasingly in practice, a CDN can support the delivery of any digital >content -- including various forms of streaming media. > >A number of CDN services have been built and offered commercially. In >addition, a number of hardware and software vendors have developed products >that enable the construction of a CDN with "off-the-shelf" parts. The >proliferation of CDNs and CDN capabilities gives rise to interest in >interconnecting CDNs >and finding ways for distinct CDNs to cooperate for better overall service > >A CDN has some combination of a mapping system, a content-delivery >system, a distribution system, and an accounting system. In some cases, the >"system" may be implemented by very simple components or techniques. The >content-delivery system consists of a set of "surrogate" >servers that deliver copies of content to sets of users. The mapping system >consists of mechanisms that move a client request toward a rendezvous with a >surrogate. The distribution system consists of mechanisms that move content >from the origin server to the surrogates. An effective CDN arranges the >request/content rendezvous to take place at a surrogate that is "well >suited" to a given client. Finally, the accounting system records and >aggregates information necessary for allocating costs to customers of the >CDN. > >The working group will define requirements and protocol specifications for >three kinds of peering: > >1. Mapping peering (the interoperation of mapping systems) >2. Distribution peering (the interoperation of distribution systems) and >3. Accounting peering (the interoperation of accounting systems) > >As preparation for that task, various internet-drafts have been submitted, >describing: > >-- a proposed vocabulary for the problem domain >-- a description of some CDN interoperation scenarios >-- a proposed set of requirements for accounting >-- a proposed architecture for CDN interoperation >-- a summary description of known mechanisms for mapping in use today > >Goals and Milestones > >December 2000: BOF meets, discusses existing drafts. Editors chosen for >requirement documents, protocol documents. >February 1, 2001: First drafts of requirements, protocols due on mailing >list. >March 1, 2001: Last call for vocabulary, scenarios, architecture documents >(incorporating changes from requirements process) >April 2001: WG meets at IETF meeting to discuss requirements issues, >protocol experience >June 1, 2001: New requirements, protocol docs incorporating discussions from >meeting >July 1, 2001: Last call for requirements. >August 2001: WG meets at IETF to discuss protocol issues. >October 1, 2001: Last call for protocols. >December 2001: WG meets at IETF to close. > >Internet Drafts: > >http://www.ietf.org/internet-drafts/draft-day-cdnp-model-02.txt >http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt >http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt >http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-01.txt >[Plus "known-mechanisms" draft coming soon] From owner-wrec@cs.utk.edu Mon Nov 13 12:52:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17444 for ; Mon, 13 Nov 2000 12:52:58 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA23702; Mon, 13 Nov 2000 12:48:30 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 12:47:08 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA23489; Mon, 13 Nov 2000 12:47:07 -0500 (EST) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA23425; Mon, 13 Nov 2000 12:46:54 -0500 (EST) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 12:46:54 -0500 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA03023; Mon, 13 Nov 2000 12:46:20 -0500 (EST) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAA01088; Mon, 13 Nov 2000 12:46:20 -0500 (EST) From: "Mark Day" To: "Michael W. Condry" , Cc: , Subject: RE: Proposed charter for CDNP working group Date: Mon, 13 Nov 2000 12:46:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.0.25.2.20001113093509.009f2540@FMSMSX63.fm.intel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 7bit > Is this [CDNP] an Applications or Ops? IESG appears to have decided that it's Applications. Sorry for not making that clear. --Mark From owner-wrec@cs.utk.edu Mon Nov 13 12:55:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18038 for ; Mon, 13 Nov 2000 12:55:37 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA24423; Mon, 13 Nov 2000 12:51:29 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 12:50:08 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA24110; Mon, 13 Nov 2000 12:50:07 -0500 (EST) Received: from thalia.fm.intel.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA24046; Mon, 13 Nov 2000 12:50:00 -0500 (EST) Received: from thalia.fm.intel.com (132.233.247.11 -> thalia.fm.intel.com) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 12:50:05 -0500 Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id RAA18665; Mon, 13 Nov 2000 17:51:10 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 13 Nov 2000 17:49:53 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Nov 2000 09:49:50 -0800 Message-ID: From: "Condry, Michael W" To: "'Mark Day'" , "Condry, Michael W" , cdn@ops.ietf.org Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: RE: Proposed charter for CDNP working group Date: Mon, 13 Nov 2000 09:49:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: I should have picked that up. -----Original Message----- From: Mark Day [mailto:markday@cisco.com] Sent: Monday, November 13, 2000 9:47 AM To: Michael W. Condry; cdn@ops.ietf.org Cc: wrec@cs.utk.edu; ietf-openproxy@imc.org Subject: RE: Proposed charter for CDNP working group > Is this [CDNP] an Applications or Ops? IESG appears to have decided that it's Applications. Sorry for not making that clear. --Mark From owner-wrec@cs.utk.edu Mon Nov 13 13:31:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28128 for ; Mon, 13 Nov 2000 13:31:15 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA00037; Mon, 13 Nov 2000 13:26:58 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 13:25:36 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA29794; Mon, 13 Nov 2000 13:25:36 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA29773; Mon, 13 Nov 2000 13:25:34 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 13:25:34 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA26411; Mon, 13 Nov 2000 13:25:18 -0500 (EST) Message-Id: <200011131825.NAA26411@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Condry, Michael W" cc: "'Keith Moore'" , Gary Tomlinson , Hilarie Orman , wrec@cs.utk.edu, ietf-openproxy@imc.org, cdn@ops.ietf.org Subject: Re: regarding new working groups In-reply-to: Your message of "Mon, 13 Nov 2000 07:37:10 PST." Date: Mon, 13 Nov 2000 13:25:18 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > Defining the IETF's role is a tough call. I don't think it's tough at all. IETF has no power to stop ISPs from doing abusive things. But IETF should not offer its support to practices that harm the integrity of communications. Keith From owner-wrec@cs.utk.edu Mon Nov 13 13:47:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03528 for ; Mon, 13 Nov 2000 13:47:22 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA03623; Mon, 13 Nov 2000 13:43:24 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 13 Nov 2000 13:41:51 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA03374; Mon, 13 Nov 2000 13:41:50 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA03359; Mon, 13 Nov 2000 13:41:45 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 13 Nov 2000 13:41:45 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 1752CE6; Mon, 13 Nov 2000 19:41:39 +0100 (MET) Received: from [10.10.0.106] (dhcp-2sjc13-85-86.cisco.com [171.70.85.86]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA03653; Mon, 13 Nov 2000 19:41:37 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 13 Nov 2000 10:39:32 -0800 To: "Mark Day" , "Michael W. Condry" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Proposed charter for CDNP working group Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 12.46 -0500 00-11-13, Mark Day wrote: > > Is this [CDNP] an Applications or Ops? > >IESG appears to have decided that it's Applications. Sorry for not making >that clear. The decision is not made until the wg is formally created. Apps has taken the token of hosting the BOF. Ops people will be present. I.e. this might be one of the issues which will be discussed in San Diego. We'll see. paf From owner-wrec@cs.utk.edu Tue Nov 14 06:45:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10135 for ; Tue, 14 Nov 2000 06:45:19 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA07038; Tue, 14 Nov 2000 06:41:18 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 14 Nov 2000 06:41:02 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA06998; Tue, 14 Nov 2000 06:41:01 -0500 (EST) Received: from waldorf.cs.uni-dortmund.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA06969; Tue, 14 Nov 2000 06:40:58 -0500 (EST) Received: from waldorf.cs.uni-dortmund.de (129.217.4.42 -> waldorf.cs.uni-dortmund.de) by cs.utk.edu (smtpshim v1.0); Tue, 14 Nov 2000 06:40:58 -0500 Received: from riemann.cs.uni-dortmund.de (riemann.cs.uni-dortmund.de [129.217.16.74]) by waldorf.cs.uni-dortmund.de with ESMTP id MAA28909 for ; Tue, 14 Nov 2000 12:40:52 +0100 (MET) Received: from xandi.cs.uni-dortmund.de (xandi [129.217.16.221]) by riemann.cs.uni-dortmund.de id MAA25126; Tue, 14 Nov 2000 12:40:51 +0100 (MET) Message-Id: <4.3.2.7.0.20001114123500.00bd76c0@riemann.cs.uni-dortmund.de> X-Sender: cl@riemann.cs.uni-dortmund.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Nov 2000 12:36:27 +0100 To: wrec@cs.utk.edu From: Christoph Lindemann Subject: Announcement: Special Issue on Internet Performance Modelling Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10135 Performance Evaluation journal, Vol. 42, Issue 2-3, 29 September 2000. The articles and abstracts are available online at www.elsevier.com/locate/peva Table of contents: ------------------ Christoph Lindemann and Martin Reiser, Editorial: Internet performance modelling Mark Crovella, Christoph Lindemann and Martin Reiser Internet performance modeling: the state of the art at the turn of the century M. Ajmone Marsan, C. Casetti, R. Gaeta and M. Meo Performance analysis of TCP connections sharing a congested Internet link Eitan Altman, Konstantin Avrachenkov and Chadi Barakat TCP in presence of bursty losses Joachim Charzinski HTTP/TCP connection and flow characteristics Derek L. Eager, Michael C. Ferris and Mary K. Vernon Optimized caching in systems with heterogeneous client populations Anirban Mahanti, Derek Eager and Carey Williamson Temporal locality and its impact on Web proxy cache performance Natalia M. Markovitch and Udo R. Krieger Nonparametric estimation of long-tailed density functions and its application to the analysis of World Wide Web traffic Daniel A. Menascé, Virgilio A.F. Almeida, Rodrigo Fonseca and Marco A. Mendes Business-oriented resource management policies for e-commerce servers ______________________________________________________________________ Prof. Dr.-Ing. Christoph Lindemann Universität Dortmund Informatik IV Tel: (+49231) 755-2410 -Rechnersysteme und Leistungsbewertung- Fax: (+49231) 755-2417 August-Schmidt-Str. 12 E-mail: cl@cs.uni-dortmund.de 44227 Dortmund, Germany WWW: http://www4.cs.uni-dortmund.de/~Lindemann/ _______________________________________________________________________ From owner-wrec@cs.utk.edu Tue Nov 14 15:41:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25246 for ; Tue, 14 Nov 2000 15:41:23 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA05174; Tue, 14 Nov 2000 15:36:32 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 14 Nov 2000 15:36:18 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA05121; Tue, 14 Nov 2000 15:36:17 -0500 (EST) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA05105; Tue, 14 Nov 2000 15:36:10 -0500 (EST) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 14 Nov 2000 15:36:10 -0500 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 975C1E6 for ; Tue, 14 Nov 2000 21:36:08 +0100 (MET) Received: from [10.10.0.106] ([10.19.254.16]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA21580 for ; Tue, 14 Nov 2000 21:36:07 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <4.3.2.7.0.20001114123500.00bd76c0@riemann.cs.uni-dortmund.de> References: <4.3.2.7.0.20001114123500.00bd76c0@riemann.cs.uni-dortmund.de> Date: Tue, 14 Nov 2000 12:36:17 -0800 To: wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: WEBI/WREC as WREC on the agenda at the next IETF Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: FYI: The WREC wg charter change will not be possible to do before the meeting in San Diego. You will because of this see a slot as WREC, and not WEBI. This because the IESG has made the decision that formally WREC will be killed, and WEBI will be created as a new wg. I.e. the changes are so large, and we want a complete restart. Patrik Faltstrom Co-Area Director, Applications Area From owner-wrec@cs.utk.edu Wed Nov 15 05:11:28 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23117 for ; Wed, 15 Nov 2000 05:11:28 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA13457; Wed, 15 Nov 2000 05:07:24 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 05:07:13 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA13430; Wed, 15 Nov 2000 05:07:13 -0500 (EST) Received: from unni.dsv.su.se (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA13416; Wed, 15 Nov 2000 05:07:09 -0500 (EST) Received: from unni.dsv.su.se (130.237.161.27 -> unni.dsv.su.se) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 05:07:09 -0500 Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by unni.dsv.su.se (8.9.3+Sun/8.9.3) with ESMTP id LAA08226; Wed, 15 Nov 2000 11:07:06 +0100 (MET) Mime-Version: 1.0 X-Sender: jpalme@mail.dsv.su.se Message-Id: Date: Wed, 15 Nov 2000 11:05:00 +0800 To: wrec@cs.utk.edu From: Jacob Palme Subject: Different web pages for different browser versions Cc: Mikael von Pfaler Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: I am not a regular participant of wrec. But I have a question which maybe you have already solved. I tried to look into your archives, but could not find it. The question is that more and more web sites will chech which browser type the user has, and deliver different versions of a web page depending on the browser type. How can proxies handle this, so that you deliver a cached version only if it suits the browser capabilities of the user? -- Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/jpalme/ From owner-wrec@cs.utk.edu Wed Nov 15 06:46:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03837 for ; Wed, 15 Nov 2000 06:46:06 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA22914; Wed, 15 Nov 2000 06:42:15 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 06:41:52 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA22891; Wed, 15 Nov 2000 06:41:51 -0500 (EST) Received: from ietf.org (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA22878; Wed, 15 Nov 2000 06:41:50 -0500 (EST) Received: from ietf.org (132.151.1.176 -> odin.ietf.org) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 06:41:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01656; Wed, 15 Nov 2000 06:41:48 -0500 (EST) Message-Id: <200011151141.GAA01656@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: wrec@cs.utk.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-wrec-known-prob-03.txt Date: Wed, 15 Nov 2000 06:41:47 -0500 Sender: nsyracus@cnri.reston.va.us List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Replication and Caching Working Group of the IETF. Title : Known HTTP Proxy/Caching Problems Author(s) : I. Cooper, J. Dilley Filename : draft-ietf-wrec-known-prob-03.txt Pages : 31 Date : 14-Nov-00 This memo catalogs a number of known problems with World Wide Web (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. The construction of this document is a joint effort of the Web caching community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-wrec-known-prob-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-wrec-known-prob-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-wrec-known-prob-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001114131352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-wrec-known-prob-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-wrec-known-prob-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001114131352.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-wrec@cs.utk.edu Wed Nov 15 08:46:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27648 for ; Wed, 15 Nov 2000 08:46:34 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA04584; Wed, 15 Nov 2000 08:42:40 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 08:42:33 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA04554; Wed, 15 Nov 2000 08:42:32 -0500 (EST) Received: from justice.atc-bos.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA04518; Wed, 15 Nov 2000 08:42:15 -0500 (EST) Received: from justice.atc-bos.com (216.73.149.66 -> ip-216-73-149-66.vantas.net) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 08:42:16 -0500 Received: (from mcmanus@localhost) by justice.atc-bos.com (8.9.3/8.8.7) id IAA15498; Wed, 15 Nov 2000 08:41:57 -0500 Date: Wed, 15 Nov 2000 08:41:57 -0500 From: Patrick McManus To: Jacob Palme Cc: wrec@cs.utk.edu, Mikael von Pfaler Subject: Re: Different web pages for different browser versions Message-ID: <20001115084157.A15487@appliedtheory.com> Reply-To: mcmanus@appliedtheory.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jpalme@dsv.su.se on Wed, Nov 15, 2000 at 11:05:00AM +0800 List-Unsubscribe: this is really http, not whatever the heck wrec is (I just said that to get the rhyme in.), but the server should add the Vary: User-Agent header to the 1.1 response.. A 1.1 cache knows that only future requests with the same user-agent header (and/or any other header(s) listed in the vary response header) as the request that generated the cached response may be satisified by that cached response. (subject to the other normal freshness rules of course.) [Jacob Palme: Wed, Nov 15, 2000 at 11:05:00AM +0800] > I am not a regular participant of wrec. But I have a question > which maybe you have already solved. I tried to look into > your archives, but could not find it. > > The question is that more and more web sites will chech > which browser type the user has, and deliver different > versions of a web page depending on the browser type. > > How can proxies handle this, so that you deliver a cached > version only if it suits the browser capabilities of the > user? > -- > Jacob Palme (Stockholm University and KTH) > for more info see URL: http://www.dsv.su.se/jpalme/ From owner-wrec@cs.utk.edu Wed Nov 15 11:15:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28640 for ; Wed, 15 Nov 2000 11:15:27 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA24354; Wed, 15 Nov 2000 11:11:12 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 11:11:09 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA24330; Wed, 15 Nov 2000 11:11:09 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA24303; Wed, 15 Nov 2000 11:11:01 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 11:11:06 -0500 Received: from icooper.equinix.com (dynamic2-124.corp.equinix.com [172.16.2.124]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id IAA15140 for ; Wed, 15 Nov 2000 08:10:55 -0800 (PST) Message-Id: <5.0.0.25.2.20001115080414.00a62550@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Nov 2000 08:10:36 -0800 To: wrec@cs.utk.edu From: Ian Cooper Subject: Re: I-D ACTION:draft-ietf-wrec-known-prob-03.txt In-Reply-To: <200011151141.GAA01656@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: I'd like to draw everyone's attention to this. The document has gone through a fairly major edit and I'd be grateful if folks (*especially* if you're a contributor) would take a look and check that it makes sense. If you have comments please make then *now*. The reorg is based on the discussion in Pittsburgh; if you think something should come back out of the appendix please let us know. It would be useful to have a final draft done before the cutoff date for this IETF (24th November in this case). At 06:41 11/15/00 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Web Replication and Caching Working Group >of the IETF. > > Title : Known HTTP Proxy/Caching Problems > Author(s) : I. Cooper, J. Dilley > Filename : draft-ietf-wrec-known-prob-03.txt > Pages : 31 > Date : 14-Nov-00 > >This memo catalogs a number of known problems with World Wide Web >(caching) proxies and cache servers. The goal of the document is to >provide a discussion of the problems and proposed workarounds, and >ultimately to improve conditions by illustrating problems. The >construction of this document is a joint effort of the Web caching >community. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-wrec-known-prob-03.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-wrec-known-prob-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-wrec-known-prob-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <20001114131352.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-wrec-known-prob-03.txt > > From owner-wrec@cs.utk.edu Wed Nov 15 11:17:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29449 for ; Wed, 15 Nov 2000 11:17:24 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA24697; Wed, 15 Nov 2000 11:13:05 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 11:13:04 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA24674; Wed, 15 Nov 2000 11:13:04 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA24661; Wed, 15 Nov 2000 11:13:01 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 11:13:02 -0500 Received: from icooper.equinix.com (dynamic2-124.corp.equinix.com [172.16.2.124]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id IAA15270 for ; Wed, 15 Nov 2000 08:12:57 -0800 (PST) Message-Id: <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Nov 2000 08:12:39 -0800 To: wrec@cs.utk.edu From: Ian Cooper Subject: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt >Date: Wed, 15 Nov 2000 06:41:12 -0500 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : WCIP: Web Cache Invalidation Protocol > Author(s) : D. Li, P. Cao, M. Dahlin > Filename : draft-danli-wrec-wcip-00.txt > Pages : 26 > Date : 14-Nov-00 > >Cache consistency is a major impediment to scalable content >delivery. This document describes the Web Cache Invalidation >Protocol (WCIP) which uses invalidations and updates to keep >changing objects up to date in web caches. Moreover, it allows >automatic one-to-may relay and many-to-one aggregation in a CDN >(content delivery network) environment. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-danli-wrec-wcip-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <20001114131241.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > From owner-wrec@cs.utk.edu Wed Nov 15 12:52:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03982 for ; Wed, 15 Nov 2000 12:52:47 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA18478; Wed, 15 Nov 2000 12:47:32 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 12:47:02 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA18389; Wed, 15 Nov 2000 12:47:02 -0500 (EST) Received: from nemo.corp.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA18359; Wed, 15 Nov 2000 12:46:51 -0500 (EST) From: Received: from nemo.corp.equinix.com (207.20.85.154 -> somehost-2.equinix.net) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 12:46:51 -0500 Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id JAA14729; Wed, 15 Nov 2000 09:46:23 -0800 (PST) Message-Id: <200011151746.JAA14729@nemo.corp.equinix.com> Subject: Re: Different web pages for different browser versions To: jpalme@dsv.su.se (Jacob Palme) Date: Wed, 15 Nov 2000 09:46:23 -0800 (PST) Cc: wrec@cs.utk.edu In-Reply-To: from "Jacob Palme" at Nov 15, 2000 11:05:00 AM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Jacob, Both the CONNEG working group in the IETF and the CCPP working group in the W3C have looked at this. The first step in this process is moving the decision about what version to send away from dependencies based on User-Agent to profiles (based on RDF in the CCPP case and prolog-like syntax in the CONNEG case). Those profiles can be referenced or included in the request/response stream. In some cases, the proxy capabilities may even be associated with the request so that an origin server can make a decision which includes the transcoding capabilities of the proxy. For the W3C work, please see http://www.w3.org/Mobile/CCPP/ ; for the IETF work, please see RFCs 2533, 2912, 2913, and 2938. regards, Ted Hardie > I am not a regular participant of wrec. But I have a question which > maybe you have already solved. I tried to look into your archives, > but could not find it. The question is that more and more web sites > will chech which browser type the user has, and deliver different > versions of a web page depending on the browser type. How can > proxies handle this, so that you deliver a cached version only if it > suits the browser capabilities of the user? -- Jacob Palme > (Stockholm University and KTH) for more info see > URL: http://www.dsv.su.se/jpalme/ From owner-wrec@cs.utk.edu Wed Nov 15 16:05:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23509 for ; Wed, 15 Nov 2000 16:05:25 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA13796; Wed, 15 Nov 2000 16:00:44 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 16:00:23 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA13743; Wed, 15 Nov 2000 16:00:22 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA13717; Wed, 15 Nov 2000 16:00:15 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 16:00:20 -0500 Received: from dli2-nt (dhcp-10-34-17-66.cisco.com [10.34.17.66]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA05748; Wed, 15 Nov 2000 12:59:30 -0800 (PST) Message-Id: <4.2.0.58.20001115123617.02270ab0@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Nov 2000 12:57:41 -0800 To: Ian Cooper , wrec@cs.utk.edu From: Dan Li Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt In-Reply-To: <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Hi, please take a look of the WCIP draft before the IETF meeting, as we'd spend time on issue discussions and won't cover the draft in detail. This draft is a strawman, at least the following things need more work: - clearly define the relationship of wcip with normal cache-control directives. - specify in more detail the role of relay point, especially for channel aggregation. Can we or can we not aggregate heartbeats, possibly but cutting freshness guarantee. - pick a security model. Use SSL, or PGP signature, or both, and also the security of the channel info. - do we need a default port number? pros and cons wrt. to port 80. - are people happy with persistent TCP connection? are people happy with "delta consistency" (vs. eventual consistency, strong consistency, or anything else). - in the absence of a off-the-shelf realtime reliable multicast protocol, can we still run wcip on multicast UDP for scalability. See section 3.2.3. - preloading, log reporting, advanced event notification, programability, ... future stuff on vertical peering and dynamic content What do people think? Dan At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: >>To: IETF-Announce: ; >>From: Internet-Drafts@ietf.org >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt >>Date: Wed, 15 Nov 2000 06:41:12 -0500 >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : WCIP: Web Cache Invalidation Protocol >> Author(s) : D. Li, P. Cao, M. Dahlin >> Filename : draft-danli-wrec-wcip-00.txt >> Pages : 26 >> Date : 14-Nov-00 >> >>Cache consistency is a major impediment to scalable content >>delivery. This document describes the Web Cache Invalidation >>Protocol (WCIP) which uses invalidations and updates to keep >>changing objects up to date in web caches. Moreover, it allows >>automatic one-to-may relay and many-to-one aggregation in a CDN >>(content delivery network) environment. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-danli-wrec-wcip-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>Content-Type: text/plain >>Content-ID: <20001114131241.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt >> >> > From owner-wrec@cs.utk.edu Wed Nov 15 17:39:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29476 for ; Wed, 15 Nov 2000 17:39:10 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA23301; Wed, 15 Nov 2000 17:34:33 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 17:34:24 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA23258; Wed, 15 Nov 2000 17:34:24 -0500 (EST) Received: from sj-msg-core-2.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA23242; Wed, 15 Nov 2000 17:34:17 -0500 (EST) Received: from sj-msg-core-2.cisco.com (171.69.43.88 -> sj-msg-core-2.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 17:34:22 -0500 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA26115; Wed, 15 Nov 2000 14:33:42 -0800 (PST) Received: from [10.19.254.54] ([10.19.254.54]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA16704; Wed, 15 Nov 2000 16:33:30 -0600 (CST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: Date: Wed, 15 Nov 2000 14:32:50 -0800 To: wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Cc: Ned Freed , IESG-Secretary Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: I think you get the message from the RFC Editor below. I need a new version of this document. Patrik Co-Area Director, Applications Area >Date: Wed, 15 Nov 00 14:26:41 PST >From: jkrey@ISI.EDU >Posted-Date: Wed, 15 Nov 00 14:26:41 PST >To: iesg@ISI.EDU >Subject: RFC-to-be: draft-ietf-wrec-taxonomy-05 >Cc: rfc-ed@ISI.EDU > > > >Ned, Patrik, IESG folks, > >I have been wrestling with bad URL links in this document. While the >authors have been very helpful in tracking down live links to replace >the cited bad links, I have come upon an additional problem with this >RFC-to-be. > >Laced throughout this document are pointers and citations to >Internet-Drafts. This includes full strings. >Many of them noted as "expired" I-Ds AND also noted as the >"Authoritative reference" in each descriptive section. At first, I >attempted to replace any "draft" type mention with "work in progress", >which is our practice. I am afraid that in this particular case, it is >too much! > >Since we still have the "rule" about not citing/pointing to >Internet-Drafts in RFCs, does the IESG and relevant Area Directors >still agree that this document should go forward in its current state? > >Thanks! Joyce From owner-wrec@cs.utk.edu Wed Nov 15 18:48:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22225 for ; Wed, 15 Nov 2000 18:48:09 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA29273; Wed, 15 Nov 2000 18:43:57 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 18:43:49 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA29234; Wed, 15 Nov 2000 18:43:49 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA29183; Wed, 15 Nov 2000 18:43:32 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 18:43:32 -0500 Received: from icooper.equinix.com (dynamic2-124.corp.equinix.com [172.16.2.124]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id PAA17381; Wed, 15 Nov 2000 15:43:29 -0800 (PST) Message-Id: <5.0.0.25.2.20001115145320.00a72240@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 15 Nov 2000 15:43:29 -0800 To: Patrik =?iso-8859-1?Q?Fdltstrvm?= , wrec@cs.utk.edu From: Ian Cooper Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Cc: Ned Freed , IESG-Secretary In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed List-Unsubscribe: I'm a little miffed that this issue took so long to come to light, but I'm= =20 also wondering whether there's a relatively quick fix. My reading of the draft finds 6 references to internet drafts (I'm ignoring= =20 the KP document): [3] WPAD [4] CARP [7] Ivan Lovric's ICP extensions [13] WCCPv1.0 [16] Goutard & Lovric's satellite pre-filling [21] NECP Of those [3], [4] and [13] are protocols that are in use in the real=20 Internet today. And those drafts (which we attempted to archive for this=20 specific reason - note that the URLs do *not* point to the IETF=20 repositories) are the only publicly available documentation (if you know=20 differently then please let me know!). Cisco published the specification=20 for WCCPv2 earlier this year, but I haven't seen any discussion about it. Is the fix to simply make the filenames/references look less like=20 internet-drafts and just keep them in their current locations? (For those= =20 wondering about RFC2026 section 10 stuff, all allow derivative works.) Working through the draft, as the problem references arise: Section 6.3 - CARP - Supported in commercial and free (and rather well=20 used) products. Needs mentioning, needs a reference. Section 6.4 - WPAD - MSIE supports it, and I know of several ISPs that use= =20 it. Needs mentioning, needs a reference. (There's a re-submitted version= =20 in the ID queue right now.) Section 7.1.1 - ICP - references [7] as an extension, not as an=20 authoritative reference. Shouldn't really be a problem? Section 7.1.4 - Cache pre-filling via satellite - Get rid of the=20 authoritative reference (there isn't one, I guess) and add it as a note? Section 7.2.1 - CARP (again) Section 8.1 - WCCP - Deployed in rather a few Cisco products and many=20 caching proxy vendors' products. Needs mentioning, needs a reference. Section 8.2 - NECP - Interest seems to have waned, though I know of some=20 folks who are interested in it and are using it in some way. Should be=20 mentioned, needs a reference. At 14:32 11/15/00 -0800, Patrik F=E4ltstr=F6m wrote: >I think you get the message from the RFC Editor below. > >I need a new version of this document. > > Patrik > Co-Area Director, Applications Area > >>Date: Wed, 15 Nov 00 14:26:41 PST >>From: jkrey@ISI.EDU >>Posted-Date: Wed, 15 Nov 00 14:26:41 PST >>To: iesg@ISI.EDU >>Subject: RFC-to-be: draft-ietf-wrec-taxonomy-05 >>Cc: rfc-ed@ISI.EDU >> >> >> >>Ned, Patrik, IESG folks, >> >>I have been wrestling with bad URL links in this document. While the >>authors have been very helpful in tracking down live links to replace >>the cited bad links, I have come upon an additional problem with this >>RFC-to-be. >> >>Laced throughout this document are pointers and citations to >>Internet-Drafts. This includes full strings. >>Many of them noted as "expired" I-Ds AND also noted as the >>"Authoritative reference" in each descriptive section. At first, I >>attempted to replace any "draft" type mention with "work in progress", >>which is our practice. I am afraid that in this particular case, it is >>too much! >> >>Since we still have the "rule" about not citing/pointing to >>Internet-Drafts in RFCs, does the IESG and relevant Area Directors >>still agree that this document should go forward in its current state? >> >>Thanks! Joyce From owner-wrec@cs.utk.edu Wed Nov 15 18:58:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25607 for ; Wed, 15 Nov 2000 18:58:55 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA00870; Wed, 15 Nov 2000 18:54:47 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 18:54:40 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA00833; Wed, 15 Nov 2000 18:54:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA00799; Wed, 15 Nov 2000 18:54:33 -0500 (EST) Received: from sj-msg-core-1.cisco.com (171.71.163.11 -> sj-msg-core-1.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 18:54:33 -0500 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA16517; Wed, 15 Nov 2000 15:53:57 -0800 (PST) Received: from [10.19.254.54] ([10.19.254.54]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA17275; Wed, 15 Nov 2000 17:53:52 -0600 (CST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <5.0.0.25.2.20001115145320.00a72240@nemo.corp.equinix.com> References: <5.0.0.25.2.20001115145320.00a72240@nemo.corp.equinix.com> Date: Wed, 15 Nov 2000 15:53:34 -0800 To: Ian Cooper , wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Cc: Ned Freed , IESG-Secretary Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 15.43 -0800 00-11-15, Ian Cooper wrote: >Is the fix to simply make the filenames/references look less like >internet-drafts and just keep them in their current locations? I would say, less like URL's. The URL is not persistent enough. The URL can be there, but a way is needed to find the data when the URL is no longer valid and correct. paf From owner-wrec@cs.utk.edu Wed Nov 15 19:11:25 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00488 for ; Wed, 15 Nov 2000 19:11:15 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA02267; Wed, 15 Nov 2000 19:06:47 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 19:06:42 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA02235; Wed, 15 Nov 2000 19:06:42 -0500 (EST) Received: from sj-msg-core-1.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA02222; Wed, 15 Nov 2000 19:06:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (171.71.163.11 -> sj-msg-core-1.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 19:06:40 -0500 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA25592; Wed, 15 Nov 2000 16:06:10 -0800 (PST) Received: from [10.19.254.54] ([10.19.254.54]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA17351; Wed, 15 Nov 2000 18:06:04 -0600 (CST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: <5.0.0.25.2.20001115145320.00a72240@nemo.corp.equinix.com> Date: Wed, 15 Nov 2000 16:04:24 -0800 To: Ian Cooper , wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Cc: Ned Freed , IESG-Secretary Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA00488 At 15.53 -0800 00-11-15, Patrik Fältström wrote: >At 15.43 -0800 00-11-15, Ian Cooper wrote: >>Is the fix to simply make the filenames/references look less like >>internet-drafts and just keep them in their current locations? > >I would say, less like URL's. The URL is not persistent enough. The >URL can be there, but a way is needed to find the data when the URL >is no longer valid and correct. That response only covered one of the problems. The problem with referencing I-D's are that I-D's are temporary while RFC's are static. Because of this, we write out the name of the I-D together with "Work in progress" string, and do so only for non-normative references. If you have normative references, you have to have a more static name than the name of an I-D, or rather, to a more static object than an I-D. Patrik From owner-wrec@cs.utk.edu Wed Nov 15 19:13:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01375 for ; Wed, 15 Nov 2000 19:13:20 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA02575; Wed, 15 Nov 2000 19:08:50 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 19:08:49 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA02553; Wed, 15 Nov 2000 19:08:49 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA02472; Wed, 15 Nov 2000 19:08:29 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 19:08:29 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 15 Nov 2000 17:07:59 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 15 Nov 2000 17:07:44 -0700 From: "Hilarie Orman" To: , , Cc: , Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2B700F4F.701178F4" List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2B700F4F.701178F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've not seen the text in question, but this sounds very strange. Are you saying that draft references must be to paper documents? I surely hope not. Search engines are perfectly nifty ways to find data when the URL is no longer valid and correct, so I'm confused by the advice you seem to be giving. Please forgive me if I am misunderstanding the discussion. Hilarie >>> Patrik F=E4ltstr=F6m 11/15/00 04:53PM >>> At 15.43 -0800 00-11-15, Ian Cooper wrote: >Is the fix to simply make the filenames/references look less like=20 >internet-drafts and just keep them in their current locations? I would say, less like URL's. The URL is not persistent enough. The=20 URL can be there, but a way is needed to find the data when the URL=20 is no longer valid and correct. paf --=_2B700F4F.701178F4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've not seen the text in question, but this sounds = very=20 strange.
Are you saying that draft references must be to = paper=20 documents?
I surely hope not.
 
Search engines are perfectly nifty ways to find data = when=20 the
URL is no longer valid and correct, so I'm confused = by=20 the
advice you seem to be giving.  Please forgive me = if I=20 am
misunderstanding the discussion.
 
Hilarie

>>> Patrik F=E4ltstr=F6m=  =20 <paf@cisco.com> 11/15/00 04:53PM >>>
At 15.43 -0800 = 00-11-15,=20 Ian Cooper wrote:
>Is the fix to simply make the filenames/references= look=20 less like
>internet-drafts and just keep them in their current=20 locations?

I would say, less like URL's. The URL is not persistent= =20 enough. The
URL can be there, but a way is needed to find the data = when the=20 URL
is no longer valid and correct.

   =20 paf
--=_2B700F4F.701178F4-- From owner-wrec@cs.utk.edu Wed Nov 15 19:18:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03328 for ; Wed, 15 Nov 2000 19:18:33 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA03781; Wed, 15 Nov 2000 19:13:32 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 19:13:28 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA03739; Wed, 15 Nov 2000 19:13:27 -0500 (EST) Received: from sj-msg-core-2.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA03703; Wed, 15 Nov 2000 19:13:12 -0500 (EST) Received: from sj-msg-core-2.cisco.com (171.69.43.88 -> sj-msg-core-2.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 19:13:12 -0500 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA09867; Wed, 15 Nov 2000 16:11:59 -0800 (PST) Received: from [10.19.254.54] ([10.19.254.54]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA17433; Wed, 15 Nov 2000 18:11:51 -0600 (CST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: References: Date: Wed, 15 Nov 2000 16:11:34 -0800 To: "Hilarie Orman" , , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 Cc: , Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA03328 At 17.07 -0700 00-11-15, Hilarie Orman wrote: >I've not seen the text in question, but this sounds very strange. >Are you saying that draft references must be to paper documents? Where below do I talk about paper documents? I wrote "The URL is not persistent enough.". You have to have a name of the document so it is possible to find it. For many of them, you point to only a URL and nothing else. Then we have the issues with references to Internet Drafts which I mentioned in a second email. paf >I surely hope not. > >Search engines are perfectly nifty ways to find data when the >URL is no longer valid and correct, so I'm confused by the >advice you seem to be giving. Please forgive me if I am >misunderstanding the discussion. > >Hilarie > >>>> Patrik Fältström 11/15/00 04:53PM >>> >At 15.43 -0800 00-11-15, Ian Cooper wrote: >>Is the fix to simply make the filenames/references look less like >>internet-drafts and just keep them in their current locations? > >I would say, less like URL's. The URL is not persistent enough. The >URL can be there, but a way is needed to find the data when the URL >is no longer valid and correct. > > paf From owner-wrec@cs.utk.edu Wed Nov 15 19:33:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06652 for ; Wed, 15 Nov 2000 19:33:23 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA06655; Wed, 15 Nov 2000 19:29:01 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 15 Nov 2000 19:28:51 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA06632; Wed, 15 Nov 2000 19:28:50 -0500 (EST) Received: from sj-msg-core-2.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA06589; Wed, 15 Nov 2000 19:28:24 -0500 (EST) Received: from sj-msg-core-2.cisco.com (171.69.43.88 -> sj-msg-core-2.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 15 Nov 2000 19:28:24 -0500 Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA19865 for ; Wed, 15 Nov 2000 16:28:19 -0800 (PST) Received: from pranavd-nt.cisco.com (dhcp-171-70-96-202.cisco.com [171.70.96.202]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAG20200; Wed, 15 Nov 2000 16:28:19 -0800 (PST) Message-Id: <4.3.2.7.2.20001115162756.00b21500@mira-sjc5-5.cisco.com> X-Sender: pranavd@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Nov 2000 16:28:18 -0800 To: wrec@cs.utk.edu From: Pranav Dharwadkar Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: PLease unsubscribe me from this list. thanks. pranav. From owner-wrec@cs.utk.edu Mon Nov 20 11:44:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20905 for ; Mon, 20 Nov 2000 11:44:53 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA07374; Mon, 20 Nov 2000 11:40:17 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 20 Nov 2000 11:39:42 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA07308; Mon, 20 Nov 2000 11:39:39 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA07292; Mon, 20 Nov 2000 11:39:36 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Mon, 20 Nov 2000 11:39:37 -0500 Received: from icooper.equinix.com (dynamic2-204.corp.equinix.com [172.16.2.204]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id IAA05026; Mon, 20 Nov 2000 08:39:18 -0800 (PST) Message-Id: <5.0.0.25.2.20001120081927.00a7bd38@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 20 Nov 2000 08:39:18 -0800 To: agenda@ietf.org From: Ian Cooper Subject: Updated agenda details for WREC meeting Cc: wrec@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Web Replication and Caching (wrec) Tuesday, December 12 at 1300-1400 ================================= CHAIRS: Ian Cooper Mark Nottingham AGENDA: 10 mins - introduction, agenda bashing 20 mins - invalidation: introduction, scoping of work 20 mins - intermediary discovery: introduction, scoping of work 10 mins - conclusions, next steps SUGGESTED READING MATERIAL: WREC Known Problems - draft-ietf-wrec-known-prob-03.txt Distributed Object Consistency Protocol - http://www.hpl.hp.com/techreports/1999/HPL-1999-109.html Web Cache Invalidation Protocol draft-danli-wrec-wcip-00.txt WPAD - draft-cooper-webi-wpad-00.txt Attendees should also consider attending the OPES, CDNP and C15N meetings, also scheduled for Tuesday afternoon. From owner-wrec@cs.utk.edu Mon Nov 20 20:58:01 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27151 for ; Mon, 20 Nov 2000 20:58:01 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA19907; Mon, 20 Nov 2000 20:53:37 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 20 Nov 2000 20:53:29 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA19861; Mon, 20 Nov 2000 20:53:28 -0500 (EST) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA19842; Mon, 20 Nov 2000 20:53:26 -0500 (EST) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Mon, 20 Nov 2000 20:53:26 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA11911; Mon, 20 Nov 2000 17:53:18 -0800 (PST) Message-ID: <3A19D520.37AE4B19@isi.edu> Date: Mon, 20 Nov 2000 17:51:28 -0800 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Hilarie Orman , wrec@cs.utk.edu, icooper@equinix.com, iesg-secretary@ietf.org, Ned.Freed@innosoft.com, touch@ISI.EDU Subject: Re: Fwd: RFC-to-be: draft-ietf-wrec-taxonomy-05 References: Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by cs.utk.edu id UAA19907 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27151 Patrik Fältström wrote: > > At 17.07 -0700 00-11-15, Hilarie Orman wrote: > >I've not seen the text in question, but this sounds very strange. > >Are you saying that draft references must be to paper documents? > > Where below do I talk about paper documents? > > I wrote "The URL is not persistent enough.". You have to have a name > of the document so it is possible to find it. To clarify: RFCs must use only citations to archived, widely-accessible documents when referring to external supporting documents (contrasted to when giving credit). While it may be useful in FINDING something, the web is not a citation-quality archive. Generally, only books with publishers (and thus ISBN numbers, thus including conference proceedings, etc), and university or commercial tech reports, etc. qualify. Joe From owner-wrec@cs.utk.edu Mon Nov 20 21:36:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03125 for ; Mon, 20 Nov 2000 21:36:35 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA24214; Mon, 20 Nov 2000 21:32:20 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 20 Nov 2000 21:32:18 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA24192; Mon, 20 Nov 2000 21:32:18 -0500 (EST) Received: from mnot.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA24177; Mon, 20 Nov 2000 21:32:15 -0500 (EST) Received: from mnot.sanmateo.akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Mon, 20 Nov 2000 21:32:16 -0500 Received: by mnot.sanmateo.akamai.com (Postfix, from userid 20351) id AB499503D; Mon, 20 Nov 2000 18:32:00 -0800 (PST) Date: Mon, 20 Nov 2000 18:32:00 -0800 From: Mark Nottingham To: Dan Li Cc: Ian Cooper , wrec@cs.utk.edu Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Message-ID: <20001120183159.K876@akamai.com> References: <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> <4.2.0.58.20001115123617.02270ab0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.2.0.58.20001115123617.02270ab0@omega>; from lidan@cisco.com on Wed, Nov 15, 2000 at 12:57:41PM -0800 List-Unsubscribe: First of all, thanks for presenting WCIP for consideration; having something specific to talk about is a great way to get discussion moving. That having been said, here are some things that come to mind when reading wcip; * Motivation - The draft motivates itself as solving problems in dynamic content caching. While I don't want to start nit-picking at this stage, IMHO it's important to properly motivate the work, and an invalidation protocol doesn't address this issue; it addresses cache coherence where resource freshness isn't predictable. * Variants - We'll need to very carefully specify how object variants should be handled; in some cases, it will be desireable to invalidate a limited selection of variants (e.g., english and german but not japanese), while in others it should be possible to invalidate all variants of a particular resource. This should be probably addressed in the channel description format and/or the invalidation message format. * Transport - WCIP seems to use a hodge-podge of transports, including HTTP, a yet-to-be-described TCP protocol, and multicast. I'd argue that there should be one transport, or at most two, if multicast is really necessary. I'm personally doubtful about using multicast, both because of its poor deployment and the fact that it requires specifying two separate models for using WCIP. It should be noted that I'm not exactly familiar with the issues in multicast, but then again IETF is full of people who are, so hopefully this issue can be sorted soon. I'd very much like BXXP to be addedd to the list of possible components to reuse (in design issues). It's a much more functional, clean and extensible framework than HTTP, from what little I know. Cheers, On Wed, Nov 15, 2000 at 12:57:41PM -0800, Dan Li wrote: > Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > spend time on issue discussions and won't cover the draft in detail. This > draft is a strawman, at least the following things need more work: > > - clearly define the relationship of wcip with normal cache-control directives. > > - specify in more detail the role of relay point, especially for channel > aggregation. Can we or can we not aggregate heartbeats, possibly but > cutting freshness guarantee. > > - pick a security model. Use SSL, or PGP signature, or both, and also the > security of the channel info. > > - do we need a default port number? pros and cons wrt. to port 80. > > - are people happy with persistent TCP connection? are people happy with > "delta consistency" (vs. eventual consistency, strong consistency, or > anything else). > > - in the absence of a off-the-shelf realtime reliable multicast protocol, > can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > - preloading, log reporting, advanced event notification, programability, > ... future stuff on vertical peering and dynamic content > > What do people think? > > Dan > > > > > > At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > >>To: IETF-Announce: ; > >>From: Internet-Drafts@ietf.org > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : WCIP: Web Cache Invalidation Protocol > >> Author(s) : D. Li, P. Cao, M. Dahlin > >> Filename : draft-danli-wrec-wcip-00.txt > >> Pages : 26 > >> Date : 14-Nov-00 > >> > >>Cache consistency is a major impediment to scalable content > >>delivery. This document describes the Web Cache Invalidation > >>Protocol (WCIP) which uses invalidations and updates to keep > >>changing objects up to date in web caches. Moreover, it allows > >>automatic one-to-may relay and many-to-one aggregation in a CDN > >>(content delivery network) environment. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-danli-wrec-wcip-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >>Content-Type: text/plain > >>Content-ID: <20001114131241.I-D@ietf.org> > >> > >>ENCODING mime > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >> > > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Mon Nov 20 22:21:43 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08143 for ; Mon, 20 Nov 2000 22:21:42 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA29456; Mon, 20 Nov 2000 22:17:36 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 20 Nov 2000 22:17:33 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA29434; Mon, 20 Nov 2000 22:17:33 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA29390; Mon, 20 Nov 2000 22:17:27 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 20 Nov 2000 22:17:27 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id TAA04259; Mon, 20 Nov 2000 19:16:54 -0800 (PST) Message-Id: <4.2.0.58.20001120184927.0221fee0@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 20 Nov 2000 19:20:18 -0800 To: Mark Nottingham From: Dan Li Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Cc: Ian Cooper , wrec@cs.utk.edu In-Reply-To: <20001120183159.K876@akamai.com> References: <4.2.0.58.20001115123617.02270ab0@omega> <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> <4.2.0.58.20001115123617.02270ab0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 06:32 PM 11/20/00 -0800, Mark Nottingham wrote: >* Motivation - The draft motivates itself as solving problems in dynamic > content caching. While I don't want to start nit-picking at this stage, > IMHO it's important to properly motivate the work, and an invalidation > protocol doesn't address this issue; it addresses cache coherence where > resource freshness isn't predictable. I'd say the motivation for WCIP is two fold, for dynamic content and for vertical peering. Dynamic content refers to a list of things (frequently changing, personalized, and dynamically generated from databases). The current "ObjectList" DTD covers only case 1 (frequently changing ones), but the trajectory is to carry more complex event notifications for personalization and dynamically generated stuff. By vertical peering, I refer to things like preloading, delta update, and log reporting, etc. This is mainly leveraging the notification transport (the channel and the relay). > >* Variants - We'll need to very carefully specify how object variants should > be handled; in some cases, it will be desireable to invalidate a limited > selection of variants (e.g., english and german but not japanese), while in > others it should be possible to invalidate all variants of a particular > resource. > > This should be probably addressed in the channel description format and/or > the invalidation message format. Agreed. At first glance (read:don't take my word seriously), the origin server and/or the invalidation server can set different ObjectNames to denote different variants (note that invalidations are done based on ObjectNames), and then we may use regular expression matching for invalidating a bunch of them. Another approach would be the cache just has to be aware of all the HTTP variant fields and the invalidation DTD has to provide fields for those variants. E.g., do a match on all HTTP entity headers, ... I hope we don't complicate things too much. >* Transport - WCIP seems to use a hodge-podge of transports, including HTTP, > a yet-to-be-described TCP protocol, and multicast. I'd argue that there > should be one transport, or at most two, if multicast is really necessary. I think "transport" deserves more discussion. There are really two components in WCIP, 1. a notification transport (including the concept of channel, relay point, and appl-layer multicast), and 2. the semantics/messages carried by this transport (right now is ObjectList, but will expand). Along this line, there's plenty of room to clearly separate this two and allow growth (separately) in both of them. How Beep (formerly BXXP) fits in here? a foundation for building WCIP transport? regards, Dan > I'm personally doubtful about using multicast, both because of its poor > deployment and the fact that it requires specifying two separate models > for using WCIP. It should be noted that I'm not exactly familiar with the > issues in multicast, but then again IETF is full of people who are, so > hopefully this issue can be sorted soon. > > I'd very much like BXXP to be addedd to the list of possible components to > reuse (in design issues). It's a much more functional, clean and > extensible framework than HTTP, from what little I know. > >Cheers, > > > > > >On Wed, Nov 15, 2000 at 12:57:41PM -0800, Dan Li wrote: > > Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > > spend time on issue discussions and won't cover the draft in detail. This > > draft is a strawman, at least the following things need more work: > > > > - clearly define the relationship of wcip with normal cache-control > directives. > > > > - specify in more detail the role of relay point, especially for channel > > aggregation. Can we or can we not aggregate heartbeats, possibly but > > cutting freshness guarantee. > > > > - pick a security model. Use SSL, or PGP signature, or both, and also the > > security of the channel info. > > > > - do we need a default port number? pros and cons wrt. to port 80. > > > > - are people happy with persistent TCP connection? are people happy with > > "delta consistency" (vs. eventual consistency, strong consistency, or > > anything else). > > > > - in the absence of a off-the-shelf realtime reliable multicast protocol, > > can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > > > - preloading, log reporting, advanced event notification, programability, > > ... future stuff on vertical peering and dynamic content > > > > What do people think? > > > > Dan > > > > > > > > > > > > At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > >>To: IETF-Announce: ; > > >>From: Internet-Drafts@ietf.org > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > >> > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > >>directories. > > >> > > >> > > >> Title : WCIP: Web Cache Invalidation Protocol > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > >> Filename : draft-danli-wrec-wcip-00.txt > > >> Pages : 26 > > >> Date : 14-Nov-00 > > >> > > >>Cache consistency is a major impediment to scalable content > > >>delivery. This document describes the Web Cache Invalidation > > >>Protocol (WCIP) which uses invalidations and updates to keep > > >>changing objects up to date in web caches. Moreover, it allows > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > >>(content delivery network) environment. > > >> > > >>A URL for this Internet-Draft is: > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >>Internet-Drafts are also available by anonymous FTP. Login with the > username > > >>"anonymous" and a password of your e-mail address. After logging in, > > >>type "cd internet-drafts" and then > > >> "get draft-danli-wrec-wcip-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > >> > > >>Internet-Drafts can also be obtained by e-mail. > > >> > > >>Send a message to: > > >> mailserv@ietf.org. > > >>In the body type: > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > >> > > >>NOTE: The mail server at ietf.org can return the document in > > >> MIME-encoded form by using the "mpack" utility. To use this > > >> feature, insert the command "ENCODING mime" before the "FILE" > > >> command. To decode the response(s), you will need "munpack" or > > >> a MIME-compliant mail reader. Different MIME-compliant mail > readers > > >> exhibit different behavior, especially when dealing with > > >> "multipart" MIME messages (i.e. documents which have been split > > >> up into multiple messages), so check your local documentation on > > >> how to manipulate these messages. > > >> > > >> > > >>Below is the data which will enable a MIME compliant mail reader > > >>implementation to automatically retrieve the ASCII version of the > > >>Internet-Draft. > > >> > > >>Content-Type: text/plain > > >>Content-ID: <20001114131241.I-D@ietf.org> > > >> > > >>ENCODING mime > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >> > > > > >-- >Mark Nottingham, Research Scientist >Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Tue Nov 21 14:16:39 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08050 for ; Tue, 21 Nov 2000 14:16:39 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA04145; Tue, 21 Nov 2000 14:12:07 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 14:12:00 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA04110; Tue, 21 Nov 2000 14:12:00 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA04087; Tue, 21 Nov 2000 14:11:57 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 14:11:57 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 21 Nov 2000 12:03:30 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 21 Nov 2000 09:45:16 -0700 From: "Hilarie Orman" To: , , Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08050 I think the security section is a little confused. SSL doesn't use digital signatures to validate content. Instead, SSL uses public key methods to establish a symmetric key that can be used to generate a message authentication code for data carried over TCP. Maybe that's what was meant by "unicast can use SSL" after option 2, but it's not clear. You might use an XML signature for messages that were multicast, or you might establish a symmetric key for use by a group. It's unlikely that you'd want to use digital signatures because of the computational cost and induced latency in processing the messages, but that's an engineering tradeoff decision. Basically, you need to decide if the security is done at the transport or application level, what the trust relationships are, and what the crypto encoding framework is. There's a need for a generic cache communication protocol that will support cache functionality extensions without requiring a lot of new protocols over http. Sessions, security, robustness, multicast, encodings, etc., these keep being reinvented. If BXXP+XML can cover the space, then this is probably the time to adopt them. XML for bulk data seems worrisome because of the processing latency and space inefficiency. Hilarie >>> Dan Li 11/15/00 01:57PM >>> Hi, please take a look of the WCIP draft before the IETF meeting, as we'd spend time on issue discussions and won't cover the draft in detail. This draft is a strawman, at least the following things need more work: - clearly define the relationship of wcip with normal cache-control directives. - specify in more detail the role of relay point, especially for channel aggregation. Can we or can we not aggregate heartbeats, possibly but cutting freshness guarantee. - pick a security model. Use SSL, or PGP signature, or both, and also the security of the channel info. - do we need a default port number? pros and cons wrt. to port 80. - are people happy with persistent TCP connection? are people happy with "delta consistency" (vs. eventual consistency, strong consistency, or anything else). - in the absence of a off-the-shelf realtime reliable multicast protocol, can we still run wcip on multicast UDP for scalability. See section 3.2.3. - preloading, log reporting, advanced event notification, programability, .. future stuff on vertical peering and dynamic content What do people think? Dan At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: >>To: IETF-Announce: ; >>From: Internet-Drafts@ietf.org >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt >>Date: Wed, 15 Nov 2000 06:41:12 -0500 >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : WCIP: Web Cache Invalidation Protocol >> Author(s) : D. Li, P. Cao, M. Dahlin >> Filename : draft-danli-wrec-wcip-00.txt >> Pages : 26 >> Date : 14-Nov-00 >> >>Cache consistency is a major impediment to scalable content >>delivery. This document describes the Web Cache Invalidation >>Protocol (WCIP) which uses invalidations and updates to keep >>changing objects up to date in web caches. Moreover, it allows >>automatic one-to-may relay and many-to-one aggregation in a CDN >>(content delivery network) environment. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-danli-wrec-wcip-00.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >>Content-Type: text/plain >>Content-ID: <20001114131241.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt >> >> > From owner-wrec@cs.utk.edu Tue Nov 21 14:29:54 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10704 for ; Tue, 21 Nov 2000 14:29:53 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA07962; Tue, 21 Nov 2000 14:26:02 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 14:26:02 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA07939; Tue, 21 Nov 2000 14:26:01 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA07926; Tue, 21 Nov 2000 14:25:59 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 14:26:00 -0500 Received: from dli2-nt (dhcp-10-34-17-66.cisco.com [10.34.17.66]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA03543; Tue, 21 Nov 2000 11:25:58 -0800 (PST) Message-Id: <4.2.0.58.20001121112330.02300560@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 21 Nov 2000 11:27:35 -0800 To: "Hilarie Orman" , , From: Dan Li Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 09:45 AM 11/21/00 -0700, Hilarie Orman wrote: >I think the security section is a little confused. SSL doesn't use digital >signatures to validate content. Instead, SSL uses public key methods >to establish a symmetric key that can be used to generate a message >authentication code for data carried over TCP. Maybe that's what was >meant by "unicast can use SSL" after option 2, but it's not clear. > >You might use an XML signature for messages >that were multicast, or you might establish a symmetric key for >use by a group. It's unlikely that you'd want to use digital >signatures because of the computational cost and induced >latency in processing the messages, but that's an engineering >tradeoff decision. > >Basically, you need to decide if the security is done at the >transport or application level, what the trust relationships are, >and what the crypto encoding framework is. I hope we only get to decide on a off-the-shelf security protocol and not reinventing anything. So, SSL, PGP, seem good candidates. SSL is transport level while PGP is app level. PGP may be a bit more flexible (optional encryption, signature, etc.), while SSL mandates not only authenticity but also secrecy and applies to all bytes (it's very simple this way though). Any other candidate? AAA? Dan >There's a need for a generic cache communication protocol that >will support cache functionality extensions without requiring a lot >of new protocols over http. Sessions, security, robustness, >multicast, encodings, etc., these keep being reinvented. >If BXXP+XML can cover the space, then this is probably the >time to adopt them. > >XML for bulk data seems worrisome because of the processing >latency and space inefficiency. > >Hilarie > > >>> Dan Li 11/15/00 01:57PM >>> >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd >spend time on issue discussions and won't cover the draft in detail. This >draft is a strawman, at least the following things need more work: > >- clearly define the relationship of wcip with normal cache-control >directives. > >- specify in more detail the role of relay point, especially for channel >aggregation. Can we or can we not aggregate heartbeats, possibly but >cutting freshness guarantee. > >- pick a security model. Use SSL, or PGP signature, or both, and also the >security of the channel info. > >- do we need a default port number? pros and cons wrt. to port 80. > >- are people happy with persistent TCP connection? are people happy with >"delta consistency" (vs. eventual consistency, strong consistency, or >anything else). > >- in the absence of a off-the-shelf realtime reliable multicast protocol, >can we still run wcip on multicast UDP for scalability. See section 3.2.3. > >- preloading, log reporting, advanced event notification, programability, >.. future stuff on vertical peering and dynamic content > >What do people think? > >Dan > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > >>To: IETF-Announce: ; > >>From: Internet-Drafts@ietf.org > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : WCIP: Web Cache Invalidation Protocol > >> Author(s) : D. Li, P. Cao, M. Dahlin > >> Filename : draft-danli-wrec-wcip-00.txt > >> Pages : 26 > >> Date : 14-Nov-00 > >> > >>Cache consistency is a major impediment to scalable content > >>delivery. This document describes the Web Cache Invalidation > >>Protocol (WCIP) which uses invalidations and updates to keep > >>changing objects up to date in web caches. Moreover, it allows > >>automatic one-to-may relay and many-to-one aggregation in a CDN > >>(content delivery network) environment. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the > username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-danli-wrec-wcip-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail > readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >>Content-Type: text/plain > >>Content-ID: <20001114131241.I-D@ietf.org> > >> > >>ENCODING mime > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >> > > From owner-wrec@cs.utk.edu Tue Nov 21 15:15:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18500 for ; Tue, 21 Nov 2000 15:15:18 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA17892; Tue, 21 Nov 2000 15:11:14 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 15:11:12 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA17848; Tue, 21 Nov 2000 15:11:12 -0500 (EST) Received: from akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA17834; Tue, 21 Nov 2000 15:11:10 -0500 (EST) Received: from akamai.com (64.14.77.2 -> akafire-exodus.akamai.com) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 15:11:10 -0500 Received: from akamai.com (vwall1.kendall.akamai.com [172.24.40.125]) by akamai.com (8.11.1/8.11.1) with ESMTP id eALKB8D13026 for ; Tue, 21 Nov 2000 15:11:08 -0500 (EST) Received: from ssh-gw.sanmateo.akamai.com (IDENT:root@[172.23.1.53]) by akamai.com (8.11.1/8.11.1) with ESMTP id eALKB5c09336; Tue, 21 Nov 2000 15:11:05 -0500 (EST) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id NAA17495; Tue, 21 Nov 2000 13:09:25 -0800 Date: Tue, 21 Nov 2000 13:09:25 -0800 From: Mark Nottingham To: Hilarie Orman Cc: lidan@cisco.com, wrec@cs.utk.edu, icooper@equinix.com Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Message-ID: <20001121130923.C17446@akamai.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from HORMAN@novell.com on Tue, Nov 21, 2000 at 09:45:16AM -0700 List-Unsubscribe: I agree with concerns re: XML, but it deserves consideration. If it can be used as an extensible packaging mechanism, we'd save a lot of future headaches. re: inefficiency - in what situations would you want to store the messages for any considerable period of time? On Tue, Nov 21, 2000 at 09:45:16AM -0700, Hilarie Orman wrote: > I think the security section is a little confused. SSL doesn't use digital > signatures to validate content. Instead, SSL uses public key methods > to establish a symmetric key that can be used to generate a message > authentication code for data carried over TCP. Maybe that's what was > meant by "unicast can use SSL" after option 2, but it's not clear. > > You might use an XML signature for messages > that were multicast, or you might establish a symmetric key for > use by a group. It's unlikely that you'd want to use digital > signatures because of the computational cost and induced > latency in processing the messages, but that's an engineering > tradeoff decision. > > Basically, you need to decide if the security is done at the > transport or application level, what the trust relationships are, > and what the crypto encoding framework is. > > There's a need for a generic cache communication protocol that > will support cache functionality extensions without requiring a lot > of new protocols over http. Sessions, security, robustness, > multicast, encodings, etc., these keep being reinvented. > If BXXP+XML can cover the space, then this is probably the > time to adopt them. > > XML for bulk data seems worrisome because of the processing > latency and space inefficiency. > > Hilarie > > >>> Dan Li 11/15/00 01:57PM >>> > Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > spend time on issue discussions and won't cover the draft in detail. This > draft is a strawman, at least the following things need more work: > > - clearly define the relationship of wcip with normal cache-control directives. > > - specify in more detail the role of relay point, especially for channel > aggregation. Can we or can we not aggregate heartbeats, possibly but > cutting freshness guarantee. > > - pick a security model. Use SSL, or PGP signature, or both, and also the > security of the channel info. > > - do we need a default port number? pros and cons wrt. to port 80. > > - are people happy with persistent TCP connection? are people happy with > "delta consistency" (vs. eventual consistency, strong consistency, or > anything else). > > - in the absence of a off-the-shelf realtime reliable multicast protocol, > can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > - preloading, log reporting, advanced event notification, programability, > .. future stuff on vertical peering and dynamic content > > What do people think? > > Dan > > > > > > At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > >>To: IETF-Announce: ; > >>From: Internet-Drafts@ietf.org > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : WCIP: Web Cache Invalidation Protocol > >> Author(s) : D. Li, P. Cao, M. Dahlin > >> Filename : draft-danli-wrec-wcip-00.txt > >> Pages : 26 > >> Date : 14-Nov-00 > >> > >>Cache consistency is a major impediment to scalable content > >>delivery. This document describes the Web Cache Invalidation > >>Protocol (WCIP) which uses invalidations and updates to keep > >>changing objects up to date in web caches. Moreover, it allows > >>automatic one-to-may relay and many-to-one aggregation in a CDN > >>(content delivery network) environment. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-danli-wrec-wcip-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >>Content-Type: text/plain > >>Content-ID: <20001114131241.I-D@ietf.org> > >> > >>ENCODING mime > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >> > > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Tue Nov 21 15:23:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20349 for ; Tue, 21 Nov 2000 15:23:45 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA21183; Tue, 21 Nov 2000 15:19:53 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 15:19:51 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA21157; Tue, 21 Nov 2000 15:19:51 -0500 (EST) Received: from akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA21123; Tue, 21 Nov 2000 15:19:48 -0500 (EST) Received: from akamai.com (64.14.77.2 -> akafire-exodus.akamai.com) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 15:19:48 -0500 Received: from akamai.com (vwall2.kendall.akamai.com [172.24.40.126]) by akamai.com (8.11.1/8.11.1) with ESMTP id eALKJkD16762 for ; Tue, 21 Nov 2000 15:19:46 -0500 (EST) Received: from ssh-gw.sanmateo.akamai.com (IDENT:root@[172.23.1.53]) by akamai.com (8.11.1/8.11.1) with ESMTP id eALKJk516746; Tue, 21 Nov 2000 15:19:46 -0500 (EST) Received: (from mnot@localhost) by ssh-gw.sanmateo.akamai.com (8.9.3/8.9.3) id NAA17517; Tue, 21 Nov 2000 13:16:45 -0800 Date: Tue, 21 Nov 2000 13:16:45 -0800 From: Mark Nottingham To: Dan Li Cc: Ian Cooper , wrec@cs.utk.edu Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Message-ID: <20001121131644.D17446@akamai.com> References: <4.2.0.58.20001115123617.02270ab0@omega> <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> <4.2.0.58.20001115123617.02270ab0@omega> <20001120183159.K876@akamai.com> <4.2.0.58.20001120184927.0221fee0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.2.0.58.20001120184927.0221fee0@omega>; from lidan@cisco.com on Mon, Nov 20, 2000 at 07:20:18PM -0800 List-Unsubscribe: On Mon, Nov 20, 2000 at 07:20:18PM -0800, Dan Li wrote: > I'd say the motivation for WCIP is two fold, for dynamic content and for > vertical peering. Dynamic content refers to a list of things (frequently > changing, personalized, and dynamically generated from databases). The > current "ObjectList" DTD covers only case 1 (frequently changing ones), but > the trajectory is to carry more complex event notifications for > personalization and dynamically generated stuff. By vertical peering, I > refer to things like preloading, delta update, and log reporting, etc. This > is mainly leveraging the notification transport (the channel and the relay). Perhaps "vertical peering" isn't the most fortunate phrase to use here, as it may confuse the issues ;) > I think "transport" deserves more discussion. There are really two > components in WCIP, 1. a notification transport (including the concept of > channel, relay point, and appl-layer multicast), and 2. the > semantics/messages carried by this transport (right now is ObjectList, but > will expand). Along this line, there's plenty of room to clearly separate > this two and allow growth (separately) in both of them. How Beep (formerly > BXXP) fits in here? a foundation for building WCIP transport? IIRC, BXXP is the name, 'beep' is how you pronounce it, as well as the WG name. From what little I've seen/read so far, it may be a good transport framework/foundation. The XML Protocol WG in the W3C is defining a packaging mechanism for XML over arbitrary transport (which may eventually include BXXP). While I'm not (yet) suggesting that we look at using their work, examining their approach to these issues may be educational for us. Disclaimer - I'm a member of that WG. -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Tue Nov 21 17:23:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15373 for ; Tue, 21 Nov 2000 17:23:54 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA09953; Tue, 21 Nov 2000 17:19:57 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 17:19:53 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA09931; Tue, 21 Nov 2000 17:19:53 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA09917; Tue, 21 Nov 2000 17:19:51 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 17:19:51 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 21 Nov 2000 15:19:48 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 21 Nov 2000 15:19:37 -0700 From: "Hilarie Orman" To: , , Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA15373 SSL doesn't mandate secrecy. The IETF and W3C have an XML signature standard in progress. Hilarie >>> Dan Li 11/21/00 12:27PM >>> At 09:45 AM 11/21/00 -0700, Hilarie Orman wrote: >I think the security section is a little confused. SSL doesn't use digital >signatures to validate content. Instead, SSL uses public key methods >to establish a symmetric key that can be used to generate a message >authentication code for data carried over TCP. Maybe that's what was >meant by "unicast can use SSL" after option 2, but it's not clear. > >You might use an XML signature for messages >that were multicast, or you might establish a symmetric key for >use by a group. It's unlikely that you'd want to use digital >signatures because of the computational cost and induced >latency in processing the messages, but that's an engineering >tradeoff decision. > >Basically, you need to decide if the security is done at the >transport or application level, what the trust relationships are, >and what the crypto encoding framework is. I hope we only get to decide on a off-the-shelf security protocol and not reinventing anything. So, SSL, PGP, seem good candidates. SSL is transport level while PGP is app level. PGP may be a bit more flexible (optional encryption, signature, etc.), while SSL mandates not only authenticity but also secrecy and applies to all bytes (it's very simple this way though). Any other candidate? AAA? Dan >There's a need for a generic cache communication protocol that >will support cache functionality extensions without requiring a lot >of new protocols over http. Sessions, security, robustness, >multicast, encodings, etc., these keep being reinvented. >If BXXP+XML can cover the space, then this is probably the >time to adopt them. > >XML for bulk data seems worrisome because of the processing >latency and space inefficiency. > >Hilarie > > >>> Dan Li 11/15/00 01:57PM >>> >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd >spend time on issue discussions and won't cover the draft in detail. This >draft is a strawman, at least the following things need more work: > >- clearly define the relationship of wcip with normal cache-control >directives. > >- specify in more detail the role of relay point, especially for channel >aggregation. Can we or can we not aggregate heartbeats, possibly but >cutting freshness guarantee. > >- pick a security model. Use SSL, or PGP signature, or both, and also the >security of the channel info. > >- do we need a default port number? pros and cons wrt. to port 80. > >- are people happy with persistent TCP connection? are people happy with >"delta consistency" (vs. eventual consistency, strong consistency, or >anything else). > >- in the absence of a off-the-shelf realtime reliable multicast protocol, >can we still run wcip on multicast UDP for scalability. See section 3.2.3. > >- preloading, log reporting, advanced event notification, programability, >.. future stuff on vertical peering and dynamic content > >What do people think? > >Dan > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > >>To: IETF-Announce: ; > >>From: Internet-Drafts@ietf.org > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> > >> > >> Title : WCIP: Web Cache Invalidation Protocol > >> Author(s) : D. Li, P. Cao, M. Dahlin > >> Filename : draft-danli-wrec-wcip-00.txt > >> Pages : 26 > >> Date : 14-Nov-00 > >> > >>Cache consistency is a major impediment to scalable content > >>delivery. This document describes the Web Cache Invalidation > >>Protocol (WCIP) which uses invalidations and updates to keep > >>changing objects up to date in web caches. Moreover, it allows > >>automatic one-to-may relay and many-to-one aggregation in a CDN > >>(content delivery network) environment. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >>Internet-Drafts are also available by anonymous FTP. Login with the > username > >>"anonymous" and a password of your e-mail address. After logging in, > >>type "cd internet-drafts" and then > >> "get draft-danli-wrec-wcip-00.txt". > >> > >>A list of Internet-Drafts directories can be found in > >>http://www.ietf.org/shadow.html > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >>Internet-Drafts can also be obtained by e-mail. > >> > >>Send a message to: > >> mailserv@ietf.org. > >>In the body type: > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > >> > >>NOTE: The mail server at ietf.org can return the document in > >> MIME-encoded form by using the "mpack" utility. To use this > >> feature, insert the command "ENCODING mime" before the "FILE" > >> command. To decode the response(s), you will need "munpack" or > >> a MIME-compliant mail reader. Different MIME-compliant mail > readers > >> exhibit different behavior, especially when dealing with > >> "multipart" MIME messages (i.e. documents which have been split > >> up into multiple messages), so check your local documentation on > >> how to manipulate these messages. > >> > >> > >>Below is the data which will enable a MIME compliant mail reader > >>implementation to automatically retrieve the ASCII version of the > >>Internet-Draft. > >> > >>Content-Type: text/plain > >>Content-ID: <20001114131241.I-D@ietf.org> > >> > >>ENCODING mime > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > >> > >> > > From owner-wrec@cs.utk.edu Tue Nov 21 22:03:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22997 for ; Tue, 21 Nov 2000 22:03:10 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA06542; Tue, 21 Nov 2000 21:59:16 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 21:59:12 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA06486; Tue, 21 Nov 2000 21:59:10 -0500 (EST) Received: from mail.cs.utexas.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA06429; Tue, 21 Nov 2000 21:59:07 -0500 (EST) Received: from mail.cs.utexas.edu (128.83.139.10 -> mail.cs.utexas.edu) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 21:59:08 -0500 Received: from cs.utexas.edu (vaio.csres.utexas.edu [128.83.141.4]) by mail.cs.utexas.edu (8.9.3/8.9.3) with ESMTP id UAA15339; Tue, 21 Nov 2000 20:59:04 -0600 (CST) Message-ID: <3A1B38A5.769BC437@cs.utexas.edu> Date: Tue, 21 Nov 2000 21:08:21 -0600 From: Mike Dahlin X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lidan@cisco.com CC: cao@cisco.com, wrec@cs.utk.edu Subject: 4/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit 4. Delayed invalidations The following is implicit (I think) in the current draft. It may be worth making it explicit by adding a subsection in 3 or 4 (or if I'm wrong and these rules are not true, then a discussion should definitely be added...): The protocol does provide some flexibility about when invalidations are sent. In particular, an invalidation server SHOULD send object invalidations "reasonably" soon after it learns of an object change, but it MAY delay them until some time before the subsequent heartbeat. (It MUST NOT delay them further.) Examples: o An invalidation server might place an upper bound on the rate at which invalidations are sent (to smooth bursts of load) o An invalidation server might delay an invalidation for a few seconds in hope of grouping invalidations to several objects into the same message. o An invalidation server might prioritize sending invalidations by sending invalidations to "active" clients (that have recently registered new object callbacks) before sending them to "idle" clients (that are connected but which don't seem to be actively using the channel's volume) The above examples are minor (and, I think, already implicitly allowed by the current draft.) The following is a more significant point. It is ambiguous whether it is allowed by the current draft or not. It is debatable whether it should be (my initial inclination is that it should...) Consider a unicast-tcp invalidation channel. At least the following two states are defined: o connected,synchronized -- a TCP connection is established and the server is periodically sending heartbeats o disconnected -- no TCP connection is established Although not explicit in the current description, it is possible to have a middle point: o connected, idle -- a TCP connection is established, but the server is not sending heartbeats on it; the server is queuing invalidations on this channel and sending them when idle capacity allows; if the client becomes active again, the client will send a request to the server, forcing heartbeats to begin again (and the first heartbeat will include any queued invalidates). (This could also be done with sequence numbers across connections, allowing connection state to be reclaimed for idle clients; I describe it this way to minimize changes from the current draft.) The argument for including this: o The optimization of stopping sending invalidations to idle clients is important for both average load and peak load in the studies we've done (http://www.cs.utexas.edu/users/dahlin/papers/olympics-consistency.ps, http://www.cs.utexas.edu/users/dahlin/papers/tkde99.ps). o The current draft makes "stopping sending invalidations" a heavy-weight operation -- all synchronization is dropped, so recovery takes work proportional to the number of objects in a volume. o This feature makes this apparantly important optimization much cheaper. The argument against including this feature: o The current protocol is semantically correct, so we should be hesitant to add complexity for a performance gain unless there is a proven big win. o The performance win may be modest here: the current system can handle short periods of idleness (stay connected and synchronized) and long periods of idleness (pay the resync cost), so the addition only matters of "medium" periods of idleness. Do these occur often enough to justify the additional mechanism? My sense is that there is a significant payoff for this feature, but there is room for debate. From owner-wrec@cs.utk.edu Tue Nov 21 22:03:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23029 for ; Tue, 21 Nov 2000 22:03:16 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA06552; Tue, 21 Nov 2000 21:59:17 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 21:59:13 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA06502; Tue, 21 Nov 2000 21:59:11 -0500 (EST) Received: from mail.cs.utexas.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA06449; Tue, 21 Nov 2000 21:59:08 -0500 (EST) Received: from mail.cs.utexas.edu (128.83.139.10 -> mail.cs.utexas.edu) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 21:59:09 -0500 Received: from cs.utexas.edu (vaio.csres.utexas.edu [128.83.141.4]) by mail.cs.utexas.edu (8.9.3/8.9.3) with ESMTP id UAA15343; Tue, 21 Nov 2000 20:59:06 -0600 (CST) Message-ID: <3A1B38A9.AF91A1A4@cs.utexas.edu> Date: Tue, 21 Nov 2000 21:08:25 -0600 From: Mike Dahlin X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lidan@cisco.com CC: cao@cisco.com, wrec@cs.utk.edu Subject: 5/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit 5. Other points 5.1 I would suggest adding a separate subsection on legacy rules to section 3. There is not a whole lot to say, but putting this set of rules in one place would aid clarity, I think. 5.2 I would be inclined to call "application-layer multicast" "hierarchy" since more is going on than multicast -- the nodes near the leaves can reply to registration requests (I think?) 5.3 We probably need to think through the delta-encoding under multicast case (I seem to remember some relatively complex rules about "base" versions and so on; just need to make sure everything still makes sense under multicast.) 5.4 Various broken sentences/grammer errors throughout. Once content stabilizes, a thorough pass is needed. Get rid of all contractions. 5.5 Section 2 needs to define "channel lifetime" (but see main comment #1 in notes.11.20.2000b earlier message) 5.6 Section 2 and section 3.1 I think it is worth explicitly explaining that the protocol provides consistency in two ways: a worst-case freshness guarantee and an average-case delay between update and invalidate. So, section 2 should define common-case invalidation latency average amount of time between an object update and when a synchronized client caching that object finds out that the old version is invalid. This time depends on network and invalidation server topology, the number of clients, server load, message losses, and other factors and is not a guarantee. And it should extend the "invalidation latency" definition to explicitly describe the relationship between the two components: worst case freshness guarantee and common case invalidation latency. Then in Section 3.1, a paragraph between the second-to-last and last paragraphs should explain these two pieces. And the last paragraph of section 3.1 should point out that two extreme cases are supported by the protocol: (1) set worst-case guarantee to "large" --> get fast common-case updates but no worst case guarantees ('eventual consistency') (2) batch invalidation messages with heartbeats --> get worst case guarantees and common case = worst case. 5.7 Section 3.2.1 -- strike "so is better than UDP-based invalidation, too" 5.8 Section 3.4 on "channel security" needs work. Starting off with "the barn door is already open" is weak. Suggested reorganization: 1. Start with a list of vulnerabilities/threats 2. Move the paragraph "to prevent intermediate nodes from tampering..." up to the first few paragraphs -- this rule is true regardless of which of the remaining options is chosen. Add to this paragraph "Note that the origin server can be an HTTPs server or an HTTP server." after the first sentence. 3. Move "weak ok" argument under option #1 4. The paragraph This is when the invalidation server requires strong security for the channel. The invalidation clients have to comply. For unicast, the channel can simply be a SSL connection as in HTTPS. Is really a 4th case (it is not "public-key-based strong security with mandatory verification"). 5.9 In section 4.3 "form channels" the statement "But with more objects per channel, there will be more cost for each client's targeted service state" is false. (There will be more state per channel, but the total amount of state across channels will be the same.) 5.10 steps 4 and 5 in section 5, section 5.2.4 may need to be revisited depending on results of the "channel lifetime" discussion 5.11 Section 5 "Symbols already defined in ... are not repeated here" Perhaps these should be listed. Then, a reader that hits an unrecognized symbol can check whether it is defined elsewhere (or whether the reader just missed it here) before digging out the other doc. (Also, this allows us to make sure that all terms are defined by looking at just this document and its "interface" to the other docs.) 5.12 In section 5.1, should a channel type for unreliable multicast be specified? "channel information" is defined in 5.1 and "channel-info" is defined in 5.2.2. This is confusing. At the same "level" as the channel type, I would have expected the "no-target/target" flag to appear, since the network protocol and the target/no-target directives both describe the language to speak between the client and server 5.13 In section 5.2.2 If you like the optimizations I describe for unreliable multicast case, then seqno needs to be generalized to allow for a range 5.14. in section 5.1 Last sentence "via HTTPS" --> "via HTTP or HTTPS" 5.15. section 5.2 assumes persistent connection unicast; what about other cases? 5.16 last paragraph section 5.2 "invalidation server MAY close" --> "invalidation server or invalidation client MAY close" 5.17 section 5.2.4 first paragraph How does an invalidation server (particularly an intermediate server in a hierarchy) know what value is "smaller than the lowest object freshness guarantee" given that it may not know the freshness guarantee of all objects in a channel (it may only know the FG for the objects it has seen.) 5.18 Section 5.2 It seems expensive to send a "register" with a list of objects to resynchronize and then to be redirected to a different invalidation server (and resend the list). Perhaps the messages "establish channel" and "register [objectlist]" should be split into two messages. There is no problem with the semantics since registration can be incremental. The question is one of performance: an extra round trip when no redirect v. extra work when there is a redirect. I believe the conservative thing to do is to split the messages -- a fixed cost (a round trip) v. a potentially unbounded cost (sending a long list of stuff twice). Another option would be to add a hint in the Invalidated-By header saying "on your initial registration, don't synchronize more than N objects" Another option is to say that "on the first request to a channel, we don't know if we will be redirected, but we also don't have anything to synchronize --> the right thing just happens; on later requests to a channel, we have already been redirected and we will will connect to the redirected target (is this how that works?) --> the right thing just happens." 5.19 Section 5.2 "If there is targeted service, only objects specified in the targeted service (in the registration request body) are returned in the registration response body. Otherwise, all objects covered by the invalidation channel are returned in the response body." Yikes! The "all objects" in the second sentence could be huge! I do not believe this is consistent with what is described in 3.2.3 (IP multicast) where, I think, the assumption is if no targeted service, clients don't "register" instead, servers periodically bring everyone in the untargeted channel up to date Even if registration is allowed under untargeted service (e.g., as an optimization to let a client connect sooner), there is no semantic need to send everything. The server can still just send the current version numbers for the objects that a client cares about. From owner-wrec@cs.utk.edu Tue Nov 21 22:03:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23032 for ; Tue, 21 Nov 2000 22:03:17 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA06534; Tue, 21 Nov 2000 21:59:15 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 21:59:07 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA06381; Tue, 21 Nov 2000 21:59:05 -0500 (EST) Received: from mail.cs.utexas.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA06351; Tue, 21 Nov 2000 21:59:02 -0500 (EST) Received: from mail.cs.utexas.edu (128.83.139.10 -> mail.cs.utexas.edu) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 21:59:03 -0500 Received: from cs.utexas.edu (vaio.csres.utexas.edu [128.83.141.4]) by mail.cs.utexas.edu (8.9.3/8.9.3) with ESMTP id UAA15327; Tue, 21 Nov 2000 20:58:59 -0600 (CST) Message-ID: <3A1B3890.824ACAF0@cs.utexas.edu> Date: Tue, 21 Nov 2000 21:08:00 -0600 From: Mike Dahlin X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lidan@cisco.com CC: wrec@cs.utk.edu, cao@cisco.com Subject: 1/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit First, four high level comments. Then detailed section-by-section comments. Since this set of comments has ended up getting long, and since I am cc'ing the mailing list, I will break this into five messages (each of the high level comments + detailed comments) to make a threaded discussion more managable. BTW, anyone interested in this discussion may also want to look at a draft a group of colleagues and I at UT just completed: http://www.cs.utexas.edu/users/dahlin/papers/olympics-consistency.pdf It is a first draft, so there are some rough edges. We also would appreciate any feedback (send them to me please, they probably don't need to go to this mailing list, although you are welcome to send comments here too...). -mike High level comments (notes.11.20.2000b.txt -- draft-danli-wrec-wcip-00.txt) ------------------- 1. The "channel lifetime" parameter seems unnecessary. It is not required for semantics. And, given that it is a performance optimization, I'm not sure it has the right definition. In particular, the mechanism for the server to release state is there: a server (or client) can release the TCP connection at any time (From earlier mail on this point Dan Li writes:) >>>> just to clarify, "client must periodically re-register" is when the "channel lifetime" expires and the iserver is about to release the state of the client. The client should better re-register before the channel expires. >>>> but I think you are probably right that this is not really needed. If the iserver wants to release the state, it can simply close the connection. Perhaps we'd provide a message for the iserver to indicate it's about to drop the connection, or it's about to drop the targeted service, etc. >>>> then what about "channel lifetime" which now gives the iserver a way to cut out the channel. ... An alternative is to eliminate the signalling as a mechanism. An example policy that we've simulated: a server keeps a per-client "last-contact-time" that is updated whenever a client registers a new object callback. The server disconnects from a client when this time is X seconds in the past. This is appealing for two reasons. First, it makes the protocol simpler by getting rid of a message type. Second, it does not prescribe a particular policy: servers can drop connections using time as I just described, they can keep a fixed number of connections and drop them with LRU,FIFO, or random. A fixed number of connections may be attractive for scalability/bounding worst case performance. The main disadvantage, probably, is that we make refreshing this interval implicit rather than explicit. (I can see an argument either way on this point.) Another point (whether it is a disadvantage or advantage is a matter of taste) is that if the server uses a LRU or time-based replacement protocol, a client can refresh its interval (to avoid getting dropped) by periodically renewing its lease for "/". This is either an ugly hack or an elegant extension of the protocol... I don't feel terribly strongly either way, but my inclination would be toward the simpler protocol unless there is a strong reason to add a new message. From owner-wrec@cs.utk.edu Tue Nov 21 22:03:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23051 for ; Tue, 21 Nov 2000 22:03:20 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA06538; Tue, 21 Nov 2000 21:59:16 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 21:59:09 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA06444; Tue, 21 Nov 2000 21:59:08 -0500 (EST) Received: from mail.cs.utexas.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA06378; Tue, 21 Nov 2000 21:59:05 -0500 (EST) Received: from mail.cs.utexas.edu (128.83.139.10 -> mail.cs.utexas.edu) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 21:59:05 -0500 Received: from cs.utexas.edu (vaio.csres.utexas.edu [128.83.141.4]) by mail.cs.utexas.edu (8.9.3/8.9.3) with ESMTP id UAA15335; Tue, 21 Nov 2000 20:59:02 -0600 (CST) Message-ID: <3A1B389F.B1AD952@cs.utexas.edu> Date: Tue, 21 Nov 2000 21:08:15 -0600 From: Mike Dahlin X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lidan@cisco.com CC: cao@cisco.com, wrec@cs.utk.edu Subject: 3/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit 3. I would suggest adding a separate subsection about reconnection in section 3. This would provide a place to talk about a bunch of the subtle issues all in one place: first connection, reconnection, incremental connection, using legacy headers while waiting for connection, ... Some additional features to optimize reconnection may be warranted. (3.1) First, I think it is worth stating precisely the per-object FSM: (In writing this, I'm catching some bugs in my understanding at least; I suspect other people might also benefit from explicitly including this in the draft.) I would bet that at least some one in this discussion will say "I don't think it works like you described" and they might be right; either way, this would be an indication that it is worth writing it down so we can argue about how it works in concrete terms... Each object has two parts to its state: 1) Synchronization established/lost for object --> are we guaranteed to receive an invalidation if the current version of the object changes? 2) Current version cached/not cached --> a version of the object is cached that may be current (no invalidations have been received for it). If the synchronization is established, then it IS current; otherwise, it may be, but cache control directives apply. Notice that because of server-driven reconnection, we can be synchronized for an object even if we don't currently cache that object. Read synch established <--- synch established current version cached ----> current not cached | /|\ recv | /|\ | | inval | | | connect | current | connect | current | lost | version # | lost | version | | recvd | | # recvd \|/ | Read \|/ | sync not established <----- synch not established current version cached ------> current not cached Recv inval Action on READ: sync established current version cached: return data sync established current not cached: Request newest version from origin server Recv newest version from origin server state = Sync estab; current cached sync not established current version cached: if legacy headers allow read, then if (server supports targeted inval) send "register" to inval server return read data else set state "sync not estab; current not cached" and follow those rules for READ sync not established current not cached: Request newest version from origin server Recv newest version from origin server if(inval server supports targeted inval) send "register" to inval server set state "sync not established; current cached" Action on CONNNECT LOST set "sync not established" Action on CURRENT VERSION # RECVD set "sync established" Notice that this may be received either in response to explicit client request to resynchronize or because server periodicaly sends out current version numbers? Action on INVAL RECVD current version = no current version POSSIBLE BUG/OPTIMIZATION: does inval hold current version number and therefore always allow you to go to "sync established, no current version"? (3.2) Second, as mentioned in previous message (main comment #2 in notes.11.20.2000b.txt), the idea described for server-driven resynchronization for multicast seems like it can be/should be explicilty generalized: (Most of these features are implicit in the current draft; all I'm really suggesting here is to make them explicit.) The following seem to be defined: server-driven resynchronization: servers periodically send out all of the current version numbers for all of the objects (currently defined for multicast sync/resync case) client-driven resynchronization: clients ask for the current version numbers of the objects they cache (currently defined for the unicast resync case). But it is worth noting that server-driven/client-driven resynchronization are extreme points in a continuum. In the client-driven case, it is not necessary to re-establish synchronization on everything at once (but it may be desirable to establish synchronization on some subset of data you think you will soon use). Note that the same mechanisms/rules apply for resynchronization after a reconnection and for establishing synchronization when a new object is read. Also, the only difference between targeted service and untargeted service is just one message: in either case, a client gets synchronized when it receives a message from the server indicating the current version number; the only difference is that in targeted service, the client has to ask for such a message whereas in untargeted service, such messages periodically appear. (Put another way, revalidation messages have no semantic meaning -- they may be lost, reordered, or spontaneously appear at any time; they are just a hint that "now" might be a good time for the server to send a current version number to a client.) Finally, this framework cleanly separates mechanism from policy: e.g., on resynchronization under targeted service, a client may choose to register all cached objects, no cached objects (make them all "sync not established"), or a subset of cached objects (e.g., do a "bulk re-register" on index.html and all inlined images; then do a background re-register of all other cached objects from that channel). E.g., a client may establish a callback on an object the first time it reads the object or the first time it revalidates the object and the object didn't change~\cite{dilley}. To support this, the protocol should explicitly state whether a client may contact a server to resynchronize an object. This is implicit in the "no-target" header. This section and section 5.2.2 should make this rule explicit. (Or should there be a separate header field?) From owner-wrec@cs.utk.edu Tue Nov 21 22:35:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22998 for ; Tue, 21 Nov 2000 22:03:10 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA06547; Tue, 21 Nov 2000 21:59:16 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 21 Nov 2000 21:59:08 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA06404; Tue, 21 Nov 2000 21:59:06 -0500 (EST) Received: from mail.cs.utexas.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA06363; Tue, 21 Nov 2000 21:59:04 -0500 (EST) Received: from mail.cs.utexas.edu (128.83.139.10 -> mail.cs.utexas.edu) by cs.utk.edu (smtpshim v1.0); Tue, 21 Nov 2000 21:59:04 -0500 Received: from cs.utexas.edu (vaio.csres.utexas.edu [128.83.141.4]) by mail.cs.utexas.edu (8.9.3/8.9.3) with ESMTP id UAA15331; Tue, 21 Nov 2000 20:59:01 -0600 (CST) Message-ID: <3A1B3899.F981CF71@cs.utexas.edu> Date: Tue, 21 Nov 2000 21:08:09 -0600 From: Mike Dahlin X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: lidan@cisco.com CC: cao@cisco.com, wrec@cs.utk.edu Subject: 2/5 Re: I-D ACTION:draft-danli-wrec-wcip-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit 2. Section 2.3 IP Multicast Two main comments. First, I have tried to re-organize the section to make the fundamental issues more clear and to separate the "short-term hack" for application-level reliability to support unreliable IP multicast from the rest of the discussion (since that is the section most likely to change or get deleted over time.) Second, I chew on the application-level reliability discussion a bit more and try to generalize it to accomodate the Yu et. al approach. <<<<< BEGIN proposed update to 3.2.3 >>>>>>> 3.2.3 IP multicast In this mode, an IP multicast group is allocated for the invalidation channel and its address is advertised as part of the channel information. The invalidation client subscribes to this multicast group to receive cache invalidations and/or object updates. Ideally, it's a single-source multicast group, meaning that the invalidation client subscribes to the sender and group address pair , where S is the invalidation server address and G is the multicast group address. IP multicast removes the scalability concern at the invalidation server in that the invalidation server now only needs to send one copy of any message. Plus, it doesn't maintain per-client state. A multicast invalidation channel is much more efficient than unicast- based cache consistency schemes. Worth noting, however, is that anything the invalidation server sends to the invalidation channel goes to every subscriber. Therefore, objects covered by a multicast invalidation channel need to be correlated so that if an invalidation client is interested in or has cached some objects of the channel, it is highly likely that it will cache the other ones. For example, CNNfn top stories should belong to one channel while ESPN top stories belong to another. There are two issues in implementing WCIP over ip multicast: (1) establishing synchronization and (2) retaining synchronization depite packet loss (1) Establishing synchronization To establish synchronization, the client must ensure that all cached objects' versions (Last modified times or Etags) match the most recent versions known to the consistency servers. The standard unicast approach for establishing synchronization -- the client sends a Registration message to the server containing the version numbers of cached objects and the server replies with current version numbers of those objects (see Section 5.2.1) -- has two problems. First, it is not scalable in that it can overload the consistency server. Second, because the servers reply would have to be sent on the multicast channel (in order to maintain ordering and reliability constraints), all clients would see all regitration replies, which would be inefficient. Therefore, multicast channels should use a server-driven approach to establish synchronization: the invalidation server periodically transmits resynchronization data (e.g., a list of objects' current Etags) to allow clients to re-synchronize their object freshness state. The client-driven and server-driven resynchronization protocols are discussed in more detail in section TBD. (2) Retaining synchronization despite packet loss To provide consistency guarantees, invalidation/heartbeat message channels must maintain the invariant: that the invalidation client must never receive a heartbeat without first receiving all preceding invalidations sent to it. This can be done in one of two ways. First, the system may use a reliable multicast transport protocol (e.g., PGM, SRM, etc.) by specifying the protocol to be used in the channel information header (see section 4.1). The invalidation protocol then proceeds as it does for the reliable unicast case: clients invalidate objects when they receive invalidation messags, and they re-register (but using server-driven re-registration as described above and in section TBD) if the transport layer detects a lost packet. Note: the WCIP channel information header does not currently define any headers for reliable multicast protocols. Second, because no reliable multicast transport protocols are widely deployed, WCIP provides an application-level reliability protocol to allow it to run on top of unreliable transports such as raw IP multicast. MDD: OK. I think we may agree on everything up to here. Then the remaining task is to define how application-level reliability should be done. After chewing on the specified protocol a bit, I finally understand it and basically like it. I particularly like the new idea in the draft of incrementally resynchronizing. In fact, this notion might be worth generalizing to the unicast reconnection case (see main comment 3 in notes.11.20.2000b.txt). The potential disadvantage is that if packet loss --> sync loss, synchronization losses may be common and this protocol requires work in proportion to the size of a volume to re-establish synchronization. I can easily imagine situations where clients spend a majority of their time unsynchronized. Fundamentally, the other option is to pay a cost proportional to the number of objects being invalidated to reduce the probability that synchronization is lost by retransmitting. Note that since this only reduces the probability, there still needs to be a way to establish syncrhonization, and I like your approach for that. Now that I finally understand your protocol, however, it appears to me that it is simple to add this second mode of operation as an optional optimization. This is attractive for two reasons (1) it lets an implementation balance the "per-object" overhead against the "per-invalidation" overhead; I can imagine there are some systems where one is the dominant factor and others where the other is; (2) it is general enough to accomodate, say, Yu, Breslau, and Shenker's protocol (SIGCOMM99). As always the question is whether the added complexity is worth the performance benefit. Especially given that this is a "stop gap" until real reliable multicast comes along... I could be swayed either way on that. (My instinct is that it if we support unreliable IP multicast at all, then this is worth adding.) /MDD MDD Protocol from current draft (wording slightly modified; one bug fixed; optimizations added at the end): /MDD Absent an off-the-shelf real-time reliable multicast protocol, WCIP allows for an unreliable transport protocol with application-level recovery from failures. (1) The invalidation server marks invalidation channel messages with incrementing sequence numbers; MDD NOTE: (bug fix I think) heartbeat packets need sequence numbers too. Otherwise, we can not detect the case when the last invalidation message before a heartbeat is lost. /MDD (2) Whenever the invalidation client sees a sequence number gap, it considers itself to have lost synchronization with the channel. The client marks all objects as "no-object-lease" and reverts to following the normal HTTP Cache-control directives. MDD I don't care what this state is called, but we refer to this state in a bunch of situations. Rather than saying "revert to following normal HTTP Cache Control directives" each time, it would be more clear to describe the state machine for each object and then just say "set all objects to state X". See main comment 3 in notes.11.20.2000b.txt /MDD (3) The invalidation client resynchronizes according to the resynchronization protocol specified for the channel Typically, this is server-driven resynchonization in which the server periodically transmits the current version numbers of objects. Note that resynchronization messages must also include sequence numbers. (4) Once the invalidation client resynchronizes the freshness state of certain objects, it switches those objects from HTTP cache- control back to WCIP freshness guarantees. (5) As more re-synchronization messages arrive, the invalidation client gradually reinstates all its objects back to WCIP freshness guarantees. In fact, a cache proxy may join the multicast channel and become gradually synchronized this way without ever directly contacting the invalidation server via unicast. MDD Here are the new optimizations for discussion /MDD A client MAY process or buffer invalidation packets received with out of order sequence numbers. A client MUST NOT process a heartbeat until (a) its has processed all preceeding sequence numbers or (b) it has declared a loss of synchronization and set the state of all objects in the channel to state "no-object-lease" (see Section TBD). An invalidation server MAY send a packet multiple times to reduce the probability that synchronization is lost. To reduce the cost of retransmission, an invalidation server MAY group multiple packets into a single retransmission. In this case, the sequence number field indicates a range of sequence numbers, specifying which numbers are included in the packet. Such a packet MAY include "new" information, in which case the sequence number range is extended to also include a new sequence number For example, an invalidation server could include a range of preceeding invalidations in each heartbeat message to make sure that invalidation clients "catch up" with missing messages by the end of a heartbeat interval~\cite{yu99}. seqno=100 invalidate "foo" Etag=A seqno=101 invalidate "bar" Etag=z seqno=102 invalidate "baz" Etag=q seqno=100-103 invalidate "foo" Etag=A, invalidate "bar" Etag=z, invalidate "baz" Etag=q, heartbeat <<<< END proposed update to 3.2.3 >>>> From owner-wrec@cs.utk.edu Wed Nov 22 09:28:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27220 for ; Wed, 22 Nov 2000 09:28:45 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA11708; Wed, 22 Nov 2000 09:28:29 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 22 Nov 2000 09:28:24 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA11686; Wed, 22 Nov 2000 09:28:24 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA11673; Wed, 22 Nov 2000 09:28:21 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 22 Nov 2000 09:28:22 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA26987; Wed, 22 Nov 2000 06:28:20 -0800 (PST) Message-Id: <4.2.0.58.20001122062300.02a876c0@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 22 Nov 2000 06:31:39 -0800 To: , Mark Nottingham , Ian Cooper , Mike Dahlin , cao@cisco.com, "Hilarie Orman" From: Dan Li Subject: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Given that this protocol specifies a notification transport (channels, relays, aggregations, etc.) and various notifications (invalidation, updates, preloads, log report, etc.) on top of it, the word "invalidation" seems less than descriptive as in WCIP. Along this line, it sounds to me that something like WCUP "web cache update protocol" would be better. If the name WCIP is over restrictive and we may need to change it sooner or later, I'd say we change it now. Do you feel the need? Dan > > >>> Dan Li 11/15/00 01:57PM >>> > >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > >spend time on issue discussions and won't cover the draft in detail. This > >draft is a strawman, at least the following things need more work: > > > >- clearly define the relationship of wcip with normal cache-control > >directives. > > > >- specify in more detail the role of relay point, especially for channel > >aggregation. Can we or can we not aggregate heartbeats, possibly but > >cutting freshness guarantee. > > > >- pick a security model. Use SSL, or PGP signature, or both, and also the > >security of the channel info. > > > >- do we need a default port number? pros and cons wrt. to port 80. > > > >- are people happy with persistent TCP connection? are people happy with > >"delta consistency" (vs. eventual consistency, strong consistency, or > >anything else). > > > >- in the absence of a off-the-shelf realtime reliable multicast protocol, > >can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > > >- preloading, log reporting, advanced event notification, programability, > >.. future stuff on vertical peering and dynamic content > > > >What do people think? > > > >Dan > > > > > > > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > >>To: IETF-Announce: ; > > >>From: Internet-Drafts@ietf.org > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > >> > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > >>directories. > > >> > > >> > > >> Title : WCIP: Web Cache Invalidation Protocol > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > >> Filename : draft-danli-wrec-wcip-00.txt > > >> Pages : 26 > > >> Date : 14-Nov-00 > > >> > > >>Cache consistency is a major impediment to scalable content > > >>delivery. This document describes the Web Cache Invalidation > > >>Protocol (WCIP) which uses invalidations and updates to keep > > >>changing objects up to date in web caches. Moreover, it allows > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > >>(content delivery network) environment. > > >> > > >>A URL for this Internet-Draft is: > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > > >>"anonymous" and a password of your e-mail address. After logging in, > > >>type "cd internet-drafts" and then > > >> "get draft-danli-wrec-wcip-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > >> > > >>Internet-Drafts can also be obtained by e-mail. > > >> > > >>Send a message to: > > >> mailserv@ietf.org. > > >>In the body type: > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > >> > > >>NOTE: The mail server at ietf.org can return the document in > > >> MIME-encoded form by using the "mpack" utility. To use this > > >> feature, insert the command "ENCODING mime" before the "FILE" > > >> command. To decode the response(s), you will need "munpack" or > > >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > >> exhibit different behavior, especially when dealing with > > >> "multipart" MIME messages (i.e. documents which have been split > > >> up into multiple messages), so check your local documentation on > > >> how to manipulate these messages. > > >> > > >> > > >>Below is the data which will enable a MIME compliant mail reader > > >>implementation to automatically retrieve the ASCII version of the > > >>Internet-Draft. > > >> > > >>Content-Type: text/plain > > >>Content-ID: <20001114131241.I-D@ietf.org> > > >> > > >>ENCODING mime > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >> > > > From owner-wrec@cs.utk.edu Wed Nov 22 14:19:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04466 for ; Wed, 22 Nov 2000 14:19:06 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA18563; Wed, 22 Nov 2000 14:18:27 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 22 Nov 2000 14:17:47 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA18486; Wed, 22 Nov 2000 14:17:47 -0500 (EST) Received: from mnot.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA18468; Wed, 22 Nov 2000 14:17:40 -0500 (EST) Received: from mnot.sanmateo.akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Wed, 22 Nov 2000 14:17:40 -0500 Received: by mnot.sanmateo.akamai.com (Postfix, from userid 20351) id 85F07503D; Wed, 22 Nov 2000 11:17:29 -0800 (PST) Date: Wed, 22 Nov 2000 11:17:29 -0800 From: Mark Nottingham To: Dan Li Cc: wrec@cs.utk.edu, Ian Cooper , Mike Dahlin , cao@cisco.com, Hilarie Orman Subject: Re: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] Message-ID: <20001122111728.B16663@akamai.com> References: <4.2.0.58.20001122062300.02a876c0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.2.0.58.20001122062300.02a876c0@omega>; from lidan@cisco.com on Wed, Nov 22, 2000 at 06:31:39AM -0800 List-Unsubscribe: Agree; I think that this can and should evolve into a general mechanism for propagating messages from the origin to intermediaries. I'd say the general characteristics of what we're chasing (straw man) are: * intermediary (client) registers interest in resource(s) with a server (can be, but doesn't have to be, the origin) * once registered, message flow is predominantly server->client, initiated by server * message payload can be invalidations, object metadata/handling instructions, deltas, etc. (don't know if log pushing is in scope) So, 'U' for update is more accurate, if we go this way. One might also say that 'C' for cache is a bit restrictive/misleading; How about Web Intermediary Update Protocol -- WIUP? I like 'W' for Web, as Web is > HTTP; it denotes that the protocol can update anything with a URI. On Wed, Nov 22, 2000 at 06:31:39AM -0800, Dan Li wrote: > Given that this protocol specifies a notification transport (channels, > relays, aggregations, etc.) and various notifications (invalidation, > updates, preloads, log report, etc.) on top of it, the word "invalidation" > seems less than descriptive as in WCIP. > > Along this line, it sounds to me that something like WCUP "web cache update > protocol" would be better. If the name WCIP is over restrictive and we may > need to change it sooner or later, I'd say we change it now. Do you feel > the need? > > Dan > > > > >>> Dan Li 11/15/00 01:57PM >>> > > >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > > >spend time on issue discussions and won't cover the draft in detail. This > > >draft is a strawman, at least the following things need more work: > > > > > >- clearly define the relationship of wcip with normal cache-control > > >directives. > > > > > >- specify in more detail the role of relay point, especially for channel > > >aggregation. Can we or can we not aggregate heartbeats, possibly but > > >cutting freshness guarantee. > > > > > >- pick a security model. Use SSL, or PGP signature, or both, and also the > > >security of the channel info. > > > > > >- do we need a default port number? pros and cons wrt. to port 80. > > > > > >- are people happy with persistent TCP connection? are people happy with > > >"delta consistency" (vs. eventual consistency, strong consistency, or > > >anything else). > > > > > >- in the absence of a off-the-shelf realtime reliable multicast protocol, > > >can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > > > > >- preloading, log reporting, advanced event notification, programability, > > >.. future stuff on vertical peering and dynamic content > > > > > >What do people think? > > > > > >Dan > > > > > > > > > > > > > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > > > >>To: IETF-Announce: ; > > > >>From: Internet-Drafts@ietf.org > > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > > >> > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > > >>directories. > > > >> > > > >> > > > >> Title : WCIP: Web Cache Invalidation Protocol > > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > > >> Filename : draft-danli-wrec-wcip-00.txt > > > >> Pages : 26 > > > >> Date : 14-Nov-00 > > > >> > > > >>Cache consistency is a major impediment to scalable content > > > >>delivery. This document describes the Web Cache Invalidation > > > >>Protocol (WCIP) which uses invalidations and updates to keep > > > >>changing objects up to date in web caches. Moreover, it allows > > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > > >>(content delivery network) environment. > > > >> > > > >>A URL for this Internet-Draft is: > > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > > >> > > > >>Internet-Drafts are also available by anonymous FTP. Login with the > > > username > > > >>"anonymous" and a password of your e-mail address. After logging in, > > > >>type "cd internet-drafts" and then > > > >> "get draft-danli-wrec-wcip-00.txt". > > > >> > > > >>A list of Internet-Drafts directories can be found in > > > >>http://www.ietf.org/shadow.html > > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >> > > > >> > > > >>Internet-Drafts can also be obtained by e-mail. > > > >> > > > >>Send a message to: > > > >> mailserv@ietf.org. > > > >>In the body type: > > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > > >> > > > >>NOTE: The mail server at ietf.org can return the document in > > > >> MIME-encoded form by using the "mpack" utility. To use this > > > >> feature, insert the command "ENCODING mime" before the "FILE" > > > >> command. To decode the response(s), you will need "munpack" or > > > >> a MIME-compliant mail reader. Different MIME-compliant mail > > > readers > > > >> exhibit different behavior, especially when dealing with > > > >> "multipart" MIME messages (i.e. documents which have been split > > > >> up into multiple messages), so check your local documentation on > > > >> how to manipulate these messages. > > > >> > > > >> > > > >>Below is the data which will enable a MIME compliant mail reader > > > >>implementation to automatically retrieve the ASCII version of the > > > >>Internet-Draft. > > > >> > > > >>Content-Type: text/plain > > > >>Content-ID: <20001114131241.I-D@ietf.org> > > > >> > > > >>ENCODING mime > > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > > >> > > > >> > > > > -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Wed Nov 22 15:11:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21798 for ; Wed, 22 Nov 2000 15:11:22 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA25073; Wed, 22 Nov 2000 15:11:12 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 22 Nov 2000 15:11:09 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA25045; Wed, 22 Nov 2000 15:11:07 -0500 (EST) Received: from rsnt-mail.rs2i.fr (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA25029; Wed, 22 Nov 2000 15:11:02 -0500 (EST) Received: from rsnt-mail.rs2i.fr (194.3.24.118 -> mail.rs2i.fr) by cs.utk.edu (smtpshim v1.0); Wed, 22 Nov 2000 15:11:02 -0500 Date: Wed, 22 Nov 2000 21:11:42 +0100 Message-Id: <200011222111.AA2471625010@rsnt-mail.rs2i.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Vinam TRAN" Reply-To: X-Sender: To: Subject: can you unsubscribe me please X-Mailer: List-Unsubscribe: can you unsubscribe me please Regards -- Vi-Nam TRAN vtran@rs2i.fr -- From owner-wrec@cs.utk.edu Wed Nov 22 15:19:39 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23878 for ; Wed, 22 Nov 2000 15:19:39 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA26424; Wed, 22 Nov 2000 15:19:15 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 22 Nov 2000 15:19:14 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA26401; Wed, 22 Nov 2000 15:19:13 -0500 (EST) Received: from nemo.corp.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA26382; Wed, 22 Nov 2000 15:19:11 -0500 (EST) From: Received: from nemo.corp.equinix.com (207.20.85.154 -> somehost-2.equinix.net) by cs.utk.edu (smtpshim v1.0); Wed, 22 Nov 2000 15:19:11 -0500 Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id MAA18797; Wed, 22 Nov 2000 12:18:54 -0800 (PST) Message-Id: <200011222018.MAA18797@nemo.corp.equinix.com> Subject: Re: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] To: mnot@akamai.com (Mark Nottingham) Date: Wed, 22 Nov 2000 12:18:54 -0800 (PST) Cc: lidan@cisco.com (Dan Li), wrec@cs.utk.edu, icooper@equinix.com (Ian Cooper), dahlin@cs.utexas.edu (Mike Dahlin), cao@cisco.com, HORMAN@novell.com (Hilarie Orman) In-Reply-To: <20001122111728.B16663@akamai.com> from "Mark Nottingham" at Nov 22, 2000 11:17:29 AM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit URI Update Protocol would end up being "You up?", a common enough protocol message in this arena. For the irony impaired, I'm joking. Ted > > > Agree; I think that this can and should evolve into a general mechanism for > propagating messages from the origin to intermediaries. > > I'd say the general characteristics of what we're chasing (straw man) are: > > * intermediary (client) registers interest in resource(s) with a server (can > be, but doesn't have to be, the origin) > > * once registered, message flow is predominantly server->client, initiated > by server > > * message payload can be invalidations, object metadata/handling > instructions, deltas, etc. (don't know if log pushing is in scope) > > So, 'U' for update is more accurate, if we go this way. One might also say > that 'C' for cache is a bit restrictive/misleading; How about Web > Intermediary Update Protocol -- WIUP? > > I like 'W' for Web, as Web is > HTTP; it denotes that the protocol can > update anything with a URI. > > > > > On Wed, Nov 22, 2000 at 06:31:39AM -0800, Dan Li wrote: > > Given that this protocol specifies a notification transport (channels, > > relays, aggregations, etc.) and various notifications (invalidation, > > updates, preloads, log report, etc.) on top of it, the word "invalidation" > > seems less than descriptive as in WCIP. > > > > Along this line, it sounds to me that something like WCUP "web cache update > > protocol" would be better. If the name WCIP is over restrictive and we may > > need to change it sooner or later, I'd say we change it now. Do you feel > > the need? > > > > Dan > > > > > > >>> Dan Li 11/15/00 01:57PM >>> > > > >Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > > > >spend time on issue discussions and won't cover the draft in detail. This > > > >draft is a strawman, at least the following things need more work: > > > > > > > >- clearly define the relationship of wcip with normal cache-control > > > >directives. > > > > > > > >- specify in more detail the role of relay point, especially for channel > > > >aggregation. Can we or can we not aggregate heartbeats, possibly but > > > >cutting freshness guarantee. > > > > > > > >- pick a security model. Use SSL, or PGP signature, or both, and also the > > > >security of the channel info. > > > > > > > >- do we need a default port number? pros and cons wrt. to port 80. > > > > > > > >- are people happy with persistent TCP connection? are people happy with > > > >"delta consistency" (vs. eventual consistency, strong consistency, or > > > >anything else). > > > > > > > >- in the absence of a off-the-shelf realtime reliable multicast protocol, > > > >can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > > > > > > >- preloading, log reporting, advanced event notification, programability, > > > >.. future stuff on vertical peering and dynamic content > > > > > > > >What do people think? > > > > > > > >Dan > > > > > > > > > > > > > > > > > > > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > > > > > >>To: IETF-Announce: ; > > > > >>From: Internet-Drafts@ietf.org > > > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > > > >> > > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > > > >>directories. > > > > >> > > > > >> > > > > >> Title : WCIP: Web Cache Invalidation Protocol > > > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > > > >> Filename : draft-danli-wrec-wcip-00.txt > > > > >> Pages : 26 > > > > >> Date : 14-Nov-00 > > > > >> > > > > >>Cache consistency is a major impediment to scalable content > > > > >>delivery. This document describes the Web Cache Invalidation > > > > >>Protocol (WCIP) which uses invalidations and updates to keep > > > > >>changing objects up to date in web caches. Moreover, it allows > > > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > > > >>(content delivery network) environment. > > > > >> > > > > >>A URL for this Internet-Draft is: > > > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > > > >> > > > > >>Internet-Drafts are also available by anonymous FTP. Login with the > > > > username > > > > >>"anonymous" and a password of your e-mail address. After logging in, > > > > >>type "cd internet-drafts" and then > > > > >> "get draft-danli-wrec-wcip-00.txt". > > > > >> > > > > >>A list of Internet-Drafts directories can be found in > > > > >>http://www.ietf.org/shadow.html > > > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > >> > > > > >> > > > > >>Internet-Drafts can also be obtained by e-mail. > > > > >> > > > > >>Send a message to: > > > > >> mailserv@ietf.org. > > > > >>In the body type: > > > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > > > >> > > > > >>NOTE: The mail server at ietf.org can return the document in > > > > >> MIME-encoded form by using the "mpack" utility. To use this > > > > >> feature, insert the command "ENCODING mime" before the "FILE" > > > > >> command. To decode the response(s), you will need "munpack" or > > > > >> a MIME-compliant mail reader. Different MIME-compliant mail > > > > readers > > > > >> exhibit different behavior, especially when dealing with > > > > >> "multipart" MIME messages (i.e. documents which have been split > > > > >> up into multiple messages), so check your local documentation on > > > > >> how to manipulate these messages. > > > > >> > > > > >> > > > > >>Below is the data which will enable a MIME compliant mail reader > > > > >>implementation to automatically retrieve the ASCII version of the > > > > >>Internet-Draft. > > > > >> > > > > >>Content-Type: text/plain > > > > >>Content-ID: <20001114131241.I-D@ietf.org> > > > > >> > > > > >>ENCODING mime > > > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > > > >> > > > > >> > > > > > > > -- > Mark Nottingham, Research Scientist > Akamai Technologies (San Mateo, CA) > From owner-wrec@cs.utk.edu Sat Nov 25 15:51:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06429 for ; Sat, 25 Nov 2000 15:51:02 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA24952; Sat, 25 Nov 2000 15:50:17 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 25 Nov 2000 15:50:00 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA24926; Sat, 25 Nov 2000 15:49:59 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA24913; Sat, 25 Nov 2000 15:49:54 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Sat, 25 Nov 2000 15:49:54 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA09741; Sat, 25 Nov 2000 12:49:16 -0800 (PST) Message-Id: <4.2.0.58.20001125124311.02380f00@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 25 Nov 2000 12:52:26 -0800 To: hardie@equinix.com, mnot@akamai.com (Mark Nottingham) From: Dan Li Subject: Re: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] Cc: wrec@cs.utk.edu, icooper@equinix.com (Ian Cooper), dahlin@cs.utexas.edu (Mike Dahlin), cao@cisco.com, HORMAN@novell.com (Hilarie Orman) In-Reply-To: <200011222018.MAA18797@nemo.corp.equinix.com> References: <20001122111728.B16663@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 12:18 PM 11/22/00 -0800, hardie@equinix.com wrote: >URI Update Protocol would end up being "You up?", a common enough >protocol message in this arena. with WIUP, it may sound like "Why Up" ;-) Could we get rid of one vowel? I agree "cache" as in WCUP is too restrictive, and yet "intermediary" in WIUP is too loose. How about a Web Proxy Update Protocol? Dan >For the irony impaired, I'm joking. > > Ted > > > > > > > > > Agree; I think that this can and should evolve into a general mechanism for > > propagating messages from the origin to intermediaries. > > > > I'd say the general characteristics of what we're chasing (straw man) are: > > > > * intermediary (client) registers interest in resource(s) with a server > (can > > be, but doesn't have to be, the origin) > > > > * once registered, message flow is predominantly server->client, initiated > > by server > > > > * message payload can be invalidations, object metadata/handling > > instructions, deltas, etc. (don't know if log pushing is in scope) > > > > So, 'U' for update is more accurate, if we go this way. One might also say > > that 'C' for cache is a bit restrictive/misleading; How about Web > > Intermediary Update Protocol -- WIUP? > > > > I like 'W' for Web, as Web is > HTTP; it denotes that the protocol can > > update anything with a URI. > > > > > > > > > > On Wed, Nov 22, 2000 at 06:31:39AM -0800, Dan Li wrote: > > > Given that this protocol specifies a notification transport (channels, > > > relays, aggregations, etc.) and various notifications (invalidation, > > > updates, preloads, log report, etc.) on top of it, the word > "invalidation" > > > seems less than descriptive as in WCIP. > > > > > > Along this line, it sounds to me that something like WCUP "web cache > update > > > protocol" would be better. If the name WCIP is over restrictive and > we may > > > need to change it sooner or later, I'd say we change it now. Do you feel > > > the need? > > > > > > Dan > > > > > > > > >>> Dan Li 11/15/00 01:57PM >>> > > > > >Hi, please take a look of the WCIP draft before the IETF meeting, > as we'd > > > > >spend time on issue discussions and won't cover the draft in > detail. This > > > > >draft is a strawman, at least the following things need more work: > > > > > > > > > >- clearly define the relationship of wcip with normal cache-control > > > > >directives. > > > > > > > > > >- specify in more detail the role of relay point, especially for > channel > > > > >aggregation. Can we or can we not aggregate heartbeats, possibly but > > > > >cutting freshness guarantee. > > > > > > > > > >- pick a security model. Use SSL, or PGP signature, or both, and > also the > > > > >security of the channel info. > > > > > > > > > >- do we need a default port number? pros and cons wrt. to port 80. > > > > > > > > > >- are people happy with persistent TCP connection? are people > happy with > > > > >"delta consistency" (vs. eventual consistency, strong consistency, or > > > > >anything else). > > > > > > > > > >- in the absence of a off-the-shelf realtime reliable multicast > protocol, > > > > >can we still run wcip on multicast UDP for scalability. See > section 3.2.3. > > > > > > > > > >- preloading, log reporting, advanced event notification, > programability, > > > > >.. future stuff on vertical peering and dynamic content > > > > > > > > > >What do people think? > > > > > > > > > >Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > > > > > > > >>To: IETF-Announce: ; > > > > > >>From: Internet-Drafts@ietf.org > > > > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > > > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > > > > >> > > > > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > > > > >>directories. > > > > > >> > > > > > >> > > > > > >> Title : WCIP: Web Cache Invalidation Protocol > > > > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > > > > >> Filename : draft-danli-wrec-wcip-00.txt > > > > > >> Pages : 26 > > > > > >> Date : 14-Nov-00 > > > > > >> > > > > > >>Cache consistency is a major impediment to scalable content > > > > > >>delivery. This document describes the Web Cache Invalidation > > > > > >>Protocol (WCIP) which uses invalidations and updates to keep > > > > > >>changing objects up to date in web caches. Moreover, it allows > > > > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > > > > >>(content delivery network) environment. > > > > > >> > > > > > >>A URL for this Internet-Draft is: > > > > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > > > > >> > > > > > >>Internet-Drafts are also available by anonymous FTP. Login with the > > > > > username > > > > > >>"anonymous" and a password of your e-mail address. After > logging in, > > > > > >>type "cd internet-drafts" and then > > > > > >> "get draft-danli-wrec-wcip-00.txt". > > > > > >> > > > > > >>A list of Internet-Drafts directories can be found in > > > > > >>http://www.ietf.org/shadow.html > > > > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >> > > > > > >> > > > > > >>Internet-Drafts can also be obtained by e-mail. > > > > > >> > > > > > >>Send a message to: > > > > > >> mailserv@ietf.org. > > > > > >>In the body type: > > > > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > > > > >> > > > > > >>NOTE: The mail server at ietf.org can return the document in > > > > > >> MIME-encoded form by using the "mpack" utility. To > use this > > > > > >> feature, insert the command "ENCODING mime" before the > "FILE" > > > > > >> command. To decode the response(s), you will need > "munpack" or > > > > > >> a MIME-compliant mail reader. Different > MIME-compliant mail > > > > > readers > > > > > >> exhibit different behavior, especially when dealing with > > > > > >> "multipart" MIME messages (i.e. documents which have > been split > > > > > >> up into multiple messages), so check your local > documentation on > > > > > >> how to manipulate these messages. > > > > > >> > > > > > >> > > > > > >>Below is the data which will enable a MIME compliant mail reader > > > > > >>implementation to automatically retrieve the ASCII version of the > > > > > >>Internet-Draft. > > > > > >> > > > > > >>Content-Type: text/plain > > > > > >>Content-ID: <20001114131241.I-D@ietf.org> > > > > > >> > > > > > >>ENCODING mime > > > > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > > > > >> > > > > > >> > > > > > > > > > > -- > > Mark Nottingham, Research Scientist > > Akamai Technologies (San Mateo, CA) > > From owner-wrec@cs.utk.edu Sat Nov 25 19:45:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14297 for ; Sat, 25 Nov 2000 19:45:34 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA09810; Sat, 25 Nov 2000 19:45:28 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 25 Nov 2000 19:45:22 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA09779; Sat, 25 Nov 2000 19:45:21 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA09765; Sat, 25 Nov 2000 19:45:19 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Sat, 25 Nov 2000 19:45:20 -0500 Received: from icooper.equinix.com (tunnel2-2.corp.equinix.com [172.16.252.2]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id QAA16673; Sat, 25 Nov 2000 16:45:12 -0800 (PST) Message-Id: <5.0.2.1.2.20001125163252.00aae6e0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 25 Nov 2000 16:45:10 -0800 To: Dan Li , hardie@equinix.com, mnot@akamai.com (Mark Nottingham) From: Ian Cooper Subject: Re: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] Cc: wrec@cs.utk.edu, dahlin@cs.utexas.edu (Mike Dahlin), cao@cisco.com, HORMAN@novell.com (Hilarie Orman) In-Reply-To: <4.2.0.58.20001125124311.02380f00@omega> References: <200011222018.MAA18797@nemo.corp.equinix.com> <20001122111728.B16663@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: [With apologies to everyone getting 2 copies. We're probably all on the mailing list, but just in case...] At 12:52 11/25/2000 -0800, Dan Li wrote: >At 12:18 PM 11/22/00 -0800, hardie@equinix.com wrote: >>URI Update Protocol would end up being "You up?", a common enough >>protocol message in this arena. > >with WIUP, it may sound like "Why Up" ;-) Could we get rid of one vowel? > >I agree "cache" as in WCUP is too restrictive, and yet "intermediary" in >WIUP is too loose. How about a Web Proxy Update Protocol? The protocol has use in CDN environments (for example, it could be of use in CDN peering), in which case "proxy" is too restrictive. Not sure that simply using "proxy" gets the right message across anyway (it's the cache within a caching proxy that's being updates). "Distributed Web Object Consistency Protocol" (choose your acronym to come up with something funky) seems closer to what's being considered. All that said, we're perhaps spending too much time thinking about what to call it when we should be working on what it actually does and how it does it. (Hmm, memories of a certain Dilbert come to mind.) From owner-wrec@cs.utk.edu Sun Nov 26 00:24:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18382 for ; Sun, 26 Nov 2000 00:24:22 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA27244; Sun, 26 Nov 2000 00:24:15 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 26 Nov 2000 00:24:11 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA27221; Sun, 26 Nov 2000 00:24:10 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA27208; Sun, 26 Nov 2000 00:24:09 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Sun, 26 Nov 2000 00:24:09 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA22037; Sat, 25 Nov 2000 21:23:34 -0800 (PST) Message-Id: <4.2.0.58.20001125212413.023a3dd0@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 25 Nov 2000 21:26:42 -0800 To: Ian Cooper , hardie@equinix.com, mnot@akamai.com (Mark Nottingham) From: Dan Li Subject: Re: rename WCIP ... [Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt] Cc: wrec@cs.utk.edu, dahlin@cs.utexas.edu (Mike Dahlin), cao@cisco.com, HORMAN@novell.com (Hilarie Orman) In-Reply-To: <5.0.2.1.2.20001125163252.00aae6e0@nemo.corp.equinix.com> References: <4.2.0.58.20001125124311.02380f00@omega> <200011222018.MAA18797@nemo.corp.equinix.com> <20001122111728.B16663@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 04:45 PM 11/25/00 -0800, Ian Cooper wrote: >"Distributed Web Object Consistency Protocol" (choose your acronym to come >up with something funky) seems closer to what's being considered. "consistency protocol" is just one aspect of it, given that the protocol ought to cover not only invalidation but also updates and other types of notifications. I think having a "U" for update there is the right thing. Dan From owner-wrec@cs.utk.edu Sun Nov 26 15:50:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16096 for ; Sun, 26 Nov 2000 15:50:30 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA20451; Sun, 26 Nov 2000 15:49:19 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 26 Nov 2000 15:49:15 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA20428; Sun, 26 Nov 2000 15:49:14 -0500 (EST) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA20414; Sun, 26 Nov 2000 15:49:10 -0500 (EST) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Sun, 26 Nov 2000 15:49:10 -0500 Received: from icooper.equinix.com (tunnel2-2.corp.equinix.com [172.16.252.2]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id MAA16143 for ; Sun, 26 Nov 2000 12:48:38 -0800 (PST) Message-Id: <5.0.2.1.2.20001126111500.00aae6e0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 26 Nov 2000 11:19:56 -0800 To: wrec@cs.utk.edu From: Ian Cooper Subject: Updated taxonomy FYI Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_75800996==_" List-Unsubscribe: --=====================_75800996==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is the updated version of the taxonomy submitted to the IESG having considered the comments from IESG and RFC-editor. --=====================_75800996==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-wrec-taxonomy-06.txt" Network Working Group I. Cooper Internet-Draft Equinix Expires: May 23, 2001 I. Melve UNINETT G. Tomlinson Entera November 22, 2000 Internet Web Replication and Caching Taxonomy draft-ietf-wrec-taxonomy-06.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in an accompanying document[23], and are not part of this document. This document presents open protocols and points to published material for each protocol. Cooper, et. al. Expires May 23, 2001 [Page 1] Internet-Draft WREC Taxonomy November 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 First order derivative terms . . . . . . . . . . . . . . . 7 2.3 Second order derivatives . . . . . . . . . . . . . . . . . 8 2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 8 2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 9 3. Distributed System Relationships . . . . . . . . . . . . . 11 3.1 Replication Relationships . . . . . . . . . . . . . . . . 11 3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 12 3.2.1 Client to Non-Interception Proxy . . . . . . . . . . . . . 12 3.2.2 Client to Surrogate to Origin Server . . . . . . . . . . . 12 3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 13 3.2.3.2 (Caching) Proxy Arrays . . . . . . . . . . . . . . . . . . 14 3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 14 4. Replica Selection . . . . . . . . . . . . . . . . . . . . 16 4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 16 4.2 Replica HTTP Redirection . . . . . . . . . . . . . . . . . 16 4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 17 5. Inter-Replica Communication . . . . . . . . . . . . . . . 18 5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 18 5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 18 5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 19 6. User Agent to Proxy Configuration . . . . . . . . . . . . 20 6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 20 6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 20 6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 21 6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 21 7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 23 7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 23 7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 23 7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 24 7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 24 7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 25 7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 26 7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 26 8. Network Element Communication . . . . . . . . . . . . . . 27 8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 27 8.2 Network Element Control Protocol (NECP) . . . . . . . . . 27 8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . 29 9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 29 9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 29 9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 29 Cooper, et. al. Expires May 23, 2001 [Page 2] Internet-Draft WREC Taxonomy November 2000 9.1.3 Authentication based on IP number . . . . . . . . . . . . 29 9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 30 9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 30 9.3 Service security . . . . . . . . . . . . . . . . . . . . . 30 9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 31 9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 31 9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 31 9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 31 9.3.5 Application level access . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 References . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 34 Full Copyright Statement . . . . . . . . . . . . . . . . . 36 Cooper, et. al. Expires May 23, 2001 [Page 3] Internet-Draft WREC Taxonomy November 2000 1. Introduction Since its introduction in 1990, the World-Wide Web has evolved from a simple client server model into a complex distributed architecture. This evolution has been driven largely due to the scaling problems associated with exponential growth. Distinct paradigms and solutions have emerged to satisfy specific requirements. Two core infrastructure components being employed to meet the demands of this growth are replication and caching. In many cases, there is a need for web caches and replicated services to be able to coexist. This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure deployed in the Internet today. The principal goal of this document is to establish a common understanding and reference point of this application domain. It is also expected that this document will be used in the creation of a standard architectural framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Some of the protocols which this memo examines are specified only by company technical whitepapers or draft documents. Such references are included to demonstrate the existence of such protocols, their experimental deployment in the Internet today, or to aid the reader in their understanding of this technology area. There are many protocols, both open and proprietary, employed in web replication and caching today. A majority of the open protocols include DNS[8], Cache Digests[21][10], CARP[14], HTTP[1], ICP[2], PAC[12], SOCKS[7], WPAD[13], and WCCP [18][19]. These protocols, and their use within the caching and replication environments, are discussed below. Cooper, et. al. Expires May 23, 2001 [Page 4] Internet-Draft WREC Taxonomy November 2000 2. Terminology The following terminology provides definitions of common terms used within the web replication and caching community. Base terms are taken, where possible, from the HTTP/1.1 specification[1] and are included here for reference. First- and second-order derivatives are constructed from these base terms to help define the relationships that exist within this area. Terms that are in common usage and which are contrary to definitions in RFC2616 and this document are highlighted. 2.1 Base Terms The majority of these terms are taken as-is from RFC2616[1], and are included here for reference. client (taken from [1]) A program that establishes connections for the purpose of sending requests. server (taken from [1]) An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. proxy (taken from [1]) An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. Note: The term "transparent proxy" refers to a semantically transparent proxy as described in [1], not what is commonly Cooper, et. al. Expires May 23, 2001 [Page 5] Internet-Draft WREC Taxonomy November 2000 understood within the caching community. We recommend that the term "transparent proxy" is always prefixed to avoid confusion (e.g. "network transparent proxy"). However, see definition of "interception proxy" below. The above condition requiring implementation of both the server and client requirements of HTTP/1.1 is only appropriate for a non-network transparent proxy. cache (taken from [1]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. Note: The term "cache" used alone often is meant as "caching proxy". Note: There are additional motivations for caching, for example reducing server load (as a further means to reduce response time). cacheable (taken from [1]) A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request. gateway (taken from [1]) A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway. tunnel (taken from [1]) An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. replication "Creating and maintaining a duplicate copy of a database or file system on a different computer, typically a server." - Free Online Dictionary of Computing (FOLDOC) inbound/outbound (taken from [1]) Cooper, et. al. Expires May 23, 2001 [Page 6] Internet-Draft WREC Taxonomy November 2000 Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent". network element A network device that introduces multiple paths between source and destination, transparent to HTTP. 2.2 First order derivative terms The following terms are constructed taking the above base terms as foundation. origin server (taken from [1]) The server on which a given resource resides or is to be created. user agent (taken from [1]) The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. caching proxy A proxy with a cache, acting as a server to clients, and a client to servers. Caching proxies are often referred to as "proxy caches" or simply "caches". The term "proxy" is also frequently misused when referring to caching proxies. surrogate A gateway co-located with an origin server, or at a different point in the network, delegated the authority to operate on behalf of, and typically working in close co-operation with, one or more origin servers. Responses are typically delivered from an internal cache. Surrogates may derive cache entries from the origin server or from another of the origin server's delegates. In some cases a surrogate may tunnel such requests. Where close co-operation between origin servers and surrogates exists, this enables modifications of some protocol requirements, including the Cache-Control directives in [1]. Such modifications have yet to be fully specified. Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates. reverse proxy See "surrogate". Cooper, et. al. Expires May 23, 2001 [Page 7] Internet-Draft WREC Taxonomy November 2000 server accelerator See "surrogate". 2.3 Second order derivatives The following terms further build on first order derivatives: master origin server An origin server on which the definitive version of a resource resides. replica origin server An origin server holding a replica of a resource, but which may act as an authoritative reference for client requests. content consumer The user or system that initiates inbound requests, through use of a user agent. browser A special instance of a user agent that acts as a content presentation device for content consumers. 2.4 Topological terms The following definitions are added to describe caching device topology: user agent cache The cache within the user agent program. local caching proxy The caching proxy to which a user agent connects. intermediate caching proxy Seen from the content consumer's view, all caches participating in the caching mesh that are not the user agent's local caching proxy. cache server A server to requests made by local and intermediate caching proxies, but which does not act as a proxy. cache array A cluster of caching proxies, acting logically as one service and partitioning the resource name space across the array. Also known as "diffused array" or "cache cluster". caching mesh Cooper, et. al. Expires May 23, 2001 [Page 8] Internet-Draft WREC Taxonomy November 2000 a loosely coupled set of co-operating proxy- and (optionally) caching-servers, or clusters, acting independently but sharing cacheable content between themselves using inter-cache communication protocols. 2.5 Automatic use of proxies Network administrators may wish to force or facilitate the use of proxies by clients, enabling such configuration within the network itself or within automatic systems in user agents, such that the content consumer need not be aware of any such configuration issues. The terms that describe such configurations are given below. automatic user-agent proxy configuration The technique of discovering the availability of one or more proxies and the automated configuration of the user agent to use them. The use of a proxy is transparent to the content consumer but not to the user agent. The term "automatic proxy configuration" is also used in this sense. traffic interception The process of using a network element to examine network traffic to determine whether it should be redirected. traffic redirection Redirection of client requests from a network element performing traffic interception to a proxy. Used to deploy (caching) proxies without the need to manually reconfigure individual user agents, or to force the use of a proxy where such use would not otherwise occur. interception proxy (a.k.a. "transparent proxy", "transparent cache") The term "transparent proxy" has been used within the caching community to describe proxies used with zero configuration within the user agent. Such use is somewhat transparent to user agents. Due to discrepancies with [1] (see definition of "proxy" above), and objections to the use of the word "transparent", we introduce the term "interception proxy" to describe proxies that receive redirected traffic flows from network elements performing traffic interception. Interception proxies receive inbound traffic flows through the process of traffic redirection. (Such proxies are deployed by network administrators to facilitate or require the use of appropriate services offered by the proxy). Problems associated with the deployment of interception proxies are described in the companion document "Known HTTP Proxy/Caching Problems"[23]. The use of interception proxies requires zero configuration of the Cooper, et. al. Expires May 23, 2001 [Page 9] Internet-Draft WREC Taxonomy November 2000 user agent which act as though communicating directly with an origin server. Cooper, et. al. Expires May 23, 2001 [Page 10] Internet-Draft WREC Taxonomy November 2000 3. Distributed System Relationships This section identifies the relationships that exist in a distributed replication and caching environment. Having defined these relationships, later sections describe the communication protocols used in each relationship. 3.1 Replication Relationships The following sections describe relationships between clients and replicas and between replicas themselves. 3.1.1 Client to Replica A client may communicate with one or more replica origin servers, as well as with master origin servers. (In the absence of replica servers the client interacts directly with the origin server as is the normal case.) ------------------ ----------------- ------------------ | Replica Origin | | Master Origin | | Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ \ | / \ | / ----------------------------------------- | Client to ----------------- Replica Server | Client | ----------------- Protocols used to enable the client to use one of the replicas can be found in Section 4. 3.1.2 Inter-Replica This is the relationship between master origin server(s) and replica origin servers, to replicate data sets that are accessed by clients in the relationship shown in Section 3.1.1. ------------------ ----------------- ------------------ | Replica Origin |-----| Master Origin |-----| Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ Protocols used in this relationship can be found in Section 5. Cooper, et. al. Expires May 23, 2001 [Page 11] Internet-Draft WREC Taxonomy November 2000 3.2 Proxy Relationships There are a variety of ways in which (caching) proxies and cache servers communicate with each other, and with user agents. 3.2.1 Client to Non-Interception Proxy A client may communicate with zero or more proxies for some or all requests. Where the result of communication results in no proxy being used, the relationship is between client and (replica) origin server (see Section 3.1.1). ----------------- ----------------- ----------------- | Local | | Local | | Local | | Proxy | | Proxy | | Proxy | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | ----------------- | Client | ----------------- In addition, a user agent may interact with an additional server - operated on behalf of a proxy for the purpose of automatic user agent proxy configuration. Schemes and protocols used in these relationships can be found in Section 6. 3.2.2 Client to Surrogate to Origin Server A client may communicate with zero or more surrogates for requests intended for one or more origin servers. Where a surrogate is not used, the client communicates directly with an origin server. Where a surrogate is used the client communicates as if with an origin server. The surrogate fulfills the request from its internal cache, or acts as a gateway or tunnel to the origin server. Cooper, et. al. Expires May 23, 2001 [Page 12] Internet-Draft WREC Taxonomy November 2000 -------------- -------------- -------------- | Origin | | Origin | | Origin | | Server | | Server | | Server | -------------- -------------- -------------- \ | / \ | / ----------------- | Surrogate | | | ----------------- | | ------------ | Client | ------------ 3.2.3 Inter-Proxy Inter-Proxy relationships exist as meshes (loosely coupled) and clusters (tightly coupled). 3.2.3.1 (Caching) Proxy Meshes Within a loosely coupled mesh of (caching) proxies, communication can happen at the same level between peers, and with one or more parents. --------------------- --------------------- -----------| Intermediate | | Intermediate | | | Caching Proxy (D) | | Caching Proxy (E) | |(peer) --------------------- --------------------- -------------- | (parent) / (parent) | Cache | | ------/ | Server (C) | | / -------------- | / (peer) | ----------------- --------------------- -------------| Local Caching |-------| Intermediate | | Proxy (A) | (peer)| Caching Proxy (B) | ----------------- --------------------- | | ---------- | Client | ---------- Client included for illustration purposes only An inbound request may be routed to one of a number of intermediate (caching) proxies based on a determination of whether that parent is Cooper, et. al. Expires May 23, 2001 [Page 13] Internet-Draft WREC Taxonomy November 2000 better suited to resolving the request. For example, in the above figure, Cache Server C and Intermediate Caching Proxy B are peers of the Local Caching Proxy A, and may only be used when the resource requested by A already exists on either B or C. Intermediate Caching Proxies D & E are parents of A, and it is A's choice of which to use to resolve a particular request. The relationship between A & B only makes sense in a caching environment, while the relationships between A & D and A & E are also appropriate where D or E are non-caching proxies. Protocols used in these relationships can be found in Section 7.1. 3.2.3.2 (Caching) Proxy Arrays Where a user agent may have a relationship with a proxy, it is possible that it may instead have a relationship with an array of proxies arranged in a tightly coupled mesh. ---------------------- ---------------------- | --------------------- | | | (Caching) Proxy | |----- | Array |----- ^ ^ --------------------- ^ ^ | | ^ ^ | |--- | | |----- | -------------------------- Protocols used in this relationship can be found in Section 7.2. 3.2.4 Network Element to Caching Proxy A network element performing traffic interception may choose to redirect requests from a client to a specific proxy within an array. (It may also choose not to redirect the traffic, in which case the relationship is between client and (replica) origin server, see Section 3.1.1.) Cooper, et. al. Expires May 23, 2001 [Page 14] Internet-Draft WREC Taxonomy November 2000 ----------------- ----------------- ----------------- | Caching Proxy | | Caching Proxy | | Caching Proxy | | Array | | Array | | Array | ----------------- ----------------- ----------------- \ | / ----------------------------------------- | -------------- | Network | | Element | -------------- | /// | ------------ | Client | ------------ The interception proxy may be directly in-line of the flow of traffic - in which case the intercepting network element and interception proxy form parts of the same hardware system - or may be out-of-path, requiring the intercepting network element to redirect traffic to another network segment. In this latter case, communication protocols enable the intercepting network element to stop and start redirecting traffic when the interception proxy becomes (un)available. Details of these protocols can be found in Section 8. Cooper, et. al. Expires May 23, 2001 [Page 15] Internet-Draft WREC Taxonomy November 2000 4. Replica Selection This section describes the schemes and protocols used in the cooperation and communication between client and replica origin web servers. The ideal situation is to discover an optimal replica origin server for clients to communicate with. Optimality is a policy based decision, often based upon proximity, but may be based on other criteria such as load. 4.1 Navigation Hyperlinks Best known reference: This memo. Description: The simplest of client to replica communication mechanisms. This utilizes hyperlink URIs embedded in web pages that point to the individual replica origin servers. The content consumer manually selects the link of the replica origin server they wish to use. Security: Relies on the protocol security associated with the appropriate URI scheme. Deployment: Probably the most commonly deployed client to replica communication mechanism. Ubiquitous interoperability with humans. Submitter: Document editors. 4.2 Replica HTTP Redirection Best known reference: This memo. Description: A simple and commonly used mechanism to connect clients with replica origin servers is to use HTTP redirection. Clients are redirected to an optimal replica origin server via the use of the HTTP[1] protocol response codes, e.g. 302 "Found", or 307 "Temporary Redirect". A client establishes HTTP communication with one of the replica origin servers. The initially contacted replica origin server can then either choose to accept the service or redirect the client again. Refer to section 10.3 in HTTP/1.1[1] for information on HTTP response codes. Security: Relies entirely upon HTTP security. Cooper, et. al. Expires May 23, 2001 [Page 16] Internet-Draft WREC Taxonomy November 2000 Deployment: Observed at a number of large web sites. Extent of usage in the Internet is unknown. Submitter: Document editors. 4.3 DNS Redirection Best known references: * RFC1794 DNS Support for Load Balancing Proximity[8] * This memo Description: The Domain Name Service (DNS) provides a more sophisticated client to replica communication mechanism. This is accomplished by DNS servers that sort resolved IP addresses based upon quality of service policies. When a client resolves the name of an origin server, the enhanced DNS server sorts the available IP addresses of the replica origin servers starting with the most optimal replica and ending with the least optimal replica. Security: Relies entirely upon DNS security, and other protocols that may be used in determining the sort order. Deployment: Observed at a number of large web sites and large ISP web hosted services. Extent of usage in the Internet is unknown, but is believed to be increasing. Submitter: Document editors. Cooper, et. al. Expires May 23, 2001 [Page 17] Internet-Draft WREC Taxonomy November 2000 5. Inter-Replica Communication This section describes the cooperation and communication between master- and replica- origin servers. Used in replicating data sets between origin servers. 5.1 Batch Driven Replication Best known reference: This memo. Description: The replica origin server to be updated initiates communication with a master origin server. The communication is established at intervals based upon queued transactions which are scheduled for deferred processing. The scheduling mechanism policies vary, but generally are re-occurring at a specified time. Once communication is established, data sets are copied to the initiating replica origin server. Security: Relies upon the protocol being used to transfer the data set. FTP[4] and RDIST are the most common protocols observed. Deployment: Very common for synchronization of mirror sites in the Internet. Submitter: Document editors. 5.2 Demand Driven Replication Best known reference: This memo. Description: Replica origin servers acquire content as needed due to client demand. When a client requests a resource that is not in the data set of the replica origin server/surrogate, an attempt is made to resolve the request by acquiring the resource from the master origin server, returning it to the requesting client. Security: Relies upon the protocol being used to transfer the resources. FTP[4], Gopher[5], HTTP[1] and ICP[2] are the most common protocols observed. Deployment: Observed at several large web sites. Extent of usage in the Cooper, et. al. Expires May 23, 2001 [Page 18] Internet-Draft WREC Taxonomy November 2000 Internet is unknown. Submitter: Document editors. 5.3 Synchronized Replication Best known reference: This memo. Description: Replicated origin servers cooperate using synchronized strategies and specialized replica protocols to keep the replica data sets coherent. Synchronization strategies range from tightly coherent (a few minutes) to loosely coherent (a few or more hours). Updates occur between replicas based upon the synchronization time constraints of the coherency model employed and are generally in the form of deltas only. Security: All of the known protocols utilize strong cryptographic key exchange methods, which are either based upon the Kerberos shared secret model or the public/private key RSA model. Deployment: Observed at a few sites, primarily at university campuses. Submitter: Document editors. Note: The editors are aware of at least two open source protocols - AFS and CODA - as well as the proprietary NRS protocol from Novell. Cooper, et. al. Expires May 23, 2001 [Page 19] Internet-Draft WREC Taxonomy November 2000 6. User Agent to Proxy Configuration This section describes the configuration, cooperation and communication between user agents and proxies. 6.1 Manual Proxy Configuration Best known reference: This memo. Description: Each user must configure her user agent by supplying information pertaining to proxied protocols and local policies. Security: The potential for doing wrong is high; each user individually sets preferences. Deployment: Widely deployed, used in all current browsers. Most browsers also support additional options. Submitter: Document editors. 6.2 Proxy Auto Configuration (PAC) Best known reference: "Navigator Proxy Auto-Config File Format"[12] Description: A JavaScript script retrieved from a web server is executed for each URL accessed to determine the appropriate proxy (if any) to be used to access the resource. User agents must be configured to request this script upon startup. There is no bootstrap mechanism, manual configuration is necessary. Despite manual configuration, the process of proxy configuration is simplified by centralizing it within a script at a single location. Security: Common policy per organization possible but still requires initial manual configuration. PAC is better than "manual proxy configuration" since PAC administrators may update the proxy configuration without further user intervention. Interoperability of PAC files is not high, since different browsers have slightly different interpretations of the same Cooper, et. al. Expires May 23, 2001 [Page 20] Internet-Draft WREC Taxonomy November 2000 script, possibly leading to undesired effects. Deployment: Implemented in Netscape Navigator and Microsoft Internet Explorer. Submitter: Document editors. 6.3 Cache Array Routing Protocol (CARP) v1.0 Best known references: * "Cache Array Routing Protocol"[14] (work in progress) * "Cache Array Routing Protocol (CARP) v1.0 Specifications"[15] * "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"[16] Description: User agents may use CARP directly as a hash function based proxy selection mechanism. They need to be configured with the location of the cluster information. Security: Security considerations are not covered in the specification drafts. Deployment: Implemented in Microsoft Proxy Server, Squid. Implemented in user agents via PAC scripts. Submitter: Document editors. 6.4 Web Proxy Auto-Discovery Protocol (WPAD) Best known reference: "The Web Proxy Auto-Discovery Protocol"[13] (work in progress) Description: WPAD uses a collection of pre-existing Internet resource discovery mechanisms to perform web proxy auto-discovery. The only goal of WPAD is to locate the PAC URL[12]. WPAD does not specify which proxies will be used. WPAD supplies the PAC URL, and the PAC script then operates as defined above to choose proxies per resource request. Cooper, et. al. Expires May 23, 2001 [Page 21] Internet-Draft WREC Taxonomy November 2000 The WPAD protocol specifies the following: * how to use each mechanism for the specific purpose of web proxy auto-discovery * the order in which the mechanisms should be performed * the minimal set of mechanisms which must be attempted by a WPAD compliant user agent The resource discovery mechanisms utilized by WPAD are as follows: * Dynamic Host Configuration Protocol DHCP * Service Location Protocol SLP * "Well Known Aliases" using DNS A records * DNS SRV records * "service: URLs" in DNS TXT records Security: Relies upon DNS and HTTP security. Deployment: Implemented in some user agents and caching proxy servers. More than two independent implementations. Submitter: Josh Cohen, Microsoft, joshco@microsoft.com Cooper, et. al. Expires May 23, 2001 [Page 22] Internet-Draft WREC Taxonomy November 2000 7. Inter-Proxy Communication 7.1 Loosely coupled Inter-Proxy Communication This section describes the cooperation and communication between caching proxies. 7.1.1 Internet Cache Protocol (ICP) Best known reference: RFC2186 Internet Cache Protocol (ICP), version 2[2] Description: ICP is used by proxies to query other (caching) proxies about web resources, to see if the requested resource is present on the other system. ICP uses UDP. Since UDP is an uncorrected network transport protocol, an estimate of network congestion and availability may be calculated by ICP loss. This rudimentary loss measurement provides, together with round trip times, a load balancing method for caches. Security: See RFC2187[3] ICP does not convey information about HTTP headers associated with resources. HTTP headers may include access control and cache directives. Since proxies ask for the availability of resources, and subsequently retrieve them using HTTP, false cache hits may occur (object present in cache, but not accessible to a sibling is one example). ICP suffers from all the security problems of UDP. Deployment: Widely deployed. Most current caching proxy implementations support ICP in some form. Submitter: Document editors. See also: "Internet Cache Protocol Extension"[17] (work in progress) Cooper, et. al. Expires May 23, 2001 [Page 23] Internet-Draft WREC Taxonomy November 2000 7.1.2 Hyper Text Caching Protocol Best known reference: RFC2756 Hyper Text Caching Protocol (HTCP/0.0)[9] Description: HTCP is a protocol for discovering HTTP caching proxies and cached data, managing sets of HTTP caching proxies, and monitoring cache activity. HTCP requests include HTTP header material, while ICPv2 does not, enabling HTCP replies to more accurately describe the behaviour that would occur as a result of a subsequent HTTP request for the same resource. Security: Optionally uses HMAC-MD5[11] shared secret authentication. Protocol is subject to attack if authentication is not used. Deployment: HTCP is implemented in Squid and the "Web Gateway Interceptor". Submitter: Document editors. 7.1.3 Cache Digest Best known references: * "Cache Digest Specification - version 5"[21] * "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol"[10] (see note) Description: Cache Digests are a response to the problems of latency and congestion associated with previous inter-cache communication mechanisms such as the Internet Cache Protocol (ICP)[2] and the Hyper Text Cache Protocol[9]. Unlike these protocols, Cache Digests support peering between caching proxies and cache servers without a request-response exchange taking place for each inbound request. Instead, a summary of the contents in cache (the Digest) is fetched by other systems that peer with it. Using Cache Digests it is possible to determine with a relatively high degree of accuracy whether a given resource is cached by a particular system. Cache Digests are both an exchange protocol and a data format. Cooper, et. al. Expires May 23, 2001 [Page 24] Internet-Draft WREC Taxonomy November 2000 Security: If the contents of a Digest are sensitive, they should be protected. Any methods which would normally be applied to secure an HTTP connection can be applied to Cache Digests. A 'Trojan horse' attack is currently possible in a mesh: System A A can build a fake peer Digest for system B and serve it to B's peers if requested. This way A can direct traffic toward/from B. The impact of this problem is minimized by the 'pull' model of transferring Cache Digests from one system to another. Cache Digests provide knowledge about peer cache content on a URL level. Hence, they do not dictate a particular level of policy management and can be used to implement various policies on any level (user, organization, etc.). Deployment: Cache Digests are supported in Squid. Cache Meshes: NLANR Mesh; TF-CACHE Mesh (European Academic networks Submitter: Alex Rousskov, NLANR, rousskov@nlanr.net for [21] Pei Cao for [10] Note: The technology of Summary Cache[10] is patent pending by the University of Wisconsin-Madison. 7.1.4 Cache Pre-filling Best known reference: "Pre-filling a cache - A satellite overview"[20] (work in progress) Description: Cache pre-filling is a push-caching implementation. It is particularly well adapted to IP-multicast networks because it allows preselected resources to be simultaneously inserted into caches within the targeted multicast group. Different implementations of cache pre-filling already exist, especially in satellite contexts. However, there is still no standard for this kind of push-caching and vendors propose solutions either based on dedicated equipment or public domain caches extended with a pre-filling module. Security: Relies on the inter-cache protocols being employed. Cooper, et. al. Expires May 23, 2001 [Page 25] Internet-Draft WREC Taxonomy November 2000 Deployment: Observed in two commercial content distribution service providers. Submitter: Ivan Lovric, France Telecom, ivan.lovric@cnet.francetelecom.fr 7.2 Tightly Coupled Inter-Cache Communication 7.2.1 Cache Array Routing Protocol (CARP) v1.0 Also see Section 6.3 Best known references: * "Cache Array Routing Protocol"[14] (work in progress) * "Cache Array Routing Protocol (CARP) v1.0 Specifications"[15] * "Cache Array Routing Protocol and Microsoft Proxy Server 2.0"[16] Description: CARP is a hashing function for dividing URL-space among a cluster of proxies. Included in CARP is the definition of a Proxy Array Membership Table, and ways to download this information. A user agent which implements CARP v1.0 can allocate and intelligently route requests for the URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates may be improved. Security: Security considerations are not covered in the specification drafts. Deployment: Implemented in caching proxy servers. More than two independent implementations. Submitter: Document editors. Cooper, et. al. Expires May 23, 2001 [Page 26] Internet-Draft WREC Taxonomy November 2000 8. Network Element Communication This section describes the cooperation and communication between proxies and network elements. Examples of such network elements include routers and switches. Generally used for deploying interception proxies and/or diffused arrays. 8.1 Web Cache Control Protocol (WCCP) Best known references: "Web Cache Control Protocol"[18][19] (work in progress) Note: The mame used for this protocol varies, sometimes referred to as the "Web Cache Coordination Protocol", but frequently just "WCCP" to avoid confusion Description: WCCP V1 runs between a router functioning as a redirecting network element and out-of-path interception proxies. The protocol allows one or more proxies to register with a single router to receive redirected traffic. It also allows one of the proxies, the designated proxy, to dictate to the router how redirected traffic is distributed across the array. WCCP V2 additionally runs between multiple routers and the proxies. Security: WCCP V1 has no security features. WCCP V2 provides optional authentication of protocol packets. Deployment: Network elements: WCCP is deployed on a wide range of Cisco routers. Caching proxies: WCCP is deployed on a number of vendors' caching proxies. Submitter: David Forster, CISCO, dforster@cisco.com Document editors. 8.2 Network Element Control Protocol (NECP) Best known reference: "NECP: The Network Element Control Protocol"[22] (work in progress) Description: NECP provides methods for network elements to learn about server Cooper, et. al. Expires May 23, 2001 [Page 27] Internet-Draft WREC Taxonomy November 2000 capabilities, availability, and hints as to which flows can and cannot be serviced. This allows network elements to perform load balancing across a farm of servers, redirection to interception proxies, and cut-through of flows that cannot be served by the farm. Security: Optionally uses HMAC-SHA-1[11] shared secret authentication along with complex sequence numbers to provide moderately strong security. Protocol is subject to attack if authentication is not used. Deployment: Unknown at present; several network element and caching proxy vendors have expressed intent to implement the protocol. Submitter: Gary Tomlinson, Novell, garyt@novell.com 8.3 SOCKS Best known reference: RFC1928 SOCKS Protocol Version 5[7] Description: SOCKS is primarily used as a caching proxy to firewall protocol. Although firewalls don't conform to the narrowly defined network element definition above, they are a integral part of the network infrastructure. When used in conjunction with a firewall, SOCKS provides a authenticated tunnel between the caching proxy and the firewall. Security: An extensive framework provides for multiple authentication methods. Currently, SSL, CHAP, DES, 3DES are known to be available. Deployment: SOCKS is widely deployed in the Internet. Submitter: Document editors. Cooper, et. al. Expires May 23, 2001 [Page 28] Internet-Draft WREC Taxonomy November 2000 9. Security Considerations This document provides a taxonomy for web caching and replication. Recommended practice, architecture and protocols are not described in detail. By definition, replication and caching involve the copying of resources. There are legal implications of making and keeping transient or permanent copies; these are not covered here. Information on security of each protocol referred to by this memo is provided in the preceding sections, and in their accompanying documentation. HTTP security is discussed in section 15 of RFC2616[1], the HTTP/1.1 specification, and to a lesser extent in RFC1945[6], the HTTP/1.0 specification. RFC2616 contains security considerations for HTTP proxies. Caching proxies have the same security issues as other application level proxies. Application level proxies are not covered in these security considerations. IP number based authentication is problematic when a proxy is involved in the communications. Details are not discussed here. 9.1 Authentication Requests for web resources, and responses to such requests, may be directed to replicas and/or may flow through intermediate proxies. The integrity of communication needs to be preserved to ensure protection from both loss of access and from unintended change. 9.1.1 Man in the middle attacks HTTP proxies are men-in-the-middle, the perfect place for a man-in-the-middle-attack. A discussion of this is found in section 15 of RFC2616[1]. 9.1.2 Trusted third party A proxy must either be trusted to act on behalf of the origin server and/or client, or it must act as a tunnel. When presenting cached objects to clients, the clients need to trust the caching proxy to act on behalf on the origin server. A replica may get accreditation from the origin server. 9.1.3 Authentication based on IP number Authentication based on the client's IP number is problematic when connecting through a proxy, since the authenticating device only has Cooper, et. al. Expires May 23, 2001 [Page 29] Internet-Draft WREC Taxonomy November 2000 access to the proxy's IP number. One (problematic) solution to this is for the proxy to spoof the client's IP number for inbound requests. Authentication based on IP number assumes that the end-to-end properties of the Internet are preserved. This is typically not the case for environments containing interception proxies. 9.2 Privacy 9.2.1 Trusted third party When using a replication service, one must trust both the replica origin server and the replica selection system. Redirection of traffic - either by automated replica selection methods, or within proxies - may introduce third parties the end user and/or origin server must to trust. In the case of interception proxies, such third parties are often unknown to both end points of the communication. Unknown third parties may have security implications. Both proxies and replica selection services may have access to aggregated access information. A proxy typically knows about accesses by each client using it, information that is more sensitive than the information held by a single origin server. 9.2.2 Logs and legal implications Logs from proxies should be kept secure, since they provide information about users and their patterns of behaviour. A proxy's log is even more sensitive than a web server log, as every request from the user population goes through the proxy. Logs from replica origin servers may need to be amalgamated to get aggregated statistics from a service, and transporting logs across borders may have legal implications. Log handling is restricted by law in some countries. Requirements for object security and privacy are the same in a web replication and caching system as it is in the Internet at large. The only reliable solution is strong cryptography. End-to-end encryption frequently makes resources uncacheable, as in the case of SSL encrypted web sessions. 9.3 Service security Cooper, et. al. Expires May 23, 2001 [Page 30] Internet-Draft WREC Taxonomy November 2000 9.3.1 Denial of service Any redirection of traffic is susceptible to denial of service attacks at the redirect point, and both proxies and replica selection services may redirect traffic. By attacking a proxy, access to all servers may be denied for a large set of clients. It has been argued that introduction of an interception proxy is a denial of service attack, since the end-to-end nature of the Internet is destroyed without the content consumer's knowledge. 9.3.2 Replay attack A caching proxy is by definition a replay attack. 9.3.3 Stupid configuration of proxies It is quite easy to have a stupid configuration which will harm service for content consumers. This is the most common security problem with proxies. 9.3.4 Copyrighted transient copies The legislative forces of the world are considering the question of transient copies, like those kept in replication and caching system, being legal. The legal implications of replication and caching are subject to local law. Caching proxies need to preserve the protocol output, including headers. Replication services need to preserve the source of the objects. 9.3.5 Application level access Caching proxies are application level components in the traffic flow path, and may give intruders access to information that was previously only available at the network level in a proxy-free world. Some network level equipment may have required physical access to get sensitive information. Introduction of application level components may require additional system security. Cooper, et. al. Expires May 23, 2001 [Page 31] Internet-Draft WREC Taxonomy November 2000 10. Acknowledgements The editors would like to thank the following for their assistance: David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley, Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry Masinter, Keith Moore, Roy Fielding, Patrick Faltstrom, Hilarie Orman, Mark Nottingham and Oskar Batuner. Cooper, et. al. Expires May 23, 2001 [Page 32] Internet-Draft WREC Taxonomy November 2000 References [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997. [3] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997. [4] Postel, J. and J.K. Reynolds, "File Transfer Protocol (FTP)", RFC 959, Oct 1985. [5] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol", RFC 1436, Mar 1993. [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [7] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [8] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [9] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000. [10] Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of ACM SIGCOMM'98 pp. 254-265, September 1998. [11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [12] Netscape, Inc., "Navigator Proxy Auto-Config File Format", March 1996, . [13] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web Proxy Auto-Discovery Protocol", draft-ietf-wrec-wpad-01.txt (work in progress), July 1999. [14] Valloppillil, V. and K.W. Ross, "Cache Array Routing Protocol", draft-vinod-carp-v1-03.txt (work in progress), Cooper, et. al. Expires May 23, 2001 [Page 33] Internet-Draft WREC Taxonomy November 2000 February 1998. [15] Microsoft Corporation, "Cache Array Routing Protocol (CARP) v1.0 Specifications, Technical Whitepaper", August 1999, . [16] Microsoft Corporation, "Cache Array Routing Protocol and Microsoft Proxy Server 2.0, Technical Whitepaper", August 1998, . [17] Lovric, I., "Internet Cache Protocol Extension", draft-lovric-icp-ext-02.txt (work in progress), October 1999. [18] Cieslak, M. and D. Forster, "Cisco Web Cache Coordination Protocol V1.0", draft-ietf-wrec-web-pro-00.txt (work in progress), June 1999. [19] Cieslak, M., Forster, D., Tiwana, G. and R. Wilson, "Cisco Web Cache Coordination Protocol V2.0", draft-wilson-wrec-wccp-v2-00.txt (work in progress), July 2000. [20] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", draft-lovric-francetelecom-satellites-01.txt (work in progress), February 2000. [21] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest specification - version 5", December 1998, . [22] Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson, "NECP: The Network Element Control Protocol", draft-cerpa-necp-02.txt (work in progress), February 2000. [23] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems", draft-ietf-wrec-known-prob-03.txt (work in progress), November 2000. Authors' Addresses Ian Cooper Equinix EMail: icooper@equinix.com Cooper, et. al. Expires May 23, 2001 [Page 34] Internet-Draft WREC Taxonomy November 2000 Ingrid Melve UNINETT Tempeveien 22 Trondheim N-7465 Norway Phone: +47 73 55 79 07 EMail: Ingrid.Melve@uninett.no Gary Tomlinson Entera, Inc. 40971 Encyclopedia Circle Freemont, CA 94538 USA Phone: +1 510 580 3726 EMail: garyt@entera.com Cooper, et. al. Expires May 23, 2001 [Page 35] Internet-Draft WREC Taxonomy November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cooper, et. al. Expires May 23, 2001 [Page 36] --=====================_75800996==_-- From owner-wrec@cs.utk.edu Mon Nov 27 15:37:13 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28657 for ; Mon, 27 Nov 2000 15:37:13 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA16818; Mon, 27 Nov 2000 15:36:36 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 27 Nov 2000 15:36:17 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA16766; Mon, 27 Nov 2000 15:36:16 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA16744; Mon, 27 Nov 2000 15:36:09 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 27 Nov 2000 15:36:09 -0500 Received: from dli2-nt (dhcp-10-34-17-66.cisco.com [10.34.17.66]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA27766; Mon, 27 Nov 2000 12:35:30 -0800 (PST) Message-Id: <4.2.0.58.20001127122451.02338d50@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 27 Nov 2000 12:35:49 -0800 To: Ian Cooper , Mark Nottingham From: Dan Li Subject: informal meeting on cache invalidation etc. Cc: wrec@cs.utk.edu, Pei Cao , mike Dahlin In-Reply-To: <5.0.2.1.2.20001122163935.00ac3e70@nemo.corp.equinix.com> References: <4.2.0.58.20001122161420.02a83990@omega> <20001122160710.H16663@akamai.com> <4.2.0.58.20001112204854.00c9a4e0@omega> <4.2.0.58.20001112204854.00c9a4e0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Hi, we don't have much time in wrec to have technical discussions, so I'll schedule an informal discussion on wcip, docp, beep etc. work on Tuesday morning (and perhaps in the evening after the wrec meeting), for people interested in this work. Let me know if you think this is a good idea and whether the time works for you. I will figure out a rendezvous place. Thanks! Dan From owner-wrec@cs.utk.edu Mon Nov 27 16:22:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09369 for ; Mon, 27 Nov 2000 16:22:50 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA23610; Mon, 27 Nov 2000 16:22:35 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 27 Nov 2000 16:22:25 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA23518; Mon, 27 Nov 2000 16:22:24 -0500 (EST) Received: from market.ffnet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA23464; Mon, 27 Nov 2000 16:22:18 -0500 (EST) From: Received: from market.ffnet.com (208.176.6.221 -> w221.z208176006.sjc-ca.dsl.cnc.net) by cs.utk.edu (smtpshim v1.0); Mon, 27 Nov 2000 16:22:19 -0500 Received: by market.ffnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 13:25:25 -0800 Message-ID: <485CD88F337799449852DFED2A3BB7DC025008@beach> To: wrec@cs.utk.edu Date: Mon, 27 Nov 2000 13:22:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C058B8.1967E580" List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C058B8.1967E580 Content-Type: text/plain; charset="iso-8859-1" lists ------_=_NextPart_001_01C058B8.1967E580 Content-Type: text/html; charset="iso-8859-1"

lists

------_=_NextPart_001_01C058B8.1967E580-- From owner-wrec@cs.utk.edu Tue Nov 28 00:04:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13882 for ; Tue, 28 Nov 2000 00:04:21 -0500 (EST) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA08834; Tue, 28 Nov 2000 00:04:03 -0500 (EST) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 28 Nov 2000 00:02:39 -0500 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA08763; Tue, 28 Nov 2000 00:02:38 -0500 (EST) Received: from cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA08737; Tue, 28 Nov 2000 00:02:32 -0500 (EST) Received: from cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 28 Nov 2000 00:02:32 -0500 Received: from lgregoir-nt2 (richvill-dsl3.cisco.com [10.19.134.124]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA15269; Mon, 27 Nov 2000 21:01:58 -0800 (PST) Message-Id: <4.2.0.58.20001127210053.02378220@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 27 Nov 2000 21:06:01 -0800 To: Mark Nottingham From: Dan Li Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt Cc: Ian Cooper , wrec@cs.utk.edu In-Reply-To: <20001120183159.K876@akamai.com> References: <4.2.0.58.20001115123617.02270ab0@omega> <5.0.0.25.2.20001115081050.00a99e20@nemo.corp.equinix.com> <4.2.0.58.20001115123617.02270ab0@omega> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 06:32 PM 11/20/00 -0800, Mark Nottingham wrote: >* Transport - WCIP seems to use a hodge-podge of transports, including HTTP, > a yet-to-be-described TCP protocol, and multicast. I'd argue that there > should be one transport, or at most two, if multicast is really necessary. Did anyone have experience with TIBCO/Rendezvous software (or Globalcast's software, for that matter). They seem to provide reliable multicast messaging, a publisher/subscriber model. Could be a transport for cache invalidation etc. I'd like to first understand their wide-area-network implications, e.g., latency, scalability. Also, the performance of fine-grained message filtering. Any input? Dan > I'm personally doubtful about using multicast, both because of its poor > deployment and the fact that it requires specifying two separate models > for using WCIP. It should be noted that I'm not exactly familiar with the > issues in multicast, but then again IETF is full of people who are, so > hopefully this issue can be sorted soon. > > I'd very much like BXXP to be addedd to the list of possible components to > reuse (in design issues). It's a much more functional, clean and > extensible framework than HTTP, from what little I know. > >Cheers, > > > > > >On Wed, Nov 15, 2000 at 12:57:41PM -0800, Dan Li wrote: > > Hi, please take a look of the WCIP draft before the IETF meeting, as we'd > > spend time on issue discussions and won't cover the draft in detail. This > > draft is a strawman, at least the following things need more work: > > > > - clearly define the relationship of wcip with normal cache-control > directives. > > > > - specify in more detail the role of relay point, especially for channel > > aggregation. Can we or can we not aggregate heartbeats, possibly but > > cutting freshness guarantee. > > > > - pick a security model. Use SSL, or PGP signature, or both, and also the > > security of the channel info. > > > > - do we need a default port number? pros and cons wrt. to port 80. > > > > - are people happy with persistent TCP connection? are people happy with > > "delta consistency" (vs. eventual consistency, strong consistency, or > > anything else). > > > > - in the absence of a off-the-shelf realtime reliable multicast protocol, > > can we still run wcip on multicast UDP for scalability. See section 3.2.3. > > > > - preloading, log reporting, advanced event notification, programability, > > ... future stuff on vertical peering and dynamic content > > > > What do people think? > > > > Dan > > > > > > > > > > > > At 08:12 AM 11/15/00 -0800, Ian Cooper wrote: > > > > >>To: IETF-Announce: ; > > >>From: Internet-Drafts@ietf.org > > >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt > > >>Date: Wed, 15 Nov 2000 06:41:12 -0500 > > >> > > >>A New Internet-Draft is available from the on-line Internet-Drafts > > >>directories. > > >> > > >> > > >> Title : WCIP: Web Cache Invalidation Protocol > > >> Author(s) : D. Li, P. Cao, M. Dahlin > > >> Filename : draft-danli-wrec-wcip-00.txt > > >> Pages : 26 > > >> Date : 14-Nov-00 > > >> > > >>Cache consistency is a major impediment to scalable content > > >>delivery. This document describes the Web Cache Invalidation > > >>Protocol (WCIP) which uses invalidations and updates to keep > > >>changing objects up to date in web caches. Moreover, it allows > > >>automatic one-to-may relay and many-to-one aggregation in a CDN > > >>(content delivery network) environment. > > >> > > >>A URL for this Internet-Draft is: > > >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >>Internet-Drafts are also available by anonymous FTP. Login with the > username > > >>"anonymous" and a password of your e-mail address. After logging in, > > >>type "cd internet-drafts" and then > > >> "get draft-danli-wrec-wcip-00.txt". > > >> > > >>A list of Internet-Drafts directories can be found in > > >>http://www.ietf.org/shadow.html > > >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >> > > >> > > >>Internet-Drafts can also be obtained by e-mail. > > >> > > >>Send a message to: > > >> mailserv@ietf.org. > > >>In the body type: > > >> "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt". > > >> > > >>NOTE: The mail server at ietf.org can return the document in > > >> MIME-encoded form by using the "mpack" utility. To use this > > >> feature, insert the command "ENCODING mime" before the "FILE" > > >> command. To decode the response(s), you will need "munpack" or > > >> a MIME-compliant mail reader. Different MIME-compliant mail > readers > > >> exhibit different behavior, especially when dealing with > > >> "multipart" MIME messages (i.e. documents which have been split > > >> up into multiple messages), so check your local documentation on > > >> how to manipulate these messages. > > >> > > >> > > >>Below is the data which will enable a MIME compliant mail reader > > >>implementation to automatically retrieve the ASCII version of the > > >>Internet-Draft. > > >> > > >>Content-Type: text/plain > > >>Content-ID: <20001114131241.I-D@ietf.org> > > >> > > >>ENCODING mime > > >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt > > >> > > >> > > > > >-- >Mark Nottingham, Research Scientist >Akamai Technologies (San Mateo, CA)