From daemon@optimus.ietf.org Tue Jan 8 09:04:34 2002 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 JAA21977 for ; Tue, 8 Jan 2002 09:04:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00354 for diffserv-archive@odin.ietf.org; Tue, 8 Jan 2002 09:04: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 IAA29087; Tue, 8 Jan 2002 08:42: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 IAA29054 for ; Tue, 8 Jan 2002 08:42:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20417; Tue, 8 Jan 2002 08:42:45 -0500 (EST) Message-Id: <200201081342.IAA20417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Jan 2002 08:42:45 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-07.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology and Clarification for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-07.txt Pages : 9 Date : 07-Jan-02 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020107134945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107134945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 From daemon@optimus.ietf.org Tue Jan 8 12:03:50 2002 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 MAA00007 for ; Tue, 8 Jan 2002 12:03:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09377 for diffserv-archive@odin.ietf.org; Tue, 8 Jan 2002 12:03: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 LAA07575; Tue, 8 Jan 2002 11:48: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 LAA07533 for ; Tue, 8 Jan 2002 11:48:54 -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 LAA29295 for ; Tue, 8 Jan 2002 11:48:52 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA29791 for ; Tue, 8 Jan 2002 09:48:53 -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 JAA10461 for ; Tue, 8 Jan 2002 09:48:52 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA09762 for ; Tue, 8 Jan 2002 11:48:28 -0500 (EST) Message-Id: <200201081648.LAA09762@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: Tue, 08 Jan 2002 11:46:39 -0500 From: Dan Grossman Subject: [Diffserv] New Terms draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As you have seen in this morning's email, the -07 version of the New Terms draft is out. This will be the final version. It reflects comments made during last call, including: -- relationship between SLS and service provisioning policy has been aligned with RFC 3198 -- reference to BCP0037 has been updated -- the issue of backward compatibility with RFC 1349 has been clarified. It was pointed out that TOS bit processing is present not only in RFC 1812 (router requirments) but also in RFC 1122 and RFC 1123 (host requirements). Since TOS bit processing was more pervasive in RFC 1812 than I originally thought, specific section references were removed. -- A clarification of IANA considerations in RFC 2474 was added at the request of IANA -- All references are marked as "Normative" In addition, I have slightly modified the title to better reflect the content. With that, the next step is in the able hands of the chairs. Dan _______________________________________________ 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 From daemon@optimus.ietf.org Tue Jan 8 12:40:57 2002 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 MAA01671 for ; Tue, 8 Jan 2002 12:40:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11665 for diffserv-archive@odin.ietf.org; Tue, 8 Jan 2002 12:40: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 MAA10602; Tue, 8 Jan 2002 12:27:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10578 for ; Tue, 8 Jan 2002 12:27:48 -0500 (EST) Received: from zeus.anet-chi.com (root@zeus.anet-chi.com [207.7.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01098 for ; Tue, 8 Jan 2002 12:27:45 -0500 (EST) Received: from RepliGate (as1b-39.chi.il.dial.anet.com [198.92.157.39]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g08HRiop022648; Tue, 8 Jan 2002 11:27:45 -0600 (CST) Message-ID: <1b4701c19882$71ac4410$0100a8c0@RepliGate> From: "Jim Fleming" To: , "Dan Grossman" References: <200201081648.LAA09762@noah.dma.isg.mot.com> Subject: Re: [Diffserv] New Terms draft Date: Tue, 8 Jan 2002 12:24:14 -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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Dan Grossman" > -- All references are marked as "Normative" > > In addition, I have slightly modified the title to better reflect the content. > > With that, the next step is in the able hands of the chairs. > It sounds like your IPv4 experiments have been interesting. The chairs of the various ICANN groups seem to be changing. It is not clear how that will impact your results. Do you use a 2002 prefix ? http://www.dot-biz.com/INFO/Papers/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jan 9 09:47:41 2002 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 JAA04531 for ; Wed, 9 Jan 2002 09:47:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03994 for diffserv-archive@odin.ietf.org; Wed, 9 Jan 2002 09:47: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 JAA03354; Wed, 9 Jan 2002 09:31: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 JAA03320 for ; Wed, 9 Jan 2002 09:31:01 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04307 for ; Wed, 9 Jan 2002 09:30:57 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA07092; Wed, 9 Jan 2002 15:30:25 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42380 from ; Wed, 9 Jan 2002 15:30:24 +0100 Message-Id: <3C3C5400.D04583AD@hursley.ibm.com> Date: Wed, 09 Jan 2002 15:30:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Dan Grossman Cc: diffserv@ietf.org Subject: Re: [Diffserv] New Terms draft References: <200201081648.LAA09762@noah.dma.isg.mot.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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Thanks Dan. The request for publication as an Informational RFC is already on its way to our Area Director. Brian Dan Grossman wrote: > > As you have seen in this morning's email, the -07 version of the New Terms > draft is out. This will be the final version. It reflects comments made > during last call, including: > -- relationship between SLS and service provisioning policy has been aligned > with RFC 3198 > -- reference to BCP0037 has been updated > -- the issue of backward compatibility with RFC 1349 has been clarified. It > was pointed out > that TOS bit processing is present not only in RFC 1812 (router > requirments) but also in > RFC 1122 and RFC 1123 (host requirements). Since TOS bit processing was > more pervasive > in RFC 1812 than I originally thought, specific section references were > removed. > -- A clarification of IANA considerations in RFC 2474 was added at the > request of IANA > -- All references are marked as "Normative" > > In addition, I have slightly modified the title to better reflect the content. > > With that, the next step is in the able hands of the chairs. > > Dan _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jan 9 10:32:16 2002 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 KAA05493 for ; Wed, 9 Jan 2002 10:32:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06267 for diffserv-archive@odin.ietf.org; Wed, 9 Jan 2002 10:32:16 -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 KAA05457; Wed, 9 Jan 2002 10:22: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 KAA05423 for ; Wed, 9 Jan 2002 10:22:07 -0500 (EST) Received: from zeus.anet-chi.com (root@zeus.anet-chi.com [207.7.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05272 for ; Wed, 9 Jan 2002 10:22:04 -0500 (EST) Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09FLNGx020087; Wed, 9 Jan 2002 09:21:24 -0600 (CST) Message-ID: <231201c19939$f7d03e90$0100a8c0@RepliGate> From: "Jim Fleming" To: "Brian E Carpenter" , "Dan Grossman" Cc: References: <200201081648.LAA09762@noah.dma.isg.mot.com> <3C3C5400.D04583AD@hursley.ibm.com> Subject: Re: [Diffserv] New Terms draft Date: Wed, 9 Jan 2002 10:17:57 -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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Brian E Carpenter" To: "Dan Grossman" Cc: Sent: Wednesday, January 09, 2002 6:30 AM Subject: Re: [Diffserv] New Terms draft > Thanks Dan. The request for publication as an Informational RFC is > already on its way to our Area Director. > > Brian > http://www.icann.org/general/iana-contract-09feb00.htm Contract Between ICANN and the United States Government for Performance of the IANA Function http://www.pso.icann.org/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 10 11:33:42 2002 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 LAA18336 for ; Thu, 10 Jan 2002 11:33:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03479 for diffserv-archive@odin.ietf.org; Thu, 10 Jan 2002 11:33: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 LAA02297; Thu, 10 Jan 2002 11:10: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 LAA02266 for ; Thu, 10 Jan 2002 11:10:11 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17379 for ; Thu, 10 Jan 2002 11:10:09 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA09654 for ; Thu, 10 Jan 2002 17:09:39 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28744 from ; Thu, 10 Jan 2002 17:09:38 +0100 Message-Id: <3C3DBCC3.C3BB2F1A@hursley.ibm.com> Date: Thu, 10 Jan 2002 17:09:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Test (please ignore) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit It's been suggested to me that there may be a robot generating replies to this list. So please ignore this, unless you are a robot. Brian Carpenter diffserv co-chair _______________________________________________ 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 From daemon@optimus.ietf.org Fri Jan 18 07:13:12 2002 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 HAA07832 for ; Fri, 18 Jan 2002 07:13:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08838 for diffserv-archive@odin.ietf.org; Fri, 18 Jan 2002 07:13: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 GAA07760; Fri, 18 Jan 2002 06:56: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 GAA07732 for ; Fri, 18 Jan 2002 06:56:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07200; Fri, 18 Jan 2002 06:56:32 -0500 (EST) Message-Id: <200201181156.GAA07200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 18 Jan 2002 06:56:32 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-08.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology and Clarification for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-08.txt Pages : 10 Date : 17-Jan-02 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020117103113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020117103113.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 From daemon@optimus.ietf.org Fri Jan 18 10:28:04 2002 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 KAA14524 for ; Fri, 18 Jan 2002 10:28:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17333 for diffserv-archive@odin.ietf.org; Fri, 18 Jan 2002 10:28:06 -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 JAA15415; Fri, 18 Jan 2002 09:59: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 JAA15382 for ; Fri, 18 Jan 2002 09:59:03 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13525 for ; Fri, 18 Jan 2002 09:58:55 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA18769 for ; Fri, 18 Jan 2002 07:58:57 -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 HAA07190 for ; Fri, 18 Jan 2002 07:58:57 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id JAA10872 for ; Fri, 18 Jan 2002 09:58:51 -0500 (EST) Message-Id: <200201181458.JAA10872@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: Fri, 18 Jan 2002 09:57:43 -0500 From: Dan Grossman Subject: [Diffserv] -08 version of New Terms and Clarifications Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org A new version of draft-ietf-diffserv-new-terms has been posted. It takes care of a couple of minor issues that were pointed out by our A-D. First, the bits that are "CU" in RFC 2474 have been assigned for explicit congestion notification in RFC 3168, which is standards track. Previous versions of the draft had this usage as experimental. He also suggested mentioning that OSPF use of TOS bits per RFC 1247 was removed in STD 0054. While I was at it, I also cleaned up some minor formatting problems. Dan _______________________________________________ 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 From daemon@optimus.ietf.org Mon Jan 28 14:37:22 2002 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 OAA06803 for ; Mon, 28 Jan 2002 14:37:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01554 for diffserv-archive@odin.ietf.org; Mon, 28 Jan 2002 14:37: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 OAA00233; Mon, 28 Jan 2002 14:16: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 OAA00197 for ; Mon, 28 Jan 2002 14:16:48 -0500 (EST) Received: from stingray.shentel.net (stingray.shentel.net [204.111.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06352 for ; Mon, 28 Jan 2002 14:16:46 -0500 (EST) Received: from steves (ha30s495.d.shentel.net [204.111.30.239]) by stingray.shentel.net (8.11.3/8.11.3) with SMTP id g0SJGHW01079 for ; Mon, 28 Jan 2002 14:16:17 -0500 From: "Steve Silverman" To: Date: Mon, 28 Jan 2002 14:18:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Subject: [Diffserv] Bidirectional flows Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Has anything been done in this WG on setting up bidirectional flows with Diffserv? RFC2475 says: “This architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric.” I have a prospective service that requires setting up such a bidirectional flow. Steve Silverman Houston Associates steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Tue Jan 29 08:15:27 2002 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 IAA02188 for ; Tue, 29 Jan 2002 08:15:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29406 for diffserv-archive@odin.ietf.org; Tue, 29 Jan 2002 08: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 IAA28153; Tue, 29 Jan 2002 08:00:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28092 for ; Tue, 29 Jan 2002 08:00:17 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01901 for ; Tue, 29 Jan 2002 08:00:13 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id NAA10556; Tue, 29 Jan 2002 13:59:39 +0100 Received: from dhcp222-2.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32516 from ; Tue, 29 Jan 2002 13:59:37 +0100 Message-Id: <3C569CBA.FE324CDD@hursley.ibm.com> Date: Tue, 29 Jan 2002 13:59:38 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Steve Silverman Cc: diffserv@ietf.org Subject: Re: [Diffserv] Bidirectional flows References: 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 IAA28093 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit No. Diffserv is unidirectional. If you need the same behavior in both directions, you simply have to configure it the same way in both directions. If you think your traffic flows are in fact roughly symmetric, it's easy enough. If they are in fact asymmetric, it may be better to set up an asymmetric configuration to optimize resource usage. This is an operational choice. In general this sort of discussion fits better on the diffserv-interest list, but since it goes to the heart of the architecture it seems appropriate here. Brian P.S. I've just deleted about 6 copies of the infamous MyParty worm from the diffserv list filter - somebody on this list is spraying us with multiple copies of it. Steve Silverman wrote: > > Has anything been done in this WG on setting up bidirectional flows with > Diffserv? RFC2475 says: > > “This architecture only provides service differentiation in one > direction of traffic flow and is therefore asymmetric.” > > I have a prospective service that requires setting up such a bidirectional > flow. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Tue Jan 29 08:40:03 2002 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 IAA02732 for ; Tue, 29 Jan 2002 08:40:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01378 for diffserv-archive@odin.ietf.org; Tue, 29 Jan 2002 08:40:06 -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 IAA29916; Tue, 29 Jan 2002 08:26:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29882 for ; Tue, 29 Jan 2002 08:26:22 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02423 for ; Tue, 29 Jan 2002 08:26:19 -0500 (EST) Received: from FRED-W2K6.cisco.com (sjc-vpn3-75.cisco.com [10.21.64.75]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA27193; Tue, 29 Jan 2002 05:25:00 -0800 (PST) Message-Id: <4.3.2.7.2.20020129051324.03a2a220@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jan 2002 05:24:57 -0800 To: Brian E Carpenter From: Fred Baker Subject: Re: [Diffserv] Bidirectional flows Cc: "Rei S. Atarashi" , diffserv@ietf.org In-Reply-To: <3C569CBA.FE324CDD@hursley.ibm.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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:18 AM 1/28/2002, Steve Silverman wrote: >Has anything been done in this WG on setting up bidirectional flows with >Diffserv? At 04:59 AM 1/29/2002, Brian E Carpenter wrote: >In general this sort of discussion fits better on the diffserv-interest >list, but since it goes to the heart of the architecture it seems >appropriate here. this is very much an architectural question, and not the first time is has come up. See draft-atarashi-dscp-policy-00.txt Here's the deal, according to various customers (note the plural) who have asked me about it. Suppose that they offer several grades of service at various prices to various folks. When a customer approaches a server at a given class of service, the server should reply with the same class of service. Atarashi-san's application (digital libraries and related applications) goes on to suggest that the metadata for an object may specify a class of service for the reply to over-ride the user class of service; there are clearly also other approaches. So her proposal is to have the host mirror the user's class of service by default, and provide an override capability through the host's API. An alternative that I have been asked for is that (since the hosts don't mirror the class of service) my router should do it for them. As in, isolate each incoming session in the router, record the DSCP used incoming, and force the outbound DSCP to the same value. Personally, I think that's architecturally broken (did anyone mention 'state'?), so we have not done that. But something like Atarashi-san's approach is necessary for that service to be offered. _______________________________________________ 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 From daemon@optimus.ietf.org Tue Jan 29 12:11:39 2002 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 MAA09698 for ; Tue, 29 Jan 2002 12:11:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14810 for diffserv-archive@odin.ietf.org; Tue, 29 Jan 2002 12:11: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 LAA12417; Tue, 29 Jan 2002 11:49: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 LAA12386 for ; Tue, 29 Jan 2002 11:49:07 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08992 for ; Tue, 29 Jan 2002 11:49:03 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id RAA08252 for ; Tue, 29 Jan 2002 17:48:35 +0100 Received: from dhcp222-2.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA73124 from ; Tue, 29 Jan 2002 17:48:34 +0100 Message-Id: <3C56D263.32B33290@hursley.ibm.com> Date: Tue, 29 Jan 2002 17:48:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Subject: Re: [Diffserv] Bidirectional flows 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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit For some reason our list management software rejected this posting from Andrzej... --------------- Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01467 for ; Tue, 29 Jan 2002 08:42:07 -0500 (EST) Received: from domino2.netia.pl (domino2.netia.pl [195.114.160.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02774 for ; Tue, 29 Jan 2002 08:42:02 -0500 (EST) Subject: Re: [Diffserv] Bidirectional flows To: "Steve Silverman" Cc: X-Mailer: Lotus Notes Wydanie 5.0.4a 24 lipca 2000 Message-ID: From: "Andrzej Czerczak" Date: Tue, 29 Jan 2002 14:41:15 +0100 X-MIMETrack: Serialize by Router on WaWarNotesSMTP/HeadQ(Release 5.0.9 |November 16, 2001) at 01/29/2002 02:43:20 PM 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 IAA01468 Hi, Take a look at receiver-based traffic control: it's based on ECN, and can work for TCP traffic. I'm not aware about the availability of this approach. Andrzej "Steve Silverman" et> cc: Sent by: Subject: [Diffserv] Bidirectional flows diffserv-admin@ie tf.org 28-01-02 20:18 Has anything been done in this WG on setting up bidirectional flows with Diffserv? RFC2475 says: "This architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric." I have a prospective service that requires setting up such a bidirectional flow. Steve Silverman Houston Associates steves@shentel.net _______________________________________________ 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 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 From daemon@optimus.ietf.org Wed Jan 30 06:33:58 2002 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 GAA15062 for ; Wed, 30 Jan 2002 06:33:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA19098 for diffserv-archive@odin.ietf.org; Wed, 30 Jan 2002 06: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 GAA17962; Wed, 30 Jan 2002 06:19: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 GAA17933 for ; Wed, 30 Jan 2002 06:19:09 -0500 (EST) Received: from duck.doc.ic.ac.uk (duck.doc.ic.ac.uk [146.169.1.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14844 for ; Wed, 30 Jan 2002 06:19:05 -0500 (EST) Received: from top.doc.ic.ac.uk ([146.169.14.94]) by duck.doc.ic.ac.uk with esmtp (Exim 3.16 #7) id 16Vslf-0000I7-00 for diffserv@ietf.org; Wed, 30 Jan 2002 11:19:07 +0000 Message-Id: <4.3.2.7.2.20020130111950.00b2de78@pop.doc.ic.ac.uk> X-Sender: llymber@pop.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jan 2002 11:19:53 +0000 To: diffserv@ietf.org From: "Leonidas A. Lymberopoulos" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] DiffServ MIB implementation on Linux Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I have used ucd-snmp package and I have written an snmp agent that supports the IETF's diffserv MIB (version 0.4). I can set a mib value at the snmpd memory space, but the value must be set at an appropriate entry to the kernel. Is there is an implementation for setting the IETF MIBs parameters to the Linux kernel using the netlink interface? Linux kernel supports different utilities (qdisc, class, filters and policing); therefore there is the need to translate the MIB to these elements and to use netlink. Have anyone done this? Thank you in advance, Leonidas _________________________________________________________ Leonidas A. Lymberopoulos, Research Associate, Department of Computing, Imperial College of Science Technology and Medicine, 180 Queen's Gate, London SW7 2BZ, U.K Phone: ( +44 | 0 ) 207 594 8394 Fax: ( +44 | 0 ) 207 581 8024 E-mail: llymber@doc.ic.ac.uk _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jan 30 09:22:28 2002 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 JAA19977 for ; Wed, 30 Jan 2002 09:22:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28762 for diffserv-archive@odin.ietf.org; Wed, 30 Jan 2002 09:22: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 JAA27404; Wed, 30 Jan 2002 09:03: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 JAA27363 for ; Wed, 30 Jan 2002 09:03:10 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18825 for ; Wed, 30 Jan 2002 09:02:54 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA08428; Wed, 30 Jan 2002 15:02:21 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34604 from ; Wed, 30 Jan 2002 15:02:20 +0100 Message-Id: <3C57FCEC.B10B8C08@hursley.ibm.com> Date: Wed, 30 Jan 2002 15:02:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Leonidas A. Lymberopoulos" Cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ MIB implementation on Linux References: <4.3.2.7.2.20020130111950.00b2de78@pop.doc.ic.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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I would try the diffserv implementation list for this question See http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian "Leonidas A. Lymberopoulos" wrote: > > Hi, > I have used ucd-snmp package and I have written an snmp agent that supports > the IETF's > diffserv MIB (version 0.4). > I can set a mib value at the snmpd memory space, > but the value must be set at an appropriate entry to the kernel. > Is there is an implementation for setting the IETF MIBs parameters to > the Linux kernel using the netlink interface? Linux kernel supports different > utilities (qdisc, class, filters and policing); therefore there is the need > to translate the MIB to > these elements and to use netlink. Have anyone done this? > > Thank you in advance, > > Leonidas > _________________________________________________________ > > Leonidas A. Lymberopoulos, Research Associate, > Department of Computing, > Imperial College of Science Technology and Medicine, > 180 Queen's Gate, > London SW7 2BZ, U.K > Phone: ( +44 | 0 ) 207 594 8394 Fax: ( +44 | 0 ) 207 581 8024 > E-mail: llymber@doc.ic.ac.uk _______________________________________________ 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 From daemon@optimus.ietf.org Wed Jan 30 14:05:40 2002 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 OAA29374 for ; Wed, 30 Jan 2002 14:05:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16724 for diffserv-archive@odin.ietf.org; Wed, 30 Jan 2002 14:05: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 NAA14856; Wed, 30 Jan 2002 13:44: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 NAA14814 for ; Wed, 30 Jan 2002 13:44:53 -0500 (EST) Received: from stingray.shentel.net (stingray.shentel.net [204.111.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28749 for ; Wed, 30 Jan 2002 13:44:52 -0500 (EST) Received: from steves (ha96s638.d.shentel.net [204.111.98.126]) by stingray.shentel.net (8.11.3/8.11.3) with SMTP id g0UIiHW30463; Wed, 30 Jan 2002 13:44:18 -0500 From: "Steve Silverman" To: Cc: , Subject: [Diffserv] Bidirectional flows, Emergency Services Date: Wed, 30 Jan 2002 13:44:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit In response to my question about bidirectional flows, Fred Baker didn’t want to impose the requirement on the routers to mark return packets because that would mean keeping state info on every flow. I sympathize with the desire to avoid complicating the switch but: If the system is going to allow DSCP marking to affect packet treatment, the access router is going to have to be a gatekeeper to ensure that such markings aren’t abused. Otherwise most spam will be sent at high priority. One would assume that Service Providers will want to limit use of and/or charge for high priority markings. This creates a state-keeping burden that can’t be avoided. If UserA has premium service, and sends a packet to ServerX, packets from ServerX to UserA should get that premium service but not packets from ServerX to other users. The only way for the network to validate these service requests is to note the packet from UserA to ServerX, keep this state, and allow ServerX to UserA traffic to use this Diffserv marking. If IP is to be the global data/voice network of the future, I think emergency services (and bidirectional flows) are going to be an unavoidable part of the package even though it complicates the switch. As I remember, when the Diffserv WG was first set up, allowing SPs to create a premium service was a major driver for the WG. This was presumed to include web browsing. Web browsing with Diffserv only makes sense if priority is given to the return packets. Steve Silverman Houston Associates steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 08:51:28 2002 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 IAA26386 for ; Thu, 31 Jan 2002 08:51:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16356 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 08:51: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 IAA15486; Thu, 31 Jan 2002 08:33:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15456 for ; Thu, 31 Jan 2002 08:33:43 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25786 for ; Thu, 31 Jan 2002 08:33:38 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA12552; Thu, 31 Jan 2002 14:32:50 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42512 from ; Thu, 31 Jan 2002 14:32:48 +0100 Message-Id: <3C594781.25CAC7E6@hursley.ibm.com> Date: Thu, 31 Jan 2002 14:32:49 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Steve Silverman Cc: diffserv@ietf.org, ray@crl.go.jp, fred@cisco.com Subject: Re: [Diffserv] Bidirectional flows, Emergency Services References: 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 IAA15457 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit I believe the points you raise are all discussed in RFC 2475. Brian Steve Silverman wrote: > > In response to my question about bidirectional flows, Fred Baker didn’t want > to impose the requirement on the routers to mark return packets because that > would mean keeping state info on every flow. I sympathize with the desire > to avoid complicating the switch but: > > If the system is going to allow DSCP marking to affect packet treatment, the > access router is going to have to be a gatekeeper to ensure that such > markings aren’t abused. Otherwise most spam will be sent at high priority. > One would assume that Service Providers will want to limit use of and/or > charge for high priority markings. This creates a state-keeping burden that > can’t be avoided. If UserA has premium service, and sends a packet to > ServerX, packets from ServerX to UserA should get that premium service but > not packets from ServerX to other users. The only way for the network to > validate these service requests is to note the packet from UserA to ServerX, > keep this state, and allow ServerX to UserA traffic to use this Diffserv > marking. > > If IP is to be the global data/voice network of the future, I think > emergency services (and bidirectional flows) are going to be an unavoidable > part of the package even though it complicates the switch. > > As I remember, when the Diffserv WG was first set up, allowing SPs to create > a premium service was a major driver for the WG. This was presumed to > include web browsing. Web browsing with Diffserv only makes sense if > priority is given to the return packets. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 09:46:26 2002 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 JAA28072 for ; Thu, 31 Jan 2002 09:46:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20006 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 09:46: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 JAA19016; Thu, 31 Jan 2002 09:30: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 JAA18959 for ; Thu, 31 Jan 2002 09:30:32 -0500 (EST) Received: from domino2.netia.pl (domino2.netia.pl [195.114.160.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27587 for ; Thu, 31 Jan 2002 09:30:26 -0500 (EST) Subject: Re: [Diffserv] Bidirectional flows, Emergency Services To: Steve Silverman Cc: diffserv@ietf.org, Brian E Carpenter X-Mailer: Lotus Notes Wydanie 5.0.4a 24 lipca 2000 Message-ID: From: "Andrzej Czerczak" Date: Thu, 31 Jan 2002 15:29:35 +0100 X-MIMETrack: Serialize by Router on WaWarNotesSMTP/HeadQ(Release 5.0.9a |January 7, 2002) at 01/31/2002 03:31:44 PM 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 JAA18961 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi Steve, I believe, that at the momoment it is more technical than diff-serv standarization problem. If you group your users say into 2 groups, using addressing, every router in your network will know exactly how to treat returning packet: if your customer belongs to "priority" group then he will get priority treatment even for return traffic, if it belongs to "standard" group he will get "standard" treatment. And so on. It will easily work in your AS, and no "states" need to be introduced. If you want to have such treatment all over internet, then you need to think about such solutions as receiver-based traffic control. rgrds Andrzej Steve Silverman wrote: > > In response to my question about bidirectional flows, Fred Baker didn't want > to impose the requirement on the routers to mark return packets because that > would mean keeping state info on every flow. I sympathize with the desire > to avoid complicating the switch but: > > If the system is going to allow DSCP marking to affect packet treatment, the > access router is going to have to be a gatekeeper to ensure that such > markings aren't abused. Otherwise most spam will be sent at high priority. > One would assume that Service Providers will want to limit use of and/or > charge for high priority markings. This creates a state-keeping burden that > can't be avoided. If UserA has premium service, and sends a packet to > ServerX, packets from ServerX to UserA should get that premium service but > not packets from ServerX to other users. The only way for the network to > validate these service requests is to note the packet from UserA to ServerX, > keep this state, and allow ServerX to UserA traffic to use this Diffserv > marking. > > If IP is to be the global data/voice network of the future, I think > emergency services (and bidirectional flows) are going to be an unavoidable > part of the package even though it complicates the switch. > > As I remember, when the Diffserv WG was first set up, allowing SPs to create > a premium service was a major driver for the WG. This was presumed to > include web browsing. Web browsing with Diffserv only makes sense if > priority is given to the return packets. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 10:18:53 2002 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 KAA29161 for ; Thu, 31 Jan 2002 10:18:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22881 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 10:18: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 KAA21676; Thu, 31 Jan 2002 10:03:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21648 for ; Thu, 31 Jan 2002 10:03:44 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28595 for ; Thu, 31 Jan 2002 10:03:38 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GQT00F015S4HP@firewall.wcom.com> for diffserv@ietf.org; Thu, 31 Jan 2002 15:02:28 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GQT00F105S4GQ@firewall.wcom.com>; Thu, 31 Jan 2002 15:02:28 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00M015RTWI@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:02:28 +0000 (GMT) Received: from lyao ([166.60.14.59]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00LDS5ROXI@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:02:13 +0000 (GMT) Date: Thu, 31 Jan 2002 09:58:18 -0500 From: Lei Yao Subject: RE: [Diffserv] Bidirectional flows, Emergency Services In-reply-to: To: Andrzej Czerczak , Steve Silverman Cc: diffserv@ietf.org, Brian E Carpenter Reply-to: lei.yao@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Andrzej, Even for a single service provider's network, your suggested approach is not trivial to implement. You have to proxy on EVERY edge router for the "priority" groups and "non-priority" groups. How can it be provisioned? Lei -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Andrzej Czerczak Sent: Thursday, January 31, 2002 9:30 AM To: Steve Silverman Cc: diffserv@ietf.org; Brian E Carpenter Subject: Re: [Diffserv] Bidirectional flows, Emergency Services Hi Steve, I believe, that at the momoment it is more technical than diff-serv standarization problem. If you group your users say into 2 groups, using addressing, every router in your network will know exactly how to treat returning packet: if your customer belongs to "priority" group then he will get priority treatment even for return traffic, if it belongs to "standard" group he will get "standard" treatment. And so on. It will easily work in your AS, and no "states" need to be introduced. If you want to have such treatment all over internet, then you need to think about such solutions as receiver-based traffic control. rgrds Andrzej Steve Silverman wrote: > > In response to my question about bidirectional flows, Fred Baker didn't want > to impose the requirement on the routers to mark return packets because that > would mean keeping state info on every flow. I sympathize with the desire > to avoid complicating the switch but: > > If the system is going to allow DSCP marking to affect packet treatment, the > access router is going to have to be a gatekeeper to ensure that such > markings aren't abused. Otherwise most spam will be sent at high priority. > One would assume that Service Providers will want to limit use of and/or > charge for high priority markings. This creates a state-keeping burden that > can't be avoided. If UserA has premium service, and sends a packet to > ServerX, packets from ServerX to UserA should get that premium service but > not packets from ServerX to other users. The only way for the network to > validate these service requests is to note the packet from UserA to ServerX, > keep this state, and allow ServerX to UserA traffic to use this Diffserv > marking. > > If IP is to be the global data/voice network of the future, I think > emergency services (and bidirectional flows) are going to be an unavoidable > part of the package even though it complicates the switch. > > As I remember, when the Diffserv WG was first set up, allowing SPs to create > a premium service was a major driver for the WG. This was presumed to > include web browsing. Web browsing with Diffserv only makes sense if > priority is given to the return packets. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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.ht ml _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 10:44:28 2002 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 KAA00118 for ; Thu, 31 Jan 2002 10:44:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25130 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 10:44: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 KAA24014; Thu, 31 Jan 2002 10:35: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 KAA23986 for ; Thu, 31 Jan 2002 10:34:57 -0500 (EST) Received: from domino2.netia.pl (domino2.netia.pl [195.114.160.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29761 for ; Thu, 31 Jan 2002 10:34:53 -0500 (EST) To: lei.yao@wcom.com Cc: diffserv@ietf.org, Brian E Carpenter , Steve Silverman X-Mailer: Lotus Notes Wydanie 5.0.4a 24 lipca 2000 Message-ID: From: "Andrzej Czerczak" Date: Thu, 31 Jan 2002 16:31:19 +0100 X-MIMETrack: Serialize by Router on WaWarNotesSMTP/HeadQ(Release 5.0.9a |January 7, 2002) at 01/31/2002 04:36:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] (no subject) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, I hope you agree, that it has to be provisioned only in the places where it makes sense -> where you have scare resources and where you need to differentiate treatment of the traffic, eg. to schedule it differently or route it to different TE-tunnel (with different traffic parameters) -> I hope that none will claim that's the violation of diffserv architecture. Openly, with xDSL concetrators/routers the gain of implementation of complicated scheduling mechanism would probably be to high to be returned. This approach reduce the number of routers where you configure treatment per group of users. rgrds, Andrzej >Andrzej, >Even for a single service provider's network, your suggested approach is not >trivial to implement. You have to proxy on EVERY edge router for the >"priority" groups and "non-priority" groups. How can it be provisioned? > Lei -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Andrzej Czerczak Sent: Thursday, January 31, 2002 9:30 AM To: Steve Silverman Cc: diffserv@ietf.org; Brian E Carpenter Subject: Re: [Diffserv] Bidirectional flows, Emergency Services Hi Steve, I believe, that at the momoment it is more technical than diff-serv standarization problem. If you group your users say into 2 groups, using addressing, every router in your network will know exactly how to treat returning packet: if your customer belongs to "priority" group then he will get priority treatment even for return traffic, if it belongs to "standard" group he will get "standard" treatment. And so on. It will easily work in your AS, and no "states" need to be introduced. If you want to have such treatment all over internet, then you need to think about such solutions as receiver-based traffic control. rgrds Andrzej Steve Silverman wrote: > > In response to my question about bidirectional flows, Fred Baker didn't want > to impose the requirement on the routers to mark return packets because that > would mean keeping state info on every flow. I sympathize with the desire > to avoid complicating the switch but: > > If the system is going to allow DSCP marking to affect packet treatment, the > access router is going to have to be a gatekeeper to ensure that such > markings aren't abused. Otherwise most spam will be sent at high priority. > One would assume that Service Providers will want to limit use of and/or > charge for high priority markings. This creates a state-keeping burden that > can't be avoided. If UserA has premium service, and sends a packet to > ServerX, packets from ServerX to UserA should get that premium service but > not packets from ServerX to other users. The only way for the network to > validate these service requests is to note the packet from UserA to ServerX, > keep this state, and allow ServerX to UserA traffic to use this Diffserv > marking. > > If IP is to be the global data/voice network of the future, I think > emergency services (and bidirectional flows) are going to be an unavoidable > part of the package even though it complicates the switch. > > As I remember, when the Diffserv WG was first set up, allowing SPs to create > a premium service was a major driver for the WG. This was presumed to > include web browsing. Web browsing with Diffserv only makes sense if > priority is given to the return packets. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 10:49:36 2002 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 KAA00332 for ; Thu, 31 Jan 2002 10:49:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26024 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 10:49: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 KAA24371; Thu, 31 Jan 2002 10:38: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 KAA24320 for ; Thu, 31 Jan 2002 10:38:42 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29860 for ; Thu, 31 Jan 2002 10:38:37 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id QAA13136; Thu, 31 Jan 2002 16:38:05 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75378 from ; Thu, 31 Jan 2002 16:38:04 +0100 Message-Id: <3C5964DC.B478AC53@hursley.ibm.com> Date: Thu, 31 Jan 2002 16:38:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: lei.yao@wcom.com Cc: Andrzej Czerczak , Steve Silverman , diffserv@ietf.org Subject: Re: [Diffserv] Bidirectional flows, Emergency Services 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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Why is it different from provisioning any other aggregates? Brian Lei Yao wrote: > > Andrzej, > > Even for a single service provider's network, your suggested approach is not > trivial to implement. You have to proxy on EVERY edge router for the > "priority" groups and "non-priority" groups. How can it be provisioned? > > Lei > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > Andrzej Czerczak > Sent: Thursday, January 31, 2002 9:30 AM > To: Steve Silverman > Cc: diffserv@ietf.org; Brian E Carpenter > Subject: Re: [Diffserv] Bidirectional flows, Emergency Services > > Hi Steve, > I believe, that at the momoment it is more technical than diff-serv > standarization problem. > If you group your users say into 2 groups, using addressing, every router > in your network will know exactly how to treat returning packet: if your > customer belongs to "priority" group then he will get priority treatment > even for return traffic, if it belongs to "standard" group he will get > "standard" treatment. And so on. > It will easily work in your AS, and no "states" need to be introduced. > > If you want to have such treatment all over internet, then you need to > think about such solutions as receiver-based traffic control. > > rgrds > Andrzej > > Steve Silverman wrote: > > > > In response to my question about bidirectional flows, Fred Baker didn't > want > > to impose the requirement on the routers to mark return packets because > that > > would mean keeping state info on every flow. I sympathize with the > desire > > to avoid complicating the switch but: > > > > If the system is going to allow DSCP marking to affect packet treatment, > the > > access router is going to have to be a gatekeeper to ensure that such > > markings aren't abused. Otherwise most spam will be sent at high > priority. > > One would assume that Service Providers will want to limit use of and/or > > charge for high priority markings. This creates a state-keeping burden > that > > can't be avoided. If UserA has premium service, and sends a packet to > > ServerX, packets from ServerX to UserA should get that premium service > but > > not packets from ServerX to other users. The only way for the network to > > validate these service requests is to note the packet from UserA to > ServerX, > > keep this state, and allow ServerX to UserA traffic to use this Diffserv > > marking. > > > > If IP is to be the global data/voice network of the future, I think > > emergency services (and bidirectional flows) are going to be an > unavoidable > > part of the package even though it complicates the switch. > > > > As I remember, when the Diffserv WG was first set up, allowing SPs to > create > > a premium service was a major driver for the WG. This was presumed to > > include web browsing. Web browsing with Diffserv only makes sense if > > priority is given to the return packets. > > > > Steve Silverman > > Houston Associates > > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 10:53:34 2002 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 KAA00493 for ; Thu, 31 Jan 2002 10:53:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26705 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 10:53: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 KAA24937; Thu, 31 Jan 2002 10:43: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 KAA24901 for ; Thu, 31 Jan 2002 10:43:25 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00049 for ; Thu, 31 Jan 2002 10:42:47 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GQT00D017MBHT@firewall.wcom.com> for diffserv@ietf.org; Thu, 31 Jan 2002 15:42:11 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GQT00D317MA55@firewall.wcom.com>; Thu, 31 Jan 2002 15:42:11 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00I017M9TT@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:42:10 +0000 (GMT) Received: from lyao ([166.60.14.59]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00G6F7LVE8@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:41:55 +0000 (GMT) Date: Thu, 31 Jan 2002 10:38:01 -0500 From: Lei Yao In-reply-to: To: Andrzej Czerczak Cc: diffserv@ietf.org, Brian E Carpenter , Steve Silverman Reply-to: lei.yao@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Would the access links be the most likely congestion points to protect? Lei -----Original Message----- From: Andrzej Czerczak [mailto:Andrzej_Czerczak/HeadQ@netia.pl] Sent: Thursday, January 31, 2002 10:31 AM To: lei.yao@wcom.com Cc: diffserv@ietf.org; Brian E Carpenter; Steve Silverman Subject: Hi, I hope you agree, that it has to be provisioned only in the places where it makes sense -> where you have scare resources and where you need to differentiate treatment of the traffic, eg. to schedule it differently or route it to different TE-tunnel (with different traffic parameters) -> I hope that none will claim that's the violation of diffserv architecture. Openly, with xDSL concetrators/routers the gain of implementation of complicated scheduling mechanism would probably be to high to be returned. This approach reduce the number of routers where you configure treatment per group of users. rgrds, Andrzej >Andrzej, >Even for a single service provider's network, your suggested approach is not >trivial to implement. You have to proxy on EVERY edge router for the >"priority" groups and "non-priority" groups. How can it be provisioned? > Lei -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Andrzej Czerczak Sent: Thursday, January 31, 2002 9:30 AM To: Steve Silverman Cc: diffserv@ietf.org; Brian E Carpenter Subject: Re: [Diffserv] Bidirectional flows, Emergency Services Hi Steve, I believe, that at the momoment it is more technical than diff-serv standarization problem. If you group your users say into 2 groups, using addressing, every router in your network will know exactly how to treat returning packet: if your customer belongs to "priority" group then he will get priority treatment even for return traffic, if it belongs to "standard" group he will get "standard" treatment. And so on. It will easily work in your AS, and no "states" need to be introduced. If you want to have such treatment all over internet, then you need to think about such solutions as receiver-based traffic control. rgrds Andrzej Steve Silverman wrote: > > In response to my question about bidirectional flows, Fred Baker didn't want > to impose the requirement on the routers to mark return packets because that > would mean keeping state info on every flow. I sympathize with the desire > to avoid complicating the switch but: > > If the system is going to allow DSCP marking to affect packet treatment, the > access router is going to have to be a gatekeeper to ensure that such > markings aren't abused. Otherwise most spam will be sent at high priority. > One would assume that Service Providers will want to limit use of and/or > charge for high priority markings. This creates a state-keeping burden that > can't be avoided. If UserA has premium service, and sends a packet to > ServerX, packets from ServerX to UserA should get that premium service but > not packets from ServerX to other users. The only way for the network to > validate these service requests is to note the packet from UserA to ServerX, > keep this state, and allow ServerX to UserA traffic to use this Diffserv > marking. > > If IP is to be the global data/voice network of the future, I think > emergency services (and bidirectional flows) are going to be an unavoidable > part of the package even though it complicates the switch. > > As I remember, when the Diffserv WG was first set up, allowing SPs to create > a premium service was a major driver for the WG. This was presumed to > include web browsing. Web browsing with Diffserv only makes sense if > priority is given to the return packets. > > Steve Silverman > Houston Associates > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 10:54:10 2002 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 KAA00519 for ; Thu, 31 Jan 2002 10:54:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26765 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 10:54: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 KAA25445; Thu, 31 Jan 2002 10:46: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 KAA25410 for ; Thu, 31 Jan 2002 10:46:18 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00193 for ; Thu, 31 Jan 2002 10:46:14 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GQT00A017S18C@firewall.wcom.com> for diffserv@ietf.org; Thu, 31 Jan 2002 15:45:37 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GQT008HV7S1CU@firewall.wcom.com>; Thu, 31 Jan 2002 15:45:37 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00K017RONO@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:45:37 +0000 (GMT) Received: from lyao ([166.60.14.59]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQT00J707RMPX@pmismtp04.wcomnet.com>; Thu, 31 Jan 2002 15:45:22 +0000 (GMT) Date: Thu, 31 Jan 2002 10:41:28 -0500 From: Lei Yao Subject: RE: [Diffserv] Bidirectional flows, Emergency Services In-reply-to: <3C5964DC.B478AC53@hursley.ibm.com> To: Brian E Carpenter Cc: Andrzej Czerczak , Steve Silverman , diffserv@ietf.org Reply-to: lei.yao@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit The difference is that the proxy is receiver-based. You cannot predict from where you will get the traffic; you have to provision on every edge router. If it is source-based, you can probably only provision on selected routers where the priority traffic would come from. Lei -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Thursday, January 31, 2002 10:38 AM To: lei.yao@wcom.com Cc: Andrzej Czerczak; Steve Silverman; diffserv@ietf.org Subject: Re: [Diffserv] Bidirectional flows, Emergency Services Why is it different from provisioning any other aggregates? Brian Lei Yao wrote: > > Andrzej, > > Even for a single service provider's network, your suggested approach is not > trivial to implement. You have to proxy on EVERY edge router for the > "priority" groups and "non-priority" groups. How can it be provisioned? > > Lei > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > Andrzej Czerczak > Sent: Thursday, January 31, 2002 9:30 AM > To: Steve Silverman > Cc: diffserv@ietf.org; Brian E Carpenter > Subject: Re: [Diffserv] Bidirectional flows, Emergency Services > > Hi Steve, > I believe, that at the momoment it is more technical than diff-serv > standarization problem. > If you group your users say into 2 groups, using addressing, every router > in your network will know exactly how to treat returning packet: if your > customer belongs to "priority" group then he will get priority treatment > even for return traffic, if it belongs to "standard" group he will get > "standard" treatment. And so on. > It will easily work in your AS, and no "states" need to be introduced. > > If you want to have such treatment all over internet, then you need to > think about such solutions as receiver-based traffic control. > > rgrds > Andrzej > > Steve Silverman wrote: > > > > In response to my question about bidirectional flows, Fred Baker didn't > want > > to impose the requirement on the routers to mark return packets because > that > > would mean keeping state info on every flow. I sympathize with the > desire > > to avoid complicating the switch but: > > > > If the system is going to allow DSCP marking to affect packet treatment, > the > > access router is going to have to be a gatekeeper to ensure that such > > markings aren't abused. Otherwise most spam will be sent at high > priority. > > One would assume that Service Providers will want to limit use of and/or > > charge for high priority markings. This creates a state-keeping burden > that > > can't be avoided. If UserA has premium service, and sends a packet to > > ServerX, packets from ServerX to UserA should get that premium service > but > > not packets from ServerX to other users. The only way for the network to > > validate these service requests is to note the packet from UserA to > ServerX, > > keep this state, and allow ServerX to UserA traffic to use this Diffserv > > marking. > > > > If IP is to be the global data/voice network of the future, I think > > emergency services (and bidirectional flows) are going to be an > unavoidable > > part of the package even though it complicates the switch. > > > > As I remember, when the Diffserv WG was first set up, allowing SPs to > create > > a premium service was a major driver for the WG. This was presumed to > > include web browsing. Web browsing with Diffserv only makes sense if > > priority is given to the return packets. > > > > Steve Silverman > > Houston Associates > > steves@shentel.net _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 11:13:10 2002 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 LAA01330 for ; Thu, 31 Jan 2002 11:13:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00309 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 11:13: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 LAA28303; Thu, 31 Jan 2002 11:04: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 LAA28252 for ; Thu, 31 Jan 2002 11:03:56 -0500 (EST) Received: from domino2.netia.pl (domino2.netia.pl [195.114.160.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00964 for ; Thu, 31 Jan 2002 11:03:51 -0500 (EST) Subject: Re: [Diffserv] Bidirectional flows, Emergency Services To: lei.yao@wcom.com Cc: Steve Silverman , diffserv@ietf.org, Brian E Carpenter X-Mailer: Lotus Notes Wydanie 5.0.4a 24 lipca 2000 Message-ID: From: "Andrzej Czerczak" Date: Thu, 31 Jan 2002 16:54:05 +0100 X-MIMETrack: Serialize by Router on WaWarNotesSMTP/HeadQ(Release 5.0.9a |January 7, 2002) at 01/31/2002 05:05:10 PM 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: Diffserv Discussion List X-BeenThere: diffserv@ietf.org It is worth to compare the cost "traditional" ATM-based xDSL contentrator working over costly SDH metro network with the cost of Long Reach Ethernet with optical (most atractive option)ethernet uplink. I expect technology shift in the access, where you will have plenty of cheap btw, and cheaper backbone (instead of costly ATM interfaces cheap ethernet interfaces). So, I do not expect congestion points in the access, contradictory to common opinion. rgrds Andrzej >Would the access links be the most likely congestion points to protect? >Lei _______________________________________________ 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 From daemon@optimus.ietf.org Thu Jan 31 11:20:32 2002 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 LAA01759 for ; Thu, 31 Jan 2002 11:20:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01214 for diffserv-archive@odin.ietf.org; Thu, 31 Jan 2002 11:20: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 LAA29986; Thu, 31 Jan 2002 11:11: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 LAA29950 for ; Thu, 31 Jan 2002 11:11:00 -0500 (EST) Received: from rumba.cefriel.it (rumba.cefriel.it [131.175.53.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01201 for ; Thu, 31 Jan 2002 11:10:56 -0500 (EST) Received: by rumba.cefriel.it with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Jan 2002 17:11:35 +0100 Message-ID: <7B6D8AAF768F194EB3090A0325C8520206AB1E@rumba.cefriel.it> From: Marco De Bernardi To: "'diffserv@ietf.org'" Date: Thu, 31 Jan 2002 17:11:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Capabilities information Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi everybody, I have a little question for you. How does the PDP uses the capabilities information reported by the PEP's request message? Do you have an exemple? Thanks. You can mail to debernar@cefriel.it _______________________________________________ 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