From mailnull@www1.ietf.org Tue Mar 4 19:04:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16229 for ; Tue, 4 Mar 2003 19:04:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h250FRw26782 for diffserv-interest-archive@odin.ietf.org; Tue, 4 Mar 2003 19:15:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250FR526777; Tue, 4 Mar 2003 19:15:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250Ef526723 for ; Tue, 4 Mar 2003 19:14:41 -0500 Received: from mshield (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16196 for ; Tue, 4 Mar 2003 19:03:26 -0500 (EST) Received: FROM cse.nd.edu BY mshield ; Tue Mar 04 19:03:51 2003 -0500 Date: Tue, 4 Mar 2003 19:05:29 -0500 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed From: Aaron Striegel To: diffserv-interest@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2D23545B-4E9E-11D7-9EC5-000393CE003E@cse.nd.edu> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] [Diffserv] Benchmarking I-D: draft-ietf-bmwg-dsmterm-05.txt Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Kevin Dubray > Date: Tue Mar 4, 2003 9:59:02 AM America/Indianapolis > To: diffserv@ietf.org > Cc: Randy Bush , Bert Wijnen > Subject: [Diffserv] Benchmarking I-D: draft-ietf-bmwg-dsmterm-05.txt > > Hi, > > The Benchmarking Methodology WG (BMWG) is currently reviewing an > I-D, "Terminology for Benchmarking Network-layer Traffic > Control Mechanisms." This I-D seeks to describes terminology > for the benchmarking of devices that implement traffic control > based on IP precedence or diff-serv code point criteria. > > Interested parties will find the related Internet-Draft here: > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-05.txt > > Discussion can be found on the BMWG mailing list and its archive: > http://www.ietf.org/mail-archive/working-groups/bmwg/current/ > maillist.html > > Commentary posted to bmwg@ietf.org is welcome. > > Posted in the fine spirit of cross-WG feedback, > Kevin > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/current/ > maillist.html _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From mailnull@www1.ietf.org Sat Mar 8 21:31:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09549 for ; Sat, 8 Mar 2003 21:31:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h292hI725187 for diffserv-interest-archive@odin.ietf.org; Sat, 8 Mar 2003 21:43:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h292gjO25132; Sat, 8 Mar 2003 21:42:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h292X6O23989 for ; Sat, 8 Mar 2003 21:33:06 -0500 Received: from dalziel.ucs.ed.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07348; Sat, 8 Mar 2003 21:20:18 -0500 (EST) Received: from PYTHAGORAS.internetdesigntools.com (opal.epcc.ed.ac.uk [129.215.56.2]) by dalziel.ucs.ed.ac.uk (8.12.6/8.12.6) with ESMTP id h292J0Je013626; Sun, 9 Mar 2003 02:19:02 GMT Message-Id: <5.1.0.14.0.20030309015249.027bdbc0@localhost> X-Sender: martin@internetdesigntools.com@popmail.internetdesigntools.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 02:20:36 +0000 To: Sapna Isotupa , diffserv@ietf.org From: Martin Westhead Cc: diffserv-interest@ietf.org In-Reply-To: References: <3E686E9B.BDB38CB7@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Edinburgh-Scanned: at dalziel.ucs.ed.ac.uk with MIMEDefang 2.29, Sophie 1.40rc1, Sophos Anti-Virus 3.66 X-Scanned-By: MIMEDefang 2.29 (www . roaringpenguin . com / mimedefang) Subject: [Diffserv-interest] Re: [Diffserv] simulator for diffserv Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , At 08/03/2003 15:14 Saturday, Sapna Isotupa wrote: >Hello All: > >Is there a simulator available for testing various scheduling policies for >diffserv? If yes, could you tell me whom to contact to obtain one. If >there is no simulator available, will others be interested if a simulator >for testing various scheduling policies is built? Hi Sapna, This is off-topic for the diffserv list. I have cross posted to diffserv-interest and if there is any follow-up discussion it should go there. Intersim is a simulation platform that models very precisely the behaviour of Cisco diffserv algorithms. It is currently under development by Internet Design Tools, funded by Cisco Systems. We have access to the IOS source code and have taken a lot of trouble to ensure, and have lab tests to demonstrate, that the simulator's performance is indeed very close to that of the real router. We have plans to extend the simulator to generic diffserv models, and models of other vendor's platforms, however we do not a timescale for that development. There is more information available at www.internetdesigntools.com. Intersim is not commercially available at this point, but we have a small group of users, if you are interested in using it please contact me directly. Other simulators that also have (less specialised) models of diffserv behaviour include: Opnet: www.opnet.com Qualnet: www.qualnet.com ns-2: http://www.isi.edu/nsnam/ns/ The last one is open source and free, the others are commercial. Cheers, Martin ----------------------Internet-Design-Tools-Ltd.-------------------- Dr. Martin Westhead Phone: +44 77 189 189 64 Email: martin@InternetDeignTools.com ---------------------www.InternetDesignTools.com--------------------- _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From mailnull@www1.ietf.org Thu Mar 13 08:12:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29256 for ; Thu, 13 Mar 2003 08:12:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DDROr25684 for diffserv-interest-archive@odin.ietf.org; Thu, 13 Mar 2003 08:27:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDRLO25679; Thu, 13 Mar 2003 08:27:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDQJO25609 for ; Thu, 13 Mar 2003 08:26:19 -0500 Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29210; Thu, 13 Mar 2003 08:11:18 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2DDDMOI097812; Thu, 13 Mar 2003 14:13:22 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2DDDMcx247858; Thu, 13 Mar 2003 14:13:22 +0100 Received: from dhcp23-54.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39300 from ; Thu, 13 Mar 2003 14:13:20 +0100 Message-Id: <3E7083B4.C2E75FF2@hursley.ibm.com> Date: Thu, 13 Mar 2003 14:12:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Woundy, Richard" Cc: diffserv-interest@ietf.org, "IPCDN WG (E-mail)" References: <6732623D2548D61193C90002A5C88DCC06B9ADD2@entmaexch02.broadband.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv-interest] Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Woundy, Richard" wrote: > > Brian (and many diffserv folks), > > Thanks for your input and of the diffserv WG. I will assume that our IPCDN > MIBs need to use explicit DSCP values and not use DSCP masks. > > Please forgive this question for my DiffServ education. I have heard several > times that "network operators are free to ignore the recommended code > points", and that this is a major reason why we should not use DSCP masks. > > What benefits does a network operator achieve with an unstructured set of > DSCPs? The reason we did this, after very explicit pressure from ISPs at the beginning of diffserv, was because they didn't want to be constrained by (say) having at most 4 AF classes, or only one EF class, etc. In fact it seemed pretty clear that there was no one-size-fits-all set of PHBs, since different operators had different QOS business models in mind. So all the code points became RECOMMENDED. I would expect an operator to define a structured set of PHBs and DSCPs. I would even expect many of them to use the recommended ones from the various RFCs. > > In fact, I *am* a network operator -- I work for Comcast Cable, which has > lots of regional networks and millions of residential cable modem > subscribers. I see the pain associated with network management of my > boundary nodes with unstructured DSCP assignments. Where's the benefit to > me? None whatever. I would recommend any network operator (ISP or enterprise) to define a set of DSCPs and stick to it as long as possible. The SLAs at the network edge should specify how the sets are mapped across each network-to-network border. There are more words on this topic in Differentiated Services in the Internet, B.Carpenter and K. Nichols, Proc. IEEE, 90 (9) (2002) 1479-1494. > > I don't mind if folks take this question off-list, or if folks refer me to > specific diffserv mail archives (e.g. a specific "thread" name) where this > was already discussed. Just as long as I am not mistaken as a spammer. ;^) Well, I did switch this to the diffserv-interest list, since we are now closing the diffserv list to reduce the amount of get-rich-quick mail that we have to delete each day :-) Brian > > -- Rich > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Saturday, March 08, 2003 6:59 AM > To: John Schnizlein > Cc: Woundy, Richard; 'diffserv@ietf.org' > Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs > > What John writes is definitive. Masking DSCPs is > simply wrong. The fact that the recommended AF code > points happen to be numerically consecutive is just an > accident of the code point assignment process; the bit > positions are not significant, and network operators are > free to ignore the recommended code points if they want to. > > Brian > > John Schnizlein wrote: > > > > Comments embedded in context below: > > > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > > >interaction. > > >... > > >I think there are two issues here: are Dscp mask objects legal, > > > > No. > > > > >and are they worthwhile? > > > > No. > > > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > > > The structure of the DS field shown above is incompatible with the > > > existing definition of the IPv4 TOS octet in [RFC791]. The > > > presumption is that DS domains protect themselves by deploying re- > > > marking boundary nodes, as should networks using the RFC 791 > > > Precedence designations. Correct operational procedure SHOULD follow > > > [RFC791], which states: "If the actual use of these precedence > > > designations is of concern to a particular network, it is the > > > responsibility of that network to control the access to, and use of, > > > those precedence designations." Validating the value of the DS field > > > at DS boundaries is sensible in any case since an upstream node can > > > easily set it to any arbitrary value. DS domains that are not > > > isolated by suitably configured boundary nodes may deliver > > > unpredictable service. > > > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > > or end-to-end service. Specifications of DS field translations at DS > > > boundaries are the subject of service level agreements between > > > providers and users, and are outside the scope of this document. > > > Standardized PHBs allow providers to build their services from a > > > well-known set of packet forwarding treatments that can be expected > > > to be present in the equipment of many vendors. > > > > > >On the other hand, I see the definite lack of structure in the DiffServ > > >codepoints, and I am debating with myself whether a "Dscp mask" is worth > the > > >trouble or not. > > > > > >In particular, I am looking at the current codepoint assignments in > > >,... > > > > You may be running into a subtlety that was worried about early in > > defining the DiffServ field. The code points in the registry are > > just recommended values, not required values. While there are > > requirements regarding which behaviors must be supported to claim > > DiffServ compliance, there is no requirement that the recommended > > values be used to indicate these behaviors. > > > > The point is that there is no reliable structure for "the network > > operator to take advantage of". The presence of masks in data objects > > would encourage creating the sort of structure the RFC prohibits. > > > > Note the distinction between the SHOULD regarding values, and the MUST > regarding treating the value as a unit (copied farther below): > > > > RFC 2474 section 2, page 5 > > Codepoint: a specific value of the DSCP portion of the DS field. > > Recommended codepoints SHOULD map to specific, standardized PHBs. > > > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > > > I don't appreciate the distinction. What was intended by PHB selector > > was that traffic could be selected from the aggregate by the DSCP. > > How is this different from filtering traffic based on DSCP matches? > > > > >And we'e not inferring bit-structure in the implementation, merely > > >allowing the network operator to take advantage of any structure > > >that exists. Do we really want to require the operator to install > > >three separate filters to catch one AF class? > > > > > >I don't find anything in the cited paragraph that contraindicates this > sort > > >of usage. The fact that today's PHB selector set is likely to change is > all > > >the more reason to give a filter-installer some options for concise > > >representation. > > >... > > >RFC 2474 Section 3, page 7 > > > Implementors should note that the DSCP field is six bits wide. DS- > > > compliant nodes MUST select PHBs by matching against the entire 6-bit > > > DSCP field, e.g., by treating the value of the field as a table index > > > which is used to select a particular packet handling mechanism which > > > has been implemented in that device. The value of the CU field MUST > > > be ignored by PHB selection. The DSCP field is defined as an > > > unstructured field to facilitate the definition of future per-hop > > > behaviors. > > > > John _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From mailnull@www1.ietf.org Thu Mar 20 14:45:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01877 for ; Thu, 20 Mar 2003 14:45:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KK39B20177 for diffserv-interest-archive@odin.ietf.org; Thu, 20 Mar 2003 15:03:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KK38O20172; Thu, 20 Mar 2003 15:03:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJ0dO14579 for ; Thu, 20 Mar 2003 14:00:39 -0500 Received: from smtp2.cp.tin.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28888 for ; Thu, 20 Mar 2003 13:42:08 -0500 (EST) Received: from logione (80.116.179.42) by smtp2.cp.tin.it (6.5.033) id 3E66087500655D6F for diffserv-interest@ietf.org; Thu, 20 Mar 2003 19:44:24 +0100 From: "Giovanni" To: Date: Thu, 20 Mar 2003 19:44:29 +0100 Message-ID: <000c01c2ef10$bd5f9bb0$2ab37450@logione> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C2EF19.1F2403B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Diffserv-interest] [Diffserv] implementation question Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C2EF19.1F2403B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi everybody. Can someone help me? I would like to know if when I assign a MIB kind ROW POINTER I must necessarily separately assign her each index of the OID or a function ad hoc exists? I must do so that is: q->diffServClfrElementSpecific[0] = 1; q->diffServClfrElementSpecific[1] = 3; q->diffServClfrElementSpecific[2] = 6; q->diffServClfrElementSpecific[3] = 1; q->diffServClfrElementSpecific[4] = 2; q->diffServClfrElementSpecific[5] = 1; q->diffServClfrElementSpecific[6] = 12345; q->diffServClfrElementSpecific[7] = 1; q->diffServClfrElementSpecific[8] = 2; q->diffServClfrElementSpecific[9] = 6; q->diffServClfrElementSpecific[10] = 1; q->diffServClfrElementSpecific[11] = 1; q->diffServClfrElementSpecific[12] = clfr_six_id; q->_diffServClfrElementSpecificLength = 13 * sizeof (oid); or a suitable function exists what realize: diffServClfrElementSpecific = DiffServQid for instance? Thanks to everybody. Giovanni ------=_NextPart_000_000D_01C2EF19.1F2403B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi everybody.

Can someone help me?

I would like to know if when I assign a MIB = kind ROW POINTER  I must necessarily separately assign her each index of the = OID or a function ad hoc exists?

I must do so that is:

        = ;            =       q->diffServClfrElementSpecific[0] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[1] =3D 3;

        = ;            =       q->diffServClfrElementSpecific[2] =3D 6;

        = ;            =       q->diffServClfrElementSpecific[3] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[4] =3D 2;

        = ;            =       q->diffServClfrElementSpecific[5] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[6] =3D 12345;

        = ;            =       q->diffServClfrElementSpecific[7] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[8] =3D 2;

        = ;            =       q->diffServClfrElementSpecific[9] =3D 6;

        = ;            =       q->diffServClfrElementSpecific[10] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[11] =3D 1;

        = ;            =       q->diffServClfrElementSpecific[12] =3D = clfr_six_id;

        = ;            =       q->_diffServClfrElementSpecificLength =3D = 13 * sizeof (oid);

or a suitable function exists what realize: = diffServClfrElementSpecific =3D DiffServQid for instance?

Thanks to everybody.

 

Giovanni

 

 

 

------=_NextPart_000_000D_01C2EF19.1F2403B0-- _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest From mailnull@www1.ietf.org Mon Mar 31 18:14:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01589 for ; Mon, 31 Mar 2003 18:14:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VNc4J27711 for diffserv-interest-archive@odin.ietf.org; Mon, 31 Mar 2003 18:38:04 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNc3K27706; Mon, 31 Mar 2003 18:38:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNaMK26900 for ; Mon, 31 Mar 2003 18:36:22 -0500 Received: from bells.cs.ucl.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01347 for ; Mon, 31 Mar 2003 18:12:24 -0500 (EST) Received: from kylie.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 1 Apr 2003 00:14:22 +0100 Received: by kylie.cs.ucl.ac.uk (Postfix, from userid 16091) id DC7FE372A1; Tue, 1 Apr 2003 00:14:21 +0100 (BST) Received: from kylie.cs.ucl.ac.uk (localhost [127.0.0.1]) by kylie.cs.ucl.ac.uk (Postfix) with ESMTP id DB6D0372A0 for ; Tue, 1 Apr 2003 00:14:21 +0100 (BST) To: diffserv-interest@ietf.org Date: Tue, 01 Apr 2003 00:14:16 +0100 Message-ID: <21773.1049152456@kylie.cs.ucl.ac.uk> From: Tristan Henderson Subject: [Diffserv-interest] SIGCOMM 2003 RIPQOS Workshop - deadline extended Sender: diffserv-interest-admin@ietf.org Errors-To: diffserv-interest-admin@ietf.org X-BeenThere: diffserv-interest@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Differentiated services general discussion List-Post: List-Help: List-Subscribe: , WORKSHOP in conjunction with ACM SIGCOMM 2003 Karlsruhe, Germany 25 and 27 August 2003 http://www.acm.org/sigcomm/sigcomm2003/workshops.html Workshop on Revisiting IP QoS: Why do we care, what have we learned? RIPQOS -- Wed. 27 Aug. 2003 Paper registration deadline: 31 March 2003 Paper submission deadline: 7 April 2003 http://www.acm.org/sigcomm/sigcomm2003/workshop/ripqos For over a decade the Internet engineering and research community has debated, designed, and ignored IP Quality of Service tools and techniques. There's a sense that something might be needed, but little agreement on why and who will pay. At times the very notion of QoS has seemed to be a pointless waste of time, almost a solution waiting for a problem. This workshop is an opportunity for researchers and practitioners to discuss the history of IP QoS research and development, review what could have been done better, and perhaps develop a new focus going forward. _______________________________________________ Diffserv-interest mailing list Diffserv-interest@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv-interest