From diffserv-admin@ietf.org Wed Jan 5 01:25:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17964 for ; Wed, 5 Jan 2000 01:25:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA15854; Wed, 5 Jan 2000 00:37:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA15827 for ; Wed, 5 Jan 2000 00:36:58 -0500 (EST) Received: from giasbm01.vsnl.net.in (giasbm01.vsnl.net.in [202.54.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15983 for ; Wed, 5 Jan 2000 00:37:56 -0500 (EST) Received: from hyd.chiplogic.com ([203.197.21.23]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id LAA11505 for ; Wed, 5 Jan 2000 11:07:34 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id KAA02450 for ; Wed, 5 Jan 2000 10:07:32 +0530 Message-ID: <3872CCD3.BC037214@chiplogic.com> Date: Wed, 05 Jan 2000 10:17:15 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] AF shaping for interior routers Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, I have one basic question regarding shaping in the case of AF. I think shaping is needed at ingress interface for Edge routers, correct me if I am wrong. Do we need shaping at ingress interface for interior routers? Sreeni. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 5 07:07:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02000 for ; Wed, 5 Jan 2000 07:07:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA00870; Wed, 5 Jan 2000 05:38:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA00837 for ; Wed, 5 Jan 2000 05:38:26 -0500 (EST) Received: from giasbm01.vsnl.net.in (giasbm01.vsnl.net.in [202.54.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00757 for ; Wed, 5 Jan 2000 05:39:11 -0500 (EST) Received: from hyd.chiplogic.com ([203.197.21.23]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id QAA04850 for ; Wed, 5 Jan 2000 16:09:04 +0530 (IST) Received: from chiplogic.com ([192.168.2.51]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id OAA07305 for ; Wed, 5 Jan 2000 14:42:40 +0530 Message-ID: <38730CDC.64DD995D@chiplogic.com> Date: Wed, 05 Jan 2000 14:50:28 +0530 From: Sriphaneesh Organization: Chiplogic (I) Pvt. Ltd. X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "diffserv@ietf.org" Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Differences between edge & interior router Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm new to this group. I've gone thru some of the related drafts and RFCs. After all I came to you along some doubts. Could you clarify my doubts. What is the difference between the edge and interior router's functionality? What my understanding is... in the edge router conditioning (metering, remarking, shaping and dropping) has to be done according to customer and provider SLA. Where as in interior router, that much complexity will not be there. Actually my doubt is... what are the various components of the conditioner and their functionality in case of EF and AF trffic in the interior router where there is no scope to SLA. Thanks, Phani. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 5 11:02:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08818 for ; Wed, 5 Jan 2000 11:02:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA06427; Wed, 5 Jan 2000 09:30:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA06396 for ; Wed, 5 Jan 2000 09:30:36 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05730 for ; Wed, 5 Jan 2000 09:31:34 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA28792; Wed, 5 Jan 2000 06:31:29 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 06:31:29 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE413514F7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'ksreeni'" , IETF Subject: RE: [Diffserv] AF shaping for interior routers Date: Wed, 5 Jan 2000 06:29:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, As far as I understand, shaping should be done for EF & AF before the ingress of the edge router to comply with the SLA. Diffserv documents don't enforce shaping of EF & AF at the interior routers. However, some conclusions can be drawn implicitly. For example to be able to comply with the EF requirement of "it should average the configured rate measured over any time interval equal or greater than the time it takes to send an output link MTU sized packet at configured rate" you need to shape EF at almost every egress port of interior nodes. Also to be able to benefit from the statistical multiplexing you may want not to shape AF at the interior nodes. Hope that helps, Shahram Davari Systems Engineer, Product Research PMC-Sierra Inc. 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 > -----Original Message----- > From: ksreeni [mailto:ksreeni@chiplogic.com] > Sent: Tuesday, January 04, 2000 11:47 PM > To: IETF > Subject: [Diffserv] AF shaping for interior routers > > > Hi, > I have one basic question regarding shaping in the case of AF. > > I think shaping is needed at ingress interface for Edge routers, > correct me if I am wrong. > Do we need shaping at ingress interface for interior routers? > > > Sreeni. > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 12:51:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18073 for ; Thu, 6 Jan 2000 12:51:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25552; Thu, 6 Jan 2000 11:35:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25522 for ; Thu, 6 Jan 2000 11:35:19 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15686 for ; Thu, 6 Jan 2000 11:36:16 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id JAA01278; Thu, 6 Jan 2000 09:36:00 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA22018; Thu, 6 Jan 2000 09:35:59 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17617; Thu, 6 Jan 2000 11:28:23 -0500 (EST) Message-Id: <200001061628.LAA17617@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Shahram Davari cc: "'Dan Grossman'" , Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) In-reply-to: Your message of "Fri, 24 Dec 1999 07:43:17 EST." <336ECDAFDF7DD311B9E30090277AEE413514CB@nt-exchange-bby.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jan 2000 11:28:23 -0500 From: Dan Grossman Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > 1) Although you mention that a FIFO is identified by its depth, > threshold,... But in your FIFO examples there is no Depth parameter. So I > suggest adding it to the example. The depth is a variable, not a configuration parameter. I'll add clarifying text. > > 2) You mention that a FIFO can have more than one input. I think if there > are more that one inputs, then there should be another element (i.e., > scheduler elements such as FCFS or MUX) before the FIFO. So I suggest > changing the text to "A FIFO has one input and one output, but if more that > one input are required for a FIFO they have to pass through a scheduler > element". > I thought about this and don't agree. It would be common, for example to have more than one classifier feeding the same queue. If the flow of packets is assumed to be serial, there is no scheduler element required. > 3) I think your "priority" part requires some work. I will try to work on > it. I've incorporated Andrew's text. Hope that works for you. Will send the updated text to the list shortly. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 12:52:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18092 for ; Thu, 6 Jan 2000 12:52:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25997; Thu, 6 Jan 2000 11:50:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25968 for ; Thu, 6 Jan 2000 11:50:50 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16092 for ; Thu, 6 Jan 2000 11:51:47 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id IAA05501; Thu, 6 Jan 2000 08:51:36 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 08:51:36 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351507@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Dan Grossman'" , Shahram Davari Cc: Andrew Smith , diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 08:49:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Dan, Please see comments: > -----Original Message----- > From: Dan Grossman [mailto:dan@noah.dma.isg.mot.com] > Sent: Thursday, January 06, 2000 11:28 AM > To: Shahram Davari > Cc: 'Dan Grossman'; Andrew Smith; diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues (second draft) > > > > 1) Although you mention that a FIFO is identified by its depth, > > threshold,... But in your FIFO examples there is no Depth > parameter. So I > > suggest adding it to the example. > The depth is a variable, not a configuration parameter. I'll > add clarifying > text. Agreed. My mistake, I was thinking about the MAX-depth, which of course can be configured using one of the thresholds. > > > > 2) You mention that a FIFO can have more than one input. I > think if there > > are more that one inputs, then there should be another > element (i.e., > > scheduler elements such as FCFS or MUX) before the FIFO. So > I suggest > > changing the text to "A FIFO has one input and one output, > but if more that > > one input are required for a FIFO they have to pass through > a scheduler > > element". > > > I thought about this and don't agree. It would be common, > for example to have > more than one classifier feeding the same queue. If the flow > of packets is > assumed to be serial, there is no scheduler element required. In case of serial packet flow, the multiple inputs can be directly connected to a single line like following: In1 -------| In2 -------|-------> FIFO ----> In3 -------| So I think there is no need to include this as part of the FIFO model, because it will generate confusion in case of non-serial packet flows. > > 3) I think your "priority" part requires some work. I will > try to work on > > it. > I've incorporated Andrew's text. Hope that works for you. > > Will send the updated text to the list shortly. > > > Great. -Shahram _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 12:53:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18125 for ; Thu, 6 Jan 2000 12:53:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25489; Thu, 6 Jan 2000 11:34:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25460 for ; Thu, 6 Jan 2000 11:34:10 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15670 for ; Thu, 6 Jan 2000 11:35:03 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id JAA00902 for ; Thu, 6 Jan 2000 09:34:54 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA25369 for ; Thu, 6 Jan 2000 09:34:45 -0700 (MST)] Received: from dma.isg.mot.com (rushmore.dma.isg.mot.com [150.21.50.33]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17774 for ; Thu, 6 Jan 2000 11:34:45 -0500 (EST) Message-Id: <200001061634.LAA17774@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jan 2000 11:34:45 -0500 From: Dan Grossman Subject: [Diffserv] Model - queueing block text Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Happy New Year! This text incorporates Andrew's suggestions, as well as a clarification on a point raised by Shahram. At this point, we I think we should have a consensus. Would the chairs do a consensus check and (assuming no further issues) ask the model authors to incorporate it into the model draft? Dan ------------ Add (somewhere) "Specific policy objectives are presumed to be installed by or retrieved from policy management mechanisms. However, diffserv routers are subject to implementation decisions which form a meta-policy that scopes the kinds of policies which can be created. 6.6 [Delete] 7. Queueing block The queueing block modulates the transmission of packets belonging to the different traffic streams and determines their ordering, possibly storing them temporarily or discarding them. Packets are usually stored either because there is a resource constraint (e.g., available bandwidth) which prevents immediate forwarding, or because the queueing block is being used to alter the temporal properties of a traffic stream (i.e., shaping). Packets are discarded either because of buffering limitations, because a buffer threshold is exceeded (including when shaping is performed), as a feedback control signal to reactive control protocols such as TCP, because a meter exceeds a configured rate (i.e., policing). The queueing block in this model is a logical abstraction of a queueing system, which is used to configure PHB-related parameters. There is no conformance to this model. The model can be used to represent a broad variety of possible implementations. However, it need not necessarily map one-to-one with physical queueing systems in a specific router implementation. Implementors should map the configurable parameters of the implementation's queueing systems to these queueing block parameters as appropriate to achieve equivalent behaviors. 7.1 Model Queuing is a function a which lends itself to innovation. It must be modelled to allow a broad range of possible implementations to be represented using common structures and parameters. This model uses functional decomposition as a tool to permit the needed lattitude. Queueing sytems, such as the queueing block defined in this model, perform three distinct, but related, functions: they store packets, they modulate the departure of packets belonging to various traffic streams and they selectively discard packets. This model decomposes the queueing block into the component elements that perform each of these functions. These elements which may be connected together either dynamically or statically to construct queueing blocks. A queuing block is thus composed of of one or more FIFO, one or more scheduler, and one or more discarder. See figure TBA for an example of a queueing block. Note that the term FIFO is overloaded (i.e., has more than one meaning). In common usage it is taken to mean, among other things, a data structure that permits items to be removed only in the order in which they were inserted, and a service discipline which is non-reordering. 7.1.1 FIFO A FIFO element is a data structure which at any time may contain zero or more packets. It may have one or more threshold associated with it. A FIFO has one or more inputs and exactly one output. It must support an enqueue operation to add a packet to the tail of the queue, and a dequeue operation to remove a packet from the head of the queue. Packets must be dequeued in the order in which they were enqueued. A FIFO has a depth, which indicates the number of packets that it contains at a particular time; this is a traffic dependent variable and not used to configure a FIFO. Typically, the FIFO element of this model will be implemented as a FIFO data structure. However, this does not preclude implementations which are not strictly FIFO, in that they also support operations that remove or examine packets (e.g., for use by discarders) other than at the tail. However, such operations MUST NOT have the effect of reordering packets belonging to the same microflow. In an implementation, packets are presumably stored in one or more buffer. Buffers are allocated from one or more free buffer pool. If there are multiple instances of a FIFO, their packet buffers may or may not be allocated out of the same free buffer pool. Free buffer pools may also have one or more threshold associated with them, which may affect discarding and/or scheduling. Otherwise, buffering mechanisms are implementation specific and not part of this model. A FIFO might be represented using the following parameters: FIFO1: Type: FIFO Input: QueuingBlock.input1 Output: Discarder2 Threshold1: 3 packets Another FIFO may be represented using the following parameters: FIFO2: Type: FIFO Input: Discarder1 Output: Scheduler1 Threshold1: 3 packets Threshold2: 1000 octets Threshold3: 10 packets Threshold4: 2000 octets 7.1.2 Scheduler A scheduler is an element which gates the departure of each packet that arrives at one of its inputs, based on a service discipline. It has one or more input and exactly one output. Each input has an upstream element to which it is connected, and a set of parameters that affects the scheduling of packets received at that input. The service discipline (also known as a scheduling algorithm) is an algorithm which may take as its inputs static parameters (such as relative priority, and/or absolute token bucket parameters for maximum or minimum rates) associated with each of the scheduler's inputs; parameters (such as packet length or DSCP) associated with the packet present at its input; absolute time and/or local state. Possible service disciplines fall into a number of categories, including (but not limited to) first come, first served (FCFS), strict priority, weighted fair bandwidth sharing (e.g., WFQ, WRR, etc.), rate-limited strict priority, and rate-based. Service disciplines can be further distinguished by whether they are work conserving or non-work conserving. A work conserving service discipline transmits a packet at every transmission opportunity if one is available. A non-work conserving service discipline transmits packets no sooner than a scheduled departure time, even if it means leaving packets in a FIFO while the link is idle. Non-work conserving schedulers can be used to shape traffic streams by delaying packets that would be deemed non-conforming by some traffic profile. The packet is delayed until such time as it would conform to a meter using the same profile. [DSARCH] defines PHBs without specifying required scheduling algorithms. However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have configuration parameters which strongly suggest the sort of scheduling discipline needed to implement them. This memo specifies a minimal set of queue parameters to enable realization of these per- hop behaviors. These include a minimum service rate profile, a service priority and a maximum service rate profile (the latter is for use only with a non-work conserving service discipline). The minimum service rate allows rate guarantees for each traffic stream as required by EF and AF without specifying the details of how excess bandwidth between these traffic streams is shared. Additional parameters to control this behavior should be made available, but are dependent on the particular scheduling algorithm implemented. The service priority is used only after the MinRateProfiles of all inputs have been satisfied in order to decide how to allocate any remaining bandwidth. It is useful for implementing, for example, the EF PHB, using a strict priority scheduling algorithm on some links, assuming that the aggregate EF rate has been appropriately bounded to avoid starvation: for this scheduler the MinRateProfile would be reported as zero and the MaxRateProfile reported as line rate.Setting the service priority of each input to the scheduler to the same value enables the scheduler to satisfy the minimum service rates for each input, so long as the sum of all minimum service rates is less than or equal to the line rate." A non-work conserving scheduler might be represented using the following parameters: Scheduler1: Type: Scheduler Input1: Discarder1 MaxRateProfile: Profile1 MinRateProfile: Profile2 Priority: None Input2: Discarder1 MaxRateProfile: Profile3 MinRateProfile: Profile4 Priority: None A work conserving scheduler might be represented using the following parameters: Scheduler2: Type: Scheduler Input1: Scheduler1, MaxRateProfile: WorkConserving MinRateProfile: Profile5 Priority: 1 Input2: FIFO2 MaxRateProfile: WorkConserving MinRateProfile: Profile6 Priority: 2 Input3: FIFO3 MaxRateProfile: WorkConserving MinRateProfile: None Priority: 3 7.1.3 Discarder A discarder is an element which selectively discards packets that arrive at its input, based on a discarding discipline. It has one input and one output. In this model (but not necessarily in a real implementation), a packet enters the discarder at the input, and either its buffer is returned to a free buffer pool or it exits the discarder at the output. Alternatively, a discarder may invoke operations on a FIFO which selectively remove packets, then return those packets to the free buffer pool, based on a discarding discipline. In this case, the discarder's operation is modelled as a side-effect on the FIFO upon which it operates, rather than as having a discrete input and output. A discarder has a trigger that causes the discarder to make a decision whether or not to drop one (or possibly more than one) packet. The trigger may internal (i.e., the arrival of a packet at the input to the discarder), or it may be external (i.e., resulting from one or more state change at another element, such as a FIFO depth exceeding a threshold or a scheduling event). A trigger may be a boolean combination of events (e.g., a FIFO depth exceeding a threshold OR a buffer pool depth falling below a threshold). The discarding discipline is an algorithm which makes a decision to forward or discard a packet. It takes as its parameters some set of dynamic parameters (e.g., averaged or instantaneous FIFO depth) and some set of static parameters (e.g. thresholds) and possibly parameters associated with the packet (e.g. its PHB, as determined by a classifier). It may also have internal state. RED, RIO, and drop-on-threhold are examples of a discarding discipline. Tail dropping and head dropping are effected by the location of the discarder relative to the FIFO. Note that although a discarder may need to examine the DSCP or possibly other fields in a packet, it may not modify them (i.e., it is not a marker). A discarder might be represented using the following parameters: Discarder1: Type: Discarder Trigger: Internal Input: QueuingBlock.input2 Output: FIFO1 Discipline: RIO Parameters: In-MinTh: FIFO1.Threshold1 In-MaxTh: FIFO1.Threshold2 Out-Minth: FIFO1.Threshold3 Out-Maxth: FIFO1.Threshold4 InClassification: AFx1_PHB OutClassifcation: AFx2_PHB W_q .002 Max_p .01 Another discarder might be represented using the following parameters: Discarder2: Type: Discarder Trigger: Input: FIFO2 Output: Scheduler1.input1 Discipline: Drop-on-threshold Parameters: Threshold FIFO2.Threshold1 Yet another discarder (not part of the example) might be represented with the following parameters: Discarder3: Type: Discarder Operate_on FIFO3 Trigger: FIFO3.depth > 100 packets Discipline: Drop-all-out-packets Parameters: Out-DSCP: AFx2_recommended_DSCP | AFx3_recommended_DSCP 7.1.4 Constructing queueing blocks from the elements A queuing block is constructed by concatenation of these elements so as to meet the meta-policy objectives of the implementation, subject to the grammar rules specified in this section. Elements of the same type may appear more than once in a queueing block, either in parallel or in series. Typically, a queuing block will have relatively many elements in parallel and few in series. Iteration and recursion are not supported constructs in this grammar. A queuing block must have at least one FIFO, at least one discarder, and at least one scheduler. The following connections are allowed: The input of a FIFO may be the input of the queueing block, or it may be connected to the output of a discarder or to an output of a scheduler. Each input of a scheduler may be connected to the output of a FIFO, to the output of a discarder or to the output of another scheduler. The input of a discarder may be the input of the queue, or it may be connected to the output of a FIFO (e.g., head dropping). The output of the queueing block may be the output of a FIFO element, a discarding element or a scheduling element. Note, in particular, that schedulers may operate in series such that a packet at the head of a FIFO feeding the concatenated schedulers is serviced only after all of the scheduling criteria are met. For example, a FIFO which carries EF traffic streams may be served first by a non-work conserving scheduler to shape the stream to a maximum rate, then by a work conserving scheduler to mix EF traffic streams with other traffic streams. Alternatively, there might be a FIFO and/or a discarder between the two schedulers. 7.2 Shaping Traffic shaping is often used to condition traffic such that packets will be deemed conforming by subsequent meters, e.g., in downstream Diffserv nodes. Shaping may also be used to isolate certain traffic streams from the effects of other traffic streams of the same BA. A shaper is realized in this model by using a non-work conserving scheduler. Some implementations may elect to have queues whose sole purpose is shaping, while others may integrate the shaping function with other buffering, discarding and scheduling associated with access to a resource. Shapers operate by delaying the departure of packets that would be deemed non-conforming by a meter configured to the shaper's maximum service rate profile. The packet is scheduled to depart no sooner than such time that it would become conforming. ------- End of Forwarded Message _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 13:45:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19467 for ; Thu, 6 Jan 2000 13:45:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28321; Thu, 6 Jan 2000 12:53:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28288 for ; Thu, 6 Jan 2000 12:53:09 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18163 for ; Thu, 6 Jan 2000 12:54:09 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jan 6 12:53:13 EST 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA04599; Thu, 6 Jan 2000 12:53:09 -0500 (EST) Message-ID: <3874D717.E7845051@dnrc.bell-labs.com> Date: Thu, 06 Jan 2000 09:55:35 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <200001061628.LAA17617@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > > 2) You mention that a FIFO can have more than one input. I think if there > > are more that one inputs, then there should be another element (i.e., > > scheduler elements such as FCFS or MUX) before the FIFO. So I suggest > > changing the text to "A FIFO has one input and one output, but if more that > > one input are required for a FIFO they have to pass through a scheduler > > element". > > > I thought about this and don't agree. It would be common, for example to have > more than one classifier feeding the same queue. If the flow of packets is > assumed to be serial, there is no scheduler element required. Dan, I think I agree with Shahram's observation here. If we assume the packets arrive serially from the outputs of preceding classifiers then the merging (aka 'multiple inputs') isn't really an attribute of the queue/buffering stage - its a simple 'OR' function of multiple streams of packets, which might happen anywhere prior to the FIFO. At the very least, add text clarifying the assumption that the multiple inputs are in fact being fed by synchronized packet streams (i.e. synchronized to have non-overlapping arrival times at the FIFO input{s} ) cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 14:54:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21161 for ; Thu, 6 Jan 2000 14:54:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29926; Thu, 6 Jan 2000 13:47:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29892 for ; Thu, 6 Jan 2000 13:47:20 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19503 for ; Thu, 6 Jan 2000 13:48:22 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 10:47:59 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC397@SOL> From: Andrew Smith To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 10:47:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Grenville, I think that's implicit in the concept of a packet FIFO: I think the way packets from multiple sources make their way into the FIFO *is* an attribute of the FIFO queueing stage. If the FIFO worked on units of less than one packet (e.g. 53-byte chunks of it :-)) then, I agree, some sort of merge block might be needed. Maybe the clarification should be just the "packet" part of this: there is no smaller unit of time under consideration here than a complete packet time so the use the word "First" in "First In First Out" implies "the time at which the start of the packet arrives at the queue" (or should it be the end of the packet?). It is arguable that any definition that involves "first" or "the time at which ..." implies a scheduling stage but I think, in this case, that is splitting hairs. Andrew > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Thursday, January 06, 2000 9:56 AM > To: Dan Grossman > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > Dan Grossman wrote: > [..] > > > 2) You mention that a FIFO can have more than one input. > I think if there > > > are more that one inputs, then there should be another > element (i.e., > > > scheduler elements such as FCFS or MUX) before the FIFO. > So I suggest > > > changing the text to "A FIFO has one input and one > output, but if more that > > > one input are required for a FIFO they have to pass > through a scheduler > > > element". > > > > > I thought about this and don't agree. It would be common, > for example to have > > more than one classifier feeding the same queue. If the > flow of packets is > > assumed to be serial, there is no scheduler element required. > > Dan, I think I agree with Shahram's observation here. If we assume > the packets arrive serially from the outputs of preceding classifiers > then the merging (aka 'multiple inputs') isn't really an attribute > of the queue/buffering stage - its a simple 'OR' function of > multiple streams of packets, which might happen anywhere prior to > the FIFO. At the very least, add text clarifying > the assumption that the multiple inputs are in fact being fed > by synchronized packet streams (i.e. synchronized to have > non-overlapping arrival times at the FIFO input{s} ) > > cheers, > gja > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 14:58:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21248 for ; Thu, 6 Jan 2000 14:58:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00567; Thu, 6 Jan 2000 14:07:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00532 for ; Thu, 6 Jan 2000 14:06:56 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20053 for ; Thu, 6 Jan 2000 14:07:57 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA14617; Thu, 6 Jan 2000 11:07:43 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 11:07:43 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135150B@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrew Smith'" , "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 11:05:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Andrew, Imagine an edge router which has two Metering stages: a Microflow and an Aggregate Metering stage. Now imagine that flow A is not marked by the customer, and needs both Microflow and Aggregate metering. Also imagine flow B is already marked by the customer and needs only aggregate metering. Now if the metering stage is a parallel processing system in which flow A and B can be metered simultaneously, then it is possible for a packet from flow B to overtake a packet from flow A even if it had arrived later (because it needs less processing). So I don't think assumption of serial delivery to the FIFO is implicit in the concept of packet FIFO. -Shahram > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > Sent: Thursday, January 06, 2000 1:48 PM > To: 'Grenville Armitage' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Model - queues (second draft) > > > Grenville, > > I think that's implicit in the concept of a packet FIFO: I > think the way > packets from multiple sources make their way into the FIFO > *is* an attribute > of the FIFO queueing stage. If the FIFO worked on units of > less than one > packet (e.g. 53-byte chunks of it :-)) then, I agree, some > sort of merge > block might be needed. > > Maybe the clarification should be just the "packet" part of > this: there is > no smaller unit of time under consideration here than a > complete packet time > so the use the word "First" in "First In First Out" implies > "the time at > which the start of the packet arrives at the queue" (or > should it be the end > of the packet?). It is arguable that any definition that > involves "first" or > "the time at which ..." implies a scheduling stage but I > think, in this > case, that is splitting hairs. > > Andrew > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > Sent: Thursday, January 06, 2000 9:56 AM > > To: Dan Grossman > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > > > > > > Dan Grossman wrote: > > [..] > > > > 2) You mention that a FIFO can have more than one input. > > I think if there > > > > are more that one inputs, then there should be another > > element (i.e., > > > > scheduler elements such as FCFS or MUX) before the FIFO. > > So I suggest > > > > changing the text to "A FIFO has one input and one > > output, but if more that > > > > one input are required for a FIFO they have to pass > > through a scheduler > > > > element". > > > > > > > I thought about this and don't agree. It would be common, > > for example to have > > > more than one classifier feeding the same queue. If the > > flow of packets is > > > assumed to be serial, there is no scheduler element required. > > > > Dan, I think I agree with Shahram's observation here. If we assume > > the packets arrive serially from the outputs of preceding > classifiers > > then the merging (aka 'multiple inputs') isn't really an attribute > > of the queue/buffering stage - its a simple 'OR' function of > > multiple streams of packets, which might happen anywhere prior to > > the FIFO. At the very least, add text clarifying > > the assumption that the multiple inputs are in fact being fed > > by synchronized packet streams (i.e. synchronized to have > > non-overlapping arrival times at the FIFO input{s} ) > > > > cheers, > > gja > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 15:21:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21637 for ; Thu, 6 Jan 2000 15:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01009; Thu, 6 Jan 2000 14:23:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00978 for ; Thu, 6 Jan 2000 14:23:47 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20447 for ; Thu, 6 Jan 2000 14:24:48 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 11:24:25 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC399@SOL> From: Andrew Smith To: "'Shahram Davari'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 11:24:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org OK, that's a completely different issue to what I thought you were talking about. I was answering what I understood to be Grenville's point about how to merge the outputs of the preceding stages as a combinatorial sort of thing without any state or delaying etc.. Are you saying that you need a *real* scheduler at the outputs to your microflow-metering and your aggregate-metering blocks in order to get the packets for flows A and B back into the order in which they arrived, before you place them into the FIFO? If so then I think you do need to model that as a block that has real queues and schedulers of its own, before you get to the FIFO that we were talking about (you can do this with the model as it currently is although I'm not sure it's something a manager would be interested in seeing). If not then I don't see a need for another block at this point in the path. Maybe you can explain further - I think I'm still confused about the problem that you see. Andrew > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, January 06, 2000 11:06 AM > To: 'Andrew Smith'; 'Grenville Armitage' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Model - queues (second draft) > > > Hi Andrew, > > Imagine an edge router which has two Metering stages: a > Microflow and an > Aggregate Metering stage. Now imagine that flow A is not marked by the > customer, and needs both Microflow and Aggregate metering. > Also imagine flow > B is already marked by the customer and needs only aggregate > metering. Now > if the metering stage is a parallel processing system in > which flow A and B > can be metered simultaneously, then it is possible for a > packet from flow B > to overtake a packet from flow A even if it had arrived later > (because it > needs less processing). > > So I don't think assumption of serial delivery to the FIFO is > implicit in > the concept of packet FIFO. > > -Shahram > > > -----Original Message----- > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > Sent: Thursday, January 06, 2000 1:48 PM > > To: 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > Grenville, > > > > I think that's implicit in the concept of a packet FIFO: I > > think the way > > packets from multiple sources make their way into the FIFO > > *is* an attribute > > of the FIFO queueing stage. If the FIFO worked on units of > > less than one > > packet (e.g. 53-byte chunks of it :-)) then, I agree, some > > sort of merge > > block might be needed. > > > > Maybe the clarification should be just the "packet" part of > > this: there is > > no smaller unit of time under consideration here than a > > complete packet time > > so the use the word "First" in "First In First Out" implies > > "the time at > > which the start of the packet arrives at the queue" (or > > should it be the end > > of the packet?). It is arguable that any definition that > > involves "first" or > > "the time at which ..." implies a scheduling stage but I > > think, in this > > case, that is splitting hairs. > > > > Andrew > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > Sent: Thursday, January 06, 2000 9:56 AM > > > To: Dan Grossman > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > > > > > > > > > > > Dan Grossman wrote: > > > [..] > > > > > 2) You mention that a FIFO can have more than one input. > > > I think if there > > > > > are more that one inputs, then there should be another > > > element (i.e., > > > > > scheduler elements such as FCFS or MUX) before the FIFO. > > > So I suggest > > > > > changing the text to "A FIFO has one input and one > > > output, but if more that > > > > > one input are required for a FIFO they have to pass > > > through a scheduler > > > > > element". > > > > > > > > > I thought about this and don't agree. It would be common, > > > for example to have > > > > more than one classifier feeding the same queue. If the > > > flow of packets is > > > > assumed to be serial, there is no scheduler element required. > > > > > > Dan, I think I agree with Shahram's observation here. If > we assume > > > the packets arrive serially from the outputs of preceding > > classifiers > > > then the merging (aka 'multiple inputs') isn't really an attribute > > > of the queue/buffering stage - its a simple 'OR' function of > > > multiple streams of packets, which might happen anywhere prior to > > > the FIFO. At the very least, add text clarifying > > > the assumption that the multiple inputs are in fact being fed > > > by synchronized packet streams (i.e. synchronized to have > > > non-overlapping arrival times at the FIFO input{s} ) > > > > > > cheers, > > > gja > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 15:31:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21832 for ; Thu, 6 Jan 2000 15:31:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01624; Thu, 6 Jan 2000 14:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01593 for ; Thu, 6 Jan 2000 14:44:10 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20915 for ; Thu, 6 Jan 2000 14:45:08 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id LAA17280; Thu, 6 Jan 2000 11:44:59 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 11:45:01 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135150E@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Andrew Smith'" , Shahram Davari Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 11:43:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org In the example that I described there is no need to preserve the ordering of the packets from flow A and B, because they belong to different microflows, but there is a possibility that they collide at the input of the FIFO (i.e., output of the Meter). So either a kind of FCFS Muxing, or a scheduler or some speed-up is required. I think if you mention in your model that: "provided that the there is no time overlap between the packets arriving from different inputs", then it should be OK. -Shahram > -----Original Message----- > From: Andrew Smith [mailto:andrew@extremenetworks.com] > Sent: Thursday, January 06, 2000 2:24 PM > To: 'Shahram Davari' > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Model - queues (second draft) > > > OK, that's a completely different issue to what I thought you > were talking > about. I was answering what I understood to be Grenville's > point about how > to merge the outputs of the preceding stages as a > combinatorial sort of > thing without any state or delaying etc.. > > Are you saying that you need a *real* scheduler at the outputs to your > microflow-metering and your aggregate-metering blocks in > order to get the > packets for flows A and B back into the order in which they > arrived, before > you place them into the FIFO? If so then I think you do need > to model that > as a block that has real queues and schedulers of its own, > before you get to > the FIFO that we were talking about (you can do this with the > model as it > currently is although I'm not sure it's something a manager would be > interested in seeing). If not then I don't see a need for > another block at > this point in the path. > > Maybe you can explain further - I think I'm still confused > about the problem > that you see. > > Andrew > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, January 06, 2000 11:06 AM > > To: 'Andrew Smith'; 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > Hi Andrew, > > > > Imagine an edge router which has two Metering stages: a > > Microflow and an > > Aggregate Metering stage. Now imagine that flow A is not > marked by the > > customer, and needs both Microflow and Aggregate metering. > > Also imagine flow > > B is already marked by the customer and needs only aggregate > > metering. Now > > if the metering stage is a parallel processing system in > > which flow A and B > > can be metered simultaneously, then it is possible for a > > packet from flow B > > to overtake a packet from flow A even if it had arrived later > > (because it > > needs less processing). > > > > So I don't think assumption of serial delivery to the FIFO is > > implicit in > > the concept of packet FIFO. > > > > -Shahram > > > > > -----Original Message----- > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > Sent: Thursday, January 06, 2000 1:48 PM > > > To: 'Grenville Armitage' > > > Cc: diffserv@ietf.org > > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > > > > Grenville, > > > > > > I think that's implicit in the concept of a packet FIFO: I > > > think the way > > > packets from multiple sources make their way into the FIFO > > > *is* an attribute > > > of the FIFO queueing stage. If the FIFO worked on units of > > > less than one > > > packet (e.g. 53-byte chunks of it :-)) then, I agree, some > > > sort of merge > > > block might be needed. > > > > > > Maybe the clarification should be just the "packet" part of > > > this: there is > > > no smaller unit of time under consideration here than a > > > complete packet time > > > so the use the word "First" in "First In First Out" implies > > > "the time at > > > which the start of the packet arrives at the queue" (or > > > should it be the end > > > of the packet?). It is arguable that any definition that > > > involves "first" or > > > "the time at which ..." implies a scheduling stage but I > > > think, in this > > > case, that is splitting hairs. > > > > > > Andrew > > > > > > > -----Original Message----- > > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > Sent: Thursday, January 06, 2000 9:56 AM > > > > To: Dan Grossman > > > > Cc: diffserv@ietf.org > > > > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > > > > > > > > > > > > > > > > Dan Grossman wrote: > > > > [..] > > > > > > 2) You mention that a FIFO can have more than one input. > > > > I think if there > > > > > > are more that one inputs, then there should be another > > > > element (i.e., > > > > > > scheduler elements such as FCFS or MUX) before the FIFO. > > > > So I suggest > > > > > > changing the text to "A FIFO has one input and one > > > > output, but if more that > > > > > > one input are required for a FIFO they have to pass > > > > through a scheduler > > > > > > element". > > > > > > > > > > > I thought about this and don't agree. It would be common, > > > > for example to have > > > > > more than one classifier feeding the same queue. If the > > > > flow of packets is > > > > > assumed to be serial, there is no scheduler element required. > > > > > > > > Dan, I think I agree with Shahram's observation here. If > > we assume > > > > the packets arrive serially from the outputs of preceding > > > classifiers > > > > then the merging (aka 'multiple inputs') isn't really > an attribute > > > > of the queue/buffering stage - its a simple 'OR' function of > > > > multiple streams of packets, which might happen > anywhere prior to > > > > the FIFO. At the very least, add text clarifying > > > > the assumption that the multiple inputs are in fact being fed > > > > by synchronized packet streams (i.e. synchronized to have > > > > non-overlapping arrival times at the FIFO input{s} ) > > > > > > > > cheers, > > > > gja > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 16:44:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22907 for ; Thu, 6 Jan 2000 16:44:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02624; Thu, 6 Jan 2000 15:17:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02522 for ; Thu, 6 Jan 2000 15:17:01 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21598 for ; Thu, 6 Jan 2000 15:17:56 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 12:17:29 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC39B@SOL> From: Andrew Smith To: "'Shahram Davari'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 12:17:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org OK, so I *was* answering the right question: if we define "first" as an instantaneous event then there is no possibility of overlap. I suggested that "first" be defined as the instantaneous start of a packet. Andrew > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, January 06, 2000 11:43 AM > To: 'Andrew Smith'; Shahram Davari > Cc: diffserv@ietf.org > Subject: RE: [Diffserv] Model - queues (second draft) > > > In the example that I described there is no need to preserve > the ordering of > the packets from flow A and B, because they belong to > different microflows, > but there is a possibility that they collide at the input of > the FIFO (i.e., > output of the Meter). So either a kind of FCFS Muxing, or a > scheduler or > some speed-up is required. > > I think if you mention in your model that: "provided that the > there is no > time overlap between the packets arriving from different > inputs", then it > should be OK. > > -Shahram > > > -----Original Message----- > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > Sent: Thursday, January 06, 2000 2:24 PM > > To: 'Shahram Davari' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > OK, that's a completely different issue to what I thought you > > were talking > > about. I was answering what I understood to be Grenville's > > point about how > > to merge the outputs of the preceding stages as a > > combinatorial sort of > > thing without any state or delaying etc.. > > > > Are you saying that you need a *real* scheduler at the > outputs to your > > microflow-metering and your aggregate-metering blocks in > > order to get the > > packets for flows A and B back into the order in which they > > arrived, before > > you place them into the FIFO? If so then I think you do need > > to model that > > as a block that has real queues and schedulers of its own, > > before you get to > > the FIFO that we were talking about (you can do this with the > > model as it > > currently is although I'm not sure it's something a manager would be > > interested in seeing). If not then I don't see a need for > > another block at > > this point in the path. > > > > Maybe you can explain further - I think I'm still confused > > about the problem > > that you see. > > > > Andrew > > > > > -----Original Message----- > > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > > Sent: Thursday, January 06, 2000 11:06 AM > > > To: 'Andrew Smith'; 'Grenville Armitage' > > > Cc: diffserv@ietf.org > > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > > > > Hi Andrew, > > > > > > Imagine an edge router which has two Metering stages: a > > > Microflow and an > > > Aggregate Metering stage. Now imagine that flow A is not > > marked by the > > > customer, and needs both Microflow and Aggregate metering. > > > Also imagine flow > > > B is already marked by the customer and needs only aggregate > > > metering. Now > > > if the metering stage is a parallel processing system in > > > which flow A and B > > > can be metered simultaneously, then it is possible for a > > > packet from flow B > > > to overtake a packet from flow A even if it had arrived later > > > (because it > > > needs less processing). > > > > > > So I don't think assumption of serial delivery to the FIFO is > > > implicit in > > > the concept of packet FIFO. > > > > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > > > Sent: Thursday, January 06, 2000 1:48 PM > > > > To: 'Grenville Armitage' > > > > Cc: diffserv@ietf.org > > > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > > > > > > > Grenville, > > > > > > > > I think that's implicit in the concept of a packet FIFO: I > > > > think the way > > > > packets from multiple sources make their way into the FIFO > > > > *is* an attribute > > > > of the FIFO queueing stage. If the FIFO worked on units of > > > > less than one > > > > packet (e.g. 53-byte chunks of it :-)) then, I agree, some > > > > sort of merge > > > > block might be needed. > > > > > > > > Maybe the clarification should be just the "packet" part of > > > > this: there is > > > > no smaller unit of time under consideration here than a > > > > complete packet time > > > > so the use the word "First" in "First In First Out" implies > > > > "the time at > > > > which the start of the packet arrives at the queue" (or > > > > should it be the end > > > > of the packet?). It is arguable that any definition that > > > > involves "first" or > > > > "the time at which ..." implies a scheduling stage but I > > > > think, in this > > > > case, that is splitting hairs. > > > > > > > > Andrew > > > > > > > > > -----Original Message----- > > > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > > > Sent: Thursday, January 06, 2000 9:56 AM > > > > > To: Dan Grossman > > > > > Cc: diffserv@ietf.org > > > > > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > > > > > > > > > > > > > > > > > > > > > Dan Grossman wrote: > > > > > [..] > > > > > > > 2) You mention that a FIFO can have more than one input. > > > > > I think if there > > > > > > > are more that one inputs, then there should be another > > > > > element (i.e., > > > > > > > scheduler elements such as FCFS or MUX) before the FIFO. > > > > > So I suggest > > > > > > > changing the text to "A FIFO has one input and one > > > > > output, but if more that > > > > > > > one input are required for a FIFO they have to pass > > > > > through a scheduler > > > > > > > element". > > > > > > > > > > > > > I thought about this and don't agree. It would be common, > > > > > for example to have > > > > > > more than one classifier feeding the same queue. If the > > > > > flow of packets is > > > > > > assumed to be serial, there is no scheduler element > required. > > > > > > > > > > Dan, I think I agree with Shahram's observation here. If > > > we assume > > > > > the packets arrive serially from the outputs of preceding > > > > classifiers > > > > > then the merging (aka 'multiple inputs') isn't really > > an attribute > > > > > of the queue/buffering stage - its a simple 'OR' function of > > > > > multiple streams of packets, which might happen > > anywhere prior to > > > > > the FIFO. At the very least, add text clarifying > > > > > the assumption that the multiple inputs are in fact being fed > > > > > by synchronized packet streams (i.e. synchronized to have > > > > > non-overlapping arrival times at the FIFO input{s} ) > > > > > > > > > > cheers, > > > > > gja > > > > > > > > > > _______________________________________________ > > > > > diffserv mailing list > > > > > diffserv@ietf.org > > > > > http://www.ietf.org/mailman/listinfo/diffserv > > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 16:45:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22919 for ; Thu, 6 Jan 2000 16:45:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02343; Thu, 6 Jan 2000 15:09:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02311 for ; Thu, 6 Jan 2000 15:09:10 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21529 for ; Thu, 6 Jan 2000 15:10:01 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA20941 for ; Thu, 6 Jan 2000 12:09:40 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id MAA02591 for ; Thu, 6 Jan 2000 12:09:49 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 6 Jan 2000 12:09:46 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 6 Jan 2000 15:09:43 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356ED36@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Shahram Davari'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 15:09:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Shahram Davari wrote: > In the example that I described there is no need to preserve > the ordering of > the packets from flow A and B, because they belong to > different microflows, > but there is a possibility that they collide at the input of > the FIFO (i.e., > output of the Meter). So either a kind of FCFS Muxing, or a > scheduler or > some speed-up is required. I think your example was pretty much the general case. And, in fact, each of those incoming flows could very well be at drastically different rates, which means that the general case could very well have several packets from the same incoming microflow appear consecutively at the output of the FIFO, occasionally interrupted by other intruder troublemakers. The fact that a merge point could easily introduce some amount of "clumping" among packets of any given microflow, I think, is well known. Which is why I believe we should continue to permit shaping not only at egress routers, but possibly also within the core? In any event, I don't see that a scheduler is an essential part of a FIFO when there are multiple input flows. Most data flows don't care too much about clumping. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:26:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24922 for ; Thu, 6 Jan 2000 18:26:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05662; Thu, 6 Jan 2000 17:14:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05634 for ; Thu, 6 Jan 2000 17:14:05 -0500 (EST) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23319 for ; Thu, 6 Jan 2000 17:14:58 -0500 (EST) Received: by SOL with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 14:14:31 -0800 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC39E@SOL> From: Andrew Smith To: "'Grenville Armitage'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 14:14:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org And I think that, in both cases, this is not worth pointing out in a management model. What are you as a network manager going to do differently in configurating and monitoring your network if you know about such implementation nits? We already have too many hooks for such hypothetical nits in this model. Andrew > -----Original Message----- > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > Sent: Thursday, January 06, 2000 1:57 PM > To: Andrew Smith > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues (second draft) ... > I'm stating that _IF_ the packets arriving from different > classifiers are known to have non-overlapping arrival times > into a particular FIFO's buffer stage, then the notion of > a multiple input FIFO is probably not worth pointing out. > It is a simple queue-less merge, which I dont believe is a > notable attribute of a FIFO stage per se. > > There's an alternative hypothetical case which I take to be > what triggered Shahram's observation: Consider if a router's > architecture allowed packets from multiple parallel > classifiers (heading into the FIFO's buffer) to have concurrent > or overlapping arrival times. Iff this second (more general) case > is allowed, then there has to be some element that (at least > notionally) decides which packet gets into the buffer 'first'. > Thats a scheduler. > > cheers, > gja > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:28:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24973 for ; Thu, 6 Jan 2000 18:28:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06324; Thu, 6 Jan 2000 17:32:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06289 for ; Thu, 6 Jan 2000 17:32:49 -0500 (EST) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23713 for ; Thu, 6 Jan 2000 17:33:44 -0500 (EST) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id OAA29269; Thu, 6 Jan 2000 14:33:29 -0800 (PST) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Jan 2000 14:33:30 -0800 Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351512@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" , Shahram Davari Cc: "'Andrew Smith'" , "'Grenville Armitage'" , diffserv@ietf.org Subject: RE: [Diffserv] Model - queues (second draft) Date: Thu, 6 Jan 2000 14:31:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi Brian, Since multiple input behavior can be constructed by cascading a traffic conditioning element (like MUX) in front of the input to a queue, then there is no need to include the MUX function in the definition of FIFO (it is redundant, right? -Shahram > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, January 06, 2000 5:04 PM > To: Shahram Davari > Cc: 'Andrew Smith'; 'Grenville Armitage'; diffserv@ietf.org > Subject: Re: [Diffserv] Model - queues (second draft) > > > Shahram, > > I think we agreed that elements can be cascaded; what you are > describing is > cascading traffic conditioners in front of the input to a > queue. I think we had > the notion that the input to a queue is a multiplexer rather > than a wire a > long time ago. So I think the text should make it clear that > the input to > a queue may be a multiplexer, but the queue certainly doesn't > include the > traffic conditioners feeding that multiplexer. > > Apart from this point, where we need one more spin, I'm going > to pick up > my co-chair's gavel and say that Dan's text should go into > the pending > revision of the model draft. > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:28:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24980 for ; Thu, 6 Jan 2000 18:28:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05960; Thu, 6 Jan 2000 17:25:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05930 for ; Thu, 6 Jan 2000 17:25:14 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23470 for ; Thu, 6 Jan 2000 17:26:10 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jan 6 17:24:10 EST 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA13985; Thu, 6 Jan 2000 17:24:05 -0500 (EST) Message-ID: <38751697.9E2877EA@dnrc.bell-labs.com> Date: Thu, 06 Jan 2000 14:26:31 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <808F64DDB492D3119D3C00508B5D8D733EC39E@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit if you allow concurrent packet arrivals to the FIFO's input, presumably you must allow a management hook to configure the element that arbitrates between which packet gets to go in first. perhaps that's relevant. but if one assumes packets never arrive concurrently, nothing needs to be said _at all_ about multiple inputs to the FIFO. so the management model can be simplified to only describe the FIFO as a single input element. in this case, like i said, the 'multiple inputs' is nothing more than a queue-less merge preceding the FIFO element. why mention it if its might create ambiguous interpretations later. cheers, gja Andrew Smith wrote: > > And I think that, in both cases, this is not worth pointing out in a > management model. What are you as a network manager going to do differently > in configurating and monitoring your network if you know about such > implementation nits? We already have too many hooks for such hypothetical > nits in this model. > > Andrew > > > -----Original Message----- > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > Sent: Thursday, January 06, 2000 1:57 PM > > To: Andrew Smith > > Cc: diffserv@ietf.org > > Subject: Re: [Diffserv] Model - queues (second draft) > ... > > I'm stating that _IF_ the packets arriving from different > > classifiers are known to have non-overlapping arrival times > > into a particular FIFO's buffer stage, then the notion of > > a multiple input FIFO is probably not worth pointing out. > > It is a simple queue-less merge, which I dont believe is a > > notable attribute of a FIFO stage per se. > > > > There's an alternative hypothetical case which I take to be > > what triggered Shahram's observation: Consider if a router's > > architecture allowed packets from multiple parallel > > classifiers (heading into the FIFO's buffer) to have concurrent > > or overlapping arrival times. Iff this second (more general) case > > is allowed, then there has to be some element that (at least > > notionally) decides which packet gets into the buffer 'first'. > > Thats a scheduler. > > > > cheers, > > gja > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:30:16 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25029 for ; Thu, 6 Jan 2000 18:30:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06683; Thu, 6 Jan 2000 17:42:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06655 for ; Thu, 6 Jan 2000 17:42:09 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23872 for ; Thu, 6 Jan 2000 17:43:06 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA17270; Thu, 6 Jan 2000 22:42:28 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA17814; Thu, 6 Jan 2000 22:42:26 GMT Message-ID: <387515EE.2F25581C@hursley.ibm.com> Date: Thu, 06 Jan 2000 16:23:42 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Grenville Armitage CC: Andrew Smith , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <808F64DDB492D3119D3C00508B5D8D733EC399@SOL> <38750FC2.FCF6970C@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Grenville Armitage wrote: ... > > There's an alternative hypothetical case which I take to be > what triggered Shahram's observation: Consider if a router's > architecture allowed packets from multiple parallel > classifiers (heading into the FIFO's buffer) to have concurrent > or overlapping arrival times. Iff this second (more general) case > is allowed, then there has to be some element that (at least > notionally) decides which packet gets into the buffer 'first'. > Thats a scheduler. Only if it is allowed to look ahead in time. Otherwise, the only tricky case is a race condition where the first bit of each packet arrives simultaneously. But I think this is far too detailed to cover in the model; I think we should simply observe that a FIFO may need to multiplex inputs and leave the rest to the imagination of the reader. I remind you all once again that we are not designing a router here, and conceptual models don't have to be perfect. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:35:21 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25168 for ; Thu, 6 Jan 2000 18:35:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07357; Thu, 6 Jan 2000 17:55:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07326 for ; Thu, 6 Jan 2000 17:55:11 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24229 for ; Thu, 6 Jan 2000 17:56:08 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jan 6 17:54:21 EST 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA14727; Thu, 6 Jan 2000 17:54:16 -0500 (EST) Message-ID: <38751DAA.144FA2C2@dnrc.bell-labs.com> Date: Thu, 06 Jan 2000 14:56:42 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <808F64DDB492D3119D3C00508B5D8D733EC399@SOL> <38750FC2.FCF6970C@dnrc.bell-labs.com> <387515EE.2F25581C@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: [..] > I remind you all once again that we are not designing a router > here, and conceptual models don't have to be perfect. I'd settle for un-ambiguous. It seems reasonable to reduce ambiguity by elaborating on the packet arrival assumptions in the 'multiple input' FIFO element. Or just remove references to a FIFO element having multiple inputs (I personally think _this_ description is the one being too detailed - any router designer knows they can make a single input element into a multiple input element with queue-less packet merging, no need to call it out explicitly). cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:38:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24971 for ; Thu, 6 Jan 2000 18:28:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05187; Thu, 6 Jan 2000 16:55:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05163 for ; Thu, 6 Jan 2000 16:55:20 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23035 for ; Thu, 6 Jan 2000 16:56:13 -0500 (EST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jan 6 16:55:01 EST 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA13204; Thu, 6 Jan 2000 16:54:56 -0500 (EST) Message-ID: <38750FC2.FCF6970C@dnrc.bell-labs.com> Date: Thu, 06 Jan 2000 13:57:22 -0800 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith CC: diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <808F64DDB492D3119D3C00508B5D8D733EC399@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andrew, Now that we're all happily tied up in knots.... Andrew Smith wrote: > > OK, that's a completely different issue to what I thought you were talking > about. I was answering what I understood to be Grenville's point about how > to merge the outputs of the preceding stages as a combinatorial sort of > thing without any state or delaying etc.. To clarify the words I used below: [..] > > > > Dan, I think I agree with Shahram's observation here. If > > we assume > > > > the packets arrive serially from the outputs of preceding > > > classifiers > > > > then the merging (aka 'multiple inputs') isn't really an attribute > > > > of the queue/buffering stage - its a simple 'OR' function of > > > > multiple streams of packets, which might happen anywhere prior to > > > > the FIFO. At the very least, add text clarifying > > > > the assumption that the multiple inputs are in fact being fed > > > > by synchronized packet streams (i.e. synchronized to have > > > > non-overlapping arrival times at the FIFO input{s} ) I'm stating that _IF_ the packets arriving from different classifiers are known to have non-overlapping arrival times into a particular FIFO's buffer stage, then the notion of a multiple input FIFO is probably not worth pointing out. It is a simple queue-less merge, which I dont believe is a notable attribute of a FIFO stage per se. There's an alternative hypothetical case which I take to be what triggered Shahram's observation: Consider if a router's architecture allowed packets from multiple parallel classifiers (heading into the FIFO's buffer) to have concurrent or overlapping arrival times. Iff this second (more general) case is allowed, then there has to be some element that (at least notionally) decides which packet gets into the buffer 'first'. Thats a scheduler. cheers, gja _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 6 18:38:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24923 for ; Thu, 6 Jan 2000 18:26:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05858; Thu, 6 Jan 2000 17:22:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05827 for ; Thu, 6 Jan 2000 17:21:57 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23417 for ; Thu, 6 Jan 2000 17:22:51 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA44114; Thu, 6 Jan 2000 22:22:12 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA29058; Thu, 6 Jan 2000 22:22:10 GMT Message-ID: <38751154.34A5C1AC@hursley.ibm.com> Date: Thu, 06 Jan 2000 16:04:04 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Shahram Davari CC: "'Andrew Smith'" , "'Grenville Armitage'" , diffserv@ietf.org Subject: Re: [Diffserv] Model - queues (second draft) References: <336ECDAFDF7DD311B9E30090277AEE4135150B@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Shahram, I think we agreed that elements can be cascaded; what you are describing is cascading traffic conditioners in front of the input to a queue. I think we had the notion that the input to a queue is a multiplexer rather than a wire a long time ago. So I think the text should make it clear that the input to a queue may be a multiplexer, but the queue certainly doesn't include the traffic conditioners feeding that multiplexer. Apart from this point, where we need one more spin, I'm going to pick up my co-chair's gavel and say that Dan's text should go into the pending revision of the model draft. Brian Shahram Davari wrote: > > Hi Andrew, > > Imagine an edge router which has two Metering stages: a Microflow and an > Aggregate Metering stage. Now imagine that flow A is not marked by the > customer, and needs both Microflow and Aggregate metering. Also imagine flow > B is already marked by the customer and needs only aggregate metering. Now > if the metering stage is a parallel processing system in which flow A and B > can be metered simultaneously, then it is possible for a packet from flow B > to overtake a packet from flow A even if it had arrived later (because it > needs less processing). > > So I don't think assumption of serial delivery to the FIFO is implicit in > the concept of packet FIFO. > > -Shahram > > > -----Original Message----- > > From: Andrew Smith [mailto:andrew@extremenetworks.com] > > Sent: Thursday, January 06, 2000 1:48 PM > > To: 'Grenville Armitage' > > Cc: diffserv@ietf.org > > Subject: RE: [Diffserv] Model - queues (second draft) > > > > > > Grenville, > > > > I think that's implicit in the concept of a packet FIFO: I > > think the way > > packets from multiple sources make their way into the FIFO > > *is* an attribute > > of the FIFO queueing stage. If the FIFO worked on units of > > less than one > > packet (e.g. 53-byte chunks of it :-)) then, I agree, some > > sort of merge > > block might be needed. > > > > Maybe the clarification should be just the "packet" part of > > this: there is > > no smaller unit of time under consideration here than a > > complete packet time > > so the use the word "First" in "First In First Out" implies > > "the time at > > which the start of the packet arrives at the queue" (or > > should it be the end > > of the packet?). It is arguable that any definition that > > involves "first" or > > "the time at which ..." implies a scheduling stage but I > > think, in this > > case, that is splitting hairs. > > > > Andrew > > > > > -----Original Message----- > > > From: Grenville Armitage [mailto:gja@dnrc.bell-labs.com] > > > Sent: Thursday, January 06, 2000 9:56 AM > > > To: Dan Grossman > > > Cc: diffserv@ietf.org > > > Subject: Re: [Diffserv] Model - queues (second draft) > > > > > > > > > > > > > > > Dan Grossman wrote: > > > [..] > > > > > 2) You mention that a FIFO can have more than one input. > > > I think if there > > > > > are more that one inputs, then there should be another > > > element (i.e., > > > > > scheduler elements such as FCFS or MUX) before the FIFO. > > > So I suggest > > > > > changing the text to "A FIFO has one input and one > > > output, but if more that > > > > > one input are required for a FIFO they have to pass > > > through a scheduler > > > > > element". > > > > > > > > > I thought about this and don't agree. It would be common, > > > for example to have > > > > more than one classifier feeding the same queue. If the > > > flow of packets is > > > > assumed to be serial, there is no scheduler element required. > > > > > > Dan, I think I agree with Shahram's observation here. If we assume > > > the packets arrive serially from the outputs of preceding > > classifiers > > > then the merging (aka 'multiple inputs') isn't really an attribute > > > of the queue/buffering stage - its a simple 'OR' function of > > > multiple streams of packets, which might happen anywhere prior to > > > the FIFO. At the very least, add text clarifying > > > the assumption that the multiple inputs are in fact being fed > > > by synchronized packet streams (i.e. synchronized to have > > > non-overlapping arrival times at the FIFO input{s} ) > > > > > > cheers, > > > gja > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 7 10:04:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19546 for ; Fri, 7 Jan 2000 10:04:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07761; Fri, 7 Jan 2000 09:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07734 for ; Fri, 7 Jan 2000 09:29:30 -0500 (EST) Received: from giasbm01.vsnl.net.in (giasbm01.vsnl.net.in [202.54.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18558 for ; Fri, 7 Jan 2000 09:30:27 -0500 (EST) Received: from hyd.chiplogic.com ([203.197.20.191]) by giasbm01.vsnl.net.in (8.9.2/8.9.2) with ESMTP id UAA01489; Fri, 7 Jan 2000 20:00:13 +0530 (IST) Received: from chiplogic.com ([192.168.2.59]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id TAA19954; Fri, 7 Jan 2000 19:07:51 +0530 Message-ID: <3875EE49.A3A05D0@chiplogic.com> Date: Fri, 07 Jan 2000 19:16:49 +0530 From: ksreeni X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari , IETF Subject: Re: [Diffserv] AF shaping for interior routers References: <336ECDAFDF7DD311B9E30090277AEE413514F7@nt-exchange-bby.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sharam, If we are doing shaping for EF at interior nodes, means we are doing policing also at egress port. This is exactly opposite to ,what RFC2598 says in the introduction chapter. Correct me if I am wrong. Do we need any policing for AF traffic at interior nodes? I got this doubt because , RFC2597 mentioned traffic conditioning actions for only DS domain edge routers. Sreeni Shahram Davari wrote: > Hi, > > As far as I understand, shaping should be done for EF & AF before the > ingress of the edge router to comply with the SLA. Diffserv documents don't > enforce shaping of EF & AF at the interior routers. However, some > conclusions can be drawn implicitly. > > For example to be able to comply with the EF requirement of "it should > average the configured rate measured over any time interval equal or greater > than the time it takes to send an output link MTU sized packet at configured > rate" you need to shape EF at almost every egress port of interior nodes. > > Also to be able to benefit from the statistical multiplexing you may want > not to shape AF at the interior nodes. > > Hope that helps, > > Shahram Davari > Systems Engineer, Product Research > PMC-Sierra Inc. > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > -----Original Message----- > > From: ksreeni [mailto:ksreeni@chiplogic.com] > > Sent: Tuesday, January 04, 2000 11:47 PM > > To: IETF > > Subject: [Diffserv] AF shaping for interior routers > > > > > > Hi, > > I have one basic question regarding shaping in the case of AF. > > > > I think shaping is needed at ingress interface for Edge routers, > > correct me if I am wrong. > > Do we need shaping at ingress interface for interior routers? > > > > > > Sreeni. > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 7 11:15:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21209 for ; Fri, 7 Jan 2000 11:15:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09532; Fri, 7 Jan 2000 10:40:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09501 for ; Fri, 7 Jan 2000 10:39:58 -0500 (EST) Received: from nausicaa.coritel.it ([193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20531 for ; Fri, 7 Jan 2000 10:40:56 -0500 (EST) Received: from coritel.it (hobbes.coritel.it [193.205.242.28]) by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id QAA03497; Fri, 7 Jan 2000 16:40:29 +0100 (MET) Message-ID: <38760842.31494DA6@coritel.it> Date: Fri, 07 Jan 2000 16:37:38 +0100 From: Stefano Salsano Reply-To: salsano@coritel.it Organization: CORITEL - COnsorzio di RIcerca sulle TELecomunicazioni X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ksreeni , Shahram Davari , IETF Subject: Re: [Diffserv] AF shaping for interior routers References: <336ECDAFDF7DD311B9E30090277AEE413514F7@nt-exchange-bby.pmc-sierra.bc.ca> <3875EE49.A3A05D0@chiplogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ksreeni wrote: > > Sharam, > If we are doing shaping for EF at interior nodes, means we are > doing policing also at egress port. This is exactly opposite to ,what > RFC2598 says in the introduction chapter. Correct me if I am wrong. > Sreeni I agree, NO shaping is needed at interior nodes (see below). > Shahram Davari wrote: > > As far as I understand, shaping should be done for EF & AF before the > > ingress of the edge router to comply with the SLA. Diffserv documents > > don't enforce shaping of EF & AF at the interior routers. However, > > some conclusions can be drawn implicitly. > > For example to be able to comply with the EF requirement of "it should > > average the configured rate measured over any time interval equal or > > greater than the time it takes to send an output link MTU sized > > packet at configured rate" you need to shape EF at almost every > > egress port of interior nodes. No, this does not mean you have to shape... you must only be able to provide AT LEAST that rate. As described in RFC 2598, you can use priority queueing to support EF (which means no shaping...) Stefano -- ******************************************************************* Stefano Salsano CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni E-mail : salsano@coritel.it URL : http://www.coritel.it Tel. : +39 06 20410029 Address : Via di Tor Vergata, 135 Fax. : +39 06 20410037 00133 Roma - ITALY ******************************************************************* _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 7 15:57:59 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27139 for ; Fri, 7 Jan 2000 15:57:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15629; Fri, 7 Jan 2000 14:52:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15602 for ; Fri, 7 Jan 2000 14:52:47 -0500 (EST) Received: from ns01.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26079 for ; Fri, 7 Jan 2000 14:53:45 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id OAA00255 for ; Fri, 7 Jan 2000 14:48:56 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdBAA7OMgp_; Fri Jan 7 14:48:50 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Fri, 7 Jan 2000 14:53:32 -0500 Received: from pcswbdesk ([138.120.49.86]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA17BD for ; Fri, 7 Jan 2000 14:53:23 -0500 Message-Id: <4.2.2.20000107144934.00a5c210@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 07 Jan 2000 14:53:01 -0500 To: diffserv@ietf.org From: "Scott W Brim" Subject: Re: [Diffserv] AF shaping for interior routers In-Reply-To: <3875EE49.A3A05D0@chiplogic.com> References: <336ECDAFDF7DD311B9E30090277AEE413514F7@nt-exchange-bby.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Networks induce burstiness which is not present in the traffic provided by the source. In order to avoid penalizing customers for a problem which is your fault, not theirs, a little bit of shaping of EF traffic, in the aggregate, seems reasonable. However, that's not a protocol issue. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 7 15:58:00 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27145 for ; Fri, 7 Jan 2000 15:57:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15949; Fri, 7 Jan 2000 15:06:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15916 for ; Fri, 7 Jan 2000 15:06:04 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26244 for ; Fri, 7 Jan 2000 15:07:01 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA36868; Fri, 7 Jan 2000 20:06:31 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA21756; Fri, 7 Jan 2000 20:06:27 GMT Message-ID: <38764663.7F296BD9@hursley.ibm.com> Date: Fri, 07 Jan 2000 14:02:43 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Scott W Brim CC: diffserv@ietf.org Subject: Re: [Diffserv] AF shaping for interior routers References: <336ECDAFDF7DD311B9E30090277AEE413514F7@nt-exchange-bby.pmc-sierra.bc.ca> <4.2.2.20000107144934.00a5c210@kanmail01.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Exactly. We're still planning to get a "deployment" list going for discussion of such points. Brian Scott W Brim wrote: > > Networks induce burstiness which is not present in the traffic provided > by the source. In order to avoid penalizing customers for a problem > which is your fault, not theirs, a little bit of shaping of EF traffic, > in the aggregate, seems reasonable. However, that's not a protocol issue. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 9 02:46:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23476 for ; Sun, 9 Jan 2000 02:46:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29893; Sun, 9 Jan 2000 02:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29861 for ; Sun, 9 Jan 2000 02:00:10 -0500 (EST) Received: from mhostnew.iitb.ac.in ([203.197.74.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15834 for ; Sun, 9 Jan 2000 02:01:07 -0500 (EST) Received: (qmail 19149 invoked from network); 9 Jan 2000 07:20:20 -0000 Received: from surya.cse.iitb.ernet.in (144.16.111.14) by mailhost.iitb.ac.in with SMTP; 9 Jan 2000 07:20:20 -0000 Received: from everest.cse.iitb.ernet.in (dhiman@everest [144.16.111.4]) by surya.cse.iitb.ernet.in (8.8.8/8.8.8) with ESMTP id MAA02707 for ; Sun, 9 Jan 2000 12:33:16 +0530 (IST) Received: (from dhiman@localhost) by everest.cse.iitb.ernet.in (8.9.2/8.9.2) id MAA04158 for diffserv@ietf.org; Sun, 9 Jan 2000 12:31:38 +0530 (GMT) Date: Sun, 9 Jan 2000 12:31:37 +0530 From: Dhiman Barman To: diffserv@ietf.org Message-ID: <20000109123137.B3989@cse.iitb.ernet.in> Reply-To: dhiman@cse.iitb.ernet.in Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Subject: [Diffserv] Linux Code Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, Where can I get a paper which explains the Linux DiffServ Code fragment ? Thanks, Dhiman _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 12 18:14:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26670 for ; Wed, 12 Jan 2000 18:14:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22659; Wed, 12 Jan 2000 17:31:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22627 for ; Wed, 12 Jan 2000 17:31:16 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25876 for ; Wed, 12 Jan 2000 17:32:21 -0500 (EST) Message-Id: <200001122232.RAA25876@ietf.org> Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprch1.nortel.com; Wed, 12 Jan 2000 16:31:59 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0A8S0X; Wed, 12 Jan 2000 17:31:57 -0500 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MSGJA; Wed, 12 Jan 2000 17:31:58 -0500 Date: Wed, 12 Jan 2000 17:31:19 -0500 (EST) From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" To: diffserv@ietf.org X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA22629 Subject: [Diffserv] TSWTCM - Action from Washington IETF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, At the Washington IETF, the authors of the TSWTCM draft were actioned as described below (thanks to David Black for the minutes): > -- Time Sliding Window Three Color Marker > (draft-fang-diffserv-tc-tswtcm-00.txt) > [.....] >There are experimental results that will be reported > in Broadcom '99 (December). > The experimental results should be made available to > the WG, and then it would be reasonable to have this > draft progress to become an experimental RFC. > The authors will post a message to the list containing > URLs for all of their results. There have been a number of Diffserv studies with variants of the TSWTCM. Those that we are aware of include: 1. Clark & Fang TON '98 paper 2. Ibanez & Nichols Internet Draft - August 1998 3. Yeom & Reddy paper - iwqos 99 4. Seddigh, Nandy & Pieda paper - Globecom 99 5. Seddigh, Nandy & Pieda IETF draft - TCP/UDP in AF (1999) Detailed paper titles and URLs are at the end of this message. The first study is simulation-based and focuses on using the TSWTCM for single-TCP flows. The second study is a preliminary simulation-based study of the TSW. The third study is also simulation-based and uses a TSWTCM-variant with aggregate TCP flows. The fourth study also uses the TSWTCM for aggregate flows but is based on a VxWorks-based implementation. The final study is implementation-based and shows that aggregates with UDP traffic can also use the TSWTCM. As a side note, by the end of this month, the TSWTCM will be available in BSD's ALTQ (thanks to Kenjiro Cho) and in Linux Diffserv (thanks to Jamal Hadi Salim). Regards Nabil Seddigh nseddigh@nortelnetworks.com -------------------- Fang W, Seddigh N and Nandy B, "A Time Sliding Window Three Colour Marker (TSWTCM)", Internet Draft, draft-fang-diffserv-tc-tswtcm-00.txt, October 1999 http://www.ietf.org/internet-drafts/draft-fang-diffserv-tc-tswtcm-00.txt Clark D. and Fang W., Explicit Allocation of Best Effort Packet Delivery Service, ACM Transactions on Networking, Vol. 6, No 4, August 1998 , pp 362-373 http://www.cs.princeton.edu/~wfang/papers.html Ibanez J and Nichols K, "Preliminary Simulation Evaluation of an Assured Service", Internet Draft, , August 1998 Yeom I and Reddy N, "Impact of Marking Strategy on Aggregated Flows in a Differentiated Services Network", Proceedings of IwQoS, May 1999 http://dropzone.tamu.edu/~ikjun/papers.html Seddigh N, Nandy B and Pieda P, "Bandwidth Assurance Issues for TCP Flows in a Differentiated Services Network", Proceedings of Global Internet Symposium, Globecom 99, Rio de Janeiro, December 1999 http://www7.nortel.com:8080/CTL/globe9806.pdf Seddigh N, Nandy B, and Pieda P, "Study of TCP and UDP Interaction for the AF PHB", Internet Draft, , August, 1999 http://www7.nortel.com:8080/CTL/draft-nsbnpp-diffserv-tcpudpaf-01.pdf _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 14 11:37:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19583 for ; Fri, 14 Jan 2000 11:37:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12477; Fri, 14 Jan 2000 10:34:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12441 for ; Fri, 14 Jan 2000 10:34:48 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18459 for ; Fri, 14 Jan 2000 10:35:50 -0500 (EST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.130.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA08984 for ; Fri, 14 Jan 2000 16:35:08 +0100 (MET) Received: from eed.ericsson.se (dhcp1-69 [164.48.195.69]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA22166 for ; Fri, 14 Jan 2000 16:35:07 +0100 (MET) Message-ID: <387F4228.E76BC80B@eed.ericsson.se> Date: Fri, 14 Jan 2000 16:35:04 +0100 From: Juan-Antonio Ibanez X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] TSWTCM - Action from Washington IETF References: <200001122232.RAA25876@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, Before I get an avalanche of emails asking for the URL, here it is :-) Ibanez J and Nichols K, "Preliminary Simulation Evaluation of an Assured Service", Internet Draft, , August 1998 http://ec.eurecom.fr/~ibanez/internet_draft.html Regards, Juan Nabil Seddigh wrote: > > Hi, > > At the Washington IETF, the authors of the TSWTCM > draft were actioned as described below (thanks to David > Black for the minutes): > > > -- Time Sliding Window Three Color Marker > > (draft-fang-diffserv-tc-tswtcm-00.txt) > > [.....] > >There are experimental results that will be reported > > in Broadcom '99 (December). > > The experimental results should be made available to > > the WG, and then it would be reasonable to have this > > draft progress to become an experimental RFC. > > The authors will post a message to the list containing > > URLs for all of their results. > > There have been a number of Diffserv studies with variants of the > TSWTCM. Those that we are aware of include: > > 1. Clark & Fang TON '98 paper > 2. Ibanez & Nichols Internet Draft - August 1998 > 3. Yeom & Reddy paper - iwqos 99 > 4. Seddigh, Nandy & Pieda paper - Globecom 99 > 5. Seddigh, Nandy & Pieda IETF draft - TCP/UDP in AF (1999) > > Detailed paper titles and URLs are at the end of this message. > > The first study is simulation-based and focuses on using the > TSWTCM for single-TCP flows. The second study is > a preliminary simulation-based study of the TSW. The > third study is also simulation-based and uses a > TSWTCM-variant with aggregate TCP flows. The fourth study > also uses the TSWTCM for aggregate flows but is based on > a VxWorks-based implementation. The final study is > implementation-based and shows that aggregates with UDP > traffic can also use the TSWTCM. > > As a side note, by the end of this month, the TSWTCM will be available > in BSD's ALTQ (thanks to Kenjiro Cho) and in Linux Diffserv > (thanks to Jamal Hadi Salim). > > Regards > Nabil Seddigh > nseddigh@nortelnetworks.com > > -------------------- > Fang W, Seddigh N and Nandy B, "A Time Sliding Window Three > Colour Marker (TSWTCM)", Internet Draft, > draft-fang-diffserv-tc-tswtcm-00.txt, October 1999 > http://www.ietf.org/internet-drafts/draft-fang-diffserv-tc-tswtcm-00.txt > > Clark D. and Fang W., Explicit Allocation of Best Effort Packet Delivery > Service, ACM Transactions on Networking, Vol. 6, No 4, August 1998 > , pp 362-373 http://www.cs.princeton.edu/~wfang/papers.html > > Ibanez J and Nichols K, "Preliminary Simulation Evaluation of > an Assured Service", Internet Draft, > , August 1998 > > Yeom I and Reddy N, "Impact of Marking Strategy on Aggregated Flows > in a Differentiated Services Network", Proceedings of IwQoS, May 1999 > http://dropzone.tamu.edu/~ikjun/papers.html > > Seddigh N, Nandy B and Pieda P, "Bandwidth Assurance Issues for TCP > Flows in a Differentiated Services Network", Proceedings of Global > Internet Symposium, Globecom 99, Rio de Janeiro, December 1999 > http://www7.nortel.com:8080/CTL/globe9806.pdf > > Seddigh N, Nandy B, and Pieda P, "Study of TCP and UDP > Interaction for the AF PHB", Internet Draft, > , August, 1999 > http://www7.nortel.com:8080/CTL/draft-nsbnpp-diffserv-tcpudpaf-01.pdf > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 15 23:00:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18055 for ; Sat, 15 Jan 2000 23:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29910; Sat, 15 Jan 2000 22:09:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA29880 for ; Sat, 15 Jan 2000 22:09:37 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16916 for ; Sat, 15 Jan 2000 22:10:37 -0500 (EST) Received: from mariecurie.cisco.com (mariecurie.cisco.com [192.168.82.33]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA00473 for ; Sat, 15 Jan 2000 19:03:05 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by mariecurie.cisco.com (8.9.1b+Sun/8.9.1) with SMTP id TAA23424 for ; Sat, 15 Jan 2000 19:09:52 -0800 (PST) Received: from tounes.gw.tn (tounes.gw.tn [193.95.50.118]) by proxy2.cisco.com with SMTP (MailShield v1.5); Sat, 15 Jan 2000 19:13:12 -0800 Received: from tounes (tounes.tn [193.95.50.110]) by tounes.gw.tn (8.8.8/8.8.8) with ESMTP id EAA19306 for ; Sun, 16 Jan 2000 04:09:05 -0100 (GMT) Received: from tounes.ati.tn (tounes.ati.tn [193.95.66.21]) by tounes.tngw.tn (8.8.8/8.8.8) with ESMTP id EAA10829 for ; Sun, 16 Jan 2000 04:08:27 -0100 (GMT) Received: from email.rnu.tn ([193.95.67.131]) by tounes.ati.tn (8.8.7/8.8.8) with ESMTP id DAA14786 for ; Sun, 16 Jan 2000 03:56:05 -0100 Received: from ensi.rnu.tn ([193.95.37.60]) by email.rnu.tn (8.8.8/8.8.8) with ESMTP id QAA25006 for ; Sat, 15 Jan 2000 16:17:34 +0100 Message-Id: <388138BC.EE19E34C@ensi.rnu.tn> Date: Sun, 16 Jan 2000 04:19:24 +0100 From: Mounir Eddabbabi Organization: ENSI X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@external.cisco.com Content-Type: multipart/mixed; boundary="------------4BA6CB34FDDE377AAEBF1613" X-SMTP-HELO: tounes.gw.tn X-SMTP-MAIL-FROM: Mounir.Eddabbabi@ensi.rnu.tn X-SMAP-Received-From: outside X-SMTP-PEER-INFO: tounes.gw.tn [193.95.50.118] Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------4BA6CB34FDDE377AAEBF1613 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe diffserv Mounir.Eddabbabi@ensi.rnu.tn --------------4BA6CB34FDDE377AAEBF1613 Content-Type: text/x-vcard; charset=us-ascii; name="Mounir.Eddabbabi.vcf" Content-Description: Card for Mounir Eddabbabi Content-Disposition: attachment; filename="Mounir.Eddabbabi.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Eddabbabi;Mounir tel;home:216-4-896142 x-mozilla-html:FALSE url:http://members.xoom.com/dabbabi/ org:ENSI;RSR adr:;;BP 290 Av Taieb M'Hiri;Ariana;;2080;Tunisia version:2.1 email;internet:Mounir.Eddabbabi@ensi.rnu.tn title:Master Student x-mozilla-cpt:;8864 fn:Mounir Eddabbabi end:vcard --------------4BA6CB34FDDE377AAEBF1613-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 17 13:03:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04939 for ; Mon, 17 Jan 2000 13:03:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21183; Mon, 17 Jan 2000 11:44:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21149 for ; Mon, 17 Jan 2000 11:44:54 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03719 for ; Mon, 17 Jan 2000 11:46:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jan 17 11:45:40 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA06873; Mon, 17 Jan 2000 11:45:37 -0500 (EST) Message-ID: <388346D7.8321A1D5@research.bell-labs.com> Date: Mon, 17 Jan 2000 11:44:07 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: RSVP , mpls , diffserv , te-wg CC: Henning Schulzrinne , Ellen Hahne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] A new draft on inter-domain level resource management Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, all, We have just submitted a draft, "BGRP: A Framework for Scalable Resource Reservation". It describes a new scalable signaling protocol that can setup reservation trunks/MPLS LSP's over multiple internet domains. I think that people on the above mailing lists may want to take a look at it. You may find the draft in http://www.cs.columbia.edu/~pingpan/papers/draft-pan-bgrp-framework-00.txt Some more information is in http://www.cs.columbia.edu/~pingpan/projects/bgrp.html Here are some of the highlights: - Why not RSVP? In RSVP, PATH messages are required to pin-down reservation routes prior to the actual reservation. Thus with PATH/RESV, each route has to maintain both source and destination information. This would cause the N**2 problem, where N is total number of end users. In our proposal, we suggest to have senders probing the network, but the routers don't have to store the probing information. The routers only have to remember the reservation destination (that is, sink-tree model). This would reduce the problem to O(N). - Useful to MPLS and TE Each link may not have too many end-host real-time reservations all at once. But to apply traffic engineering, the ISP's may want to setup a fully connected LSP network. With RSVP/LDP, N**2 would be a problem. We proposed a different way for setting up the LSP's for inter-domain. - DiffServ IMHO, DiffServ is good for data aggregation so that the routers don't have to maintain micro-flow information as in IntServ. But DiffServ is NOT a control mechanism. Our proposal can be used to setup DiffServ trunks across the network. - Routing interface We interface with BGP for reservation routes. If we look at the network today, BGP with route aggregation provides nice sink-trees to all destination networks. Our objective is to set up reservations along the BGP routes. So please take a look at our draft. We have collected a lot of traffic traces with the help from NLANR people. From the trace, we observed some very interesting behaviors with source/destination data. Also we have talked (formally and informally) to many developers and operation people to make sure our scheme would work. Thanks to them all. This is a new area of work on inter-domain resource management, which I believe it would be useful in the near future. We would like to hear from all of you to make sure we didn't think in the wrong direction. Thank you all in advance! -- Ping, Ellen, Henning _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 17 14:41:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07138 for ; Mon, 17 Jan 2000 14:41:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25167; Mon, 17 Jan 2000 13:54:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25139 for ; Mon, 17 Jan 2000 13:53:59 -0500 (EST) Received: from lion.statslab.cam.ac.uk (exim@lion.statslab.cam.ac.uk [131.111.20.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05717 for ; Mon, 17 Jan 2000 13:55:05 -0500 (EST) Received: from theta.statslab.cam.ac.uk [131.111.20.110] by lion.statslab.cam.ac.uk with smtp (Exim 1.82 #2) id 12AHIp-0004Cn-00; Mon, 17 Jan 2000 18:55:00 +0000 Received: by theta.statslab.cam.ac.uk with Microsoft Mail id <01BF611C.ABB7EF00@theta.statslab.cam.ac.uk>; Mon, 17 Jan 2000 18:57:15 -0000 Message-ID: <01BF611C.ABB7EF00@theta.statslab.cam.ac.uk> From: Richard Gibbens To: "'diffserv@ietf.org'" Date: Mon, 17 Jan 2000 18:57:14 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Service Level Agreements Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This paper (together with an extended version) An approach to service level agreements for IP networks with differentiated services R J Gibbens, S K Sargood, F P Kelly, M Azmoodeh, R Macfadyen and N Macfadyen is now available in draft form here http://www.statslab.cam.ac.uk/~richard/research/papers/sla/ Synopsis: In this paper we report on a study of possible Service Level Agreements in an IP network employing Differentiated Services. We discuss the nature of the quality of service guarantees given to network flows and relate this to the capacity provisioning processes of network operators. The authors welcome comment and feedback on the approach and our preliminary findings. -- Richard Gibbens Royal Society University Research Fellow Statistical Laboratory, University of Cambridge _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 17 18:42:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10362 for ; Mon, 17 Jan 2000 18:42:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02213; Mon, 17 Jan 2000 18:08:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02136 for ; Mon, 17 Jan 2000 18:05:56 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10032 for ; Mon, 17 Jan 2000 18:06:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jan 17 18:05:18 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA23758; Mon, 17 Jan 2000 18:05:17 -0500 (EST) Message-ID: <38839FD3.34430465@dnrc.bell-labs.com> Date: Mon, 17 Jan 2000 18:03:47 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne References: <200001172049.PAA24260@anchor.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: A new draft on inter-domain level resource management Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > > > You should be clear in your discussions of BGRP what problem it is you > are trying to solve. BGRP is trying to solve the scalability problems > that arrise when using MPLS for microflows. This is what is commonly > referred to as QoS routing. > Hi, Curtis, BGRP is not a routing protocol. It uses the information provided by BGP4 (specifically, AS_PATH and NEXT_HOP attributes) to set up reservation trunks in the backbone. First, it involves only with BGP border routers. Second, it further reduces the number of "flows" a border router has to maintain. I think QoS routing is to periodically advertise link/resource information throughout the network, which is not really what we are targeting here. Sorry about the confusion. > [ aside: > > This is why I have insisted that we not confuse the term "QoS routing" > with "traffic engineering". The two have similarities, but some very > significant differences. Traffic engineeering as it is currently > practiced by ISPs is not concerned with microflows (even very large > ones) and in a stable network would be expected to generate zero > setups despite huge numbers (could be hundreds of thousands or > millions) of microflows appearing and going away per second. > For traffic engineering, there could be many long-lived "flows" that established by the ISP's. The cost of setting them up in terms of processing CPU cycles and storage space may not be a big deal, but the cost of maintain these "flows" may be a big problem for the routers. Soft-state is a good idea to allow the routers to adjust to route changes. But the side-effect here is that soft-state requires the routers to maintain a copy of all the states. If there are thousands or millions of microflows that need to refresh, I doubt the routers can sustain the CPU cost. > For traffic engineered backbones, the total number of LSPs is bounded > by the number of LSRs in the network and the number of classes of > service offerred. Most providers estimate the total number of LSPs > that will be needed in their network to be on the order of 10^3 or > 10^4. The number going through any one LSR should be even smaller. > The setup rate should normally be zero or very close to zero except in > response to network failure. Actually, as being pointed out in RFC2430 (PASTE by Tony Li and Yokov Rekhter), the number of trunks (or LSP's, or reservations) is N * (N-1) * C, where C is the number of service classes, N is the number of MPLS-speaking routers. This is the N**2 problem we are talking about here. In case of intra-domain, N is the number of border routers at backbone edge, and is in the range of ~100. To setup a full-meshed network to support traffic engineering, the ISP needs indeed 10^3 or 10^4 trunks. The current RSVP/LDP should have no problem for intra-domain. But to setup such trunks over multiple domains, we will have problem here. As pointed out in our draft, we have thousands of AS's and routes over the network. To provide a similar level of traffic engineering functionality in multi-domain environment would require millions of trunks. We proposed a new protocol here to provide trunk setup mechanism for inter-domain only. When routers use BGRP to setup inter-domain trunks, the border routers will interface with intra-domain signaling protocols to set up internal trunks. BGRP is hopping between the border routers to trigger LSP setups. > > Some of those estimating higher than 10^4 LSPs tend to be interested > in voice and counting on doing one LSP per T1 voice trunk (not even > aggregating to trunk group) rather than engineering IP networks. > Those who believe that MPLS traffic engineering should be used solely > to provide more efficient routing through provider backbones may > consider this broken by design (though it may be essential to some > VoMPLS approaches, not that it would be the first time something > broken by design was proposed within or outside the IETF). > IMHO, I hope the ISP's consider traffic in terms of service classes and bandwidth only (as being defined in DiffServ), not in terms of application. The end users at network edge can choose any service class to carry their voice depending on how much they are willing to pay. > ... end of aside] > > > A question for the MPLS WG is "is this a problem the MPLS WG is trying > to solve?" Perhaps the MPLS deployment WG in the OPs area can help > provide an answer. > I have the same question. That's why I send the note to multiple lists. ;-) > Curtis Regards, -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 07:02:07 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28175 for ; Tue, 18 Jan 2000 07:02:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26372; Tue, 18 Jan 2000 06:13:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26341 for ; Tue, 18 Jan 2000 06:13:41 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27762 for ; Tue, 18 Jan 2000 06:14:48 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Jan 2000 11:14:23 +0000 To: Ping Pan cc: curtis@avici.com, Ping Pan , RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management In-reply-to: Your message of "Mon, 17 Jan 2000 18:03:47 EST." <38839FD3.34430465@dnrc.bell-labs.com> Date: Tue, 18 Jan 2000 11:14:23 +0000 Message-ID: <9755.948194063@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org In message <38839FD3.34430465@dnrc.bell-labs.com>, Ping Pan typed: hmm - interesting - thouhg i am still not sure why you can't work on an evolutionary path with RSVP rather than a whole new protocol but alternatively, what i'd like is to do a joint re-design of inter-domain routing, and inter-domain signaling rather than just pile more and more things into BGP and new signaling protocols...one possibility: to use NIMROD architecture http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html to exchange two types of thing: 1/ tag a map for a region (aka core, or trunk area) with current traffic load advertisement (what one wishes to export as effective available capacity -the map based approach alows you to scale state and size of exchanges...the use of IP or AS numbers or MPLS labels as the means of description of flows or aggregations is, imho, doomed to fail... 2/ tag requests for class based trunk adaptive sized DELTAs in capacity requests from routers at the edge of such a region - delta's allow you to scale the message rate, as well as the state - as the rate of edge device requests increases (iptel call setup or teardown rate goes up), you just modify the deltas to anticipate the desired trunk sizes...rsvp can be modified to do this relatively easily (documents on aggregate reservations only need modest changes in identifying who is requesting what of whom...) some discussion from noel chiappa and others might ensue (pnni too...?) cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 09:02:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29575 for ; Tue, 18 Jan 2000 09:02:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28642; Tue, 18 Jan 2000 08:06:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28619 for ; Tue, 18 Jan 2000 08:06:53 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28793 for ; Tue, 18 Jan 2000 08:08:02 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Jan 18 08:07:14 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.42.208]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id IAA09197; Tue, 18 Jan 2000 08:07:10 -0500 (EST) Message-ID: <388465B2.C85E8CF3@research.bell-labs.com> Date: Tue, 18 Jan 2000 08:08:02 -0500 From: Ping Pan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Jon Crowcroft CC: Ping Pan , curtis@avici.com, RSVP , mpls , diffserv , te-wg , Henning Schulzrinne , Ellen Hahne Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <9755.948194063@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Jon Crowcroft wrote: > > hmm - interesting - thouhg i am still not sure why you can't work on > an evolutionary path with RSVP rather than a whole new protocol > We've tried very hard to address the scaling problem with RSVP in the past year or so. Lou Berger, George Swallow, Lixia (and her students) and us have tried to enhance RSVP soft-state properties in various drafts. At this point, I believe RSVP (and its LSP extension) will have no problem whatsoever to handle intra-domain requirements. But RSVP does have the N**2 problem. When you look at the data we had gathered in Section-2 of our draft, any signaling protocol with N**2 property would be difficult work in inter-domain environment. One of the issues in RSVP is the notion of "route-pinning" at PATH processing time. This forces the routers to remember every reservation sender. At RESV processing time, the routers need to map the RESV to the previous PATH. This means that the routers need to maintain N**2 states. I think this is designed to prevent reservation looping problem. (BTW, Bob Braden told me a couple of years ago that during the RSVP design, people had thought about not storing PATH at routers, but...) In BGRP, we still use the two-pass reservation mechanism. But the PROBE messages (equivalent to RSVP PATH) gather the route information, and the receivers use the gathered routing data to construct sink-trees. At reservation time, the routers need only to remember sink-tree information, which is O(N). Later, -- Ping Pan htpp://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 10:55:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01401 for ; Tue, 18 Jan 2000 10:55:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02177; Tue, 18 Jan 2000 10:09:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02148 for ; Tue, 18 Jan 2000 10:09:03 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00446 for ; Tue, 18 Jan 2000 10:10:09 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA50146; Tue, 18 Jan 2000 15:05:41 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA31210; Tue, 18 Jan 2000 15:05:39 GMT Message-ID: <38848157.7474DCA8@hursley.ibm.com> Date: Tue, 18 Jan 2000 09:05:59 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv , DS interest References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv Implementation mailing list Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Calling all Diffservers, Muneyb Minhazuddin of CSIRO in Australia has kindly agreed to host a diffserv implementation list and archive. Please look at http://www.tip.csiro.au/dsimplementation for the list's charter and joining instructions. Just to remind you - the diffserv@ietf.org list is the IETF WG's official list, limited to matters covered by the WG charter. The new list is for implementation issues, as defined at the above Web page. The diffserv-interest@external.cisco.com is an unmoderated list for any other diffserv-related discussion. Thanks to Muneyb for setting up the new list. Brian Carpenter _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 11:42:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02378 for ; Tue, 18 Jan 2000 11:42:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03478; Tue, 18 Jan 2000 10:58:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03449 for ; Tue, 18 Jan 2000 10:58:20 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01473 for ; Tue, 18 Jan 2000 10:59:26 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA23186; Tue, 18 Jan 2000 15:58:19 GMT Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA31146; Tue, 18 Jan 2000 15:58:10 GMT Message-ID: <38848D85.86BB640A@hursley.ibm.com> Date: Tue, 18 Jan 2000 09:57:57 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ping Pan CC: Jon Crowcroft , Ping Pan , curtis@avici.com, diffserv , Henning Schulzrinne , Ellen Hahne Subject: Not here please [Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <9755.948194063@cs.ucl.ac.uk> <388465B2.C85E8CF3@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please people, drop the diffserv list from this thread. Thanks Brian Ping Pan wrote: > > Jon Crowcroft wrote: > > > > hmm - interesting - thouhg i am still not sure why you can't work on > > an evolutionary path with RSVP rather than a whole new protocol > > > > We've tried very hard to address the scaling problem with RSVP in the > past year or so. Lou Berger, George Swallow, Lixia (and her students) > and us have tried to enhance RSVP soft-state properties in various > drafts. At this point, I believe RSVP (and its LSP extension) will have > no problem whatsoever to handle intra-domain requirements. But RSVP does > have the N**2 problem. When you look at the data we had gathered in > Section-2 of our draft, any signaling protocol with N**2 property would > be difficult work in inter-domain environment. > > One of the issues in RSVP is the notion of "route-pinning" at PATH > processing time. This forces the routers to remember every reservation > sender. At RESV processing time, the routers need to map the RESV to the > previous PATH. This means that the routers need to maintain N**2 states. > I think this is designed to prevent reservation looping problem. (BTW, > Bob Braden told me a couple of years ago that during the RSVP design, > people had thought about not storing PATH at routers, but...) > > In BGRP, we still use the two-pass reservation mechanism. But the PROBE > messages (equivalent to RSVP PATH) gather the route information, and the > receivers use the gathered routing data to construct sink-trees. At > reservation time, the routers need only to remember sink-tree > information, which is O(N). > > Later, > > -- > Ping Pan htpp://www.cs.columbia.edu/~pingpan > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 18:33:55 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07401 for ; Tue, 18 Jan 2000 18:33:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15089; Tue, 18 Jan 2000 17:58:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15056 for ; Tue, 18 Jan 2000 17:58:49 -0500 (EST) Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06995 for ; Tue, 18 Jan 2000 17:59:56 -0500 (EST) Received: from pcfayal (ppp-108-121.villette.club-internet.fr [194.158.108.121]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA25486 for ; Tue, 18 Jan 2000 23:59:55 +0100 (MET) Message-ID: <004601bf6208$c7f13f40$796c9ec2@pcfayal> From: =?iso-8859-1?Q?Fay=E7al_Bennani?= To: Date: Wed, 19 Jan 2000 00:07:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01BF6211.28985060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] SNA over DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0041_01BF6211.28985060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Any work / recommendation on which DiffServ PHB / CoS should be used for = legacy non native IP traffic, such as SNA and X25 ? =20 Fay=E7al Bennani =20 ------=_NextPart_000_0041_01BF6211.28985060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Any work / recommendation on which = DiffServ PHB /=20 CoS should be used for legacy non native IP traffic, such as SNA and X25 = ?
 
Fay=E7al Bennani  =
------=_NextPart_000_0041_01BF6211.28985060-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 18:53:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07657 for ; Tue, 18 Jan 2000 18:53:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15692; Tue, 18 Jan 2000 18:23:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15661 for ; Tue, 18 Jan 2000 18:23:24 -0500 (EST) Received: from infres.enst.fr (infres.enst.fr [137.194.160.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07248 for ; Tue, 18 Jan 2000 18:24:30 -0500 (EST) Received: from esmeralda.enst.fr (esmeralda.enst.fr [137.194.160.71]) by infres.enst.fr (Postfix) with ESMTP id F0D0445410 for ; Wed, 19 Jan 2000 00:24:31 +0100 (MET) Received: from localhost (fbennani@localhost) by esmeralda.enst.fr (8.9.3+Sun/8.9.1) with SMTP id AAA01360 for ; Wed, 19 Jan 2000 00:24:31 +0100 (MET) Date: Wed, 19 Jan 2000 00:24:31 +0100 (MET) From: Faycal Bennani To: diffserv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] SNA over DiffServ Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi, Any work / recommendation on which DiffServ PHB / CoS should be used for legacy non native IP traffic, such as SNA and X25 ? Faycal Bennani _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 18 19:04:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07826 for ; Tue, 18 Jan 2000 19:04:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16253; Tue, 18 Jan 2000 18:40:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16222 for ; Tue, 18 Jan 2000 18:40:01 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07503 for ; Tue, 18 Jan 2000 18:41:07 -0500 (EST) From: Masataka Ohta Message-Id: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA14823; Wed, 19 Jan 2000 08:37:48 +0859 Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management To: pingpan@research.bell-labs.com (Ping Pan) Date: Wed, 19 Jan 0 8:37:47 JST Cc: J.Crowcroft@cs.ucl.ac.uk, pingpan@dnrc.bell-labs.com, curtis@avici.com, rsvp@ISI.EDU, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com In-Reply-To: <388465B2.C85E8CF3@research.bell-labs.com>; from "Ping Pan" at Jan 18, 100 10:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Ping Pan; > > hmm - interesting - thouhg i am still not sure why you can't work on > > an evolutionary path with RSVP rather than a whole new protocol > > > > We've tried very hard to address the scaling problem with RSVP in the > past year or so. Lou Berger, George Swallow, Lixia (and her students) > and us have tried to enhance RSVP soft-state properties in various > drafts. At this point, I believe RSVP (and its LSP extension) will have > no problem whatsoever to handle intra-domain requirements. But RSVP does > have the N**2 problem. When you look at the data we had gathered in > Section-2 of our draft, any signaling protocol with N**2 property would > be difficult work in inter-domain environment. As I have pointed out in RSVP-related WGs and several research papers, RSVP has no scalability problem from the begining. So, I agree with you that it is very hard (impossible) to solve your problem, because the problem does not exist. > One of the issues in RSVP is the notion of "route-pinning" at PATH > processing time. This forces the routers to remember every reservation > sender. At RESV processing time, the routers need to map the RESV to the > previous PATH. No. As I pointed it out in some I-D and the INET'97 paper, the solution is to route RESV first and let PATH follows the route. Note that route stabilization is easy that route-pinning is not necessary at all. There are simple reasons why BGP like policy can not be applicable to resource reservation. But it seems to me that the topic is to hard for you to understand. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 19 11:54:57 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01959 for ; Wed, 19 Jan 2000 11:54:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21413; Wed, 19 Jan 2000 10:46:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21380 for ; Wed, 19 Jan 2000 10:46:53 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00963 for ; Wed, 19 Jan 2000 10:48:02 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jan 19 10:47:32 EST 2000 Received: from dnrc.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA25536; Wed, 19 Jan 2000 10:47:31 -0500 (EST) Message-ID: <3885DC3B.E050189F@dnrc.bell-labs.com> Date: Wed, 19 Jan 2000 10:46:03 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Masataka Ohta CC: Ping Pan , J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, mpls@UU.NET, diffserv@ietf.org, te-wg@UU.NET, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > As I have pointed out in RSVP-related WGs and several research papers, > RSVP has no scalability problem from the begining. > Huh? Please provide the pointers to your draft. > So, I agree with you that it is very hard (impossible) to solve > your problem, because the problem does not exist. > Man. This is deep! > > There are simple reasons why BGP like policy can not be applicable to > resource reservation. But it seems to me that the topic is to hard > for you to understand. > In the past few years, sir, you have been insulting many people in public without much technical input. It's not the topic too hard for me to understand, rather it's your attitude that is too hard for me to understand. Please provide meaningful technical input NICELY. Thank you! - Ping _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 19 13:54:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03453 for ; Wed, 19 Jan 2000 13:54:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25551; Wed, 19 Jan 2000 13:14:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25518 for ; Wed, 19 Jan 2000 13:14:37 -0500 (EST) Received: from hotmail.com (f261.law3.hotmail.com [209.185.240.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03010 for ; Wed, 19 Jan 2000 13:15:47 -0500 (EST) Received: (qmail 77466 invoked by uid 0); 19 Jan 2000 18:15:16 -0000 Message-ID: <20000119181516.77465.qmail@hotmail.com> Received: from 213.30.11.169 by www.hotmail.com with HTTP; Wed, 19 Jan 2000 10:15:16 PST X-Originating-IP: [213.30.11.169] From: "RUI VALENTE" To: diffserv@ietf.org Date: Wed, 19 Jan 2000 18:15:16 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org ruivalente@hotmail.com ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 19 15:08:40 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04592 for ; Wed, 19 Jan 2000 15:08:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27180; Wed, 19 Jan 2000 14:21:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27155 for ; Wed, 19 Jan 2000 14:20:57 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03951 for ; Wed, 19 Jan 2000 14:22:05 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Jan 19 14:21:16 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA04778; Wed, 19 Jan 2000 14:21:15 -0500 (EST) Message-ID: <38860E46.33F186B4@research.bell-labs.com> Date: Wed, 19 Jan 2000 14:19:34 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Faycal Bennani CC: diffserv@ietf.org Subject: Re: [Diffserv] SNA over DiffServ References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Don't think there was any proposal on SNA over DiffServ. But native SNA traffic is very sensitive to loss and delay. Normally SNA packets are encapsulated in TCP (or IBM RTP format) before sending to the network. I think long delay could be bad for SNA traffic. Faycal Bennani wrote: > > Hi, > > Any work / recommendation on which DiffServ PHB / CoS should be used for > legacy non native IP traffic, such as SNA and X25 ? > > Faycal Bennani > -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 19 22:39:46 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09767 for ; Wed, 19 Jan 2000 22:39:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07336; Wed, 19 Jan 2000 22:00:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07307 for ; Wed, 19 Jan 2000 22:00:29 -0500 (EST) Received: from mlsrv1.avici.com ([208.246.215.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08635 for ; Wed, 19 Jan 2000 22:01:39 -0500 (EST) Received: from adunstanpc2 (dialin16.avici.com [10.1.3.136]) by mlsrv1.avici.com (8.8.5/8.8.4) with SMTP id WAA24963; Wed, 19 Jan 2000 22:00:55 -0500 (EST) Reply-To: From: "Adam Dunstan" To: "Ping Pan" , "Faycal Bennani" Cc: Subject: RE: [Diffserv] SNA over DiffServ Date: Wed, 19 Jan 2000 22:10:37 -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: <38860E46.33F186B4@research.bell-labs.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit If my memory serves me correctly, DLSw puts SNA into TCP sessions, I think that DLSw v2 allowed difference COS into difference TCP sessions but I am probably wrong, the DLSw WG (if it still exists) is probably a good place for this question. -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Ping Pan Sent: Wednesday, January 19, 2000 2:20 PM To: Faycal Bennani Cc: diffserv@ietf.org Subject: Re: [Diffserv] SNA over DiffServ Don't think there was any proposal on SNA over DiffServ. But native SNA traffic is very sensitive to loss and delay. Normally SNA packets are encapsulated in TCP (or IBM RTP format) before sending to the network. I think long delay could be bad for SNA traffic. Faycal Bennani wrote: > > Hi, > > Any work / recommendation on which DiffServ PHB / CoS should be used for > legacy non native IP traffic, such as SNA and X25 ? > > Faycal Bennani > -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 00:53:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11183 for ; Thu, 20 Jan 2000 00:53:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10101; Thu, 20 Jan 2000 00:18:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10074 for ; Thu, 20 Jan 2000 00:18:49 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10897 for ; Thu, 20 Jan 2000 00:20:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Thu Jan 20 00:19:36 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.42.72]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA21831; Thu, 20 Jan 2000 00:19:34 -0500 (EST) Message-ID: <38869B1D.AEF3683C@research.bell-labs.com> Date: Thu, 20 Jan 2000 00:20:29 -0500 From: Ping Pan X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: adunstan@avici.com CC: Faycal Bennani , diffserv@ietf.org Subject: Re: [Diffserv] SNA over DiffServ References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Adam, You're right. I recall that IBM had defined a special TOS precedence bit combination to carry "important" SNA packets, and zero precedence value to carry regular SNA data. It's mapped into the old TOS byte format, where the precedence filed has a mask of 0xE0. It had all sort of fancy precedence levels. ;-) But it won't work with the new DS byte mapping anymore. - Ping Adam Dunstan wrote: > > If my memory serves me correctly, DLSw puts SNA into TCP sessions, I think > that DLSw v2 allowed difference COS into difference TCP sessions but I am > probably wrong, the DLSw WG (if it still exists) is probably a good place > for this question. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 09:13:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29571 for ; Thu, 20 Jan 2000 09:13:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27830; Thu, 20 Jan 2000 08:31:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27801 for ; Thu, 20 Jan 2000 08:31:30 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27825 for ; Thu, 20 Jan 2000 08:32:40 -0500 (EST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Thu, 20 Jan 2000 08:31:28 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 08:31:28 -0500 Message-ID: <29400B68197CD31188830000F8CD15D3012FF8C8@zcard00q.ca.nortel.com> From: "Harry Silverstone" To: "'Ping Pan'" , adunstan@avici.com Cc: Faycal Bennani , diffserv@ietf.org Subject: RE: [Diffserv] SNA over DiffServ Date: Thu, 20 Jan 2000 08:31:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF634A.A77F930E" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org 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_01BF634A.A77F930E Content-Type: text/plain; charset="iso-8859-1" Hi, I think that the TOS precedence mapping being referred to applies only to the SNA Enterprise Extender architecture that was introduced within the past couple of years. Using this, one can set the COS for the SNA over IP traffic. With DLSw, there is nothing in the standard with respect to setting the TOS precedence bits. It only provides a means to prioritize its own data. However there is nothing stopping a DLSw implementation from setting the TOS field as needed, similar to any other IP application. ~harry -----Original Message----- From: Ping Pan [mailto:pingpan@research.bell-labs.com] Sent: Thursday, January 20, 2000 12:20 AM To: adunstan@avici.com Cc: Faycal Bennani; diffserv@ietf.org Subject: Re: [Diffserv] SNA over DiffServ Adam, You're right. I recall that IBM had defined a special TOS precedence bit combination to carry "important" SNA packets, and zero precedence value to carry regular SNA data. It's mapped into the old TOS byte format, where the precedence filed has a mask of 0xE0. It had all sort of fancy precedence levels. ;-) But it won't work with the new DS byte mapping anymore. - Ping Adam Dunstan wrote: > > If my memory serves me correctly, DLSw puts SNA into TCP sessions, I think > that DLSw v2 allowed difference COS into difference TCP sessions but I am > probably wrong, the DLSw WG (if it still exists) is probably a good place > for this question. > Faycal Bennani wrote: > > Hi, > > Any work / recommendation on which DiffServ PHB / CoS should be used for > legacy non native IP traffic, such as SNA and X25 ? > > Faycal Bennani > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ ------_=_NextPart_001_01BF634A.A77F930E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Diffserv] SNA over DiffServ

Hi,

        I think = that the TOS precedence mapping being referred to applies only
to the SNA Enterprise Extender architecture that was = introduced within the
past couple of years. Using this, one can set the = COS for the SNA over IP traffic.

        With DLSw, = there is nothing in the standard with respect to setting the
TOS precedence bits. It only provides a means to = prioritize its own data. However
there is nothing stopping a DLSw implementation from = setting the TOS field as
needed, similar to any other IP application.

~harry

-----Original Message-----
From: Ping Pan [mailto:pingpan@research.b= ell-labs.com]
Sent: Thursday, January 20, 2000 12:20 AM
To: adunstan@avici.com
Cc: Faycal Bennani; diffserv@ietf.org
Subject: Re: [Diffserv] SNA over DiffServ


Adam,

You're right. I recall that IBM had defined a special = TOS precedence bit
combination to carry "important" SNA = packets, and zero precedence value
to carry regular SNA data. It's mapped into the old = TOS byte format,
where the precedence filed has a mask of 0xE0. It = had all sort of fancy
precedence levels. ;-) But it won't work with the = new DS byte mapping
anymore.

- Ping

Adam Dunstan wrote:
>
> If my memory serves me correctly, DLSw puts SNA = into TCP sessions, I think
> that DLSw v2 allowed difference COS into = difference TCP sessions but I am
> probably wrong, the DLSw WG (if it still = exists) is probably a good place
> for this question.
>

Faycal Bennani wrote:
>
> Hi,
>
> Any work / recommendation on which DiffServ PHB = / CoS should be used for
> legacy non native IP traffic, such as SNA and = X25 ?
>
> Faycal Bennani
>

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

------_=_NextPart_001_01BF634A.A77F930E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 11:16:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05340 for ; Thu, 20 Jan 2000 11:16:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00439; Thu, 20 Jan 2000 10:16:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00403 for ; Thu, 20 Jan 2000 10:16:26 -0500 (EST) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02042 for ; Thu, 20 Jan 2000 10:17:35 -0500 (EST) From: remoore@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA13038; Thu, 20 Jan 2000 10:06:06 -0600 Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA42216; Thu, 20 Jan 2000 10:17:34 -0500 Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525686C.0053FE7A ; Thu, 20 Jan 2000 10:17:26 -0500 X-Lotus-FromDomain: IBMUS To: Ping Pan , diffserv@ietf.org Message-ID: <8525686C.0053C66C.00@d54mta04.raleigh.ibm.com> Date: Thu, 20 Jan 2000 10:12:32 -0500 Subject: Re: [Diffserv] SNA over DiffServ Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org This isn't quite right. While the architecture for HPR over IP was initially defined in terms of the 3 TOS Precedence bits, it was revised to reflect the new definition of the DS codepoint. The architecture continues to work just as it did before. Anyone interested in more details on the architecture for HPR over IP can get them at http://www.raleigh.ibm.com:80/cgi-bin/bookmgr/BOOKS/D50H6003/2.5.5 Note that both IBM and Cisco have implemented the HPR over IP architecture under the brand name "Enterprise Extender". Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com Ping Pan @ietf.org on 01/20/2000 12:20:29 AM Sent by: diffserv-admin@ietf.org To: adunstan@avici.com cc: Faycal Bennani , diffserv@ietf.org Subject: Re: [Diffserv] SNA over DiffServ Adam, You're right. I recall that IBM had defined a special TOS precedence bit combination to carry "important" SNA packets, and zero precedence value to carry regular SNA data. It's mapped into the old TOS byte format, where the precedence filed has a mask of 0xE0. It had all sort of fancy precedence levels. ;-) But it won't work with the new DS byte mapping anymore. - Ping Adam Dunstan wrote: > > If my memory serves me correctly, DLSw puts SNA into TCP sessions, I think > that DLSw v2 allowed difference COS into difference TCP sessions but I am > probably wrong, the DLSw WG (if it still exists) is probably a good place > for this question. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 11:26:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05919 for ; Thu, 20 Jan 2000 11:26:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00818; Thu, 20 Jan 2000 10:29:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00787 for ; Thu, 20 Jan 2000 10:29:24 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02705 for ; Thu, 20 Jan 2000 10:30:32 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id KAA29599 for ; Thu, 20 Jan 2000 10:24:39 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdCAA0SyAMi; Thu Jan 20 10:24:33 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Thu, 20 Jan 2000 10:29:26 -0500 Received: from pcswb ([138.120.49.84]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA23BD; Thu, 20 Jan 2000 10:29:24 -0500 Message-Id: <4.2.2.20000120102615.00a55740@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 10:29:00 -0500 To: Faycal Bennani , diffserv@ietf.org From: "Scott W Brim" Subject: Re: [Diffserv] SNA over DiffServ In-Reply-To: <38860E46.33F186B4@research.bell-labs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org When we were first getting started, Ed Ellesson came in with SNA requirements. I believe he needed 5 classes but just WFQ. Last I heard he was ellesson@raleigh.ibm.com and he was working on policy. Ed, you there? Faycal Bennani wrote: > > > > Hi, > > > > Any work / recommendation on which DiffServ PHB / CoS should be used for > > legacy non native IP traffic, such as SNA and X25 ? > > > > Faycal Bennani _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 13:06:17 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10249 for ; Thu, 20 Jan 2000 13:06:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06107; Thu, 20 Jan 2000 11:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06074 for ; Thu, 20 Jan 2000 11:57:37 -0500 (EST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07178 for ; Thu, 20 Jan 2000 11:58:45 -0500 (EST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE03@monza.broadswitch.com> From: Thomas Eklund To: "'diffserv@ietf.org'" Cc: "'yoramb@microsoft.com'" , "'andrew@extremenetworks.com'" , "'slblake@torrentnet.com'" Date: Thu, 20 Jan 2000 17:58:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06075 Subject: [Diffserv] TCB's in diffserv router model. Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, I have some questions about the draft-ietf-diffserv-model-01.txt... I wonder why TCB (Traffic Conditioning Block) is specified to include the classifier stage?? I would like to see something like Filter Block (BA, MF filtering) Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, Queuing/Scheduling) So that you set the ingress and egress filtering rules in the FB and applies a TCB for every FB. So the FB is in, out, in/out (flow). Then I would also like to see a paper on how ipsec in tunnel mode over diffserv should be handled at the same time in FB. Or is there any work already done on this? So the model would become: FB + TCB = (filtering block for both security filters and qos classification) + (and a traffic conditioning block that apply the traffic behaviour) = What treatment and how a packet is forwarded Any comments? Best Regards Thomas Thomas Eklund System Design, MSc SwitchCore i Stockholm AB Positionen 153, Hangövägen 19 SE-115 74 Stockholm, Sweden phone +46 8 5630 5815 fax +46 8 5630 5801 mobile +46 709 952910 Thomas.Eklund@switchcore.com visit our web page at http://www.switchcore.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Thu Jan 20 15:11:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14150 for ; Thu, 20 Jan 2000 15:11:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10285; Thu, 20 Jan 2000 14:25:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10257 for ; Thu, 20 Jan 2000 14:25:02 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12704 for ; Thu, 20 Jan 2000 14:26:12 -0500 (EST) Received: from pasteur.cisco.com (pasteur.cisco.com [171.69.43.89]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA17313 for ; Thu, 20 Jan 2000 11:18:04 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by pasteur.cisco.com (8.9.1b+Sun/8.9.1) with SMTP id LAA05534 for ; Thu, 20 Jan 2000 11:26:12 -0800 (PST) Received: from level1.level1.com (level1.level1.com [204.160.84.10]) by proxy1.cisco.com with SMTP (MailShield v1.5); Thu, 20 Jan 2000 11:25:58 -0800 Received: from sentinel2 ([204.160.84.2] helo=sentinel2.level1.com) by level1.level1.com with smtp (Exim 2.12 #1) id 12BMuX-0000gg-00 for diffserv@external.cisco.com; Thu, 20 Jan 2000 11:06:25 -0800 Received: from level6.level1.com by sentinel2.level1.com via smtpd (for level1.level1.com [204.160.84.10]) with SMTP; 20 Jan 2000 19:14:26 UT Received: from warder.level1.com ([10.13.30.100]) by mailgw.level1.com with esmtp (Exim 2.10 #1) id 12BN4Z-0000lm-00 for diffserv@external.cisco.com; Thu, 20 Jan 2000 11:16:47 -0800 Received: by warder.level1.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 11:00:22 -0800 Message-ID: From: "Dabir, Srinivas" To: "'diffserv@external.cisco.com'" Date: Thu, 20 Jan 2000 11:00:21 -0800 X-Mailer: Internet Mail Service (5.5.2448.0) X-SMTP-HELO: level1.level1.com X-SMTP-MAIL-FROM: SDabir@level1.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: level1.level1.com [204.160.84.10] Subject: [Diffserv] unsubscribe diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 04:57:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05938 for ; Fri, 21 Jan 2000 04:57:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09862; Fri, 21 Jan 2000 04:01:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09831 for ; Fri, 21 Jan 2000 04:00:55 -0500 (EST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05535 for ; Fri, 21 Jan 2000 04:02:06 -0500 (EST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE08@monza.broadswitch.com> From: Thomas Eklund To: Thomas Eklund , "'diffserv@ietf.org'" Cc: "'yoramb@microsoft.com'" , "'andrew@extremenetworks.com'" , "'slblake@torrentnet.com'" Subject: RE: [Diffserv] TCB's in diffserv router model. Date: Fri, 21 Jan 2000 10:01:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA09832 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Oops I forgot the forwarder block FOB... But that was obviuos but I did not see that in the draft. Then you would have three buliding blocks; Forwarding block, filter block and traffic conditioning block... This would be very good to fit the different models i HW (shared memory design, crossbar, shared bus etc...)... I dont know if this should be included in the draft or a new one..? Any Comments? /Thomas > -----Original Message----- > From: Thomas Eklund [mailto:thomas.eklund@switchcore.com] > Sent: Thursday, January 20, 2000 5:58 PM > To: 'diffserv@ietf.org' > Cc: 'yoramb@microsoft.com'; 'andrew@extremenetworks.com'; > 'slblake@torrentnet.com' > Subject: [Diffserv] TCB's in diffserv router model. > > > Hi, > I have some questions about the draft-ietf-diffserv-model-01.txt... > > I wonder why TCB (Traffic Conditioning Block) is specified to > include the > classifier stage?? > > I would like to see something like > Filter Block (BA, MF filtering) > Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, > Queuing/Scheduling) > > So that you set the ingress and egress filtering rules in the > FB and applies > a TCB for every FB. > > So the FB is in, out, in/out (flow). > > Then I would also like to see a paper on how ipsec in tunnel mode over > diffserv should be handled at the same time in FB. Or is > there any work > already done on this? > > So the model would become: > FB + TCB = (filtering block for both security filters and qos > classification) + (and a traffic conditioning block that > apply the traffic > behaviour) = What treatment and how a packet is forwarded > > Any comments? > > Best Regards Thomas > > Thomas Eklund > System Design, MSc > SwitchCore i Stockholm AB > Positionen 153, Hangövägen 19 > SE-115 74 Stockholm, Sweden > phone +46 8 5630 5815 > fax +46 8 5630 5801 > mobile +46 709 952910 > Thomas.Eklund@switchcore.com > visit our web page at http://www.switchcore.com > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 15:32:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16948 for ; Fri, 21 Jan 2000 15:32:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24741; Fri, 21 Jan 2000 15:06:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24711 for ; Fri, 21 Jan 2000 15:06:51 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16548 for ; Fri, 21 Jan 2000 15:08:01 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Jan 21 15:06:38 EST 2000 Received: from research.bell-labs.com (hamster [135.180.130.93]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA19361; Fri, 21 Jan 2000 15:06:38 -0500 (EST) Message-ID: <3888BBF6.AB9CF12D@research.bell-labs.com> Date: Fri, 21 Jan 2000 15:05:10 -0500 From: Ping Pan Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Istvan.I.Cselenyi@telia.se CC: RSVP , diffserv , end2end-interest@isi.edu, Ping Pan References: <200001211953.UAA04618@malmo.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: QoSSIG BOF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Istvan Cselenyi wrote: > > Reading Ping's and earlier threads [1-3] and works [4-11] it seems that > there are many people who want to contribute to the future of signaled > QoS, As for end-user QoS signaling protocol, here is another one. ;-) http://www.cs.columbia.edu/~pingpan/projects/yessir.html Since I am implementing it on FreeBSD as we speak now, and changing the draft as I code, so no official draft for it yet. But we should have something (draft plus working code) soon.... My previous implementation was on IBM routers, and many things have changed since then. ;-) - Ping _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 15:35:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16969 for ; Fri, 21 Jan 2000 15:35:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24363; Fri, 21 Jan 2000 14:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24326 for ; Fri, 21 Jan 2000 14:52:03 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16338 for ; Fri, 21 Jan 2000 14:53:13 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id UAA04618; Fri, 21 Jan 2000 20:53:09 +0100 (MET) Message-Id: <200001211953.UAA04618@malmo.trab.se> From: "Istvan Cselenyi" To: RSVP , diffserv , end2end-interest@isi.edu Date: Fri, 21 Jan 2000 20:53:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: Istvan.I.Cselenyi@telia.se CC: Ping Pan Priority: normal In-reply-to: <38848D85.86BB640A@hursley.ibm.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Subject: [Diffserv] QoSSIG BOF Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT Reading Ping's and earlier threads [1-3] and works [4-11] it seems that there are many people who want to contribute to the future of signaled QoS, but there is no IETF charter for aggregating all these good (not best :-) efforts since * the DS WG excludes new signaling by (re)definition * the MPLS WG deals with QoS routing and TE which are different * the ISSLL WG doesn't really suit to DS * the RSVP WG is closing done Shall we start with a BOF in Adelaide? /Istvan ------------------------------ Links [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html [4] http://icawww1.epfl.ch/srp/ [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated Reservation in the Internet, Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight Resource Reservation for Unicast IP Traffic", International WS on QoS'98, IWQoS'98, May 18-20, 1998 [8] http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt [9] http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-00.txt [10] http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt [11] http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 18:32:49 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18965 for ; Fri, 21 Jan 2000 18:32:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29941; Fri, 21 Jan 2000 17:52:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29916 for ; Fri, 21 Jan 2000 17:52:32 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18346 for ; Fri, 21 Jan 2000 17:53:42 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA25728; Fri, 21 Jan 2000 22:52:32 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA27830; Fri, 21 Jan 2000 22:52:28 GMT Message-ID: <3888E179.15865C94@hursley.ibm.com> Date: Fri, 21 Jan 2000 16:45:13 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ping Pan CC: Masataka Ohta , Ping Pan , J.Crowcroft@cs.ucl.ac.uk, curtis@avici.com, rsvp@isi.edu, diffserv@ietf.org, schulzrinne@cs.columbia.edu, hahne@bell-labs.com Subject: Re: [Diffserv] Re: A new draft on inter-domain level resource management References: <200001182338.IAA14823@necom830.hpcl.titech.ac.jp> <3885DC3B.E050189F@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I agree that we need a normal standard of personal politeness, but more to the point Please drop this thread from the diffserv list. It is way outside our charter. Thanks Brian Carpenter diffserv co-chair Ping Pan wrote: > > Masataka Ohta wrote: > > > > As I have pointed out in RSVP-related WGs and several research papers, > > RSVP has no scalability problem from the begining. > > > > Huh? Please provide the pointers to your draft. > > > So, I agree with you that it is very hard (impossible) to solve > > your problem, because the problem does not exist. > > > > Man. This is deep! > > > > > There are simple reasons why BGP like policy can not be applicable to > > resource reservation. But it seems to me that the topic is to hard > > for you to understand. > > > > In the past few years, sir, you have been insulting many people in > public without much technical input. It's not the topic too hard for me > to understand, rather it's your attitude that is too hard for me to > understand. Please provide meaningful technical input NICELY. > > Thank you! > > - Ping > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 18:33:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18976 for ; Fri, 21 Jan 2000 18:33:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00045; Fri, 21 Jan 2000 17:56:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00016 for ; Fri, 21 Jan 2000 17:56:11 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18388 for ; Fri, 21 Jan 2000 17:57:21 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA36412; Fri, 21 Jan 2000 22:56:15 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA21536; Fri, 21 Jan 2000 22:56:10 GMT Message-ID: <3888E253.519C2C0C@hursley.ibm.com> Date: Fri, 21 Jan 2000 16:48:51 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Eklund CC: "'diffserv@ietf.org'" , "'yoramb@microsoft.com'" , "'andrew@extremenetworks.com'" , "'slblake@torrentnet.com'" Subject: Re: [Diffserv] TCB's in diffserv router model. References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE08@monza.broadswitch.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA00017 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Thomas, We aren't designing hardware; this is only a conceptual model. The current functional decomposition has been debated for quite a while. Any choice of decomposition is arbitrary, and this is the one that got consensus. As soon as we get the draft revised according to the discussion in Washington, we will be going for Informational RFC. Regards Brian Carpenter diffserv co-chair Thomas Eklund wrote: > > Oops I forgot the forwarder block FOB... But that was obviuos but I did not > see that in the draft. > > Then you would have three buliding blocks; Forwarding block, filter block > and traffic conditioning block... > > This would be very good to fit the different models i HW (shared memory > design, crossbar, shared bus etc...)... > > I dont know if this should be included in the draft or a new one..? > Any Comments? > > /Thomas > > -----Original Message----- > > From: Thomas Eklund [mailto:thomas.eklund@switchcore.com] > > Sent: Thursday, January 20, 2000 5:58 PM > > To: 'diffserv@ietf.org' > > Cc: 'yoramb@microsoft.com'; 'andrew@extremenetworks.com'; > > 'slblake@torrentnet.com' > > Subject: [Diffserv] TCB's in diffserv router model. > > > > > > Hi, > > I have some questions about the draft-ietf-diffserv-model-01.txt... > > > > I wonder why TCB (Traffic Conditioning Block) is specified to > > include the > > classifier stage?? > > > > I would like to see something like > > Filter Block (BA, MF filtering) > > Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, > > Queuing/Scheduling) > > > > So that you set the ingress and egress filtering rules in the > > FB and applies > > a TCB for every FB. > > > > So the FB is in, out, in/out (flow). > > > > Then I would also like to see a paper on how ipsec in tunnel mode over > > diffserv should be handled at the same time in FB. Or is > > there any work > > already done on this? > > > > So the model would become: > > FB + TCB = (filtering block for both security filters and qos > > classification) + (and a traffic conditioning block that > > apply the traffic > > behaviour) = What treatment and how a packet is forwarded > > > > Any comments? > > > > Best Regards Thomas > > > > Thomas Eklund > > System Design, MSc > > SwitchCore i Stockholm AB > > Positionen 153, Hangövägen 19 > > SE-115 74 Stockholm, Sweden > > phone +46 8 5630 5815 > > fax +46 8 5630 5801 > > mobile +46 709 952910 > > Thomas.Eklund@switchcore.com > > visit our web page at http://www.switchcore.com > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 21 21:22:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20296 for ; Fri, 21 Jan 2000 21:22:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05575; Fri, 21 Jan 2000 20:47:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05543 for ; Fri, 21 Jan 2000 20:47:39 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20043 for ; Fri, 21 Jan 2000 20:48:50 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jan 2000 17:10:33 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jan 2000 17:10:33 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Istvan.I.Cselenyi@telia.se, RSVP , diffserv , end2end-interest@isi.edu Cc: Ping Pan , issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF Date: Fri, 21 Jan 2000 17:10:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Actually, in response to the comment: "The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL WG has been working for some time on the mapping of RSVP/Integrated services to DS. So - this statement is somewhat inaccurate. Nonetheless, I do think that it is appropriate ot have a forum to continue to discuss signaled QoS and its application. In fact, in the discussions preceeding the closing of the RSVP group, it was suggested that an RSVP implementation group might be formed. I would generally oppose the creation of a wroking group to start standardizing new layer-3 qos signaling protocols. Rather, I would encourage continuing the work on using RSVP in a scalable manner to unify the various disparate layer-2 QoS mechanisms in an end-to-end manner (as well as layer-3 hop by hop mechanisms such as diffserv)... Yoram -----Original Message----- From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se] Sent: Friday, January 21, 2000 11:53 AM To: RSVP; diffserv; end2end-interest@isi.edu Cc: Ping Pan Subject: [Diffserv] QoSSIG BOF Reading Ping's and earlier threads [1-3] and works [4-11] it seems that there are many people who want to contribute to the future of signaled QoS, but there is no IETF charter for aggregating all these good (not best :-) efforts since * the DS WG excludes new signaling by (re)definition * the MPLS WG deals with QoS routing and TE which are different * the ISSLL WG doesn't really suit to DS * the RSVP WG is closing done Shall we start with a BOF in Adelaide? /Istvan ------------------------------ Links [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html [4] http://icawww1.epfl.ch/srp/ [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated Reservation in the Internet, Journal on High Speed Networks, Special Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight Resource Reservation for Unicast IP Traffic", International WS on QoS'98, IWQoS'98, May 18-20, 1998 [8] http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt [9] http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o sp-00.txt [10] http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt [11] http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 15:15:15 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10778 for ; Sat, 22 Jan 2000 15:15:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28634; Sat, 22 Jan 2000 14:31:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28605 for ; Sat, 22 Jan 2000 14:31:16 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10417 for ; Sat, 22 Jan 2000 14:32:27 -0500 (EST) Received: from trab.se (udn035.ringin.udn.telia.se [131.115.97.35]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id UAA19524; Sat, 22 Jan 2000 20:32:17 +0100 (MET) Message-ID: <388A054F.6701CA71@trab.se> Date: Sat, 22 Jan 2000 20:30:23 +0100 From: Joakim Bergkvist X-Mailer: Mozilla 4.07 [en] (Win98; I) MIME-Version: 1.0 To: Yoram Bernet CC: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF References: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yes Yoram we know you're fond of RSVP! but still.. In the face of the known problems with RSVP we are several people who want to discuss alternatives. So far there have not been a forum to discuss the posibilities of alternative signalling. Instead the people behind these has spent their time listing problems with RSVP (this is what you could discuss in the RSVP BOF). Pm sure you can tweak RSVP into doing anything but this is not really the point. We beleive that there are much simpler ways of solving the same problems. If we are right there is a solution which is fundamentally simpler both in implementation and in performance requirements. This would bennefit small vendors with limited resources (not just Microsoft and Cisco). Lower performance requirements would also mean less impact on design issues and a broader fit into the current product range. My belief is that the IETF as well as RSVP would bennefit from efforts being spent on concrete solutions instead of finding problems with RSVP. If Yoram is right problems will be solved and implementations will get good enough to make RSVP happen before anyone can show a strong alternative. If not maby there is a reason for it.. There is only one way to find out and I'm not afraid! / Joakim Bergkvist, Telia Research Yoram Bernet wrote: > > Actually, in response to the comment: > > "The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL > WG has been working for some time on the mapping of RSVP/Integrated services > to DS. So - this statement is somewhat inaccurate. > > Nonetheless, I do think that it is appropriate ot have a forum to continue > to discuss signaled QoS and its application. In fact, in the discussions > preceeding the closing of the RSVP group, it was suggested that an RSVP > implementation group might be formed. > > I would generally oppose the creation of a wroking group to start > standardizing new layer-3 qos signaling protocols. Rather, I would encourage > continuing the work on using RSVP in a scalable manner to unify the various > disparate layer-2 QoS mechanisms in an end-to-end manner (as well as layer-3 > hop by hop mechanisms such as diffserv)... > > Yoram > > -----Original Message----- > From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se] > Sent: Friday, January 21, 2000 11:53 AM > To: RSVP; diffserv; end2end-interest@isi.edu > Cc: Ping Pan > Subject: [Diffserv] QoSSIG BOF > > Reading Ping's and earlier threads [1-3] and works [4-11] it seems that > there are many people who want to contribute to the future of signaled > QoS, but there is no IETF charter for aggregating all these good (not > best :-) efforts since > > * the DS WG excludes new signaling by (re)definition > * the MPLS WG deals with QoS routing and TE which are different > * the ISSLL WG doesn't really suit to DS > * the RSVP WG is closing done > > Shall we start with a BOF in Adelaide? > > /Istvan > > ------------------------------ > Links > > [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html > > [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html > > [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html > > [4] http://icawww1.epfl.ch/srp/ > > [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps > > [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated > Reservation in the Internet, Journal on High Speed Networks, Special > Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 > > [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight > Resource Reservation for Unicast IP Traffic", International WS on > QoS'98, IWQoS'98, May 18-20, 1998 > > [8] http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt > > [9] > http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o > sp-00.txt > > [10] > http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt > > [11] > http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt > > -------------------------------------------------- > Istvan Cselenyi > Telia Research AB Phone: +46-8-7138173 > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > S-12386 Farsta Mobile: +46-70-3228801 > Sweden E-mail: Istvan.I.Cselenyi@telia.se > -------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 15:38:24 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11110 for ; Sat, 22 Jan 2000 15:38:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29281; Sat, 22 Jan 2000 15:11:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29250 for ; Sat, 22 Jan 2000 15:11:38 -0500 (EST) Received: from ursamajor.cisco.com (ursamajor.cisco.com [171.69.63.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10754 for ; Sat, 22 Jan 2000 15:12:49 -0500 (EST) Received: from casner-dsl3.cisco.com (casner-dsl3.cisco.com [10.19.3.100]) by ursamajor.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA07739; Sat, 22 Jan 2000 12:11:42 -0800 (PST) Date: Sat, 22 Jan 2000 12:11:17 -0800 (Pacific Standard Time) From: Stephen Casner To: Joakim Bergkvist cc: Yoram Bernet , RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF In-Reply-To: <388A054F.6701CA71@trab.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org On Sat, 22 Jan 2000, Joakim Bergkvist wrote: > Pm sure you can tweak RSVP into doing anything but this is not really > the point. We beleive that there are much simpler ways of solving the > same problems. If we are right there is a solution which is > fundamentally simpler both in implementation and in performance > requirements. I find this amusing from an historical perspective. One of the motivations (not the only one) for the development of RSVP was that ST-2 was "too complex and not scalable". The designers of RSVP saw a simpler and more straightforward approach. In many ways, RSVP improved upon ST-2, and it did start out simpler. But as the RSVP solution was completed, it was no longer simple. Now those same complaints of complexity and scalability are being lodged against RSVP. Some problems are fundamentally complex. Those who believe they have a simple solution may not have reached the end game. -- Steve _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 15:39:23 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11123 for ; Sat, 22 Jan 2000 15:39:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29326; Sat, 22 Jan 2000 15:13:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29295 for ; Sat, 22 Jan 2000 15:13:10 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10763 for ; Sat, 22 Jan 2000 15:14:21 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 22 Jan 2000 12:12:51 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Sat, 22 Jan 2000 12:12:51 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60945FA7B@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Joakim Bergkvist Cc: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF Date: Sat, 22 Jan 2000 12:12:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org OK - let me try and rephrase... RSVP gives us a certain level of fucntionality in exchange for a certain degree of complexity. This raises two questions: 1. Is it possible to offer the same degree of fucntionality more efficiently (i.e. with a simpler protocol, less com-plexity)? 2. Is the degree of functionality offered by RSVP really required? Bear with me while I address these one at a time: In response to the first, consider that some pretty smart people spent a few years developing and refining RSVP. If you trust that the people who developed RSVP are reasonably good at what they do, and that they believe in keeping things simple where possible, then - probably the protocol is about as simple as it can be to offer the functionality it offers. Perhaps we could spend another five years and provide the same level of functionality with marginal improvements in efficiency/simplicity, but given that the original developers of RSVP probably were pretty good at what they do, I doubt that we could do much better with a new protocol *if* we want to offer the same level of fucntionality. But - perhaps we don't need quite the leel of fucntionality offered by RSVP (e.g. full receiver heterogeneity, other things). I actually believe that there is some excess functionality built into RSVP that doesn't justify its compelxity. So - we can claim that RSVP tried to do too much, scrap it all and start over with another protocol that will be in development for five years. Alternatively, we can look at RSVP, ask where it can be simplified and how we might use a subset of it that is simpler and that achieves most of the functionality that we need. That's really what's been happenning over the last few years. We have been working to adopt from RSVP, those pieces which provide the functionality we need. I hope that you folks that are proposing work on a new protocol are not doing so because you think that the fucntionality of RSVP can be achieed with a significantly lighterweight protocol. If you do - I think that you are casting in doubt the competence of those who created it. Rahter, I suspect that you are of the opinion that one doesn't need all the functionality of RSVP and that thereofre, some complexity could be eliminated. If so, then there are two options - 1) start all over. 2) adapt existing stuff. I tend to believe in adapting existing stuff where possible. Yoram -----Original Message----- From: Joakim Bergkvist [mailto:Joakim.F.Bergkvist@telia.se] Sent: Saturday, January 22, 2000 11:30 AM To: Yoram Bernet Cc: RSVP; diffserv; end2end-interest@isi.edu; issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF Yes Yoram we know you're fond of RSVP! but still.. In the face of the known problems with RSVP we are several people who want to discuss alternatives. So far there have not been a forum to discuss the posibilities of alternative signalling. Instead the people behind these has spent their time listing problems with RSVP (this is what you could discuss in the RSVP BOF). Pm sure you can tweak RSVP into doing anything but this is not really the point. We beleive that there are much simpler ways of solving the same problems. If we are right there is a solution which is fundamentally simpler both in implementation and in performance requirements. This would bennefit small vendors with limited resources (not just Microsoft and Cisco). Lower performance requirements would also mean less impact on design issues and a broader fit into the current product range. My belief is that the IETF as well as RSVP would bennefit from efforts being spent on concrete solutions instead of finding problems with RSVP. If Yoram is right problems will be solved and implementations will get good enough to make RSVP happen before anyone can show a strong alternative. If not maby there is a reason for it.. There is only one way to find out and I'm not afraid! / Joakim Bergkvist, Telia Research Yoram Bernet wrote: > > Actually, in response to the comment: > > "The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL > WG has been working for some time on the mapping of RSVP/Integrated services > to DS. So - this statement is somewhat inaccurate. > > Nonetheless, I do think that it is appropriate ot have a forum to continue > to discuss signaled QoS and its application. In fact, in the discussions > preceeding the closing of the RSVP group, it was suggested that an RSVP > implementation group might be formed. > > I would generally oppose the creation of a wroking group to start > standardizing new layer-3 qos signaling protocols. Rather, I would encourage > continuing the work on using RSVP in a scalable manner to unify the various > disparate layer-2 QoS mechanisms in an end-to-end manner (as well as layer-3 > hop by hop mechanisms such as diffserv)... > > Yoram > > -----Original Message----- > From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se] > Sent: Friday, January 21, 2000 11:53 AM > To: RSVP; diffserv; end2end-interest@isi.edu > Cc: Ping Pan > Subject: [Diffserv] QoSSIG BOF > > Reading Ping's and earlier threads [1-3] and works [4-11] it seems that > there are many people who want to contribute to the future of signaled > QoS, but there is no IETF charter for aggregating all these good (not > best :-) efforts since > > * the DS WG excludes new signaling by (re)definition > * the MPLS WG deals with QoS routing and TE which are different > * the ISSLL WG doesn't really suit to DS > * the RSVP WG is closing done > > Shall we start with a BOF in Adelaide? > > /Istvan > > ------------------------------ > Links > > [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html > > [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html > > [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html > > [4] http://icawww1.epfl.ch/srp/ > > [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps > > [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated > Reservation in the Internet, Journal on High Speed Networks, Special > Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 > > [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight > Resource Reservation for Unicast IP Traffic", International WS on > QoS'98, IWQoS'98, May 18-20, 1998 > > [8] http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt > > [9] > http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o > sp-00.txt > > [10] > http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt > > [11] > http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt > > -------------------------------------------------- > Istvan Cselenyi > Telia Research AB Phone: +46-8-7138173 > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > S-12386 Farsta Mobile: +46-70-3228801 > Sweden E-mail: Istvan.I.Cselenyi@telia.se > -------------------------------------------------- > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 16:50:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11662 for ; Sat, 22 Jan 2000 16:50:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00551; Sat, 22 Jan 2000 16:08:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00525 for ; Sat, 22 Jan 2000 16:08:48 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11337 for ; Sat, 22 Jan 2000 16:09:58 -0500 (EST) Received: from trab.se (udn035.ringin.udn.telia.se [131.115.97.35]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id WAA11435; Sat, 22 Jan 2000 22:09:48 +0100 (MET) Message-ID: <388A1C2A.BA86D3E@trab.se> Date: Sat, 22 Jan 2000 22:07:54 +0100 From: Joakim Bergkvist X-Mailer: Mozilla 4.07 [en] (Win98; I) MIME-Version: 1.0 To: Yoram Bernet CC: Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF References: <078292D50C98D2118D090008C7E9C6A60945FA7B@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Im glad you agree with me that RSVP might be designed for a sligthly more complex problem than the one we are facing. In this case it should be natural to create a new formum for alternatives in order to find out if a slimmer aproach with diffrent properties is better tailored to the need. / Joakim, Telia Research Yoram Bernet wrote: > > OK - let me try and rephrase... > > RSVP gives us a certain level of fucntionality in exchange for a certain > degree of complexity. This raises two questions: > > 1. Is it possible to offer the same degree of fucntionality more efficiently > (i.e. with a simpler protocol, less com-plexity)? > > 2. Is the degree of functionality offered by RSVP really required? > > Bear with me while I address these one at a time: > > In response to the first, consider that some pretty smart people spent a few > years developing and refining RSVP. If you trust that the people who > developed RSVP are reasonably good at what they do, and that they believe in > keeping things simple where possible, then - probably the protocol is about > as simple as it can be to offer the functionality it offers. Perhaps we > could spend another five years and provide the same level of functionality > with marginal improvements in efficiency/simplicity, but given that the > original developers of RSVP probably were pretty good at what they do, I > doubt that we could do much better with a new protocol *if* we want to offer > the same level of fucntionality. > > But - perhaps we don't need quite the leel of fucntionality offered by RSVP > (e.g. full receiver heterogeneity, other things). I actually believe that > there is some excess functionality built into RSVP that doesn't justify its > compelxity. So - we can claim that RSVP tried to do too much, scrap it all > and start over with another protocol that will be in development for five > years. Alternatively, we can look at RSVP, ask where it can be simplified > and how we might use a subset of it that is simpler and that achieves most > of the functionality that we need. That's really what's been happenning over > the last few years. We have been working to adopt from RSVP, those pieces > which provide the functionality we need. > > I hope that you folks that are proposing work on a new protocol are not > doing so because you think that the fucntionality of RSVP can be achieed > with a significantly lighterweight protocol. If you do - I think that you > are casting in doubt the competence of those who created it. Rahter, I > suspect that you are of the opinion that one doesn't need all the > functionality of RSVP and that thereofre, some complexity could be > eliminated. If so, then there are two options - 1) start all over. 2) adapt > existing stuff. > > I tend to believe in adapting existing stuff where possible. > > Yoram > > -----Original Message----- > From: Joakim Bergkvist [mailto:Joakim.F.Bergkvist@telia.se] > Sent: Saturday, January 22, 2000 11:30 AM > To: Yoram Bernet > Cc: RSVP; diffserv; end2end-interest@isi.edu; issll@lcs.mit.edu > Subject: Re: [Diffserv] QoSSIG BOF > > Yes Yoram we know you're fond of RSVP! but still.. In the face of the > known problems with RSVP we are several people who want to discuss > alternatives. So far there have not been a forum to discuss the > posibilities of alternative signalling. Instead the people behind these > has spent their time listing problems with RSVP (this is what you could > discuss in the RSVP BOF). > > Pm sure you can tweak RSVP into doing anything but this is not really > the point. We beleive that there are much simpler ways of solving the > same problems. If we are right there is a solution which is > fundamentally simpler both in implementation and in performance > requirements. This would bennefit small vendors with limited resources > (not just Microsoft and Cisco). Lower performance requirements would > also mean less impact on design issues and a broader fit into the > current product range. > > My belief is that the IETF as well as RSVP would bennefit from efforts > being spent on concrete solutions instead of finding problems with RSVP. > If Yoram is right problems will be solved and implementations will get > good enough to make RSVP happen before anyone can show a strong > alternative. If not maby there is a reason for it.. There is only one > way to find out and I'm not afraid! > > / Joakim Bergkvist, Telia Research > > > > Yoram Bernet wrote: > > > > Actually, in response to the comment: > > > > "The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL > > WG has been working for some time on the mapping of RSVP/Integrated > services > > to DS. So - this statement is somewhat inaccurate. > > > > Nonetheless, I do think that it is appropriate ot have a forum to continue > > to discuss signaled QoS and its application. In fact, in the discussions > > preceeding the closing of the RSVP group, it was suggested that an RSVP > > implementation group might be formed. > > > > I would generally oppose the creation of a wroking group to start > > standardizing new layer-3 qos signaling protocols. Rather, I would > encourage > > continuing the work on using RSVP in a scalable manner to unify the > various > > disparate layer-2 QoS mechanisms in an end-to-end manner (as well as > layer-3 > > hop by hop mechanisms such as diffserv)... > > > > Yoram > > > > -----Original Message----- > > From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se] > > Sent: Friday, January 21, 2000 11:53 AM > > To: RSVP; diffserv; end2end-interest@isi.edu > > Cc: Ping Pan > > Subject: [Diffserv] QoSSIG BOF > > > > Reading Ping's and earlier threads [1-3] and works [4-11] it seems that > > there are many people who want to contribute to the future of signaled > > QoS, but there is no IETF charter for aggregating all these good (not > > best :-) efforts since > > > > * the DS WG excludes new signaling by (re)definition > > * the MPLS WG deals with QoS routing and TE which are different > > * the ISSLL WG doesn't really suit to DS > > * the RSVP WG is closing done > > > > Shall we start with a BOF in Adelaide? > > > > /Istvan > > > > ------------------------------ > > Links > > > > [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html > > > > [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html > > > > [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html > > > > [4] http://icawww1.epfl.ch/srp/ > > > > [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps > > > > [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated > > Reservation in the Internet, Journal on High Speed Networks, Special > > Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 > > > > [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight > > Resource Reservation for Unicast IP Traffic", International WS on > > QoS'98, IWQoS'98, May 18-20, 1998 > > > > [8] > http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt > > > > [9] > > > http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o > > sp-00.txt > > > > [10] > > http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt > > > > [11] > > > http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt > > > > -------------------------------------------------- > > Istvan Cselenyi > > Telia Research AB Phone: +46-8-7138173 > > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > > S-12386 Farsta Mobile: +46-70-3228801 > > Sweden E-mail: Istvan.I.Cselenyi@telia.se > > -------------------------------------------------- > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 20:30:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12882 for ; Sat, 22 Jan 2000 20:30:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05635; Sat, 22 Jan 2000 20:01:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05597 for ; Sat, 22 Jan 2000 20:01:32 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12727 for ; Sat, 22 Jan 2000 20:02:42 -0500 (EST) Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id CAA12936; Sun, 23 Jan 2000 02:02:35 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Sun, 23 Jan 2000 02:02:34 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D5E5632@trab-hermes.haninge.trab.se> From: Istvan Cselenyi To: Joakim Bergkvist , "'Yoram Bernet '" , "'Ping Pan '" Cc: "'boomerang@soha.ttt.bme.hu'" , "'RSVP '" , "'diffserv '" , "'end2end-interest@ISI.EDU '" , "'issll@lcs.mit.edu '" Subject: RE: [Diffserv] QoSSIG BOF Date: Sun, 23 Jan 2000 02:02:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Summing up the QoSSIG game (before leaving some of the mailing lists) there are already two reasons to open a new forum 1. discuss new protocols as extension, replacement or successor of RSVP 2. discuss adjusting the functionality and comlexity of RSVP Any other arguments for/against a BOF?! /Istvan PS Yoram Bernet wrote: > > "The ISSLL WG doesn't really suit to DS", I would point out that the > > ISSLL WG has been working for some time on the mapping of > > RSVP/Integrated services to DS. So - this statement is somewhat > > inaccurate. I meant the historical root of ISSLL and not the current IS/DS work. But do you think that ISSLL is the right forum for all these? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sat Jan 22 23:49:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16199 for ; Sat, 22 Jan 2000 23:49:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08393; Sat, 22 Jan 2000 23:23:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08364 for ; Sat, 22 Jan 2000 23:23:12 -0500 (EST) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15575 for ; Sat, 22 Jan 2000 23:24:22 -0500 (EST) Received: from IBM (1Cust234.tnt20.sfo3.da.uu.net [63.27.224.234]) by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id UAA23177; Sat, 22 Jan 2000 20:24:11 -0800 (PST) Message-Id: <200001230424.UAA23177@hawk.prod.itd.earthlink.net> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sat, 22 Jan 2000 20:19:24 -0800 To: Joakim Bergkvist , Yoram Bernet From: Lixia Zhang Subject: Re: [Diffserv] QoSSIG BOF Cc: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu In-Reply-To: <388A054F.6701CA71@trab.se> References: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org At 11:30 AM 1/22/00 , Joakim Bergkvist wrote: >Yes Yoram we know you're fond of RSVP! but still.. In the face of the >known problems with RSVP we are several people who want to discuss >alternatives. So far there have not been a forum to discuss the >posibilities of alternative signalling. Instead the people behind these >has spent their time listing problems with RSVP (this is what you could >discuss in the RSVP BOF). There might be some people who try to find problems with RSVP solely for the sake of finding the problems (perhaps as materials for academic papers) But majority of problems I have heard are from those who run into problems with RSVP in real life (e.g. MPLS people faced problem with refresh scalability). Identifying those problems seems a good first step in developing viable alternatives. >Pm sure you can tweak RSVP into doing anything but this is not really >the point. We beleive that there are much simpler ways of solving the >same problems. That sounds great. Tell us your much simpler ways of doing the samething. (That would be a lot more productive use of the mailing list than bashing RSVP) Lixia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 00:43:54 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16760 for ; Sun, 23 Jan 2000 00:43:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09438; Sun, 23 Jan 2000 00:14:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09409 for ; Sun, 23 Jan 2000 00:14:24 -0500 (EST) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16458 for ; Sun, 23 Jan 2000 00:15:35 -0500 (EST) Received: from IBM (1Cust218.tnt4.sfo3.da.uu.net [63.23.12.218]) by snipe.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id VAA09360; Sat, 22 Jan 2000 21:15:26 -0800 (PST) Message-Id: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> X-Sender: lixia@131.179.96.157 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sat, 22 Jan 2000 21:15:40 -0800 To: Yoram Bernet , Joakim Bergkvist From: Lixia Zhang Subject: RE: [Diffserv] QoSSIG BOF Cc: RSVP , diffserv , end2end-interest@isi.edu In-Reply-To: <078292D50C98D2118D090008C7E9C6A60945FA7B@STAY.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org At 12:12 PM 1/22/00 , Yoram Bernet wrote: > ...... >But - perhaps we don't need quite the leel of fucntionality offered by RSVP >(e.g. full receiver heterogeneity, other things). I actually believe that >there is some excess functionality built into RSVP that doesn't justify its >compelxity. So - we can claim that RSVP tried to do too much, scrap it all >and start over with another protocol that will be in development for five >years. Alternatively, we can look at RSVP, ask where it can be simplified >and how we might use a subset of it that is simpler and that achieves most >of the functionality that we need. That's really what's been happenning over >the last few years. We have been working to adopt from RSVP, those pieces >which provide the functionality we need. > >I hope that you folks that are proposing work on a new protocol are not >doing so because you think that the fucntionality of RSVP can be achieed >with a significantly lighterweight protocol. If you do - I think that you >are casting in doubt the competence of those who created it. I personally would not think that way. I agree that the current RSVP is complex. I would also like to point out that RSVP did not start as complex, but ended up there. Over all these years participating in IETF ever since the very first meeting, I've seen many best people put in their best effort in dealing with Internet problems and developing solutions. However I must admit that I have not found this process the right place to produce *simple* protocols. For those who want a simple protocol: I am all for it, just that experience has shown that setting up a BOF/WG is NOT the way to reach you goal. My personal suggestion would be to lock the door with a few friends till the design is finished, then it'd be a better time to run a BOF to convince others to go with you. Lixia _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 04:25:09 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07198 for ; Sun, 23 Jan 2000 04:25:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19293; Sun, 23 Jan 2000 03:54:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19186 for ; Sun, 23 Jan 2000 03:54:46 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04732 for ; Sun, 23 Jan 2000 03:55:59 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Sun Jan 23 03:55:19 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.40.247]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id DAA20624; Sun, 23 Jan 2000 03:55:15 -0500 (EST) Message-ID: <388AC185.B42CD01@research.bell-labs.com> Date: Sun, 23 Jan 2000 03:53:25 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Stephen Casner CC: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Stephen Casner wrote: > > > I find this amusing from an historical perspective. One of the > motivations (not the only one) for the development of RSVP was that > ST-2 was "too complex and not scalable". The designers of RSVP saw a > simpler and more straightforward approach. In many ways, RSVP > improved upon ST-2, and it did start out simpler. But as the RSVP > solution was completed, it was no longer simple. > > Now those same complaints of complexity and scalability are being > lodged against RSVP. Some problems are fundamentally complex. Those > who believe they have a simple solution may not have reached the end > game. > -- Steve > Steve, IMHO, this is not a RSVP problem. Rather the network has grown too fast in the past few years. Please take a look at the network growth chart at http://www.cs.columbia.edu/~pingpan/projects/net_growth.gif. I don't think that one single protocol can provide the resource reservation solution to the world. RSVP may be already very good at what it does. We can continue to enhance RSVP again and again and squeeze the last drop of efficiency out of it, but maybe we should take one step back and re-evaluate the whole problem once again with new knowledge and new requirements. Let's fact it: during the days of original RSVP, the network was smaller. There was no MPLS (or connection-oriented IP packet-switching network) requirements. There was not much of WEB traffic if any. Instead people were expecting the coming of wild-spread multicast deployment to the entire network, and expecting the hugh number of teleconferencing applications. At the time, the Internet was a simple dumb-network/smart-end-host model. Nowadays, the Internet has smarter end-hosts and not-so-dumb networks. IETF's Traffic Engineering WG and many policy related WG's are focusing on how to configure the networks efficiently. So the original RSVP was designed with different objectives. I would think that we should first understand the problems involving with resource reservation, then try to solve the problems. In the past year, Ellen Hahne, Henning Schulzrinne and I had tried to understand the scaling problem with RSVP. After collecting some data from the network, we reasoned out some of the issues: First, we need a hierarchical reservation architecture. Making reservations on one flat network will not scale! Second, even when we are dealing with reservations at the network domain level, if we use signaling protocols with N**2 properties, such as RSVP, it will still be tough to work. Thus, our work on BGRP (http://www.ietf.org/internet-drafts/draft-pan-bgrp-framework-00.txt) is to propose an inter-domain reservation protocol running between BGP border routers. End users can use RSVP within their networks. RSVP flows can aggregate into the BGRP-reservation trunks at network edge. Thus the whole system will scale. This reminds me of the evolution of routing protocols. RIP was fine (after bug fixes ;-)) at what it does at small networks. But we could not use it to run a very large backone. With new requirements in mind, BGP came out. So a hierarchical routing model had made the Internet what it is today. We may adapt a similar approach to the reservation system. Best regards, -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 04:32:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07345 for ; Sun, 23 Jan 2000 04:32:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19540; Sun, 23 Jan 2000 04:04:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19517 for ; Sun, 23 Jan 2000 04:04:47 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05662 for ; Sun, 23 Jan 2000 04:06:00 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Sun Jan 23 04:05:19 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.40.247]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id EAA20728; Sun, 23 Jan 2000 04:05:09 -0500 (EST) Message-ID: <388AC3D4.191D7426@research.bell-labs.com> Date: Sun, 23 Jan 2000 04:03:16 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Lixia Zhang CC: Joakim Bergkvist , Yoram Bernet , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF References: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.corp.microsoft.com> <200001230424.UAA23177@hawk.prod.itd.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Lixia Zhang wrote: > > > But majority of problems I have heard are from those who run into problems > with RSVP in real life (e.g. MPLS people faced problem with refresh > scalability). Identifying those problems seems a good first step in > developing viable alternatives. > Lixia, Yes. Agree! I had talked to several developers last year. We all thought that RSVP is taking a lot of CPU cycles. If a domain becomes too big and the number of border-to-border connections increases, people will be worried about the CPU shortage. > That sounds great. > Tell us your much simpler ways of doing the samething. > (That would be a lot more productive use of the mailing list than bashing > RSVP) > Once again, agree. Bashing RSVP will not help. > Lixia > Regards, - Ping _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 07:03:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08146 for ; Sun, 23 Jan 2000 07:03:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21152; Sun, 23 Jan 2000 06:27:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA21122 for ; Sun, 23 Jan 2000 06:27:34 -0500 (EST) Received: from alijku04.edvz.uni-linz.ac.at (alijku04.edvz.uni-linz.ac.at [140.78.182.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07850 for ; Sun, 23 Jan 2000 06:28:45 -0500 (EST) Received: from Iglo (z2225.Raab-Heim.Uni-Linz.AC.AT [193.171.34.98]) by alijku04.edvz.uni-linz.ac.at (8.8.8/8.8.8) with SMTP id MAA76262; Sun, 23 Jan 2000 12:28:32 +0100 Message-Id: <3.0.32.20000123122849.00929bd0@mikasa.tk.uni-linz.ac.at> X-Sender: michael@mikasa.tk.uni-linz.ac.at X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 23 Jan 2000 12:28:50 +0100 To: Istvan Cselenyi , Joakim Bergkvist , "'Yoram Bernet '" , "'Ping Pan '" From: Michael Welzl Subject: RE: [Diffserv] QoSSIG BOF Cc: "'boomerang@soha.ttt.bme.hu'" , "'RSVP '" , "'diffserv '" , "'end2end-interest@ISI.EDU '" , "'issll@lcs.mit.edu '" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org >Summing up the QoSSIG game (before leaving some of the mailing lists) there >are already two reasons to open a new forum > >1. discuss new protocols as extension, replacement or successor of RSVP >2. discuss adjusting the functionality and comlexity of RSVP > >Any other arguments for/against a BOF?! Using RSVP, an end system basically asks whether certain QoS requirements will be met. This is based on QoS parameters such as the bandwidth, delay, ... We can move the determination to the end system and discuss simply making this information available via SNMP, for example. This would be a discussion about MIB rights, then. I absolutely agree we need a BOF. Here's another QoS signalling protocol: http://www.ietf.org/internet-drafts/draft-welzl-ptp-02.txt This protocol is also discussed in: Welzl, M.: "PTP: Better Feedback for Adaptive Distributed Multimedia Applications on the Internet", IPCCC 2000 (accepted for publication) http://www.tk.uni-linz.ac.at/~michael/publications/ipccc2000.ps And yes, I agree that we could basically use a tweaked RSVP instead of PTP; still, PTP has a mechanism (the compensation for single missing routers) that can't be added to RSVP unless we remove the reservation part :) Regards, Michael Welzl _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 08:39:10 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08732 for ; Sun, 23 Jan 2000 08:39:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22268; Sun, 23 Jan 2000 08:08:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22234 for ; Sun, 23 Jan 2000 08:08:31 -0500 (EST) Received: from phoebe.eim.surrey.ac.uk (IDENT:exim@phoebe.eim.surrey.ac.uk [131.227.74.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08456 for ; Sun, 23 Jan 2000 08:09:36 -0500 (EST) Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12CMlZ-0005Wt-00; Sun, 23 Jan 2000 13:09:17 +0000 Date: Sun, 23 Jan 2000 13:09:14 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Lixia Zhang cc: Yoram Bernet , Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu Subject: RE: [Diffserv] QoSSIG BOF In-Reply-To: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org On Sat, 22 Jan 2000, Lixia Zhang wrote: > Over all these years participating in IETF ever since the very first > meeting, I've seen many best people put in their best effort in dealing > with Internet problems and developing solutions. However I must admit that > I have not found this process the right place to produce *simple* protocols. Indeed. That's the same argument that Bruce Schneier raises when reviewing IPsec and calling for half of it to be junked: http://www.counterpane.com/ipsec.html L. > For those who want a simple protocol: I am all for it, just that experience > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > personal suggestion would be to lock the door with a few friends till the > design is finished, then it'd be a better time to run a BOF to convince > others to go with you. > > Lixia PGP _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 11:42:06 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10293 for ; Sun, 23 Jan 2000 11:42:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24476; Sun, 23 Jan 2000 11:10:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24452 for ; Sun, 23 Jan 2000 11:10:46 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09943 for ; Sun, 23 Jan 2000 11:11:59 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Sun Jan 23 11:10:07 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.43.222]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA25543; Sun, 23 Jan 2000 11:10:03 -0500 (EST) Message-ID: <388B2729.90C452A0@research.bell-labs.com> Date: Sun, 23 Jan 2000 11:07:05 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: Lixia Zhang , Yoram Bernet , Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu Subject: Re: [Diffserv] QoSSIG BOF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Sigh! The reality is that going through the entire IETF process is taking longer and longer. Maybe we are getting too many people from the old standard communities, people somehow are more interested in the process rather than the technical "meat". ;-) Big companies start to talk about "more IETF presence" while sending too many non-engineers (or slideware engineers) to the Internet ENGINEERING Task Force meetings. It's becoming more common that vendors are shipping products based on the drafts: MPLS products are based on the drafts; the entire ISP routing operation is based on a draft (draft-ietf-idr-bgp4-xx.txt). ;-) I think we need a BOF if we all promise to get job done fast. Otherwise, agree with Lixia, why not lock the door and start hacking? 2 more cents, - Ping Lloyd Wood wrote: > > On Sat, 22 Jan 2000, Lixia Zhang wrote: > > > Over all these years participating in IETF ever since the very first > > meeting, I've seen many best people put in their best effort in dealing > > with Internet problems and developing solutions. However I must admit that > > I have not found this process the right place to produce *simple* protocols. > > Indeed. That's the same argument that Bruce Schneier raises > when reviewing IPsec and calling for half of it to be junked: > > http://www.counterpane.com/ipsec.html > > L. > > > For those who want a simple protocol: I am all for it, just that experience > > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > > personal suggestion would be to lock the door with a few friends till the > > design is finished, then it'd be a better time to run a BOF to convince > > others to go with you. > > > > Lixia > -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 15:00:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11288 for ; Sun, 23 Jan 2000 15:00:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04998; Sun, 23 Jan 2000 14:25:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04975 for ; Sun, 23 Jan 2000 14:25:07 -0500 (EST) Received: from bird.eyematic.com (bird.eyematic.com [38.186.83.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10995 for ; Sun, 23 Jan 2000 14:26:17 -0500 (EST) Received: from eyematic.com (helmut.eyematic.com [38.186.83.29]) by bird.eyematic.com (8.9.3/8.9.3) with ESMTP id LAA10565; Sun, 23 Jan 2000 11:24:42 -0800 Message-ID: <388B550E.89B08B62@eyematic.com> Date: Sun, 23 Jan 2000 11:22:54 -0800 From: Tim Dorcey X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lixia Zhang CC: RSVP , diffserv Subject: Re: [Diffserv] QoSSIG BOF References: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Lixia Zhang wrote: > For those who want a simple protocol: I am all for it, just that experience > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > personal suggestion would be to lock the door with a few friends till the > design is finished, then it'd be a better time to run a BOF to convince > others to go with you. Absolutely! I have noticed that the size of a problem space tends to grow exponentially (factorially?) with the number of participants in a work group, while the ability to devise a solution grows linearly at best. Starting off with the goal of filling some n-space is generally a recipe for failure. But, a point in n-space is still just a point: simple solutions are possible by restricting scope. Then, 2 such points define a line, and so on, so that a more general solution space can grow from specific instances that are end-to-end complete, perhaps never filling n-space, but oriented to cover the most important points in practice. Tim _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 15:13:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11452 for ; Sun, 23 Jan 2000 15:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05649; Sun, 23 Jan 2000 14:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05619 for ; Sun, 23 Jan 2000 14:39:12 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11107 for ; Sun, 23 Jan 2000 14:40:23 -0500 (EST) Received: (from braden@localhost) by boreas.isi.edu (8.8.7/8.8.6) id LAA08904; Sun, 23 Jan 2000 11:39:59 -0800 (PST) Date: Sun, 23 Jan 2000 11:39:59 -0800 (PST) From: Bob Braden Message-Id: <200001231939.LAA08904@boreas.isi.edu> To: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se Subject: Re: [Diffserv] QoSSIG BOF Cc: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org *> *> Pm sure you can tweak RSVP into doing anything but this is not really *> the point. We beleive that there are much simpler ways of solving the *> same problems. If we are right there is a solution which is I would seriously question whether there are "much simpler ways of solving the same problems". However, there certainly would be simpler ways to solve a simpler problem. Bob Braden _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Sun Jan 23 18:17:33 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12280 for ; Sun, 23 Jan 2000 18:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07874; Sun, 23 Jan 2000 17:44:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07841 for ; Sun, 23 Jan 2000 17:43:55 -0500 (EST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12099 for ; Sun, 23 Jan 2000 17:45:08 -0500 (EST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA18620 for ; Sun, 23 Jan 2000 14:44:53 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id OAA22412 for ; Sun, 23 Jan 2000 14:45:09 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Sun, 23 Jan 2000 14:45:09 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Sun, 23 Jan 2000 17:45:07 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356ED99@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Bob Braden'" Cc: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF Date: Sun, 23 Jan 2000 17:44:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Bob Braden wrote: > I would seriously question whether there are "much simpler ways of > solving the same problems". > > However, there certainly would be simpler ways to solve a simpler > problem. Amen to that. Before Brian gets this thread banished from diffserv, one interesting new requirement for CoS/QoS signaling, that might not be doable with something simpler and less capable, is going to be this new idea of doing real, direct routing of IP datagrams through routers ported to WDM optical backbones. The problems seem to emerge whenever channels (circuits) must defined, for whatever set of reasons. And, especially, when one of these channels must be chosen, packet by packet, based on a multivariate set of criteria. When these circumstances occur, people scramble for that simple solution, and it historically doesn't seem to matrialize. Locking a few good people in a room until the work is done is an attractive but politically incorrect solution these days. Companies have resorted to this method, sometimes in exasperation, only to have their solution labeled "proprietary," to be further "enhanced" by a standards body. Examples, of course, are legion. Maybe some problems are irreducible. Bert albert.e.manfredi@boeing.com _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 01:38:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19297 for ; Mon, 24 Jan 2000 01:38:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22628; Mon, 24 Jan 2000 01:10:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22524 for ; Mon, 24 Jan 2000 01:10:32 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17303 for ; Mon, 24 Jan 2000 01:11:42 -0500 (EST) From: Masataka Ohta Message-Id: <200001240611.PAA09057@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA09057; Mon, 24 Jan 2000 15:11:09 +0900 Subject: RE: [Diffserv] QoSSIG BOF To: Albert.Manfredi@PHL.Boeing.com (Manfredi Albert E) Date: Mon, 24 Jan 0 15:11:08 JST Cc: braden@ISI.EDU, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu In-Reply-To: <4102273CEB77D211869200805FE6F59356ED99@xch-phl-01.he.boeing.com>; from "Manfredi, Albert E" at Jan 24, 100 8:22 am X-Mailer: ELM [version 2.3 PL11] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Bert; > > I would seriously question whether there are "much simpler ways of > > solving the same problems". > > > > However, there certainly would be simpler ways to solve a simpler > > problem. > > Amen to that. > > Before Brian gets this thread banished from diffserv, That is the proper behaviour because CoS and QoS are totally different. Brian is a honest person that I notice he always distinguishes them. > one interesting new > requirement for CoS/QoS signaling, that might not be doable with something > simpler and less capable, is going to be this new idea of doing real, direct > routing of IP datagrams through routers ported to WDM optical backbones. Label switching by physical layer labels is not a new idea. I wrote it in one of my INET'97 papers (there are three) titled "Hop, Step, but Don't Jump for Scalable Lower-Layer Forwarding of Best-Effort Traffic". It says thing like: Hence, it's better to reuse an existing mechanism, RSVP, for the signaling of virtual links. As the virtual link is best effort, all we need is a specification of "best effort" service class. A possible interpretation is that the absence of service class in RSVP messages means "best effort" class. something like which is seemingly reinvented elsewhere. But the main point of the paper is that best effort label switching does not scale and performance improvement, if any, is limited to a small constant. Especially, label switching is useless for multicast. In short, the approach has a dead end. Note also that WDM cross connect is a waste of budget because Spatial DM is more than enough unless you need Internet backbone much faster than Tbps. > When these circumstances occur, people scramble for that simple solution, > and it historically doesn't seem to matrialize. What's happening is that people do not describe the problems and misunderstand them unsolvable, Then, some people seeks alternatives, such as CoS, however poor they are, even though the alternatives does not satisfy the requirements of most real world applications. Other people, like Ping, makes protocol complex only to make the unsolvability obscure. > Examples, of course, are legion. Maybe some problems are irreducible. QoS scalability problems are easily reducible by properly architected parallel processors. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 04:31:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00289 for ; Mon, 24 Jan 2000 04:31:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27390; Mon, 24 Jan 2000 03:32:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27359 for ; Mon, 24 Jan 2000 03:32:29 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29639 for ; Mon, 24 Jan 2000 03:33:43 -0500 (EST) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jan 2000 08:33:22 +0000 To: Lixia Zhang cc: Yoram Bernet , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF In-reply-to: Your message of "Sat, 22 Jan 2000 20:19:24 PST." <200001230424.UAA23177@hawk.prod.itd.earthlink.net> Date: Mon, 24 Jan 2000 08:33:22 +0000 Message-ID: <1199.948702802@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org >>There might be some people who try to find problems with RSVP solely for >>the sake of finding the problems (perhaps as materials for academic papers) well, in any "merely" academic conference or journal i have been associated with, a paper that "solely found problems" would either be finding interesting problems, or would be propsoing interesting solutions, or both - academics are funny people (most the net was developed by them:-) but to be fair, there has been an increasing number of academic (and other) people in recent years submitting i-ds which would go in their annual researc h report but not get into a good conference or journal - good includes: (ACM/IEEE Transactions on Networking, ACM SIGCOMM, IEEE Infocom, ICNP, NOSSDAV, Packet Video, and similar...) >>But majority of problems I have heard are from those who run into problems >>with RSVP in real life (e.g. MPLS people faced problem with refresh >>scalability). Identifying those problems seems a good first step in >>developing viable alternatives. >> yes, the papers cited in this discussion mostly not only identify problems, but also propose some viable alternatives - however (as a guilty party), the majority could be implemented as relatively modest deltas (options, enhancements/configurations) to RSVP >>>Pm sure you can tweak RSVP into doing anything but this is not really >>>the point. We beleive that there are much simpler ways of solving the >>>same problems. >>That sounds great. >>Tell us your much simpler ways of doing the samething. >>(That would be a lot more productive use of the mailing list than bashing >>RSVP) agree on the topic of a BOF - i think it would be good IFF someone writes down a good set of things that a) would be good RSVP work items b) would be useful (or at least are somewhat compelling) but can;'t easily be seen to be implemted in the RSVP framework. >> cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 04:34:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00300 for ; Mon, 24 Jan 2000 04:34:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27994; Mon, 24 Jan 2000 03:55:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27962 for ; Mon, 24 Jan 2000 03:55:00 -0500 (EST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29840 for ; Mon, 24 Jan 2000 03:56:15 -0500 (EST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AE0F@monza.broadswitch.com> From: Thomas Eklund To: "'Brian E Carpenter'" , Thomas Eklund Cc: "'diffserv@ietf.org'" , "'yoramb@microsoft.com'" , "'andrew@extremenetworks.com'" , "'slblake@torrentnet.com'" Subject: RE: [Diffserv] TCB's in diffserv router model. Date: Mon, 24 Jan 2000 09:55:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA27963 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit No but my point was perhaps it might be a good thing to write a conceptual model draft for diffserv in different hardware arhitecthures like crossbar, shared memory, bus oriented... It could be written like a Informational RFC as well or BCP for HW... And I understand that the IETF are not designing HW but today there are many companies that offers integrated L2, L3 functionality in HW... Have there been any effort in defining that before? /Thomas > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, January 21, 2000 11:49 PM > To: Thomas Eklund > Cc: 'diffserv@ietf.org'; 'yoramb@microsoft.com'; > 'andrew@extremenetworks.com'; 'slblake@torrentnet.com' > Subject: Re: [Diffserv] TCB's in diffserv router model. > > > Thomas, > > We aren't designing hardware; this is only a conceptual model. > > The current functional decomposition has been debated for quite > a while. Any choice of decomposition is arbitrary, and this is > the one that got consensus. > > As soon as we get the draft revised according to the discussion > in Washington, we will be going for Informational RFC. > > Regards > > Brian Carpenter > diffserv co-chair > > > Thomas Eklund wrote: > > > > Oops I forgot the forwarder block FOB... But that was > obviuos but I did not > > see that in the draft. > > > > Then you would have three buliding blocks; Forwarding > block, filter block > > and traffic conditioning block... > > > > This would be very good to fit the different models i HW > (shared memory > > design, crossbar, shared bus etc...)... > > > > I dont know if this should be included in the draft or a new one..? > > Any Comments? > > > > /Thomas > > > -----Original Message----- > > > From: Thomas Eklund [mailto:thomas.eklund@switchcore.com] > > > Sent: Thursday, January 20, 2000 5:58 PM > > > To: 'diffserv@ietf.org' > > > Cc: 'yoramb@microsoft.com'; 'andrew@extremenetworks.com'; > > > 'slblake@torrentnet.com' > > > Subject: [Diffserv] TCB's in diffserv router model. > > > > > > > > > Hi, > > > I have some questions about the > draft-ietf-diffserv-model-01.txt... > > > > > > I wonder why TCB (Traffic Conditioning Block) is specified to > > > include the > > > classifier stage?? > > > > > > I would like to see something like > > > Filter Block (BA, MF filtering) > > > Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, > > > Queuing/Scheduling) > > > > > > So that you set the ingress and egress filtering rules in the > > > FB and applies > > > a TCB for every FB. > > > > > > So the FB is in, out, in/out (flow). > > > > > > Then I would also like to see a paper on how ipsec in > tunnel mode over > > > diffserv should be handled at the same time in FB. Or is > > > there any work > > > already done on this? > > > > > > So the model would become: > > > FB + TCB = (filtering block for both security filters and qos > > > classification) + (and a traffic conditioning block that > > > apply the traffic > > > behaviour) = What treatment and how a packet is forwarded > > > > > > Any comments? > > > > > > Best Regards Thomas > > > > > > Thomas Eklund > > > System Design, MSc > > > SwitchCore i Stockholm AB > > > Positionen 153, Hangövägen 19 > > > SE-115 74 Stockholm, Sweden > > > phone +46 8 5630 5815 > > > fax +46 8 5630 5801 > > > mobile +46 709 952910 > > > Thomas.Eklund@switchcore.com > > > visit our web page at http://www.switchcore.com > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 05:26:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00841 for ; Mon, 24 Jan 2000 05:26:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29750; Mon, 24 Jan 2000 04:39:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29718 for ; Mon, 24 Jan 2000 04:39:34 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00367 for ; Mon, 24 Jan 2000 04:40:48 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id KAA16230; Mon, 24 Jan 2000 10:40:40 +0100 (MET) Received: from betz by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA00887; Mon, 24 Jan 2000 10:40:40 +0100 From: Lars.Westberg@era-t.ericsson.se (Lars Westberg T/NI 2) Received: by betz (8.8.8+Sun/client-1.3) id KAA24320; Mon, 24 Jan 2000 10:40:39 +0100 (MET) Date: Mon, 24 Jan 2000 10:40:39 +0100 (MET) Message-Id: <200001240940.KAA24320@betz> To: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se, braden@ISI.EDU Subject: Re: [Diffserv] QoSSIG BOF Cc: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi! We have a need for a low cost solution, but our problem is not end-to-end. We would rather like to solve a intra-domain solution or edge-to-edge solution. Our need is much simplier than solving reservation from a host-to-network or between different administrative domains. Our edge could be an edge-router or gateway. We are assuming that this method should be a complement to the QOS-tool-box for some dedicated networks with certain characteristic and not for all kinds of networks. We are mostly interested of QOS for Real-time traffic such as voice. Our basic problems are: * High volume of speech-traffic. The reservation scheme has to support up to 70-90% of voice traffic. * Edge-to-edge reservation within one adminstrative domain, not end-to-end. * Mobility. Our traffic is moving between different areas in the network. semipermanent trunk allocation implies need for more transmission and O&M. Cost for operation and maintenance might be the biggest issue. * Fast reservation. The time between request and acknowledgement of the reservation should be in the order of the forwarding delay. We have as well a draft (a marker based scheme, you can find it in the library) but I would be very interested to get other proposals from other peoples. Regards Lars Westberg Ericsson Research _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 05:49:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01017 for ; Mon, 24 Jan 2000 05:49:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00644; Mon, 24 Jan 2000 05:05:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00609 for ; Mon, 24 Jan 2000 05:05:16 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00596 for ; Mon, 24 Jan 2000 05:06:30 -0500 (EST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id LAA09655; Mon, 24 Jan 2000 11:06:28 +0100 (MET) Received: from eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id LAA08588; Mon, 24 Jan 2000 11:06:23 +0100 (MET) Message-ID: <388C241E.2930078F@eth.ericsson.se> Date: Mon, 24 Jan 2000 11:06:22 +0100 From: Zoltan Richard Turanyi Organization: Ericsson TrafficLab X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Hungarian, hu, en MIME-Version: 1.0 To: Lixia Zhang CC: Yoram Bernet , Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu Subject: Re: [Diffserv] QoSSIG BOF References: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Over all these years participating in IETF ever since the very first > meeting, I've seen many best people put in their best effort in dealing > with Internet problems and developing solutions. However I must admit that > I have not found this process the right place to produce *simple* protocols. > > For those who want a simple protocol: I am all for it, just that experience > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > personal suggestion would be to lock the door with a few friends till the > design is finished, then it'd be a better time to run a BOF to convince > others to go with you. > > Lixia This is a very good point. The logic is simple: - IETF protocols must be extensible. - Anyone can propose extensions. - It is hard to reject extensions which provide useful functionality. => Protocols end up being complex. (See also Mobile IP besides RSVP as good example.) One way out might be the hierarchical thinking. This may have a few benefits. 1. The problem might be different on local and global scales, so providing a few local and one global protocol that interoperate may be better that putting everything into one protocol. 2. Locally anyone can use whatever local protocol he thinks best suits his domain. 3. Extensions or adjustments that are needed by only some of the local domains, may not effect other domains. 4. Scaling might be easier. On the negative side, interoperability and end2end is harder to achieve. Still it may be considered here and in other areas as well. In case of routing it worked. /Zoltan -- Zoltan Richard Turanyi Research Fellow, Ericsson Hungary Traffic Analysis and Network Performance Lab _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 07:15:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02347 for ; Mon, 24 Jan 2000 07:15:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03018; Mon, 24 Jan 2000 06:37:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02993 for ; Mon, 24 Jan 2000 06:37:18 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01346 for ; Mon, 24 Jan 2000 06:38:33 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id NAA27217; Mon, 24 Jan 2000 13:38:19 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14476.14763.3724.470929@lohi.eng.telia.fi> Date: Mon, 24 Jan 2000 13:38:19 +0200 (EET) To: Lars.Westberg@era-t.ericsson.se (Lars Westberg T/NI 2) Cc: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se, braden@ISI.EDU, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF In-Reply-To: <200001240940.KAA24320@betz> References: <200001240940.KAA24320@betz> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit dynamic, interdomain qos reservations are not only a technical, but even more so, an administrative problem. even if you find a good technical solution for finding and making the resources available, it may still be not enough for actual interdomain deployment. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 07:21:38 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02514 for ; Mon, 24 Jan 2000 07:21:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03395; Mon, 24 Jan 2000 06:51:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03372 for ; Mon, 24 Jan 2000 06:51:27 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01665 for ; Mon, 24 Jan 2000 06:52:42 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id MAA16921; Mon, 24 Jan 2000 12:52:31 +0100 (MET) Received: from betz by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA06397; Mon, 24 Jan 2000 12:52:30 +0100 From: Lars.Westberg@era-t.ericsson.se (Lars Westberg T/NI 2) Received: by betz (8.8.8+Sun/client-1.3) id MAA24378; Mon, 24 Jan 2000 12:52:30 +0100 (MET) Date: Mon, 24 Jan 2000 12:52:30 +0100 (MET) Message-Id: <200001241152.MAA24378@betz> To: Lars.Westberg@era-t.ericsson.se, jh@lohi.eng.telia.fi Subject: Re: [Diffserv] QoSSIG BOF Cc: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se, braden@ISI.EDU, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Hi! I agree, but an intra-domain problem might be less complicated to solve and we might use different solutions for different problems. - Lasse ----- Begin Included Message ----- From jh@lohi.eng.telia.fi Mon Jan 24 12:38:23 2000 From: Juha Heinanen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Mon, 24 Jan 2000 13:38:19 +0200 (EET) To: Lars.Westberg@era-t.ericsson.se (Lars Westberg T/NI 2) Cc: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se, braden@ISI.EDU, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF dynamic, interdomain qos reservations are not only a technical, but even more so, an administrative problem. even if you find a good technical solution for finding and making the resources available, it may still be not enough for actual interdomain deployment. -- juha ----- End Included Message ----- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 09:40:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08450 for ; Mon, 24 Jan 2000 09:40:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06411; Mon, 24 Jan 2000 08:42:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06371 for ; Mon, 24 Jan 2000 08:42:06 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05865 for ; Mon, 24 Jan 2000 08:43:20 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id OAA16569; Mon, 24 Jan 2000 14:43:07 +0100 (MET) Message-Id: <200001241343.OAA16569@malmo.trab.se> From: "Istvan Cselenyi" To: Lixia Zhang Date: Mon, 24 Jan 2000 14:43:09 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [Diffserv] QoSSIG BOF Reply-to: Istvan.I.Cselenyi@telia.se CC: boomerang@soha.ttt.bme.hu, rsvp@isi.edu, diffserv@ietf.org, end2end-interest@isi.edu Priority: normal In-reply-to: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> References: <078292D50C98D2118D090008C7E9C6A60945FA7B@STAY.platinum.cor p.microsoft.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT Lixia, thanks for your honest response, I think this is the right attitude what we need for making QoS signaling happen. > I agree that the current RSVP is complex. > I would also like to point out that RSVP did not start as complex, but > ended up there. I believe that and think the same would happen if all the "QoSsig" funs started to melt their stuff for getting The ultimate QoS protocol. > Over all these years participating in IETF ever since the very first > meeting, I've seen many best people put in their best effort in dealing > with Internet problems and developing solutions. However I must admit that > I have not found this process the right place to produce *simple* protocols. But does it mean that IETF is not the right place for standardizing QoS signaling for IP? > For those who want a simple protocol: I am all for it, just that experience > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > personal suggestion would be to lock the door with a few friends till the > design is finished, then it'd be a better time to run a BOF to convince > others to go with you. Many groups from my previous list started with a silent design period and made a prototype for verification. I think it is time for synchronizing theese works and check where are the limits of QoS signaling and what is the cost of different functionality. I may be super naive but still believe in that IETF can provide a forum for discussing a common framework for QoS signaling in future internet and reviewing the vigorous alternatives. BR Istvan -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 09:41:52 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08522 for ; Mon, 24 Jan 2000 09:41:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06492; Mon, 24 Jan 2000 08:44:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06454 for ; Mon, 24 Jan 2000 08:44:04 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05882 for ; Mon, 24 Jan 2000 08:45:05 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id OAA16747; Mon, 24 Jan 2000 14:44:08 +0100 (MET) Message-Id: <200001241344.OAA16747@malmo.trab.se> From: "Istvan Cselenyi" To: Lixia Zhang , L.Wood@eim.surrey.ac.uk, Ping , Yoram Bernet , Joakim.F.Bergkvist@telia.se Date: Mon, 24 Jan 2000 14:44:10 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Diffserv] QoSSIG BOF Reply-to: Istvan.I.Cselenyi@telia.se CC: boomerang@soha.ttt.bme.hu, RSVP , diffserv , end2end-interest@isi.edu Priority: normal In-reply-to: <388B2729.90C452A0@research.bell-labs.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT On Sun, 23 Jan 2000, Ping Pan wrote: > Sigh! The reality is that going through the entire IETF process is > taking longer and longer. Maybe we are getting too many people from the > old standard communities, people somehow are more interested in the > process rather than the technical "meat". ;-) Big companies start to > talk about "more IETF presence" while sending too many non-engineers (or > slideware engineers) to the Internet ENGINEERING Task Force meetings. > ... > I think we need a BOF if we all promise to get job done fast. Otherwise, > agree with Lixia, why not lock the door and start hacking? One way to achieve fast work and avoide slide-ware show could be to apply Dave Clark's famous slogan: "we don't believe in kings or queens, we believe in rough consensus and running code". therefore we could set up a rule that the concepts presented at the QoSSIG BOF shall be previously verified by implementation. Istvan > 2 more cents, > > - Ping > > > > Lloyd Wood wrote: > > > > On Sat, 22 Jan 2000, Lixia Zhang wrote: > > > > > Over all these years participating in IETF ever since the very first > > > meeting, I've seen many best people put in their best effort in dealing > > > with Internet problems and developing solutions. However I must admit that > > > I have not found this process the right place to produce *simple* protocols. > > > > Indeed. That's the same argument that Bruce Schneier raises > > when reviewing IPsec and calling for half of it to be junked: > > > > http://www.counterpane.com/ipsec.html > > > > L. > > > > > For those who want a simple protocol: I am all for it, just that experience > > > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > > > personal suggestion would be to lock the door with a few friends till the > > > design is finished, then it'd be a better time to run a BOF to convince > > > others to go with you. > > > > > > Lixia > > > > -- > Ping Pan http://www.cs.columbia.edu/~pingpan > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 10:08:22 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09816 for ; Mon, 24 Jan 2000 10:08:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08102; Mon, 24 Jan 2000 09:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08071 for ; Mon, 24 Jan 2000 09:21:53 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07460 for ; Mon, 24 Jan 2000 09:23:06 -0500 (EST) Received: from cisco.com (ch2-dhcp134-231.cisco.com [161.44.134.231]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA19638; Mon, 24 Jan 2000 09:21:13 -0500 (EST) Message-ID: <388C5F84.992C02E6@cisco.com> Date: Mon, 24 Jan 2000 09:19:48 -0500 From: JC Ferguson Organization: Cisco Systems Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ping Pan CC: Lixia Zhang , Joakim Bergkvist , Yoram Bernet , RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF References: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.corp.microsoft.com> <200001230424.UAA23177@hawk.prod.itd.earthlink.net> <388AC3D4.191D7426@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Ping Pan wrote: > [snip] > > Lixia, > > Yes. Agree! I had talked to several developers last year. We all thought > that RSVP is taking a lot of CPU cycles. If a domain becomes too big and > the number of border-to-border connections increases, people will be > worried about the CPU shortage. Doesn't the refresh reduction draft address some of the CPU-related issues? jc _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 10:29:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10746 for ; Mon, 24 Jan 2000 10:29:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09319; Mon, 24 Jan 2000 09:44:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09288 for ; Mon, 24 Jan 2000 09:44:32 -0500 (EST) Received: from uni-paderborn.de (uni-paderborn.de [131.234.22.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08715 for ; Mon, 24 Jan 2000 09:45:46 -0500 (EST) Received: from [131.234.83.43] ([131.234.83.43]:1684 "EHLO uni-paderborn.de") by mail.uni-paderborn.de with ESMTP id ; Mon, 24 Jan 2000 15:45:31 +0100 Message-ID: <388C658A.90F8B7C2@uni-paderborn.de> Date: Mon, 24 Jan 2000 15:45:30 +0100 From: Simon Schneider X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] IntServ over Diffserv implementation experiences Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm a student working at the C-Lab in Paderborn, Germany. We participate in a european project and in one part of this project, we want to implement IntServ/end-to-end QoS Support over an existing DiffServ network. There are no RSVP-aware elements within the DiffServ network and only the sending and receiving hosts should be IntServ elements. I'm looking for implementation experiences in this area. I would greatly appreciate any hints and pointers. If this is not the proper list for my question please advise me which list to use. Cheers, Simon Schneider _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 11:55:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14108 for ; Mon, 24 Jan 2000 11:55:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12872; Mon, 24 Jan 2000 11:19:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12840 for ; Mon, 24 Jan 2000 11:19:19 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12677 for ; Mon, 24 Jan 2000 11:20:33 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Jan 2000 08:19:25 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jan 2000 08:19:25 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> From: Yoram Bernet Cc: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Date: Mon, 24 Jan 2000 08:19:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Diffserv] An apology... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org A number of folks have pointed out that it was impolite of me to suggest that those who are calling for a new QoS signaling protocol are calling into question the competence of the original developers of RSVP. I apologize. I do believe however, that the statement which appeared in this exchange: "We believe that there are much simpler ways of solving the same problems" is rather arrogant and is indicative of an all too common tendency to scrap what has been done so far and invent something new. I'm calling for us to have the discipline to study the work that has been done and to clearly articulate where and why it falls short and what of it can be salvaged, before deciding that something entirely new is necessary... Y _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 11:56:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14128 for ; Mon, 24 Jan 2000 11:56:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12524; Mon, 24 Jan 2000 11:09:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12485 for ; Mon, 24 Jan 2000 11:09:29 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12287 for ; Mon, 24 Jan 2000 11:10:44 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id LAA20280 for ; Mon, 24 Jan 2000 11:05:47 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0CbWWz; Mon Jan 24 11:05:43 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Mon, 24 Jan 2000 11:10:35 -0500 Received: from pcswbdesk ([138.120.49.63]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4300; Mon, 24 Jan 2000 11:10:31 -0500 Message-Id: <4.2.2.20000124104412.00a5cee0@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 11:10:11 -0500 To: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu From: "Scott W Brim" Subject: RE: [Diffserv] QoSSIG BOF In-Reply-To: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org At 05:10 PM 1/21/00 -0800, Yoram Bernet wrote: >"The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL >WG has been working for some time on the mapping of RSVP/Integrated services >to DS. So - this statement is somewhat inaccurate. As is the one above. Paraphrasing Dr. Wroclawski, ISSLL is looking at how to integrate DS into the intserv model, treating a DS domain as an intserv object. That's one approach to Istvan's problem set but starts out with a definite stance regarding QoS signaling. >I would generally oppose the creation of a wroking group to start >standardizing new layer-3 qos signaling protocols. Rather, I would encourage >continuing the work on using RSVP in a scalable manner to unify the various >disparate layer-2 QoS mechanisms in an end-to-end manner (as well as layer-3 >hop by hop mechanisms such as diffserv)... RSVP is fine for certain situations, but arguments about whether it's the ultimate protocol don't make sense until we're clearer about what we want it to do. I'd like to go ahead with a discussion of general requirements, to get them all cataloged. I think we could probably do that by mail -- although we should select ONE list. If we want to meet about it I think we should use DECIDES. ...Scott _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 11:56:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14142 for ; Mon, 24 Jan 2000 11:56:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11968; Mon, 24 Jan 2000 10:55:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11867 for ; Mon, 24 Jan 2000 10:55:25 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11769 for ; Mon, 24 Jan 2000 10:56:38 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Jan 2000 07:52:21 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jan 2000 07:52:21 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Joakim Bergkvist Cc: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF Date: Mon, 24 Jan 2000 07:52:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org If you recall, I never opposed the formation of a forum to discuss signaling issues. What I opposed was scrapping RSVP. My suggestion was that the forum should take RSVP as its opening position and then work out how to modify it to suit the requirements. So far, the sense I get from the bof proposal is that the proposing folks are not familiar with the progress that has been made in adapting rsvp. For the record - I am not enamored with RSVP per-se. I am enamored with the notion of *progress*. In my opinion, the best way to progress is to pick a protocol and stick with it, modifying it and learning from it as we go. We are five years into this cycle with RSVP. Venodrs have the code, there are public code bases, there is research showing which parts of it work well and which do not. If we are ever to get an end-to-end QoS story in place, we stand to do so by remaining focused on an evolutionary path, not by distracting everyone with some new panacea... Yoram -----Original Message----- From: Joakim Bergkvist [mailto:Joakim.F.Bergkvist@telia.se] Sent: Saturday, January 22, 2000 1:08 PM To: Yoram Bernet Cc: Joakim Bergkvist; RSVP; diffserv; end2end-interest@isi.edu; issll@lcs.mit.edu Subject: Re: [Diffserv] QoSSIG BOF Im glad you agree with me that RSVP might be designed for a sligthly more complex problem than the one we are facing. In this case it should be natural to create a new formum for alternatives in order to find out if a slimmer aproach with diffrent properties is better tailored to the need. / Joakim, Telia Research Yoram Bernet wrote: > > OK - let me try and rephrase... > > RSVP gives us a certain level of fucntionality in exchange for a certain > degree of complexity. This raises two questions: > > 1. Is it possible to offer the same degree of fucntionality more efficiently > (i.e. with a simpler protocol, less com-plexity)? > > 2. Is the degree of functionality offered by RSVP really required? > > Bear with me while I address these one at a time: > > In response to the first, consider that some pretty smart people spent a few > years developing and refining RSVP. If you trust that the people who > developed RSVP are reasonably good at what they do, and that they believe in > keeping things simple where possible, then - probably the protocol is about > as simple as it can be to offer the functionality it offers. Perhaps we > could spend another five years and provide the same level of functionality > with marginal improvements in efficiency/simplicity, but given that the > original developers of RSVP probably were pretty good at what they do, I > doubt that we could do much better with a new protocol *if* we want to offer > the same level of fucntionality. > > But - perhaps we don't need quite the leel of fucntionality offered by RSVP > (e.g. full receiver heterogeneity, other things). I actually believe that > there is some excess functionality built into RSVP that doesn't justify its > compelxity. So - we can claim that RSVP tried to do too much, scrap it all > and start over with another protocol that will be in development for five > years. Alternatively, we can look at RSVP, ask where it can be simplified > and how we might use a subset of it that is simpler and that achieves most > of the functionality that we need. That's really what's been happenning over > the last few years. We have been working to adopt from RSVP, those pieces > which provide the functionality we need. > > I hope that you folks that are proposing work on a new protocol are not > doing so because you think that the fucntionality of RSVP can be achieed > with a significantly lighterweight protocol. If you do - I think that you > are casting in doubt the competence of those who created it. Rahter, I > suspect that you are of the opinion that one doesn't need all the > functionality of RSVP and that thereofre, some complexity could be > eliminated. If so, then there are two options - 1) start all over. 2) adapt > existing stuff. > > I tend to believe in adapting existing stuff where possible. > > Yoram > > -----Original Message----- > From: Joakim Bergkvist [mailto:Joakim.F.Bergkvist@telia.se] > Sent: Saturday, January 22, 2000 11:30 AM > To: Yoram Bernet > Cc: RSVP; diffserv; end2end-interest@isi.edu; issll@lcs.mit.edu > Subject: Re: [Diffserv] QoSSIG BOF > > Yes Yoram we know you're fond of RSVP! but still.. In the face of the > known problems with RSVP we are several people who want to discuss > alternatives. So far there have not been a forum to discuss the > posibilities of alternative signalling. Instead the people behind these > has spent their time listing problems with RSVP (this is what you could > discuss in the RSVP BOF). > > Pm sure you can tweak RSVP into doing anything but this is not really > the point. We beleive that there are much simpler ways of solving the > same problems. If we are right there is a solution which is > fundamentally simpler both in implementation and in performance > requirements. This would bennefit small vendors with limited resources > (not just Microsoft and Cisco). Lower performance requirements would > also mean less impact on design issues and a broader fit into the > current product range. > > My belief is that the IETF as well as RSVP would bennefit from efforts > being spent on concrete solutions instead of finding problems with RSVP. > If Yoram is right problems will be solved and implementations will get > good enough to make RSVP happen before anyone can show a strong > alternative. If not maby there is a reason for it.. There is only one > way to find out and I'm not afraid! > > / Joakim Bergkvist, Telia Research > > > > Yoram Bernet wrote: > > > > Actually, in response to the comment: > > > > "The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL > > WG has been working for some time on the mapping of RSVP/Integrated > services > > to DS. So - this statement is somewhat inaccurate. > > > > Nonetheless, I do think that it is appropriate ot have a forum to continue > > to discuss signaled QoS and its application. In fact, in the discussions > > preceeding the closing of the RSVP group, it was suggested that an RSVP > > implementation group might be formed. > > > > I would generally oppose the creation of a wroking group to start > > standardizing new layer-3 qos signaling protocols. Rather, I would > encourage > > continuing the work on using RSVP in a scalable manner to unify the > various > > disparate layer-2 QoS mechanisms in an end-to-end manner (as well as > layer-3 > > hop by hop mechanisms such as diffserv)... > > > > Yoram > > > > -----Original Message----- > > From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se] > > Sent: Friday, January 21, 2000 11:53 AM > > To: RSVP; diffserv; end2end-interest@isi.edu > > Cc: Ping Pan > > Subject: [Diffserv] QoSSIG BOF > > > > Reading Ping's and earlier threads [1-3] and works [4-11] it seems that > > there are many people who want to contribute to the future of signaled > > QoS, but there is no IETF charter for aggregating all these good (not > > best :-) efforts since > > > > * the DS WG excludes new signaling by (re)definition > > * the MPLS WG deals with QoS routing and TE which are different > > * the ISSLL WG doesn't really suit to DS > > * the RSVP WG is closing done > > > > Shall we start with a BOF in Adelaide? > > > > /Istvan > > > > ------------------------------ > > Links > > > > [1] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html > > > > [2] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html > > > > [3] http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html > > > > [4] http://icawww1.epfl.ch/srp/ > > > > [5] http://www.it.kth.se/~gk/Tyrrhenian-ws.ps > > > > [6] P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated > > Reservation in the Internet, Journal on High Speed Networks, Special > > Issue on QoS Routing and Signaling, Vol 7 No 2, 1998 > > > > [7] A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight > > Resource Reservation for Unicast IP Traffic", International WS on > > QoS'98, IWQoS'98, May 18-20, 1998 > > > > [8] > http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt > > > > [9] > > > http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-o > > sp-00.txt > > > > [10] > > http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt > > > > [11] > > > http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt > > > > -------------------------------------------------- > > Istvan Cselenyi > > Telia Research AB Phone: +46-8-7138173 > > Vitsandsgatan 9 B431 Fax: +46-8-7138199 > > S-12386 Farsta Mobile: +46-70-3228801 > > Sweden E-mail: Istvan.I.Cselenyi@telia.se > > -------------------------------------------------- > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 12:04:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14540 for ; Mon, 24 Jan 2000 12:04:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12387; Mon, 24 Jan 2000 11:06:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12353 for ; Mon, 24 Jan 2000 11:05:56 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12127 for ; Mon, 24 Jan 2000 11:07:09 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Jan 2000 08:05:02 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jan 2000 08:05:02 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A60945FBEC@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Bob Braden , Joakim.F.Bergkvist@telia.se Cc: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF Date: Mon, 24 Jan 2000 08:04:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org *> > *> Pm sure you can tweak RSVP into doing anything but this > is not really > *> the point. We beleive that there are much simpler ways > of solving the > *> same problems. If we are right there is a solution which is > > I would seriously question whether there are "much simpler ways of > solving the same problems". > > However, there certainly would be simpler ways to solve a simpler > problem. > This is the same point that I was attempting to make. If indeed we can get agreement that the goal is to solve a simpler problem, then - the work that needs to happen is: 1. What did RSVP solve that we no longer need to solve? 2. Can RSVP be efficiently scaled back to solve the simpler problem? 3. If yes - how? If no - then it's worth looking at something new... Y _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 12:30:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15370 for ; Mon, 24 Jan 2000 12:30:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14476; Mon, 24 Jan 2000 11:47:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14440 for ; Mon, 24 Jan 2000 11:47:03 -0500 (EST) Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13826 for ; Mon, 24 Jan 2000 11:48:17 -0500 (EST) Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id LAA03628; Mon, 24 Jan 2000 11:47:47 -0500 (EST) Message-ID: <388CAF56.12497A5D@comet.columbia.edu> Date: Mon, 24 Jan 2000 12:00:22 -0800 From: "Andrew T. Campbell" Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Zoltan Richard Turanyi CC: Lixia Zhang , Yoram Bernet , Joakim Bergkvist , RSVP , diffserv , end2end-interest@ISI.EDU, mnl@comet.columbia.edu Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... References: <200001230515.VAA09360@snipe.prod.itd.earthlink.net> <388C241E.2930078F@eth.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Zoltan Richard Turanyi wrote: > One way out might be the hierarchical thinking. This may have a few > benefits. > > 1. The problem might be different on local and global scales, so > providing a few local and one global protocol that interoperate may be > better that putting everything into one protocol. Signaling systems are complex by nature - we all know that there is no free lunch - they essentially define the network-wide service creation environment and services offered. The telcos have a lot of experience in engineering, dimensioning and understanding these complex systems (to perfection, whether we like the end result or not - the result is impressive). In contrast, IETF folks don't have that background or skill base here; that may be good or bad depending were you are standing. What strikes me as odd about the recent discussion on 'hierarchical' signaling (to use Zoltan's term) is that this "separation" of local and global state management for services parallels to some extent out dated ideas from telecoms al la the UNI and PNNI division (the motivation almost identical in both cases?). Is such a division arbitrary and a moving target? Tangentially, I always felt that the lingering "signaling" issues that were sidelined (or punted because their complexity) would come back to bite diffserv. I have yet to read a good diffserv signaling/management paper that argues the case of slow versus not so slow (dynamic) provisioning and the impact on service creation and signaling/management support. This is almost as a odd as not seeing a decent paper on the so called RSVP scalability problem. In fact I have yet to read that 'va-paper' that heralded RSVP's demise. Most discussion was hearsay on RSVP's problems. Yes signaling systems are costly - why is that suprising? BTW, can someone point me to a good analytical or simulation paper on the RSVP problem? Note I don't want to be told about the size of the memory requirement for maintaining per-flow state in the router or simplified complexity metrics. Lets be serious folks? Coming back to my earlier question: Is such a division arbitrary and a moving target? Some may argue in the future that there will be even more infinite bandwidth at the edge local switches (so no explicit signaling needed there) and the core should provide explicit signaling and state management for user services (e.g., in support dynamic virtual networking with its associated isolation, security constraints, state and QOS provisioning). So the signaling (none at the edges and dynamic and explicit in the core) would be quite different from that discussed (or not discussed as the case may be) in today's diffserv. So what's the panacea? open signaling? This begs the question that as services evolve the service creation engine of the network must accommodate change dynamically and with ease. There is an argument for defining a set of open signaling interfaces in support of building dynamic network based services. Such a signaling engine with its open APIs has been discussed by the OPENSIG Group over the course of the past few years initially in the context of ATM but for the last couple of years for IP and mobile networks. The proceedings can be found at: http://comet.columbia.edu/opensig/activities/activities.html I don't think we need the IETF equivalent of UNI and PNNI. Rather than enduring long drawn out discussions on the right signaling protocol, I think we need a network-based middleware platform at the end-systems, edges and in the core that provide a set of well defined building blocks for a wide variety of services and arbitrary divisions. This would herald competition (i.e., service differentiation between ISPs) and evolution in the marketplace. QOS and signaling are very difficult problems. So rhetorically I ask: is that why we are running around in circles. After diffserv, ...... _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 13:19:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17314 for ; Mon, 24 Jan 2000 13:19:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16358; Mon, 24 Jan 2000 12:29:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16327 for ; Mon, 24 Jan 2000 12:29:43 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15382 for ; Mon, 24 Jan 2000 12:30:55 -0500 (EST) Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Jan 2000 17:30:17 +0000 To: campbell@comet.columbia.edu cc: Zoltan Richard Turanyi , Lixia Zhang , Yoram Bernet , Joakim Bergkvist , RSVP , diffserv , end2end-interest@ISI.EDU, mnl@comet.columbia.edu Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... In-reply-to: Your message of "Mon, 24 Jan 2000 12:00:22 PST." <388CAF56.12497A5D@comet.columbia.edu> Date: Mon, 24 Jan 2000 17:30:15 +0000 Message-ID: <1024.948735015@cs.ucl.ac.uk> From: Jon Crowcroft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org In message <388CAF56.12497A5D@comet.columbia.edu>, "Andrew T. Campbell" typed: >>Signaling systems are complex by nature - we all know that there is >>no free lunch - they essentially define the >>network-wide service creation environment and services offered. signaling systems are anything apart from the users data. they range from ip destination address in every IP datagram, through to per flow, per VPN or per ISP-ISP state setup.....in between these, for example, the DSbyte is a quite simple signaling system - what you mean is that accurate provisioning is difficult. >>The telcos have a lot of experience in engineering, >>dimensioning and understanding these complex systems (to perfection, >>whether >>we like the end result or not - the result is impressive). In contrast, >>IETF folks don't have that background or >>skill base here; that may be good or bad depending were you are >>standing. telcos have 1 service traditionally - its quite easy after 100 years to provision for it (but even Erlangs dont cut it when ytou take into account phone-in traffic) - but telcos dont have any magic experience to offer on provisioning for multiple services on the same wire esp. when the service model is not defined, and the traffic source model and matrix are ill understood. note: there's lots more ISPs and lots more levels of hierartchy for this than there are telcos as well, just to make life harder, and the system is growing and evolving faster than the phone net did ...so that makes life harder. >>What strikes me as odd about the recent discussion on 'hierarchical' >>signaling >>(to use Zoltan's term) is that this "separation" >>of local and global state management for services >>parallels to some extent out dated ideas from telecoms al la >>the UNI and PNNI division (the motivation almost identical in both >>cases?). hierarchy is one of those strange attractor ideas - unfortunately ,it doesnt always help. just because we have address, route and name hierarchies doesnt mean that signaling or provisioning hierarchically is an improvement - there's plenty of papers on the problems of fan-out and fan-in of both signaling flows and traffic flows... >>Is such a division arbitrary and a moving target? yep... >>Tangentially, I always felt that the lingering "signaling" >>issues that were sidelined (or punted >>because their complexity) would come back to bite diffserv. yep, agree >>I have yet to read a good diffserv signaling/management paper that >>argues >>the case of slow versus not so slow (dynamic) provisioning and the >>impact on service creation and signaling/management support. i agree... >>This is almost as a odd as not seeing a decent >>paper on the so called RSVP scalability problem. In fact I have yet to >>read that >>'va-paper' that heralded RSVP's demise. Most discussion was hearsay on >>RSVP's problems. yes, good point - rsvp, per se, is a very nice piece of work for what it is designed for... >>Yes signaling systems are costly - why is that suprising? BTW, can >>someone point me >>to a good analytical or simulation paper on the RSVP problem? >>Note I don't want to be told about the size of the memory requirement >>for maintaining per-flow state in the router or simplified complexity >>metrics. Lets be serious folks? right - people would love a panacea - they want assured qos, with assured predicatable provisioning targets AND lite signaling - its a nogo - the model should be you want diff-serve with low assurance (i.e. a lot of SLA violations, a lot of subscription rejections), then you might get away with something liter - maybe thats the target - say we say we don't mind double allocating 15% of capacity, and saying no wrongly 20% of the time - what type of signaling and dimensionign tools could we use for that (after all we do this with best effort now and that creates plenty of megabucks) maybe the new new thing in signaling is to look at scaling a system by admitting a modest level of inconsistency to persist (somethign we have succesfully done in multiparty multimedia applications sometimes) - so rough resource request and reserve consensus forming protocol (R4CFP) maybe... cheers jon _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 13:48:42 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18608 for ; Mon, 24 Jan 2000 13:48:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18038; Mon, 24 Jan 2000 13:13:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18007 for ; Mon, 24 Jan 2000 13:13:52 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17174 for ; Mon, 24 Jan 2000 13:15:04 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA84066; Mon, 24 Jan 2000 18:13:52 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA24020; Mon, 24 Jan 2000 18:13:51 GMT Message-ID: <388C9604.B70024E8@hursley.ibm.com> Date: Mon, 24 Jan 2000 12:12:20 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Eklund CC: "'diffserv@ietf.org'" , "'yoramb@microsoft.com'" , "'andrew@extremenetworks.com'" , "'slblake@torrentnet.com'" Subject: Re: [Diffserv] TCB's in diffserv router model. References: <45AFD48D077ED211BB4700A0C9DCE8FD15AE0F@monza.broadswitch.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18008 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Thomas, The document is specifically positioned to be independent of the hardware architecture. That is the limit of what we are going to do in the WG. Brian Thomas Eklund wrote: > > No but my point was perhaps it might be a good thing to write a conceptual > model draft for diffserv in different hardware arhitecthures like crossbar, > shared memory, bus oriented... > > It could be written like a Informational RFC as well or BCP for HW... > > And I understand that the IETF are not designing HW but today there are many > companies that offers integrated L2, L3 functionality in HW... > > Have there been any effort in defining that before? > > /Thomas > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Friday, January 21, 2000 11:49 PM > > To: Thomas Eklund > > Cc: 'diffserv@ietf.org'; 'yoramb@microsoft.com'; > > 'andrew@extremenetworks.com'; 'slblake@torrentnet.com' > > Subject: Re: [Diffserv] TCB's in diffserv router model. > > > > > > Thomas, > > > > We aren't designing hardware; this is only a conceptual model. > > > > The current functional decomposition has been debated for quite > > a while. Any choice of decomposition is arbitrary, and this is > > the one that got consensus. > > > > As soon as we get the draft revised according to the discussion > > in Washington, we will be going for Informational RFC. > > > > Regards > > > > Brian Carpenter > > diffserv co-chair > > > > > > Thomas Eklund wrote: > > > > > > Oops I forgot the forwarder block FOB... But that was > > obviuos but I did not > > > see that in the draft. > > > > > > Then you would have three buliding blocks; Forwarding > > block, filter block > > > and traffic conditioning block... > > > > > > This would be very good to fit the different models i HW > > (shared memory > > > design, crossbar, shared bus etc...)... > > > > > > I dont know if this should be included in the draft or a new one..? > > > Any Comments? > > > > > > /Thomas > > > > -----Original Message----- > > > > From: Thomas Eklund [mailto:thomas.eklund@switchcore.com] > > > > Sent: Thursday, January 20, 2000 5:58 PM > > > > To: 'diffserv@ietf.org' > > > > Cc: 'yoramb@microsoft.com'; 'andrew@extremenetworks.com'; > > > > 'slblake@torrentnet.com' > > > > Subject: [Diffserv] TCB's in diffserv router model. > > > > > > > > > > > > Hi, > > > > I have some questions about the > > draft-ietf-diffserv-model-01.txt... > > > > > > > > I wonder why TCB (Traffic Conditioning Block) is specified to > > > > include the > > > > classifier stage?? > > > > > > > > I would like to see something like > > > > Filter Block (BA, MF filtering) > > > > Traffic Conditioning Block (Metering, Marking, Shaping, Dropping, > > > > Queuing/Scheduling) > > > > > > > > So that you set the ingress and egress filtering rules in the > > > > FB and applies > > > > a TCB for every FB. > > > > > > > > So the FB is in, out, in/out (flow). > > > > > > > > Then I would also like to see a paper on how ipsec in > > tunnel mode over > > > > diffserv should be handled at the same time in FB. Or is > > > > there any work > > > > already done on this? > > > > > > > > So the model would become: > > > > FB + TCB = (filtering block for both security filters and qos > > > > classification) + (and a traffic conditioning block that > > > > apply the traffic > > > > behaviour) = What treatment and how a packet is forwarded > > > > > > > > Any comments? > > > > > > > > Best Regards Thomas > > > > > > > > Thomas Eklund > > > > System Design, MSc > > > > SwitchCore i Stockholm AB > > > > Positionen 153, Hangövägen 19 > > > > SE-115 74 Stockholm, Sweden > > > > phone +46 8 5630 5815 > > > > fax +46 8 5630 5801 > > > > mobile +46 709 952910 > > > > Thomas.Eklund@switchcore.com > > > > visit our web page at http://www.switchcore.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > diffserv mailing list > > > > diffserv@ietf.org > > > > http://www.ietf.org/mailman/listinfo/diffserv > > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > http://www.ietf.org/mailman/listinfo/diffserv > > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 13:49:19 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18634 for ; Mon, 24 Jan 2000 13:49:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17875; Mon, 24 Jan 2000 13:11:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17844 for ; Mon, 24 Jan 2000 13:11:04 -0500 (EST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17058 for ; Mon, 24 Jan 2000 13:12:18 -0500 (EST) Received: from mailgw.level1.com (level6.level1.com [10.13.30.6]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.18 2000/01/07 21:56:55 dmccart Exp $) with ESMTP id SAA04179 for ; Mon, 24 Jan 2000 18:12:49 GMT Received: from warder.level1.com ([10.13.30.100]) by mailgw.level1.com with esmtp (Exim 2.10 #1) id 12Co0c-0004fE-00 for diffserv@ietf.org; Mon, 24 Jan 2000 10:14:38 -0800 Received: by warder.level1.com with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jan 2000 09:58:07 -0800 Message-ID: From: "Dabir, Srinivas" To: "'diffserv@ietf.org'" Date: Mon, 24 Jan 2000 09:58:07 -0800 X-Mailer: Internet Mail Service (5.5.2448.0) Subject: [Diffserv] unsubscribe diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 13:49:43 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18658 for ; Mon, 24 Jan 2000 13:49:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17918; Mon, 24 Jan 2000 13:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17884 for ; Mon, 24 Jan 2000 13:11:27 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17097 for ; Mon, 24 Jan 2000 13:12:39 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA79970; Mon, 24 Jan 2000 18:12:05 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA23988; Mon, 24 Jan 2000 18:12:03 GMT Message-ID: <388C9598.74704E46@hursley.ibm.com> Date: Mon, 24 Jan 2000 12:10:32 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Istvan.I.Cselenyi@telia.se CC: Lixia Zhang , L.Wood@eim.surrey.ac.uk, Ping , Yoram Bernet , Joakim.F.Bergkvist@telia.se, boomerang@soha.ttt.bme.hu, diffserv Subject: NOT ON THE DIFFSERV LIST PLEASE Re: [Diffserv] QoSSIG BOF References: <200001241344.OAA16747@malmo.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Please take this discussion *off* the diffserv list Thanks Brian Carpenter diffserv co-chair Istvan Cselenyi wrote: > > On Sun, 23 Jan 2000, Ping Pan wrote: > > Sigh! The reality is that going through the entire IETF process is > > taking longer and longer. Maybe we are getting too many people from the > > old standard communities, people somehow are more interested in the > > process rather than the technical "meat". ;-) Big companies start to > > talk about "more IETF presence" while sending too many non-engineers (or > > slideware engineers) to the Internet ENGINEERING Task Force meetings. > > ... > > I think we need a BOF if we all promise to get job done fast. Otherwise, > > agree with Lixia, why not lock the door and start hacking? > > One way to achieve fast work and avoide slide-ware show could be to > apply Dave Clark's famous slogan: > > "we don't believe in kings or queens, we believe in rough consensus and > running code". > > therefore we could set up a rule that the concepts presented at the > QoSSIG BOF shall be previously verified by implementation. > > Istvan > > > 2 more cents, > > > > - Ping > > > > > > > > Lloyd Wood wrote: > > > > > > On Sat, 22 Jan 2000, Lixia Zhang wrote: > > > > > > > Over all these years participating in IETF ever since the very first > > > > meeting, I've seen many best people put in their best effort in dealing > > > > with Internet problems and developing solutions. However I must admit that > > > > I have not found this process the right place to produce *simple* protocols. > > > > > > Indeed. That's the same argument that Bruce Schneier raises > > > when reviewing IPsec and calling for half of it to be junked: > > > > > > http://www.counterpane.com/ipsec.html > > > > > > L. > > > > > > > For those who want a simple protocol: I am all for it, just that experience > > > > has shown that setting up a BOF/WG is NOT the way to reach you goal. My > > > > personal suggestion would be to lock the door with a few friends till the > > > > design is finished, then it'd be a better time to run a BOF to convince > > > > others to go with you. > > > > > > > > Lixia > > > > > > > -- > > Ping Pan http://www.cs.columbia.edu/~pingpan > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 14:36:12 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20964 for ; Mon, 24 Jan 2000 14:36:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19303; Mon, 24 Jan 2000 13:38:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19275 for ; Mon, 24 Jan 2000 13:38:55 -0500 (EST) Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18343 for ; Mon, 24 Jan 2000 13:40:08 -0500 (EST) Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id NAA09813; Mon, 24 Jan 2000 13:40:04 -0500 (EST) Message-ID: <388CC9A7.E91CC41B@comet.columbia.edu> Date: Mon, 24 Jan 2000 13:52:39 -0800 From: "Andrew T. Campbell" Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Yoram Bernet CC: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: An apology... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yoram Bernet wrote: > > A number of folks have pointed out that it was impolite of me to suggest > that those who are calling for a new QoS signaling protocol are calling into > question the competence of the original developers of RSVP. > > I apologize. > > I do believe however, that the statement which appeared in this exchange: > "We believe that there are much simpler ways of solving the same problems" > is rather arrogant and is indicative of an all too common tendency to scrap > what has been done so far and invent something new. > > I'm calling for us to have the discipline to study the work that has been > done and to clearly articulate where and why it falls short and what of it > can be salvaged, before deciding that something entirely new is necessary... > > Y Bravo! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 14:36:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20977 for ; Mon, 24 Jan 2000 14:36:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19388; Mon, 24 Jan 2000 13:40:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19341 for ; Mon, 24 Jan 2000 13:40:19 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18377 for ; Mon, 24 Jan 2000 13:41:14 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id UAA27932; Mon, 24 Jan 2000 20:41:04 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14476.40127.975755.469105@lohi.eng.telia.fi> Date: Mon, 24 Jan 2000 20:41:03 +0200 (EET) To: Yoram Bernet Cc: Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: RE: [Diffserv] QoSSIG BOF In-Reply-To: <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com> References: <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yoram Bernet writes: > What I opposed was scrapping RSVP. My suggestion was that the forum > should take RSVP as its opening position and then work out how to modify it > to suit the requirements. it doesn't make sense to add even more options to an already complex protocol. whatever is produced, must be very simple to read, understand, implement and use. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 14:36:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20979 for ; Mon, 24 Jan 2000 14:36:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19439; Mon, 24 Jan 2000 13:40:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19406 for ; Mon, 24 Jan 2000 13:40:44 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18397 for ; Mon, 24 Jan 2000 13:41:59 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id TAA14209; Mon, 24 Jan 2000 19:41:55 +0100 (MET) Message-Id: <200001241841.TAA14209@malmo.trab.se> From: "Istvan Cselenyi" To: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu Date: Mon, 24 Jan 2000 19:41:54 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: [Diffserv] QoSSIG BOF => RSVP & Boomerang lists Reply-to: Istvan.I.Cselenyi@telia.se CC: boomerang@soha.ttt.bme.hu Priority: normal In-reply-to: <4.2.2.20000124104412.00a5cee0@kanmail01.ca.newbridge.com> References: <078292D50C98D2118D090008C7E9C6A60945FA04@STAY.platinum.cor p.microsoft.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT Hi, as the trouble maker who started the QoSSIG thread on several threads in parallel, I propose to move it to the RSVP list (if Lixia and Bob agree) and to the Boomerang list: General Discussion: boomerang@soha.ttt.bme.hu To Subscribe: http://soha.ttt.bme.hu/mailman/listinfo/boomerang Archive: http://soha.ttt.bme.hu/mailman/listinfo/boomerang You can surf in the Boomerang archive w/o registration or password. Sorry for the increased mail traffic. Istvan > > RSVP is fine for certain situations, but arguments about whether it's the > ultimate protocol don't make sense until we're clearer about what we want > it to do. I'd like to go ahead with a discussion of general > requirements, to get them all cataloged. I think we could probably do > that by mail -- although we should select ONE list. If we want to meet > about it I think we should use DECIDES. > > ...Scott > > -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 15:08:44 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22673 for ; Mon, 24 Jan 2000 15:08:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21722; Mon, 24 Jan 2000 14:34:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21691 for ; Mon, 24 Jan 2000 14:34:02 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20924 for ; Mon, 24 Jan 2000 14:35:16 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA09475; Mon, 24 Jan 2000 11:35:03 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id TAA07729; Mon, 24 Jan 2000 19:35:02 GMT Date: Mon, 24 Jan 2000 19:35:02 GMT Message-Id: <200001241935.TAA07729@gra.isi.edu> To: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu, Istvan.I.Cselenyi@telia.se Subject: RE: [Diffserv] QoSSIG BOF => RSVP & Boomerang lists Cc: boomerang@soha.ttt.bme.hu X-Sun-Charset: US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org I don't know what this boomerang thing is, but it is not part of IETF/ISOC. Please remove end2end-interest from this discussion. Bob Braden _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 15:09:37 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22719 for ; Mon, 24 Jan 2000 15:09:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21832; Mon, 24 Jan 2000 14:35:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21799 for ; Mon, 24 Jan 2000 14:35:35 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21027 for ; Mon, 24 Jan 2000 14:36:49 -0500 (EST) Received: from trab.se (udn063.ringin.udn.telia.se [131.115.97.63]) by malmo.trab.se (8.9.1/TRAB-primary-2) with ESMTP id UAA28818; Mon, 24 Jan 2000 20:36:43 +0100 (MET) Message-ID: <388CA956.1C07BD4E@trab.se> Date: Mon, 24 Jan 2000 20:34:46 +0100 From: Joakim Bergkvist X-Mailer: Mozilla 4.07 [en] (Win98; I) MIME-Version: 1.0 To: Yoram Bernet CC: RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] An apology... References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yoram Bernet wrote: > > A number of folks have pointed out that it was impolite of me to suggest > that those who are calling for a new QoS signaling protocol are calling into > question the competence of the original developers of RSVP. > > I apologize. > > I do believe however, that the statement which appeared in this exchange: > "We believe that there are much simpler ways of solving the same problems" > is rather arrogant and is indicative of an all too common tendency to scrap > what has been done so far and invent something new. > Sure, I stand properly corrected and do apologize! Our assumption has been that the requirements on a resource reservation protocol is actually simpler than what RSVP set out to solve. For example RSVP was designed to support hetrogenous endpoints. We have no such scenario and therefore do not have to keep per flow states in all signalling nodes. This in turn enables us to do CAC based on measured rate or by using the cumulative rate of the refresh messages over a time window. During the work with our own prototype we have discovered other people working with like presumtions. So far these ideas have been rejected by the diffserv BOF who don't want to discuss signalling at all for the moment. They have also been rejected from the RSVP BOF since it has been dedicated for work with RSVP only. From our perspective a good starting point for a new BOF would be to synchronize the diverse implementations under a common framework. We would then have a basis on which to discuss the loss of functionallity imposed by a simplified protocol. My personal belief is that the RSVP group should maintain it's focus and aim for a quick standardisation. In this case I doubt that it would be constructive to examine scenarious which require conceptual changes to the protocol. This does not mean that such changes could not be implemented as a new "runmode" of RSVP!. In the meantime I propose a BOF for the organic eolution of RSVP into full standard AND a BOF for looking at an RSVP light mode for a simplified scenario using a potentially different transport mechanism. / Jocke > I'm calling for us to have the discipline to study the work that has been > done and to clearly articulate where and why it falls short and what of it > can be salvaged, before deciding that something entirely new is necessary... > > Y > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 16:11:35 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24980 for ; Mon, 24 Jan 2000 16:11:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22959; Mon, 24 Jan 2000 15:00:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22930 for ; Mon, 24 Jan 2000 15:00:53 -0500 (EST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22248 for ; Mon, 24 Jan 2000 15:02:06 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA13593; Mon, 24 Jan 2000 12:02:05 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07761; Mon, 24 Jan 2000 20:02:04 GMT Date: Mon, 24 Jan 2000 20:02:04 GMT Message-Id: <200001242002.UAA07761@gra.isi.edu> To: yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se Cc: rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu X-Sun-Charset: US-ASCII Subject: [Diffserv] Ideas rejected by the RSVP WG? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org *> moment. They have also been rejected from the RSVP BOF since it has been *> dedicated for work with RSVP only. Joakim, If you mean the RSVP WG, as co-chair I am not aware of your ideas ever having been brought into the working group. If they were "rejected", it would be a surprise to me, at least. Indeed, Lixia did introduce some discussion of simplification, including (I think) removing the heterogeneity requirement, and there was some work in the RSVP WG (by Berson) on measurement-based admission control, which sounds like what you are suggesting. RSVP is (only) a signaling protocol, but it is not much use if it is built upon a foundation of wishful thinking about the underlying network service model. So perhaps your argument is with Guaranteed or Controlled Load service models, in which case the int-serv (or ISSLL) working group would seem to be the appropriate venue for your ideas. Bob Braden _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 19:18:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00509 for ; Mon, 24 Jan 2000 19:18:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00183; Mon, 24 Jan 2000 18:43:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00148 for ; Mon, 24 Jan 2000 18:43:52 -0500 (EST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29569 for ; Mon, 24 Jan 2000 18:45:07 -0500 (EST) Received: from mariecurie.cisco.com (mariecurie.cisco.com [192.168.82.33]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA23225 for ; Mon, 24 Jan 2000 15:36:48 -0800 (PST) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by mariecurie.cisco.com (8.9.1b+Sun/8.9.1) with SMTP id PAA14820 for ; Mon, 24 Jan 2000 15:44:19 -0800 (PST) Received: from enserv.ensemblecom.com ( [205.163.11.194]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 24 Jan 2000 15:47:55 -0800 Message-ID: <7F8199C3CF1DD2119D1400104B2F099247A1C4@ENSERV> From: Yair Bourlas To: "'diffserv@external.cisco.com'" Subject: [Diffserv] unsubscribe diffserv Date: Mon, 24 Jan 2000 15:37:45 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF66C4.043E280E" X-SPAM: Yes X-SPAM-REASON: DNS did not return a vaild name for Relay X-SPAM-REASON: Suspicious SMTP Greeting X-SMTP-HELO: enserv.ensemblecom.com X-SMTP-MAIL-FROM: yair@ensemblecom.com X-SMAP-Received-From: outside X-SMTP-PEER-INFO: [205.163.11.194] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org 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_01BF66C4.043E280E Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01BF66C4.043E280E Content-Type: text/html; charset="iso-8859-1" [Diffserv] unsubscribe diffserv
------_=_NextPart_001_01BF66C4.043E280E-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 24 22:51:14 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05404 for ; Mon, 24 Jan 2000 22:51:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07661; Mon, 24 Jan 2000 22:23:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07627 for ; Mon, 24 Jan 2000 22:23:06 -0500 (EST) Received: from gennet.com.tw ([210.244.1.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04007 for ; Mon, 24 Jan 2000 22:23:31 -0500 (EST) Received: from iim.nctu.edu.tw (webguard193 [210.244.1.67]) by gennet.com.tw (8.9.1b+Sun/8.9.3) with ESMTP id LAA01090; Tue, 25 Jan 2000 11:24:27 -0800 (PST) Message-ID: <388D1624.78FA695F@iim.nctu.edu.tw> Date: Tue, 25 Jan 2000 11:19:00 +0800 From: lewis Reply-To: lewis@gennet.com.tw X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: diffserv , "end2end-interest@ISI.EDU" , RSVP Subject: Re: [Diffserv] QoSSIG BOF References: <200001242108.VAA07833@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dear professionalism: I am not a RSVP expert like you all, but I'd like the QOS network become more concrete, so that we can use it as soon as possible! so keep trying this better! I also suggest the RSVP discussion may combine with the packet classifier / packet scheduler ,since the heart of QOS is that part: the TSPEC will map into the class for classifier and scheduler, they are the executors! we all know that the experiments on RSVP+WFQ or RSVP+CBQ are not precise as we expected. Since some seniors want to make the signaling protocol more suitable for QOS requirement (hierarchy...) , maybe we can invite DR. "Hui Zhang" 's Lab to provide their opinions on coping the RSVP with their CSFQ and HFSC. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 00:16:27 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06572 for ; Tue, 25 Jan 2000 00:16:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10091; Mon, 24 Jan 2000 23:49:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA10065 for ; Mon, 24 Jan 2000 23:49:40 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06265 for ; Mon, 24 Jan 2000 23:50:52 -0500 (EST) From: Masataka Ohta Message-Id: <200001250451.NAA14018@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA14018; Tue, 25 Jan 2000 13:51:01 +0900 Subject: RE: [Diffserv] QoSSIG BOF To: yoramb@Exchange.Microsoft.com (Yoram Bernet) Date: Tue, 25 Jan 0 13:51:01 JST Cc: Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, issll@lcs.mit.edu In-Reply-To: <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com>; from "Yoram Bernet" at Jan 25, 100 1:32 am X-Mailer: ELM [version 2.3 PL11] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Yoram; > If you recall, I never opposed the formation of a forum to discuss signaling > issues. What I opposed was scrapping RSVP. My suggestion was that the forum > should take RSVP as its opening position and then work out how to modify it > to suit the requirements. So far, the sense I get from the bof proposal is > that the proposing folks are not familiar with the progress that has been > made in adapting rsvp. > > For the record - I am not enamored with RSVP per-se. I am enamored with the > notion of *progress*. In my opinion, the best way to progress is to pick a > protocol and stick with it, modifying it and learning from it as we go. We > are five years into this cycle with RSVP. Venodrs have the code, there are > public code bases, there is research showing which parts of it work well and > which do not. If we are ever to get an end-to-end QoS story in place, we > stand to do so by remaining focused on an evolutionary path, not by > distracting everyone with some new panacea... It seems to me that you are saying we should not spend any time on RSVP and just stick to ST2. Note that ST2 did have great *progress* to finally have capabilities like receiver initiated join. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 01:02:05 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07281 for ; Tue, 25 Jan 2000 01:02:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12156; Tue, 25 Jan 2000 00:40:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12124 for ; Tue, 25 Jan 2000 00:39:56 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07029 for ; Tue, 25 Jan 2000 00:41:11 -0500 (EST) From: Masataka Ohta Message-Id: <200001250533.OAA14361@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA14361; Tue, 25 Jan 2000 14:33:22 +0900 Subject: Re: [Diffserv] QoSSIG BOF now After diffserv, ...... To: campbell@comet.columbia.edu Date: Tue, 25 Jan 0 14:33:22 JST Cc: Zoltan.Turanyi@eth.ericsson.se, lixia@cs.ucla.edu, yoramb@Exchange.Microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, mnl@comet.columbia.edu In-Reply-To: <388CAF56.12497A5D@comet.columbia.edu>; from "Andrew T. Campbell" at Jan 25, 100 2:22 am X-Mailer: ELM [version 2.3 PL11] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Andrew; > Coming back to my earlier question: Is such a division > arbitrary and a moving target? Some may argue in the future that > there will be even more infinite bandwidth at the edge local switches > (so no explicit signaling needed there) and the core should > provide explicit signaling and state management > for user services (e.g., in support dynamic virtual networking with its > associated isolation, security constraints, state and QOS provisioning). > So the signaling (none at the edges and dynamic and > explicit in the core) would be quite different > from that discussed (or not discussed as the case may be) in > today's diffserv. That's the matured standardiation committee. > So what's the panacea? open signaling? Massive parallelism. See may paper titled "Hash Parallel and Label Parallel Routing for High Performance Multicast Router with Fine Grain QoS Control" in proceedings of IWS'99 just published by IEEE press. > What strikes me as odd about the recent discussion on 'hierarchical' > signaling UNI and PNNI division solves nothing. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 05:59:50 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21234 for ; Tue, 25 Jan 2000 05:59:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25620; Tue, 25 Jan 2000 05:14:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25510 for ; Tue, 25 Jan 2000 05:13:56 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20718 for ; Tue, 25 Jan 2000 05:14:50 -0500 (EST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA00770; Tue, 25 Jan 2000 11:12:31 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA08420; Tue, 25 Jan 2000 11:10:40 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 11:13:14 +0100 Message-ID: From: Hummel Heinrich To: "'Masataka Ohta'" , campbell@comet.columbia.edu Cc: Zoltan.Turanyi@eth.ericsson.se, lixia@cs.ucla.edu, yoramb@exchange.microsoft.com, Joakim.F.Bergkvist@telia.se, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU, mnl@comet.columbia.edu Subject: AW: [Diffserv] QoSSIG BOF now After diffserv, ...... Date: Tue, 25 Jan 2000 11:11:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Masataka Ohta wrote: > > What strikes me as odd about the recent discussion on 'hierarchical' > > signaling > > UNI and PNNI division solves nothing. > > Masataka Ohta > > In the ATM Forum we are about to develop an Inter-ATM Service Provider Routing Protocol which enables any source switch of an ATM Service Provider to generate the hierarchical source route information which describes the shortest route to the nearest access interface of the destination customer network, which might be identified based on the destination address (dest. AESA). Hereby the destination AESA may contain for sure any address of the types E.164 , ICD, DCC. Of course it would work as well for new address types like : IPv4, IPv6, Autonomous System Number + IPv4. Because fairly all ATM service Providers are or will be ISPs as well, such extensions are quite natural. Heinrich Hummel Siemens Munich heinrich.hummel@icn.siemens.de _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 06:00:02 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21253 for ; Tue, 25 Jan 2000 06:00:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25795; Tue, 25 Jan 2000 05:19:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25763 for ; Tue, 25 Jan 2000 05:19:20 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20755 for ; Tue, 25 Jan 2000 05:20:19 -0500 (EST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA01041; Tue, 25 Jan 2000 11:17:20 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA09523; Tue, 25 Jan 2000 11:15:29 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 11:18:03 +0100 Message-ID: From: Hummel Heinrich To: "'Juha Heinanen'" , Yoram Bernet Cc: Joakim Bergkvist , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: AW: [Diffserv] QoSSIG BOF Date: Tue, 25 Jan 2000 11:17:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Juha, Great. Let us develop a new protocol that enables any webpage anywhere in the internet being downloadeded within a fraction of a second. I would enjoy to do so. Heinrich Hummel Siemens Munich heinrich.hummel@icn.siemens.de > Yoram Bernet writes: > > > What I opposed was scrapping RSVP. My suggestion was that the forum > > should take RSVP as its opening position and then work out how to > modify it > > to suit the requirements. > > it doesn't make sense to add even more options to an already complex > protocol. whatever is produced, must be very simple to read, understand, > implement and use. > > -- juha > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 06:06:41 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21352 for ; Tue, 25 Jan 2000 06:06:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25659; Tue, 25 Jan 2000 05:14:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25626 for ; Tue, 25 Jan 2000 05:14:30 -0500 (EST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20724 for ; Tue, 25 Jan 2000 05:15:39 -0500 (EST) Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id LAA13589; Tue, 25 Jan 2000 11:13:37 +0100 (MET) Received: from alcatel.be ([138.203.66.143]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id LAA19217; Tue, 25 Jan 2000 11:13:29 +0100 (MET) Message-ID: <388D7741.EB0B6F0@alcatel.be> Date: Tue, 25 Jan 2000 11:13:21 +0100 From: Omar Elloumi Organization: Alcatel Corporate Research Center X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: campbell@comet.columbia.edu, Stefaan De Cnodder , Ping Pan CC: Yoram Bernet , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] Re: An apology... References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> <388CC9A7.E91CC41B@comet.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit "Andrew T. Campbell" wrote: > Yoram Bernet wrote: > > > > A number of folks have pointed out that it was impolite of me to suggest > > that those who are calling for a new QoS signaling protocol are calling into > > question the competence of the original developers of RSVP. > > > > I apologize. > > > > I do believe however, that the statement which appeared in this exchange: > > "We believe that there are much simpler ways of solving the same problems" > > is rather arrogant and is indicative of an all too common tendency to scrap > > what has been done so far and invent something new. > > > > I'm calling for us to have the discipline to study the work that has been > > done and to clearly articulate where and why it falls short and what of it > > can be salvaged, before deciding that something entirely new is necessary... > > > > Y > > Bravo! > A good starting point for such a study is to try to identify the traffic which needs reservation and then to quantify the number of flows that need reservation and how many of them will go through several diffserv domains. Then may be we'll come to the conclusion that RSVP (with may be some aggregation schemes) is enough. I, somewhat, disagree with the analysis done by Ping which is a worst case study. Based on Internet traffic traces we can not say, a priori, if RSVP will scale or not. We need instead to determine the number of flows that need reservation which has nothing to do with the number of flows in the Internet (e.g. we don't, or rarely, need a RSVP session for TCP individual flows). One question that come in mind is: do we need resource reservation for VoIP traffic in DiffServ networks? -- ____________________________________________________________ Omar Elloumi Alcatel Research - Network Architecture - Traffic Technology Francis Wellesplein 1, 2018 Antwerp, Belgium Phone: + 32 3 240 78 33 Fax: + 32 3 240 99 32 http://www.alcatel.com/crc/ ____________________________________________________________ Opinions expressed are those of the sender and do not reflect Alcatel policy or agreement _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 07:52:36 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23020 for ; Tue, 25 Jan 2000 07:52:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29061; Tue, 25 Jan 2000 07:06:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29029 for ; Tue, 25 Jan 2000 07:06:44 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21714 for ; Tue, 25 Jan 2000 07:08:01 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Tue Jan 25 07:06:47 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.43.83]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id HAA25748; Tue, 25 Jan 2000 07:06:13 -0500 (EST) Message-ID: <388D9150.D17C89BF@research.bell-labs.com> Date: Tue, 25 Jan 2000 07:04:32 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: lewis@gennet.com.tw CC: diffserv , "end2end-interest@ISI.EDU" , RSVP Subject: Re: [Diffserv] QoSSIG BOF References: <200001242108.VAA07833@gra.isi.edu> <388D1624.78FA695F@iim.nctu.edu.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > > I also suggest the RSVP discussion may combine with the > > packet classifier / packet scheduler ,since the heart of > > QOS is that part: the TSPEC will map into the class for > > classifier and scheduler, they are the executors! > > we all know that the experiments on RSVP+WFQ or RSVP+CBQ are > > not precise as we expected. > RSVP and other proposals (BGRP, YESSIR...) are signaling protocols to distribute resource information between end hosts and routers. But IMO, they do NOT apply the actual reservation, packet queuing, buffer management, scheduling and classification. - Ping _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 08:47:20 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25707 for ; Tue, 25 Jan 2000 08:47:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00404; Tue, 25 Jan 2000 07:54:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00373 for ; Tue, 25 Jan 2000 07:54:45 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23125 for ; Tue, 25 Jan 2000 07:56:01 -0500 (EST) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Tue Jan 25 07:54:30 EST 2000 Received: from research.bell-labs.com (pingpan.lra.lucent.com [135.255.43.83]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id HAA26750; Tue, 25 Jan 2000 07:54:25 -0500 (EST) Message-ID: <388D9CAB.B22064E4@research.bell-labs.com> Date: Tue, 25 Jan 2000 07:52:59 -0500 From: Ping Pan Organization: Bell Labs X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,zh,zh-CN MIME-Version: 1.0 To: Omar Elloumi CC: campbell@comet.columbia.edu, Stefaan De Cnodder , Yoram Bernet , RSVP , diffserv , end2end-interest@isi.edu, issll@lcs.mit.edu Subject: Re: [Diffserv] Re: An apology... References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> <388CC9A7.E91CC41B@comet.columbia.edu> <388D7741.EB0B6F0@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Omar Elloumi wrote: > > > A good starting point for such a study is to try to identify the traffic > which needs reservation and then to quantify the number of flows > that need reservation and how many of them will go through > several diffserv domains. Then may be we'll come to the conclusion > that RSVP (with may be some aggregation schemes) is enough. > First of all, please read RFC2430 (PASTE) and check out the data in http://www.merit.edu/ipma/reports/ and http://www.employees.org/~tbates/cidr-report.html. Reservation protocols distribute "flow" information in the network. The flow can be UDP streams (such as RTP applications), TCP flows, MPLS LSP's, optical connection info. etc. First, let's take a look at the dimension of the network (6000+ AS, 60K routers....) with almost linear growth. Then, let's take a look at how to maintain reservation states efficiently within the network (soft-state, hard-state) while the route is going up/down constantly. Now, let's discuss if a protocol is good enough or not. In our work, we concluded one protocol won't do the job if there is no hierarchy. In our work, we're not trying to: (1) Trashing RSVP: RSVP is fine for intra-domain traffic engineering. Like it or not, it's in the process of being deployed for MPLS by vendors already. Let's move on already. (2) Yet another ivy-tower academic exercise: we're trying to come up with a real solution to meet the real demands for the emerging MPLS deployment and carrier-level resource management. Some may think the protocol is complex. But you're somewhat familiar with BGP, this is quite simple. (3) End-user reservation protocol: There is bo DiffServ deployment within the network today, so I doubt we will see end-user reservation application very soon. Let's see how good RSVP is for VoIP some time in the near future. > I, somewhat, disagree with the analysis done by Ping which > is a worst case study. Based on Internet traffic traces we can not > say, a priori, if RSVP will scale or not. If N is the number of ASes (that is, 6000), would you think a router can handle O(6000**2) states? ;-) > We need instead to > determine the number of flows that need reservation which > has nothing to do with the number of flows in the Internet > (e.g. we don't, or rarely, need a RSVP > session for TCP individual flows). > Again, we're not talking about end-user reservation protocol here. > One question that come in mind is: do we need resource > reservation for VoIP traffic in DiffServ networks? > It's up the end users. Some people may feel fine with the existing service, if all they want is to leave a voice mail, or making the call 3:00 in the morning. Some may want to have the best service by paying a lot for it. Again this is end-user reservation issue. BR -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 09:56:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29087 for ; Tue, 25 Jan 2000 09:56:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02167; Tue, 25 Jan 2000 08:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA02135 for ; Tue, 25 Jan 2000 08:44:36 -0500 (EST) Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25671 for ; Tue, 25 Jan 2000 08:45:52 -0500 (EST) Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45]) by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id OAA01293; Tue, 25 Jan 2000 14:42:53 +0100 (MET) From: Michael Welzl Reply-To: To: "'Hummel Heinrich'" , "'Juha Heinanen'" , "'Yoram Bernet'" Cc: "'Joakim Bergkvist'" , "'RSVP'" , "'diffserv'" , , Subject: RE: [Diffserv] QoSSIG BOF Date: Tue, 25 Jan 2000 14:44:54 +0100 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 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I don't understand that. What's so bad about Juha's opinion that we should avoid making a complex protocol like RSVP even more complex? > Juha, > > Great. Let us develop a new protocol that enables any webpage > anywhere in the internet being downloadeded within a fraction > of a second. I would enjoy to do so. > > Heinrich Hummel > Siemens Munich > heinrich.hummel@icn.siemens.de > > > Yoram Bernet writes: > > > > > What I opposed was scrapping RSVP. My suggestion was > that the forum > > > should take RSVP as its opening position and then work out how to > > modify it > > > to suit the requirements. > > > > it doesn't make sense to add even more options to an already complex > > protocol. whatever is produced, must be very simple to > read, understand, > > implement and use. > > > > -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 10:21:01 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00190 for ; Tue, 25 Jan 2000 10:21:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03609; Tue, 25 Jan 2000 09:27:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03565 for ; Tue, 25 Jan 2000 09:26:58 -0500 (EST) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27995 for ; Tue, 25 Jan 2000 09:28:12 -0500 (EST) Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id PAA23662; Tue, 25 Jan 2000 15:26:37 +0100 (MET) Message-Id: <200001251426.PAA23662@malmo.trab.se> From: "Istvan Cselenyi" To: Stefaan De Cnodder , Ping Pan , Omar Elloumi Date: Tue, 25 Jan 2000 15:26:40 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Diffserv] Re: An apology... Reply-to: Istvan.I.Cselenyi@telia.se CC: RSVP , diffserv , end2end-interest@ISI.EDU Priority: normal In-reply-to: <388D7741.EB0B6F0@alcatel.be> X-mailer: Pegasus Mail for Win32 (v3.01d) Content-Transfer-Encoding: 7BIT Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7BIT On Tue, 25 Jan 2000 Omar Elloumi wrote: > I, somewhat, disagree with the analysis done by Ping which > is a worst case study. Based on Internet traffic traces we can not > say, a priori, if RSVP will scale or not. We need instead to > determine the number of flows that need reservation which > has nothing to do with the number of flows in the Internet > (e.g. we don't, or rarely, need a RSVP > session for TCP individual flows). I agree with quantifying the scalability requirements what QoS signaling shall meet in the future (a good input to QoSSIG BOF). However, you should not underestimate the amount of flows which can benefit from using QoS signaling. As of today, the amount of traffic over internet is just taking over the traffic carried in the entire telephony network. So imargine the situation in a few years when every telephony session is moved to the internet (what many of us wishes) and new kind of real-time applications are spreading all over... > One question that come in mind is: do we need resource > reservation for VoIP traffic in DiffServ networks? Not, if you can assure the resources and do admission control in another way, e.g. promise the customer that she can always send and pray that transmission guys are quick enough in steadily increasing the extra net capacity what you need for overprovisioning ... Istvan -------------------------------------------------- Istvan Cselenyi Telia Research AB Phone: +46-8-7138173 Vitsandsgatan 9 B431 Fax: +46-8-7138199 S-12386 Farsta Mobile: +46-70-3228801 Sweden E-mail: Istvan.I.Cselenyi@telia.se -------------------------------------------------- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 11:01:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01882 for ; Tue, 25 Jan 2000 11:01:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05474; Tue, 25 Jan 2000 10:13:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05446 for ; Tue, 25 Jan 2000 10:13:03 -0500 (EST) Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29821 for ; Tue, 25 Jan 2000 10:14:10 -0500 (EST) Received: from cisco.com (cei-ultra.cisco.com [161.44.134.45]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA03401; Tue, 25 Jan 2000 10:12:58 -0500 (EST) Message-ID: <388DBD7A.19C0FFB8@cisco.com> Date: Tue, 25 Jan 2000 10:12:58 -0500 From: Carol Iturralde X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yoram Bernet CC: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu References: <078292D50C98D2118D090008C7E9C6A60945FBF2@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: An apology... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Yoram Bernet wrote: > > A number of folks have pointed out that it was impolite of me to suggest > that those who are calling for a new QoS signaling protocol are calling into > question the competence of the original developers of RSVP. > > I apologize. > > I do believe however, that the statement which appeared in this exchange: > "We believe that there are much simpler ways of solving the same problems" > is rather arrogant and is indicative of an all too common tendency to scrap > what has been done so far and invent something new. > > I'm calling for us to have the discipline to study the work that has been > done and to clearly articulate where and why it falls short and what of it > can be salvaged, before deciding that something entirely new is necessary... > > Y I agree entirely! _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 11:03:29 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01907 for ; Tue, 25 Jan 2000 11:03:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05999; Tue, 25 Jan 2000 10:29:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05962 for ; Tue, 25 Jan 2000 10:29:08 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00451 for ; Tue, 25 Jan 2000 10:30:19 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id RAA07038; Tue, 25 Jan 2000 17:30:01 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14477.49529.14188.467164@lohi.eng.telia.fi> Date: Tue, 25 Jan 2000 17:30:01 +0200 (EET) To: Istvan.I.Cselenyi@telia.se Cc: Stefaan De Cnodder , Ping Pan , Omar Elloumi , RSVP , diffserv , end2end-interest@ISI.EDU Subject: Re: [Diffserv] Re: An apology... In-Reply-To: <200001251426.PAA23662@malmo.trab.se> References: <388D7741.EB0B6F0@alcatel.be> <200001251426.PAA23662@malmo.trab.se> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Istvan Cselenyi writes: > So imargine the situation in a few years when every telephony > session is moved to the internet (what many of us wishes) and new kind > of real-time applications are spreading all over... telephone sessions will always be so small percentage of overall internet traffic that we don't need any signalling for that. diffserv bits in the packets are well enough. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 11:26:53 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02520 for ; Tue, 25 Jan 2000 11:26:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07200; Tue, 25 Jan 2000 10:55:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07167 for ; Tue, 25 Jan 2000 10:55:38 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01553 for ; Tue, 25 Jan 2000 10:56:53 -0500 (EST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA02643; Tue, 25 Jan 2000 16:55:47 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA22553; Tue, 25 Jan 2000 16:54:15 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 16:56:49 +0100 Message-ID: From: Hummel Heinrich To: "'michael@tk.uni-linz.ac.at'" , Hummel Heinrich , "'Juha Heinanen'" , "'Yoram Bernet'" Cc: "'Joakim Bergkvist'" , "'RSVP'" , "'diffserv'" , end2end-interest@ISI.EDU, issll@lcs.mit.edu Subject: AW: [Diffserv] QoSSIG BOF Date: Tue, 25 Jan 2000 16:55:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07168 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Nothing is bad with Juha's opinion. Just the opposite: IMHO we could accomplish such fast transmissions if not only the transmission of the user data is fast but if the processing/forwarding of the message for establishing either an SVC or an LSP is fairly as fast as the forwarding of the user data packets. Some time ago K.K. Ramakrishan from Bell Research Lab presented his UNITE concept both in the ATM Forum and IETF. Accordingly a single ATM-cell would contain a Mikro-SETUP message to establish an SVC resp. an LSP. This message could be forwarded based on a - let me say- "pilot-VPI/VCI resp. pilot- label" residing in the ATM-payload (not cell header !). In order to do pilot-switching however the switching tables of each transit switch/LSR must be properly filled based on a protocol that "happens" earlier. Accordingly complexity is shifted away. Complexity as such cannot be ignored, because the topology of a network changes from time to time. The protocol for "pilot-label distribution" must take this into account. With such a protocol the so-called N-square problem would be solved too. If the current N of the current internet is equal to 70 000 then any "pilot-router" would have to provide N=70,000 pilot-label switching entries (or may be 3 times 70,000 in case it will support 3 routes to the same destination router reflecting 3 different QoS classes ! But never N*N many ! ) Heinrich > -----Ursprüngliche Nachricht----- > Von: Michael Welzl [SMTP:michael@tk.uni-linz.ac.at] > Gesendet am: Dienstag, 25. Januar 2000 14:45 > An: 'Hummel Heinrich'; 'Juha Heinanen'; 'Yoram Bernet' > Cc: 'Joakim Bergkvist'; 'RSVP'; 'diffserv'; end2end-interest@ISI.EDU; > issll@lcs.mit.edu > Betreff: RE: [Diffserv] QoSSIG BOF > > I don't understand that. > What's so bad about Juha's opinion that we should avoid making a > complex protocol like RSVP even more complex? > > > > Juha, > > > > Great. Let us develop a new protocol that enables any webpage > > anywhere in the internet being downloadeded within a fraction > > of a second. I would enjoy to do so. > > > > Heinrich Hummel > > Siemens Munich > > heinrich.hummel@icn.siemens.de > > > > > Yoram Bernet writes: > > > > > > > What I opposed was scrapping RSVP. My suggestion was > > that the forum > > > > should take RSVP as its opening position and then work out how to > > > modify it > > > > to suit the requirements. > > > > > > it doesn't make sense to add even more options to an already complex > > > protocol. whatever is produced, must be very simple to > > read, understand, > > > implement and use. > > > > > > -- juha > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 12:57:39 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05104 for ; Tue, 25 Jan 2000 12:57:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09756; Tue, 25 Jan 2000 11:56:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09722 for ; Tue, 25 Jan 2000 11:56:33 -0500 (EST) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03526 for ; Tue, 25 Jan 2000 11:57:47 -0500 (EST) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id LAA23574 for ; Tue, 25 Jan 2000 11:52:42 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA0DSQt_; Tue Jan 25 11:52:38 2000 Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for diffserv@ietf.org; Tue, 25 Jan 2000 11:56:55 -0500 Received: from pcswbdesk ([138.120.49.41]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA15DA; Tue, 25 Jan 2000 11:56:52 -0500 Message-Id: <4.2.2.20000125114606.00a6dee0@kanmail01.ca.newbridge.com> X-Sender: swb@kanmail01.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 11:47:19 -0500 To: Juha Heinanen From: "Scott W Brim" Subject: RE: [Diffserv] QoSSIG BOF Cc: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu In-Reply-To: <14476.40127.975755.469105@lohi.eng.telia.fi> References: <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com> <078292D50C98D2118D090008C7E9C6A60945FBE9@STAY.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Juha, RSVP has become a generic protocol for transport signaling. You can put anything on it. That doesn't mean everyone has to implement everything. It does mean you can reuse some code. At 08:41 PM 1/24/00 +0200, Juha Heinanen wrote: >Yoram Bernet writes: > > > What I opposed was scrapping RSVP. My suggestion was that the forum > > should take RSVP as its opening position and then work out how to > modify it > > to suit the requirements. > >it doesn't make sense to add even more options to an already complex >protocol. whatever is produced, must be very simple to read, understand, >implement and use. > >-- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 13:11:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05493 for ; Tue, 25 Jan 2000 13:11:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11638; Tue, 25 Jan 2000 12:38:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11610 for ; Tue, 25 Jan 2000 12:38:33 -0500 (EST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04629 for ; Tue, 25 Jan 2000 12:39:47 -0500 (EST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA54452; Tue, 25 Jan 2000 17:39:16 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA28596; Tue, 25 Jan 2000 17:39:12 GMT Message-ID: <388DDFD8.F2EBBFB6@hursley.ibm.com> Date: Tue, 25 Jan 2000 11:39:36 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Masataka Ohta CC: Yoram Bernet , Joakim.F.Bergkvist@telia.se, diffserv@ietf.org Subject: NOT ON THE DIFFSERV LIST PLEASE Re: [Diffserv] QoSSIG BOF References: <200001250451.NAA14018@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Once again, everybody, please drop diffserv from this thread. Brian Masataka Ohta wrote: > > Yoram; > > > If you recall, I never opposed the formation of a forum to discuss signaling > > issues. What I opposed was scrapping RSVP. My suggestion was that the forum > > should take RSVP as its opening position and then work out how to modify it > > to suit the requirements. So far, the sense I get from the bof proposal is > > that the proposing folks are not familiar with the progress that has been > > made in adapting rsvp. > > > > For the record - I am not enamored with RSVP per-se. I am enamored with the > > notion of *progress*. In my opinion, the best way to progress is to pick a > > protocol and stick with it, modifying it and learning from it as we go. We > > are five years into this cycle with RSVP. Venodrs have the code, there are > > public code bases, there is research showing which parts of it work well and > > which do not. If we are ever to get an end-to-end QoS story in place, we > > stand to do so by remaining focused on an evolutionary path, not by > > distracting everyone with some new panacea... > > It seems to me that you are saying we should not spend any time on RSVP > and just stick to ST2. > > Note that ST2 did have great *progress* to finally have capabilities like > receiver initiated join. > > Masataka Ohta > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 14:13:08 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06445 for ; Tue, 25 Jan 2000 14:13:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12909; Tue, 25 Jan 2000 13:14:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12878 for ; Tue, 25 Jan 2000 13:14:14 -0500 (EST) Received: from wingate.calynet.com (216-200-28-155.snj0.flashcom.net [216.200.28.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05532 for ; Tue, 25 Jan 2000 13:15:31 -0500 (EST) Received: from MAIL-CLUSTER.calynet.com (exch-node-b.calynet.com [192.168.0.11]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z63X4S7X; Tue, 25 Jan 2000 10:16:43 -0800 Received: by MAIL-CLUSTER.calynet.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 10:05:58 -0800 Message-ID: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> From: Mudassir Tufail To: "'Juha Heinanen'" , Istvan.I.Cselenyi@telia.se Cc: Stefaan De Cnodder , Ping Pan , Omar Elloumi , RSVP , diffserv , end2end-interest@ISI.EDU Subject: RE: [Diffserv] Re: An apology... Date: Tue, 25 Jan 2000 10:05:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > Istvan Cselenyi writes: > > > So imargine the situation in a few years when every telephony > > session is moved to the internet (what many of us wishes) > and new kind > > of real-time applications are spreading all over... > > telephone sessions will always be so small percentage of overall > internet traffic that we don't need any signalling for that. diffserv > bits in the packets are well enough. > > -- juha > Not clear, curious to know how this is possible. I will appreciate if you can explain it more. As per my understanding, just the DiffServ bit in the packets would not be sufficient. It is regardless of the percentage of telephone traffic (or any real time traffic) on the internet. Signaling is required to do two important things: 1) call admission control and 2) resource allocation to an admitted call. The same is valid, as well, for networks where resources are policy-managed. Omar Elloumi wrote: > One question that come in mind is: do we need resource > reservation for VoIP traffic in DiffServ networks? > Yes, resource management policy dictates what percentage of total available resources are to be allocated to a traffic aggregate, say VoIP. Consequently, VoIP call will go through an admission control. This ensures that 1) admitted calls get guaranteed QoS and 2) lower priority classes do not face starvation. Mudassir CALY Networks 295 Santa Anna Court Tel: (408) 730 8800 ext 245 Sunnyvale, CA 94086 Fax: (408) 730 2448 > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 15:27:56 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07409 for ; Tue, 25 Jan 2000 15:27:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15576; Tue, 25 Jan 2000 14:45:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15550 for ; Tue, 25 Jan 2000 14:45:31 -0500 (EST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06800 for ; Tue, 25 Jan 2000 14:46:47 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA19303; Tue, 25 Jan 2000 11:46:40 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA25343; Tue, 25 Jan 2000 11:46:40 -0800 (PST) Received: from oahu.nsd.3com.com (oahu.nsd.3com.com [129.213.48.11]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id LAA06284; Tue, 25 Jan 2000 11:46:39 -0800 (PST) From: Barani Subbiah Received: (from bsubbiah@localhost) by oahu.nsd.3com.com (8.8.2/8.8.5) id LAA06582; Tue, 25 Jan 2000 11:50:36 -0800 (PST) Date: Tue, 25 Jan 2000 11:50:36 -0800 (PST) Message-Id: <200001251950.LAA06582@oahu.nsd.3com.com> To: jh@lohi.eng.telia.fi, Istvan.I.Cselenyi@telia.se, Mudassir@calynet.com Subject: RE: [Diffserv] Re: An apology... Cc: cnodders@rc.bel.alcatel.be, pingpan@research.bell-labs.com, Omar.Elloumi@alcatel.be, rsvp@ISI.EDU, diffserv@ietf.org, end2end-interest@ISI.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: N29ALSOCooRfD3VnDTD2+Q== Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Signaling is an integral part of QoS provisioning that includes traffic policing/shaping, classifiers, and Scheduling. All these mechanisms are needed in order to guarantee QoS with "reosurce efficiency". We can throw more bw but it may not be efficient. It would be nice to find out the middle point with additional bw (we dont have to save every byte of resources) and a lightweight signaling that would solve the QoS problem. Barani > From diffserv-admin@ietf.org Tue Jan 25 10:26:11 2000 > Return-Path: > Received: from new-york.3com.com (new-york.nsd.3com.com [129.213.96.114]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id KAA03624; Tue, 25 Jan 2000 10:26:09 -0800 (PST) > Received: from seattle.3com.com (seattle.3com.com [129.213.157.13]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id KAA18207; Tue, 25 Jan 2000 10:26:06 -0800 (PST) > Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id KAA13234; Tue, 25 Jan 2000 10:26:03 -0800 (PST) > Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12908; Tue, 25 Jan 2000 13:14:19 -0500 (EST) > Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12878 for ; Tue, 25 Jan 2000 13:14:14 -0500 (EST) > Received: from wingate.calynet.com (216-200-28-155.snj0.flashcom.net [216.200.28.155]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05532 for ; Tue, 25 Jan 2000 13:15:31 -0500 (EST) > Received: from MAIL-CLUSTER.calynet.com (exch-node-b.calynet.com [192.168.0.11]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z63X4S7X; Tue, 25 Jan 2000 10:16:43 -0800 > Received: by MAIL-CLUSTER.calynet.com with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 10:05:58 -0800 > Message-ID: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> > From: Mudassir Tufail > To: "'Juha Heinanen'" , Istvan.I.Cselenyi@telia.se > Cc: Stefaan De Cnodder , Ping Pan , Omar Elloumi , RSVP , diffserv , end2end-interest@ISI.EDU > Subject: RE: [Diffserv] Re: An apology... > Date: Tue, 25 Jan 2000 10:05:53 -0800 > X-Mailer: Internet Mail Service (5.5.2448.0) > Sender: diffserv-admin@ietf.org > Errors-To: diffserv-admin@ietf.org > X-Mailman-Version: 1.0 > Precedence: bulk > List-Id: > X-BeenThere: diffserv@ietf.org > Status: RO > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-MD5: HB1Yb7zgxce8MyBWd+cNiA== > Content-Length: 1881 > > > > > Istvan Cselenyi writes: > > > > > So imargine the situation in a few years when every telephony > > > session is moved to the internet (what many of us wishes) > > and new kind > > > of real-time applications are spreading all over... > > > > telephone sessions will always be so small percentage of overall > > internet traffic that we don't need any signalling for that. diffserv > > bits in the packets are well enough. > > > > -- juha > > > > Not clear, curious to know how this is possible. I will appreciate if you > can explain it more. > > As per my understanding, just the DiffServ bit in the packets would not be > sufficient. It is regardless of the percentage of telephone traffic (or any > real time traffic) on the internet. Signaling is required to do two > important things: 1) call admission control and 2) resource allocation to an > admitted call. The same is valid, as well, for networks where resources are > policy-managed. > > Omar Elloumi wrote: > > One question that come in mind is: do we need resource > > reservation for VoIP traffic in DiffServ networks? > > > > Yes, resource management policy dictates what percentage of total available > resources are to be allocated to a traffic aggregate, say VoIP. > Consequently, VoIP call will go through an admission control. This ensures > that 1) admitted calls get guaranteed QoS and 2) lower priority classes do > not face starvation. > > Mudassir > CALY Networks > 295 Santa Anna Court Tel: (408) 730 8800 ext 245 > Sunnyvale, CA 94086 Fax: (408) 730 2448 > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www.ietf.org/mailman/listinfo/diffserv > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www.ietf.org/mailman/listinfo/diffserv > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 17:06:26 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08712 for ; Tue, 25 Jan 2000 17:06:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18338; Tue, 25 Jan 2000 16:31:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18303 for ; Tue, 25 Jan 2000 16:31:18 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08048 for ; Tue, 25 Jan 2000 16:32:33 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id XAA07727; Tue, 25 Jan 2000 23:32:16 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14478.5728.662262.635976@lohi.eng.telia.fi> Date: Tue, 25 Jan 2000 23:32:16 +0200 (EET) To: Mudassir Tufail Cc: Istvan.I.Cselenyi@telia.se, Stefaan De Cnodder , Ping Pan , Omar Elloumi , RSVP , diffserv , end2end-interest@ISI.EDU Subject: RE: [Diffserv] Re: An apology... In-Reply-To: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> References: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Mudassir Tufail writes: > As per my understanding, just the DiffServ bit in the packets would not be > sufficient. It is regardless of the percentage of telephone traffic (or any > real time traffic) on the internet. Signaling is required to do two > important things: 1) call admission control and 2) resource allocation to an > admitted call. The same is valid, as well, for networks where resources are > policy-managed. i have no problems if my internet customer with a 10 mbps access link is using 10 % of the link bandwidth for telephone traffic and marks it accordingly. of course i'll have access control at the edge to make sure that they don't send more low delay traffic than the 10 % and there is absolutely no need for any kind of signaling. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 17:56:32 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09130 for ; Tue, 25 Jan 2000 17:56:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19985; Tue, 25 Jan 2000 17:24:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19958 for ; Tue, 25 Jan 2000 17:24:45 -0500 (EST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08873 for ; Tue, 25 Jan 2000 17:26:00 -0500 (EST) From: James_Binder@3com.com Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA29771; Tue, 25 Jan 2000 14:25:52 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id OAA07400; Tue, 25 Jan 2000 14:25:51 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 88256871.007AFEAD ; Tue, 25 Jan 2000 14:23:25 -0800 X-Lotus-FromDomain: 3COM To: Ping Pan cc: Stephen Casner , RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu Message-ID: <88256871.007AF25D.00@hqoutbound.ops.3com.com> Date: Tue, 25 Jan 2000 14:26:48 -0800 Subject: Re: [Diffserv] QoSSIG BOF Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Ping, Reading this chart, some interesting information stands out for me. First (and it may be too early to really judge from the limited data points given) but, it looks like the number of networks has begun to flatten out. While, Hosts and Domains continue to rise to to the right at about the same slope. In addition, eventhough we are increasing compacity of the networks (ie., WDM, dWDM, ect.), if the trend contineus, host will overrun the core (even at the mutligig speeds). This leads me to the agreement(s) I've heard here (as well as in other forum) where the best would be a combination of protocols (ie., QoS(RSVP like) at the edge to support host requirements and CoS (DS) in the core for use as well as scaleability. I would also draw another analogy as well. LDAP was supposed to be a scalled down version in place of X500. If you look at LDAP v3 with extensions, most the X.500 features deemed to complex are slowly creeping their way back into it because they really were needed and served a purpose. I'm not defending RSVP but, if the QoS features are really needed, no matter what protocol is used, the feature will show up again if needed. /jsb Ping Pan on 01/23/2000 12:53:25 AM To: Stephen Casner cc: RSVP , diffserv , end2end-interest@ISI.EDU, issll@lcs.mit.edu (bcc: James Binder/HQ/3Com) Subject: Re: [Diffserv] QoSSIG BOF Stephen Casner wrote: > > > I find this amusing from an historical perspective. One of the > motivations (not the only one) for the development of RSVP was that > ST-2 was "too complex and not scalable". The designers of RSVP saw a > simpler and more straightforward approach. In many ways, RSVP > improved upon ST-2, and it did start out simpler. But as the RSVP > solution was completed, it was no longer simple. > > Now those same complaints of complexity and scalability are being > lodged against RSVP. Some problems are fundamentally complex. Those > who believe they have a simple solution may not have reached the end > game. > -- Steve > Steve, IMHO, this is not a RSVP problem. Rather the network has grown too fast in the past few years. Please take a look at the network growth chart at http://www.cs.columbia.edu/~pingpan/projects/net_growth.gif. I don't think that one single protocol can provide the resource reservation solution to the world. RSVP may be already very good at what it does. We can continue to enhance RSVP again and again and squeeze the last drop of efficiency out of it, but maybe we should take one step back and re-evaluate the whole problem once again with new knowledge and new requirements. Let's fact it: during the days of original RSVP, the network was smaller. There was no MPLS (or connection-oriented IP packet-switching network) requirements. There was not much of WEB traffic if any. Instead people were expecting the coming of wild-spread multicast deployment to the entire network, and expecting the hugh number of teleconferencing applications. At the time, the Internet was a simple dumb-network/smart-end-host model. Nowadays, the Internet has smarter end-hosts and not-so-dumb networks. IETF's Traffic Engineering WG and many policy related WG's are focusing on how to configure the networks efficiently. So the original RSVP was designed with different objectives. I would think that we should first understand the problems involving with resource reservation, then try to solve the problems. In the past year, Ellen Hahne, Henning Schulzrinne and I had tried to understand the scaling problem with RSVP. After collecting some data from the network, we reasoned out some of the issues: First, we need a hierarchical reservation architecture. Making reservations on one flat network will not scale! Second, even when we are dealing with reservations at the network domain level, if we use signaling protocols with N**2 properties, such as RSVP, it will still be tough to work. Thus, our work on BGRP (http://www.ietf.org/internet-drafts/draft-pan-bgrp-framework-00.txt) is to propose an inter-domain reservation protocol running between BGP border routers. End users can use RSVP within their networks. RSVP flows can aggregate into the BGRP-reservation trunks at network edge. Thus the whole system will scale. This reminds me of the evolution of routing protocols. RIP was fine (after bug fixes ;-)) at what it does at small networks. But we could not use it to run a very large backone. With new requirements in mind, BGP came out. So a hierarchical routing model had made the Internet what it is today. We may adapt a similar approach to the reservation system. Best regards, -- Ping Pan http://www.cs.columbia.edu/~pingpan _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Tue Jan 25 21:17:04 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12946 for ; Tue, 25 Jan 2000 21:17:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27141; Tue, 25 Jan 2000 20:21:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27107 for ; Tue, 25 Jan 2000 20:20:57 -0500 (EST) Received: from krdl.org.sg (IDENT:root@rodin.krdl.org.sg [192.122.139.27]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12235 for ; Tue, 25 Jan 2000 20:22:11 -0500 (EST) Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id JAA03457; Wed, 26 Jan 2000 09:27:59 +0800 Received: from bnpc80 (lonestar.krdl.org.sg [192.168.133.124]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id JAA13959; Wed, 26 Jan 2000 09:21:39 +0800 (SGT) Message-ID: <001701bf679c$373766c0$7c85a8c0@krdl.org.sg> From: "Masilamany Raguparan" To: "Juha Heinanen" , "Mudassir Tufail" Cc: , "Stefaan De Cnodder" , "Ping Pan" , "Omar Elloumi" , "RSVP" , "diffserv" , References: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> <14478.5728.662262.635976@lohi.eng.telia.fi> Subject: Re: [Diffserv] Re: An apology... Date: Wed, 26 Jan 2000 09:25:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit > Mudassir Tufail writes: > > > As per my understanding, just the DiffServ bit in the packets would not be > > sufficient. It is regardless of the percentage of telephone traffic (or any > > real time traffic) on the internet. Signaling is required to do two > > important things: 1) call admission control and 2) resource allocation to an > > admitted call. The same is valid, as well, for networks where resources are > > policy-managed. > > i have no problems if my internet customer with a 10 mbps access link is > using 10 % of the link bandwidth for telephone traffic and marks it > accordingly. of course i'll have access control at the edge to make > sure that they don't send more low delay traffic than the 10 % and there > is absolutely no need for any kind of signaling. > What happens the required 10% of the link bandwidth becomes 15% at 10.00am. IMO, there is no need for signaling at packet level, slower time scale signaling needed for programming/reconfiguring the schedulers, buffer managers and policers. Regards Ragu Masilamany Raguparan InfoComm Lab, KRDL Singapore Tel : (65) 874 8541 Fax : (65)774 4998 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 03:02:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29796 for ; Wed, 26 Jan 2000 03:02:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18398; Wed, 26 Jan 2000 02:39:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18361 for ; Wed, 26 Jan 2000 02:39:25 -0500 (EST) Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29641 for ; Wed, 26 Jan 2000 02:40:41 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id JAA08770; Wed, 26 Jan 2000 09:40:24 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14478.42215.961311.2348@lohi.eng.telia.fi> Date: Wed, 26 Jan 2000 09:40:23 +0200 (EET) To: "Masilamany Raguparan" Cc: "Mudassir Tufail" , , "Stefaan De Cnodder" , "Ping Pan" , "Omar Elloumi" , "RSVP" , "diffserv" , Subject: Re: [Diffserv] Re: An apology... In-Reply-To: <001701bf679c$373766c0$7c85a8c0@krdl.org.sg> References: <636C2D109E6CD3119C3600062905FE8F086048@MAIL-CLUSTER.calynet.com> <14478.5728.662262.635976@lohi.eng.telia.fi> <001701bf679c$373766c0$7c85a8c0@krdl.org.sg> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Masilamany Raguparan writes: > What happens the required 10% of the link bandwidth becomes 15% at 10.00am. > IMO, there is no need for signaling at packet level, slower time scale > signaling needed for programming/reconfiguring the schedulers, buffer > managers and policers. 10 % was just an example. 15 % would be fine too. but my point was that the amount of real telephone conversations is not really growing at all if you exclude calls made for fax and internet, whereas internet data traffic is at least doubling every year. so a couple of years from now the total amount of traffic from telephone conversations will be so small as compared to the amount of data traffic that it becomes negligible. the internet is thus able to easily absorb the telephone traffic faster than it can be introduced taking into account the present rate of voip deployment. -- juha _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 04:07:13 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00310 for ; Wed, 26 Jan 2000 04:07:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20588; Wed, 26 Jan 2000 03:37:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20556 for ; Wed, 26 Jan 2000 03:37:38 -0500 (EST) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00069 for ; Wed, 26 Jan 2000 03:38:49 -0500 (EST) Received: from pasteur.cisco.com (pasteur.cisco.com [171.69.43.89]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id AAA07819 for ; Wed, 26 Jan 2000 00:56:54 -0800 (PST) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by pasteur.cisco.com (8.9.1b+Sun/8.9.1) with SMTP id AAA27008 for ; Wed, 26 Jan 2000 00:39:45 -0800 (PST) Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8]) by proxy1.cisco.com with SMTP (MailShield v1.5); Wed, 26 Jan 2000 00:39:31 -0800 Received: from hermes3.cstelecom.cie-signaux.fr (hermes3.cstelecom.cie-signaux.fr [172.17.64.31]) by oass09.cstelecom.cie-signaux.fr with ESMTP id JAA28152 for ; Wed, 26 Jan 2000 09:26:13 +0100 (MET) Received: from experdata.tm.fr ([172.17.65.84]) by hermes3.cstelecom.cie-signaux.fr (Netscape Messaging Server 3.62) with ESMTP id 424 for ; Wed, 26 Jan 2000 09:21:56 +0100 Message-ID: <388EAFAE.DD1F1FF8@experdata.tm.fr> Date: Wed, 26 Jan 2000 09:26:22 +0100 From: Laroche Christophe X-Mailer: Mozilla 4.5 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: diffserv@external.cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-SPAM: Yes X-SPAM-REASON: Suspicious SMTP Greeting X-SMTP-HELO: oass09.cstelecom.cie-signaux.fr X-SMTP-MAIL-FROM: claroche@experdata.tm.fr X-SMAP-Received-From: outside X-SMTP-PEER-INFO: mailhub.cie-signaux.fr [194.2.40.8] Content-Transfer-Encoding: 7bit Subject: [Diffserv] unsubscribe diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 09:44:34 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04831 for ; Wed, 26 Jan 2000 09:44:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00038; Wed, 26 Jan 2000 09:11:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00009 for ; Wed, 26 Jan 2000 09:11:06 -0500 (EST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04459 for ; Wed, 26 Jan 2000 09:12:21 -0500 (EST) Received: from haserver.cs.huji.ac.il ([132.65.200.200] ident=exim) by cs.huji.ac.il with esmtp (Exim 3.10 #1) id 12DTB0-0007iO-00; Wed, 26 Jan 2000 16:12:06 +0200 Received: from anker by haserver.cs.huji.ac.il with local (Exim 3.03 #1) id 12DTAz-0006j6-00; Wed, 26 Jan 2000 16:12:05 +0200 Date: Wed, 26 Jan 2000 16:12:05 +0200 (IST) From: Tal Anker To: Ping Pan cc: lewis@gennet.com.tw, diffserv , "end2end-interest@ISI.EDU" , RSVP Subject: Re: [Diffserv] QoSSIG BOF In-Reply-To: <388D9150.D17C89BF@research.bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > > > I also suggest the RSVP discussion may combine with the > > > > packet classifier / packet scheduler ,since the heart of > > > > QOS is that part: the TSPEC will map into the class for > > > > classifier and scheduler, they are the executors! > > > > we all know that the experiments on RSVP+WFQ or RSVP+CBQ are > > > > not precise as we expected. > > > > RSVP and other proposals (BGRP, YESSIR...) are signaling protocols to > distribute resource information between end hosts and routers. But IMO, > they do NOT apply the actual reservation, packet queuing, buffer > management, scheduling and classification. > That is correct. However, the scaling of the reservation model is not only a matter of the signaling protocol, but it also concerned with the other elements, mentioned above, as to how well do they scale. Thus, it will be interesting to know, apart from the debate wether RSVP scales or not, if the elements that need to perform the actual reservation can scale to up to the granularity of the QoS reservation signaled by RSVP. Otherwise, what's the sense to reserve bw/delay for a microflow, if the scheduling element in the core network can not support the guaranteed reservation granularity? - Tal. ----------------------------------------------------------- Institute of Computer Science The Hebrew University of Jerusalem, Givat Ram, Jerusalem 91904 Israel Phone: +972-2-6585706 Fax : +972-2-6585439 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 10:38:31 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05647 for ; Wed, 26 Jan 2000 10:38:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01473; Wed, 26 Jan 2000 09:58:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01451 for ; Wed, 26 Jan 2000 09:58:33 -0500 (EST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05022 for ; Wed, 26 Jan 2000 09:59:50 -0500 (EST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jan 2000 06:55:15 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jan 2000 06:55:15 -0800 Message-ID: <078292D50C98D2118D090008C7E9C6A6094602AA@STAY.platinum.corp.microsoft.com> From: Yoram Bernet To: Tal Anker , Ping Pan Cc: lewis@gennet.com.tw, diffserv , "end2end-interest@ISI.EDU" , RSVP Subject: RE: [Diffserv] QoSSIG BOF Date: Wed, 26 Jan 2000 06:55:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org > > > RSVP and other proposals (BGRP, YESSIR...) are signaling > protocols to > > distribute resource information between end hosts and > routers. But IMO, > > they do NOT apply the actual reservation, packet queuing, buffer > > management, scheduling and classification. > > > > That is correct. However, the scaling of the reservation > model is not only > a matter of the signaling protocol, but it also concerned > with the other > elements, mentioned above, as to how well do they scale. > Actually, no - it is not. RSVP does *not* mandate per-flow traffic handling. When I speak about work that has been done to make the RSVP approach more scalable, one of the key aspect of this work is coupling per-flow reservation with aggregate (diffserv) traffic handling. Please keep the two separate. The scaling characteristics of listening to one message per flow, every 30 seconds, are very very different from those of policing/scheduling every packet on each flow. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 18:48:28 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13430 for ; Wed, 26 Jan 2000 18:48:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15032; Wed, 26 Jan 2000 18:20:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15000 for ; Wed, 26 Jan 2000 18:20:15 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13169 for ; Wed, 26 Jan 2000 18:21:32 -0500 (EST) From: Masataka Ohta Message-Id: <200001262316.IAA21785@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA21785; Thu, 27 Jan 2000 08:16:18 +0900 Subject: Re: [Diffserv] QoSSIG BOF To: anker@cs.huji.ac.il (Tal Anker) Date: Thu, 27 Jan 0 8:16:17 JST Cc: pingpan@research.bell-labs.com, lewis@gennet.com.tw, diffserv@ietf.org, end2end-interest@ISI.EDU, rsvp@ISI.EDU In-Reply-To: ; from "Tal Anker" at Jan 26, 100 11:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Tal; > > > I also suggest the RSVP discussion may combine with the > > > packet classifier / packet scheduler ,since the heart of > > > QOS is that part: the TSPEC will map into the class for > > > classifier and scheduler, they are the executors! > > > we all know that the experiments on RSVP+WFQ or RSVP+CBQ are > > > not precise as we expected. > > RSVP and other proposals (BGRP, YESSIR...) are signaling protocols to > > distribute resource information between end hosts and routers. But IMO, > > they do NOT apply the actual reservation, packet queuing, buffer > > management, scheduling and classification. > That is correct. However, the scaling of the reservation model is not only > a matter of the signaling protocol, but it also concerned with the other > elements, mentioned above, as to how well do they scale. Right. > Thus, it will be interesting to know, apart from the debate wether RSVP > scales or not, if the elements that need to perform the actual reservation > can scale to up to the granularity of the QoS reservation signaled by > RSVP. It was an interesting research topic to confirm everything scale. The most aggressive part was to throw away GS as an overkill (but note that CL is underkill and useless). > Otherwise, what's the sense to reserve bw/delay for a microflow, if > the scheduling element in the core network can not support the guaranteed > reservation granularity? Given the uniform end to end scalability, your terminology of "core network" is improper. Masataka Ohta _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Wed Jan 26 22:22:45 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16309 for ; Wed, 26 Jan 2000 22:22:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24002; Wed, 26 Jan 2000 21:52:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23962 for ; Wed, 26 Jan 2000 21:52:08 -0500 (EST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15887 for ; Wed, 26 Jan 2000 21:53:26 -0500 (EST) Message-Id: <200001270253.VAA15887@ietf.org> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Wed, 26 Jan 2000 21:52:54 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DKPQQD9C; Wed, 26 Jan 2000 21:52:53 -0500 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DMXA23ZN; Wed, 26 Jan 2000 21:52:53 -0500 Date: Wed, 26 Jan 2000 21:52:16 -0500 (EST) From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: Re: [Diffserv] Re: An apology... To: Mudassir@calynet.com cc: jh@lohi.eng.telia.fi, Istvan.I.Cselenyi@telia.se, cnodders@rc.bel.alcatel.be, pingpan@research.bell-labs.com, Omar.Elloumi@alcatel.be, rsvp@isi.edu, diffserv@ietf.org, end2end-interest@isi.edu X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA23963 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit This whole discussion on signalling seems to be confusing a few things. In Intserv, you had: - an explicitly signalled request for access to the network (via RSVP) AND - Dynamically configured router resources to meet the needs of the RSVP request In Diffserv, the basic architecture facilitates a 2X2 matrix of options: 1. Implicit signalling + Statically configured router resources 2. Explicit signalling + Statically configured router resources 3. Explicit signalling + Dynamic configuration of router resources. 4. Implicit signalling + Dynamic configuration of router resources Option 1 is the option being adopted today to enable widespread deployment of Diffserv. It does not preclude the emergence of wide-spread use of explicit signalling However, the need to develop a signalling mechanism for Diffserv is independent of whether network resources are configured statically or dynamically. It seems to me that signalling schemes or revectored RSVP schemes should not be directly coupled with the provisioning of router resources. Regards Nabil Seddigh nseddigh@nortelnetworks.com Mudassir Tufail writes: >......... It is regardless of the percentage of telephone traffic > (or any real time traffic) on the internet. Signaling is required > to do two important things: > 1) call admission control and 2) resource allocation > to an admitted call. The same is valid, as well, > for networks where resources are policy-managed. > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Fri Jan 28 08:44:47 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09808 for ; Fri, 28 Jan 2000 08:44:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08607; Fri, 28 Jan 2000 07:51:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08581 for ; Fri, 28 Jan 2000 07:51:33 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07504 for ; Fri, 28 Jan 2000 07:52:50 -0500 (EST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 28 Jan 2000 06:52:45 -0600 Received: by zsc4c002.corpwest.baynetworks.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 04:52:38 -0800 Message-ID: From: "Ken Birtwistle" To: "'diffserv@ietf.org'" , "'iptel@lists.research.bell-labs.com'" , "'mpls@UU.NET'" , "'pint@lists.research.bell-labs.com'" , "'policy@raleigh.ibm.com'" , "'rap@iphighway.com'" , "'rsvp@ISI.EDU'" Date: Fri, 28 Jan 2000 04:52:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF698E.8E625628" Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org 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_01BF698E.8E625628 Content-Type: text/plain; charset="ISO-8859-1" unsubscribe kbirtwis@nortelnetworks.com ------_=_NextPart_001_01BF698E.8E625628 Content-Type: text/html; charset="ISO-8859-1"

unsubscribe kbirtwis@nortelnetworks.com

------_=_NextPart_001_01BF698E.8E625628-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/ From diffserv-admin@ietf.org Mon Jan 31 00:15:30 2000 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16651 for ; Mon, 31 Jan 2000 00:15:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13384; Sun, 30 Jan 2000 23:27:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13353 for ; Sun, 30 Jan 2000 23:27:21 -0500 (EST) Received: from server1.itr.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15867 for ; Sun, 30 Jan 2000 23:28:24 -0500 (EST) Received: from spri.levels.unisa.edu.au (maria@kruschev [172.17.0.97]) by server1.itr.unisa.edu.au (8.9.3/8.9.1) with ESMTP id OAA01437; Mon, 31 Jan 2000 14:57:06 +1030 (CST) Message-ID: <38950FB1.6BEECF02@spri.levels.unisa.edu.au> Date: Mon, 31 Jan 2000 14:59:38 +1030 From: Maria Elena Villapol X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.35 i586) MIME-Version: 1.0 To: RSVP , diffserv Content-Type: multipart/alternative; boundary="------------9CEB57EB3D376BE6C9018D75" Subject: [Diffserv] IETF Meeting Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: diffserv@ietf.org --------------9CEB57EB3D376BE6C9018D75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody I am a PhD student at the University of South Australia which is in Adelaide. I and some other students have the opportunity to go to the 47th IETF Meeting which will be held in Adelaide at the end of March. Particularly I am interested in RSVP since I am modeling it. So, I would like to attend RSVP-related sessions and DiffServ-related sessions. How could we get the work group scheduling (agenda) for the meeting? Thank in advance Maria -- Maria Elena Villapol PhD Student Institute for Telecommunications Research University of South Australia email: maria@spri.levels.unisa.edu.au VILME001@Students.UniSA.Edu.Au Web Page: http://www.itr.unisa.edu.au/~maria/index.htm --------------9CEB57EB3D376BE6C9018D75 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody

I am a PhD student at the University of South Australia which is in Adelaide. I and some other students have the opportunity to go to the 47th IETF Meeting which will be held in Adelaide at the end of March. Particularly I am interested in RSVP since I am modeling it. So, I would like to attend RSVP-related sessions and DiffServ-related sessions.
How could we get the work group scheduling (agenda) for the meeting?

Thank in advance

Maria 

-- 
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: maria@spri.levels.unisa.edu.au
       VILME001@Students.UniSA.Edu.Au

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm
  --------------9CEB57EB3D376BE6C9018D75-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www.ietf.org/mailman/listinfo/diffserv Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/