From owner-diffserv@optimus.ietf.org  Mon Nov  1 05:08:01 1999
Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07599
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 05:08:00 -0500 (EST)
Received: from inferno-01.cs.huji.ac.il ([132.65.32.101] helo=cs.huji.ac.il)
	by cs.huji.ac.il with esmtp (Exim 3.03 #1)
	id 11iENX-0005zX-00
	for diffserv@ietf.org; Mon, 01 Nov 1999 12:07:55 +0200
Sender: osnaty@cs.huji.ac.il
Message-ID: <381D6676.A8402C24@cs.huji.ac.il>
Date: Mon, 01 Nov 1999 12:07:50 +0200
From: Osnat Mokryn <osnaty@cs.huji.ac.il>
Organization: Hebrew University of Jerusalem
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

remove osnaty@cs.huji.ac.il



From owner-diffserv@optimus.ietf.org  Mon Nov  1 06:10:25 1999
Received: from ornet.ornet.co.il (ornet.co.il [194.90.140.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16849
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 06:10:22 -0500 (EST)
Received: from christin.ornet.co.il (christin.ornet.co.il [194.90.140.37])
	by ornet.ornet.co.il (8.9.3/8.9.3) with ESMTP id NAA14382
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 13:10:21 +0200 (IST)
Received: by christin.ornet.co.il with Internet Mail Service (5.5.2448.0)
	id <T83S0K6Y>; Mon, 1 Nov 1999 13:10:21 +0200
Message-ID: <004246117607D21188470060089C61BBA68317@christin.ornet.co.il>
From: Arie Abramovich <ariea@siemensdc.com>
To: "'diffserv@ietf.org'" <diffserv@ietf.org>
Date: Mon, 1 Nov 1999 13:10:20 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain

remove ariea@siemensdc.com
 





From diffserv-admin@ietf.org  Mon Nov  1 16:05:20 1999
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 QAA15881
	for <diffserv-archive@ietf.org>; Mon, 1 Nov 1999 16:05:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA28610;
	Mon, 1 Nov 1999 13:53:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA28524
	for <diffserv@optimus.ietf.org>; Mon, 1 Nov 1999 13:53:49 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05920
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 13:04:02 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA04312; Mon, 1 Nov 1999 18:02:56 GMT
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA16302; Mon, 1 Nov 1999 18:02:45 GMT
Message-ID: <381DD5C7.9312DC2@hursley.ibm.com>
Date: Mon, 01 Nov 1999 12:02:47 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: k claffy <kc@caida.org>
CC: diffserv <diffserv@ietf.org>, jambi@caida.org, dm <dmoore@caida.org>
Subject: Re: [Diffserv] Classifying fragments
References: <D0805D3B448BD211A7990008C7B1813001850415@ftp.extremenetworks.com> <19991029145744.O9560@caida.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Thanks for the facts kc

So, fragments are a tiny fraction of 1% of traffic.

So, do we have any reason to worry? I don't think so.

   Brian

k claffy wrote:
> 
> i guess "just a little of it."
> 
> 18 month old data courtesy MCI/vBNS/NSF
> 
>     http://www.caida.org/Presentations/Soa9905/mgp00031.html
> 
> june 99 data jambi  (then caida.elf, now vBNS.elf),
>         not polished/documented.much, but fwiw
> 
>         http://www.caida.org/~bigj/frag.html
> 
> that's all i have right now
> k
> 
> On Wed, Oct 27, 1999 at 10:49:49AM -0700, Steve Haddock wrote:
>   Out of curiosity, is this a problem that affects most of the traffic, or
>   just a little of it?  I've seen several reports from people that capture a
>   snapshot of traffic at various points in the backbone, and produce a
>   histogram of packets sizes.  Does anyone know of a study that shows the
>   percentage of packets that are fragments?
> 
>   Steve
> 
>   > ----------
>   > From:       Brian E Carpenter[SMTP:brian@hursley.ibm.com]
>   > Sent:       Monday, October 25, 1999 10:30 AM
>   > To:         Nick Williamson
>   > Cc:         diffserv
>   > Subject:    Re: [Diffserv] Classifying fragments
>   >
>   > This is an open issue in the architecture (see RFC 2475, section 2.3.1).
>   > Yet another reason why PMTU discovery is a Good Thing.
>   >
>   > Note that the problem only arises for MF classifiers, i.e. only at
>   > border routers. But that doesn't help if the packets were already
>   > fragmented upstream of the border.
>   >
>   >   Brian
>   >
>   > Nick Williamson wrote:
>   > >
>   > > The Conceptual Model for Diffserv Routers defines standard method for
>   > > classifying IP packets using filters. This method may interpret
>   > > information  in the protocol header (e.g. TCP/UDP port #), which is not
>   > > available in IP fragments. My question is: without saving state, how do
>   > > we ensure that all the fragments (including fragment 0) are classified
>   > > consistently?
>   > >
>   > > --
>   > > ==================================
>   > > Nicholas WIlliamson
>   > > Nick.Williamson@go.ecitele.com
>   > >
>   > > ECI Telecom
>   > > 1201 Cypress Creek Road
>   > > Ft Lauderdale, FL 33309
>   > > (954) 772-3070
>   > > ==================================
>   > >
>   > > _______________________________________________
>   > > diffserv mailing list
>   > > diffserv@ietf.org
>   > > http://www.ietf.org/mailman/listinfo/diffserv
>   > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>   >
>   > _______________________________________________
>   > diffserv mailing list
>   > diffserv@ietf.org
>   > http://www.ietf.org/mailman/listinfo/diffserv
>   > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>   >
> 
>   _______________________________________________
>   diffserv mailing list
>   diffserv@ietf.org
>   http://www.ietf.org/mailman/listinfo/diffserv
>   Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Mon Nov  1 17:37:41 1999
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 RAA16427
	for <diffserv-archive@ietf.org>; Mon, 1 Nov 1999 17:37:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA03988;
	Mon, 1 Nov 1999 16:59:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA03958
	for <diffserv@optimus.ietf.org>; Mon, 1 Nov 1999 16:59:14 -0500 (EST)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01056
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 16:58:57 -0500 (EST)
Received: from coritel.it (kant_ppp_re2.coritel.it [193.205.242.17])
	by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id WAA12591;
	Mon, 1 Nov 1999 22:25:32 +0100 (MET)
Message-ID: <381E0B8F.54CAD9B@coritel.it>
Date: Mon, 01 Nov 1999 22:52:15 +0100
From: Stefano Salsano <salsano@coritel.it>
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: Kathleen Nichols <kmn@cisco.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] EF RFC and loss
References: <381ABF5A.89623619@coritel.it> <381BC2CD.DDC9C21@cisco.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Kathleen Nichols wrote:
> 
> 
> The discussion was about the VLL (also called "Premium" service
> build using the EF PHB) rather than the general problem of burstiness
> in flows.
> 
>         Kathie

Dear Kathie,

I was dealing with the VLL service built using the EF PHB...

My point is that the buffer requirements in core routers 
to provide a "zero loss" VLL service based on the EF PHB 
can be much higher than simply proportional to the number 
of different VLLs, due to the worst case clumping effect. 

Best regards,
Stefano

P.S. To come back to the original question of this thread:
only if you provide such a "zero loss" VLL service you can 
consider buffer overflows as misconfigurations or security 
attacks...

-- 
*******************************************************************
Stefano Salsano
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
                  
E-mail  : salsano@coritel.it      URL     : http://www.coritel.it
Tel.    : +39 06 20410029          Address : Via di Tor Vergata, 135     
Fax.    : +39 06 20410037                    00133 Roma - ITALY          
*******************************************************************

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



From diffserv-admin@ietf.org  Mon Nov  1 19:54:58 1999
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 TAA15266
	for <diffserv-archive@ietf.org>; Mon, 1 Nov 1999 19:54:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA07706;
	Mon, 1 Nov 1999 19:26:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA07658
	for <diffserv@optimus.ietf.org>; Mon, 1 Nov 1999 19:25:52 -0500 (EST)
Received: from auemlsrv.firewall.lucent.com ([192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24765
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 18:00:28 -0500 (EST)
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA11833
	for <diffserv@ietf.org>; Mon, 1 Nov 1999 17:59:48 -0500 (EST)
Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA11777;
	Mon, 1 Nov 1999 17:59:46 -0500 (EST)
Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id SAA04810; Mon, 1 Nov 1999 18:00:38 -0500
Message-ID: <381E1B34.DE669C0@lucent.com>
Date: Mon, 01 Nov 1999 17:59:00 -0500
From: "Enrique J. Hernandez-Valencia" <enrique@lucent.com>
Reply-To: enrique@bell-labs.com
Organization: Lucent Technologies
X-Mailer: Mozilla 4.06 [en]C-EMS-1.4  (Win95; U)
MIME-Version: 1.0
To: diffserv@ietf.org
CC: Stefano Salsano <salsano@coritel.it>, Kathleen Nichols <kmn@cisco.com>
Subject: Re: [Diffserv] EF RFC and loss
References: <381ABF5A.89623619@coritel.it> <381BC2CD.DDC9C21@cisco.com> <381E0B8F.54CAD9B@coritel.it>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Alternatively, there may be services using the EF PHB 
(including VLL itself) that do not _require_ "zero loss." 
In those scenarios, it would be expected that the EF PHB 
will be engineered to provide some level of overflow 
performance. There again, one may not immediately infer
a security violation or PHB misconfiguration from a 
buffer overflow event.

Enrique


Stefano Salsano wrote:
> 
> Kathleen Nichols wrote:
> >
> >
> > The discussion was about the VLL (also called "Premium" service
> > build using the EF PHB) rather than the general problem of burstiness
> > in flows.
> >
> >         Kathie
> 
> Dear Kathie,
> 
> I was dealing with the VLL service built using the EF PHB...
> 
> My point is that the buffer requirements in core routers
> to provide a "zero loss" VLL service based on the EF PHB
> can be much higher than simply proportional to the number
> of different VLLs, due to the worst case clumping effect.
> 
> Best regards,
> Stefano
> 
> P.S. To come back to the original question of this thread:
> only if you provide such a "zero loss" VLL service you can
> consider buffer overflows as misconfigurations or security
> attacks...
> 
> --
> *******************************************************************
> Stefano Salsano
> CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
> 
> E-mail  : salsano@coritel.it      URL     : http://www.coritel.it
> Tel.    : +39 06 20410029          Address : Via di Tor Vergata, 135
> Fax.    : +39 06 20410037                    00133 Roma - ITALY
> *******************************************************************
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
======================================================================
Enrique J. Hernandez-Valencia		email:  enrique@lucent.com
Bell Laboratories				enrique@bell-labs.com
Lucent Technologies			
Room 3H-313				phone:	732-949-6153
Holmdel, NJ 07733, USA			fax:	732-834-5906
=====================================================================

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



From diffserv-admin@ietf.org  Tue Nov  2 01:06:31 1999
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 BAA24097
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 01:06:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA14789;
	Tue, 2 Nov 1999 00:25:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA14760
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 00:25:32 -0500 (EST)
Received: from sngrel5.hp.com (sngrel5.hp.com [192.6.86.210])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06803
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 00:25:32 -0500 (EST)
From: stuart_t_wilson@agilent.com
Received: from burmail.aus.hp.com (root@burmail.aus.hp.com [15.73.171.102])
	by sngrel5.hp.com (8.9.3 (PHNE_18979)/8.8.5tis) with ESMTP id MAA13654
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 12:25:17 +0700 (SST)
Received: from localhost (root@localhost)
	by burmail.aus.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit6.0.6 OpenMail) with SMTP id QAA20746
	for diffserv@ietf.org; Tue, 2 Nov 1999 16:25:14 +1100 (EDT)
X-OpenMail-Hops: 1
Date: Tue, 2 Nov 1999 16:25:00 +1100
Message-Id: <H000021b0102f372@MHS>
MIME-Version: 1.0
TO: diffserv@ietf.org
Content-Type: multipart/mixed; boundary="openmail-part-02fd3493-00000001"
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.ietf.org>
X-BeenThere: diffserv@ietf.org


--openmail-part-02fd3493-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit

remove stuart_wilson@aus.hp.com

--openmail-part-02fd3493-00000001
Content-Type: application/octet-stream; name="Stuart Wilson.vcf"
Content-Disposition: attachment; filename="Stuart Wilson.vcf"
Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOldpbHNvbjtTdHVhcnQ7O01yLjsNCkZOOlN0
dWFydCBXaWxzb24NCk9SRzpIZXdsZXR0IFBhY2thcmQgQXVzdHJhbGlhIEx0ZDtSJkQNClRJ
VExFOlByb2plY3QgTWFuYWdlciAtIFBPUw0KVEVMO1dPUks7Vk9JQ0U6KDMpIDg4NzctNTYy
MQ0KVEVMO0hPTUU7Vk9JQ0U6KDMpIDk4NzgtOTk4Mw0KVEVMO0NFTEw7Vk9JQ0U6MDQxMS40
NC4yNTYzDQpURUw7V09SSztGQVg6KDMpIDg4NzctNTU1MA0KVEVMO0hPTUU7RkFYOigzKSA5
ODc3LTkyNTUNCkFEUjtXT1JLOjs7MzQ3IEJ1cndvb2QgSGlnaHdheTtGb3Jlc3QgSGlsbDtW
SUM7MzEzMTtBdXN0cmFsaWENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJM
RTozNDcgQnVyd29vZCBIaWdod2F5PTBEPTBBRm9yZXN0IEhpbGwsIFZJQyAzMTMxPTBEPTBB
QXVzdHJhbGlhDQpFTUFJTDtQUkVGO0lOVEVSTkVUOnN0dWFydF93aWxzb25AYXVzLmhwLmNv
bQ0KRU1BSUw7SU5URVJORVQ6c3R1YXJ0d0BzaWxpY29uLmNvbS5hdQ0KUkVWOjE5OTkwNjI5
VDA0NDMwOVoNCkVORDpWQ0FSRA0K

--openmail-part-02fd3493-00000001--


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



From diffserv-admin@ietf.org  Tue Nov  2 04:54:40 1999
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 EAA06580
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 04:54:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA28008;
	Tue, 2 Nov 1999 04:15:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA27975
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 04:15:40 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24674
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 04:15:35 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11ia2O-0000M4-00; Tue, 02 Nov 1999 10:15:32 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA15939;
	Tue, 2 Nov 1999 10:15:28 +0100 (MET)
Message-ID: <381EAD62.A7D47114@telematik.informatik.uni-karlsruhe.de>
Date: Tue, 02 Nov 1999 10:22:42 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: Institut =?iso-8859-1?Q?f=FCr?= Telematik - 
	=?iso-8859-1?Q?Universit=E4t?= Karlsruhe
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Dirk Kopplin <dirk.kopplin@erv.ericsson.se>
CC: diffserv@ietf.org
References: <2DADC88F8F19D31193340090277A3661017E28D8@esegsnt003.erv.ericsson.se>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hello Dirk,

Dirk Kopplin wrote:

> Hi,
>
> I've read your IETF draft on IP multicast in diffserv networks and found the
> idea with the new field in the multicast routing table very interesting.
>

This solution of the neglected reservation subtree problem is very simple and
would not result in any scalability problems. Currently we are integrating it
into our DiffServ-Implementation KIDS.

> What I'm concerned with is the fact that IP multicast behavior contradicts
> with the diffserv specification, which in my understanding defines a
> diffserv domain as a pure transport network without any payload generating
> hosts. Traffic need to  enter the diffserv domain through border or edge
> nodes.

Thats right. It is very important to control the traffic, that enters a domain
to guarantee the 'better services'.
But thats not in opposite to support multicast traffic. It's right that
IP-multicast creates new traffic within a ds-domain, but with our solution we
can degredate this traffic to best effort (if necessary).
In RFC2475 is is also mentioned, that a host can be located within a DS-domain.
In my opinion, this host must have the same mechanisms as a boundary router:
meter, marker, policing, ...

IP-multicast has also the problem, that each host can join a multicast group,
and if a multicast flow uses a better service the new receiver would get this
service too - without reservation or payment.


> With this in mind it is difficult the define a diffserv domain since
> new flows can be generated in every multicast enabled router in the network.
> Traffic engineering becomes very difficult in those networks. Even if
> diffserv introduced a mechanism without "hard" QoS guarantees e.g. EF
> traffic shouldn't be punished within the network.

But with the solution proposed in our draft, each new receiver of a multicast
group will first get Best-Effort (or LBE) instead of the better service. Only
when a reservation has been set up for the new subtree of the multicast group,
it will get the full 'better service'. There will be no new traffic that uses a
codepoint of better services without reservation of the ressources - only best
effort (or as proposed: lower than best effort). EF or AF is not concerned by
more Best-Effort-traffic and there will be no change in their guarantees.

> Do you have any comments on that?

see above.

> /dirk

Best Regards,
Klaus


--

 Klaus Wehrle
 Institut für Telematik, Universität Karlsruhe (TH)
 Zirkel 2, 76128 Karlsruhe, Germany
 Phone: +49 721 608 6414, Fax: +49 721 388097
 mailto:wehrle@telematik.informatik.uni-karlsruhe.de
 http://www.telematik.informatik.uni-karlsruhe.de/~wehrle



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



From diffserv-admin@ietf.org  Tue Nov  2 12:39:10 1999
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 MAA21205
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 12:39:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA12283;
	Tue, 2 Nov 1999 11:50:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA12245
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 11:50:46 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01744
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 11:50:47 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Tue, 2 Nov 1999 11:49:38 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V865V9YH; Tue, 2 Nov 1999 11:49:35 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJK08V; Tue, 2 Nov 1999 11:49:35 -0500
Message-ID: <381F161F.1FCA897@nortel.com>
Date: Tue, 02 Nov 1999 11:49:35 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
CC: Dirk Kopplin <dirk.kopplin@erv.ericsson.se>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <2DADC88F8F19D31193340090277A3661017E28D8@esegsnt003.erv.ericsson.se> <381EAD62.A7D47114@telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Klaus Wehrle wrote:

> IP-multicast has also the problem, that each host can join a multicast group,
> and if a multicast flow uses a better service the new receiver would get this
> service too - without reservation or payment.

You might like to take a look at :
http://www.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt

which looks at the problem in a different perspective and does not have the
problem mentioned above because resource reservations are made as the multicast
tree is constructed, and all branches of the tree receives the same service level.
Receivers requiring different service level are met by other means mentioned in
the draft.

This approach does NOT require pkts to be remarked at interior routers.

A related draft is at
http://www.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt.

Policing of data pkts at the boundary router is the same as for unicast traffic,
the growth of the multicast tree (ie additional resources required within the DS
network) is controlled as the tree is being constructed.

I'll be happy to discuss your approach and this approach with you further if
you're interested.

cheers,
cyl
p.s We have a slot to discuss these drafts at the DECIDES BoF, in case you're
interested.


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



From diffserv-admin@ietf.org  Tue Nov  2 13:09:50 1999
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 NAA01459
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 13:09:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA13945;
	Tue, 2 Nov 1999 12:33:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA13912
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 12:33:25 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19344
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 12:33:25 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA19125
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 09:32:40 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Tue, 2 Nov 1999 09:32:38 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Tue, 2 Nov 1999 13:32:16 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Tue, 2 Nov 1999 12:32:30 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <381F161F.1FCA897@nortel.com>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

You know, this is a rather fascinating thread, because this problem
with leaf-initiated multicast, and how to accommodate potentially
different QoS requests such a multicast environment, is exactly the
same problem one would encounter in ATM's UNI 4.0 style of
leaf-initiated multicast.

It seems to me that the answers are going to look similar: either
you set up different trees at the different QoS levels as leaves
send in join requests (ugh), or you allow only less-than-or-equal-to
branches to be added to the multicast tree (which means that
multicasts will tend to degrade to BE), or you simply only construct
the multicast tree based on the source's QoS needs, potentially
meaning that some would-be sinks will never get their join messages
honored.

Bert
manfredi@arl.bna.boeing.com


> -----Original Message-----
> From: diffserv-admin@ietf.org
> [mailto:diffserv-admin@ietf.org]On Behalf
> Of Cheng-Yin Lee
> Sent: Tuesday, November 02, 1999 11:50 AM
> To: Klaus Wehrle
> Cc: Dirk Kopplin; diffserv@ietf.org
> Subject: Re: [Diffserv] Re: Problems with IP-Multicast in
> DiffServ-Networks
>
>
> Klaus Wehrle wrote:
>
> > IP-multicast has also the problem, that each host can
> join a multicast group,
> > and if a multicast flow uses a better service the new
> receiver would get this
> > service too - without reservation or payment.
>
> You might like to take a look at :
> http://www.ietf.org/internet-drafts/draft-leecy-multicast-
> provisioning-00.txt
>
> which looks at the problem in a different perspective and
> does not have the
> problem mentioned above because resource reservations are
> made as the multicast
> tree is constructed, and all branches of the tree
> receives the same service level.
> Receivers requiring different service level are met by
> other means mentioned in
> the draft.
>
> This approach does NOT require pkts to be remarked at
> interior routers.
>
> A related draft is at
> http://www.ietf.org/internet-drafts/draft-leecy-multicast-
> egress-limit-00.txt.
>
> Policing of data pkts at the boundary router is the same
> as for unicast traffic,
> the growth of the multicast tree (ie additional resources
> required within the DS
> network) is controlled as the tree is being constructed.
>
> I'll be happy to discuss your approach and this approach
> with you further if
> you're interested.
>
> cheers,
> cyl
> p.s We have a slot to discuss these drafts at the DECIDES
> BoF, in case you're
> interested.
>
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>


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



From diffserv-admin@ietf.org  Tue Nov  2 16:04:11 1999
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 QAA08021
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 16:04:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA19340;
	Tue, 2 Nov 1999 15:04:34 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA19269
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 15:04:28 -0500 (EST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16143
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 15:04:25 -0500 (EST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Tue, 2 Nov 1999 14:03:48 -0600
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5BQWCTC; Tue, 2 Nov 1999 15:03:48 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLA4B; Tue, 2 Nov 1999 15:03:46 -0500
Message-ID: <381F43A2.3F6085C7@nortel.com>
Date: Tue, 02 Nov 1999 15:03:46 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: diffserv <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:

> You know, this is a rather fascinating thread, because this problem
> with leaf-initiated multicast, and how to accommodate potentially
> different QoS requests such a multicast environment, is exactly the
> same problem one would encounter in ATM's UNI 4.0 style of
> leaf-initiated multicast.

Should we attempt to provide different QOS on a tree or should we use
other alternatives e.g layer encoding?  The latter seems easier.

> either
> you set up different trees at the different QoS levels as leaves
> send in join requests (ugh),

I don't follow why this is bad.
The network is not involved in this choice or selection, the user
selects the goup(s) it wants to join. Perhaps i missed your point?

> or you allow only less-than-or-equal-to
> branches to be added to the multicast tree (which means that
> multicasts will tend to degrade to BE),

i'm not  sure if requesting a service level is going to be very useful
then...

> or you simply only construct
> the multicast tree based on the source's QoS needs, potentially
> meaning that some would-be sinks will never get their join messages
> honored.

And there is no reason to honour them if  the source has not
requested/pay for the resources required to multicast to these sinks,
assuming a model where the source 'pays' the network provider for the
network resources required for multicast and the receivers 'pay' the
source for the 'content'. The source of course could belong to the
network provider as well.

Even if you use the same service level within a multicast tree/group,
there is still the problem where
a host can join a multicast group, and get multicast data before
resources have been allocated for the branch leading to the host (as
implied by Klaus Wehrle as well). The draft i posted earlier allocates
resources (if a group requires a certain service level) as the tree is
constructed, so data is not sent on a path where resources have not been
allocated yet and there is no need to remark pkts in interior routers as
a result.

I should also mention that resources need not be allocated per flow in
the draft mentioned in my previous email.

cheers,
cyl
p.s BTW, may i know what is the solution in ATM UNI 4.0?

>
>
> Bert
> manfredi@arl.bna.boeing.com
>
> > -----Original Message-----
> > From: diffserv-admin@ietf.org
> > [mailto:diffserv-admin@ietf.org]On Behalf
> > Of Cheng-Yin Lee
> > Sent: Tuesday, November 02, 1999 11:50 AM
> > To: Klaus Wehrle
> > Cc: Dirk Kopplin; diffserv@ietf.org
> > Subject: Re: [Diffserv] Re: Problems with IP-Multicast in
> > DiffServ-Networks
> >
> >
> > Klaus Wehrle wrote:
> >
> > > IP-multicast has also the problem, that each host can
> > join a multicast group,
> > > and if a multicast flow uses a better service the new
> > receiver would get this
> > > service too - without reservation or payment.
> >
> > You might like to take a look at :
> > http://www.ietf.org/internet-drafts/draft-leecy-multicast-
> > provisioning-00.txt
> >
> > which looks at the problem in a different perspective and
> > does not have the
> > problem mentioned above because resource reservations are
> > made as the multicast
> > tree is constructed, and all branches of the tree
> > receives the same service level.
> > Receivers requiring different service level are met by
> > other means mentioned in
> > the draft.
> >
> > This approach does NOT require pkts to be remarked at
> > interior routers.
> >
> > A related draft is at
> > http://www.ietf.org/internet-drafts/draft-leecy-multicast-
> > egress-limit-00.txt.
> >
> > Policing of data pkts at the boundary router is the same
> > as for unicast traffic,
> > the growth of the multicast tree (ie additional resources
> > required within the DS
> > network) is controlled as the tree is being constructed.
> >
> > I'll be happy to discuss your approach and this approach
> > with you further if
> > you're interested.
> >
> > cheers,
> > cyl
> > p.s We have a slot to discuss these drafts at the DECIDES
> > BoF, in case you're
> > interested.
> >
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >


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



From diffserv-admin@ietf.org  Tue Nov  2 17:26:52 1999
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 RAA11945
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 17:26:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA21810;
	Tue, 2 Nov 1999 16:34:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA21737
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 16:34:18 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19218
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 16:34:16 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA12244
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 13:34:17 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Tue, 2 Nov 1999 13:34:14 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Tue, 2 Nov 1999 17:33:53 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
Cc: "diffserv" <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Tue, 2 Nov 1999 16:34:06 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIECDCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <381F43A2.3F6085C7@nortel.com>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:leecy@nortelnetworks.com]

Albert Manfredi wrote:

> > either
> > you set up different trees at the different QoS levels as leaves
> > send in join requests (ugh),
>
> I don't follow why this is bad.
> The network is not involved in this choice or selection, the user
> selects the goup(s) it wants to join. Perhaps i missed your point?

The problem here is scaling. In principle, you could have n users
each requesting a different QoS level, which is not the best way to
support multicast. But it's possible.

> > or you allow only less-than-or-equal-to
> > branches to be added to the multicast tree (which means that
> > multicasts will tend to degrade to BE),
>
> i'm not  sure if requesting a service level is going to
> be very useful
> then...

I tend to agree.

> > or you simply only construct
> > the multicast tree based on the source's QoS needs, potentially
> > meaning that some would-be sinks will never get their
> join messages
> > honored.
>
> And there is no reason to honour them if  the source has not
> requested/pay for the resources required to multicast to
> these sinks,
> assuming a model where the source 'pays' the network
> provider for the
> network resources required for multicast and the
> receivers 'pay' the
> source for the 'content'. The source of course could belong to the
> network provider as well.

Well, true enough. Regardless of who pays, it's possible that a
source could mandate that at least such a QoS is required for this
multicast, and then perhaps (in the future) some constraint-based
routing scheme would help ensure that a good path is found.
Otherwise, if the diffserv nets in the path can't support the source
requirements, too bad. That's a valid approach, I think.

> Even if you use the same service level within a multicast
> tree/group,
> there is still the problem where
> a host can join a multicast group, and get multicast data before
> resources have been allocated for the branch leading to
> the host (as
> implied by Klaus Wehrle as well). The draft i posted
> earlier allocates
> resources (if a group requires a certain service level)
> as the tree is
> constructed, so data is not sent on a path where
> resources have not been
> allocated yet and there is no need to remark pkts in
> interior routers as
> a result.

But the tree will not necessarily be constructed at time 0. It's a
living thing, as users come and go, is it not? You won't know ahead
of time which routers are going to come into play. So a user that
wants to join at time +x might be out of luck.

> p.s BTW, may i know what is the solution in ATM UNI 4.0?

ATM uses the "source determines QoS level" method, essentially, but
allows for a lot of flexibility in doing so. UNI 4.0 allows the root
or the leaf to initiate the join request. But if the leaf initiates
the request, this kicks off the standard source-initiated setup
handshaking, where the source (root) establishes the QoS needs and
transmits these to the leaf via SETUP or ADD PARTY signaling
messages. So a leaf-initiated join is merely one extra step to a
root-initiated join, and any QoS requirement the source has would
presumably be met by PNNI's constraint-based routing.

(In typical ATM fashion, though, a leaf-initiated join request can,
via the call identifier alone, implictly request a particular QoS
level. But how the root would match a call identifier to a QoS level
is not specified.)

In ATM UNI 4.0 multicast, if the leaf initiates the call, the
request can either go all the way to the root or the network can
grant it before it reaches the root. So the latter would be more
like RFC 1112. This would be the case if switches along the path
back to the root are already servicing that multicast.

So it seems to me that an IP implementation of QoS-aware multicast
could work similar to ATM's leaf-initiated join, where the network,
acting as the source, establishes the QoS requirement. This is
valid, I think, and will mandate that any leaf wishing to join a
multicast would be required to pay whatever the rate is for that
multicast.

Bert
manfredi@arl.bna.boeing.com



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



From diffserv-admin@ietf.org  Tue Nov  2 18:53:40 1999
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 SAA08738
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 18:53:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24231;
	Tue, 2 Nov 1999 18:13:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24204
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 18:13:51 -0500 (EST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26035
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 18:13:50 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Tue, 2 Nov 1999 16:47:45 -0600
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V865XSXH; Tue, 2 Nov 1999 17:47:40 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLBDQ; Tue, 2 Nov 1999 17:47:41 -0500
Message-ID: <381F6A0D.C48D7D0C@nortel.com>
Date: Tue, 02 Nov 1999 17:47:41 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: diffserv <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECDCAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:

> \> > either
> > > you set up different trees at the different QoS levels as leaves
> > > send in join requests (ugh),
> >
> > I don't follow why this is bad.
> > The network is not involved in this choice or selection, the user
> > selects the goup(s) it wants to join. Perhaps i missed your point?
>
> The problem here is scaling. In principle, you could have n users
> each requesting a different QoS level, which is not the best way to
> support multicast. But it's possible.

There is a finite number of 'QoS level' that users would subscribe to,
if you look at typical applications.
For eg. below a certain minimum service level, the data may not be
useful to receivers.

> But the tree will not necessarily be constructed at time 0. It's a
> living thing, as users come and go, is it not?

Yes.

> You won't know ahead of time which routers are going to come into
> play. So a user that wants to join at time +x might be out of luck.

As an example, a  provider would allocate a pool of resources
statically  for multicast traffic, and as receivers join certain groups,
the tree construction can be directed on paths allocated a priori with a
sufficient pool of resources . These resources can then be shared and
dynamically provisioned for different service levels.  Unless the egress
points are fixed, there are no guarantees, but with proper path
engineering the probability of not being able to meet an SLA can be very
low.
(It seems just as important that if traffic is admitted into the
DS network, there are sufficient resources on the paths leading to the
receivers and to prevent  multicast traffic from  flowing on paths that
do not have sufficient resources).

> > p.s BTW, may i know what is the solution in ATM UNI 4.0?
>

Thanks for description, i'm taking a closer look. I have to say that
i've concerns about ATM style reservations though, since it maintains
reservation states per group.

cheers,
cyl



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



From diffserv-admin@ietf.org  Tue Nov  2 19:01:52 1999
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 TAA11538
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 19:01:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24618;
	Tue, 2 Nov 1999 18:30:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA24549
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 18:29:59 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00768
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 18:30:00 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA11069
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 15:30:01 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Tue, 2 Nov 1999 15:29:55 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Tue, 2 Nov 1999 19:29:26 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
Cc: "diffserv" <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Tue, 2 Nov 1999 18:29:40 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIECECAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <381F6A0D.C48D7D0C@nortel.com>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: Cheng-Yin Lee [mailto:leecy@nortelnetworks.com]

[ ... ]

> > > p.s BTW, may i know what is the solution in ATM UNI 4.0?
> >
>
> Thanks for description, i'm taking a closer look. I have
> to say that
> i've concerns about ATM style reservations though, since
> it maintains
> reservation states per group.

Of course, the ATM solution is not compatible with diffserv exactly.
You certainly don't want to maintain state per flow or microflow.
But the concept of how QoS is provided in a macro sense might be
applicable. There are only so many reasonable ways of doing this.

As to only a finite number of QoS levels, although this might be
true, that number is still too large if the sinks get to choose any
value they like. So it makes sense for the source to provide one or
a small number of options somehow. Perhaps with separate trees, as
you suggest. That sounds feasible.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Tue Nov  2 19:51:50 1999
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 TAA25180
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 19:51:50 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA26062;
	Tue, 2 Nov 1999 19:27:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA26030
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 19:27:53 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18095;
	Tue, 2 Nov 1999 19:27:55 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA07553;
	Tue, 2 Nov 1999 16:27:24 -0800 (PST)
Message-ID: <381F819B.CCE1187@cisco.com>
Date: Tue, 02 Nov 1999 16:28:11 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: agenda@ietf.org
CC: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] agenda
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Monday, 11/15, 19:30-22:00

(10) Agenda bashing and status......Brian Carpenter and Kathie Nichols

Working Group Drafts
--------------------

(15) Tterminology: diffserv-ietf-new-terms-01.txt ... Dan Grossman
(15) PHB IDs: diffserv-ietf-phbid-00.txt ... Scott Brim

(30) Model: draft-ietf-diffserv-model-01.txt ... Bernet, Blake, Smith
(30) MIB: draft-ietf-diffserv-mib-01.txt ... Baker et al,
(NOTE: the MIB draft appears not to have made the cut-off but must be
discussed. A version is apparently available at:
ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt,
if you're not from Cisco. Fred will presumably make a version
available for those of us from Cisco)
(10) additional joint discussion of Model and MIB, if needed

(20) Diffserv and Tunnels: draft-black-diffserv-tunnels-00.txt ... Black
(NOTE: despite the name, this draft was solicited by the WG, but
David chose to submit it as individual since he didn't have time to
get the review of other WG members. We expect the next version to
be title as a WG draft.)

(15) Future work, looking for drafts ... Brian and Kathie

Tuesday, 11/16, 13:00-14:00

Unsolicited drafts
------------------

If business on the WG drafts was concluded on Monday, we
can discuss the unsolicited drafts. This session will be
run by the WG co-chairs who will be looking for the "sense"
of the WG on the following drafts. Authors of the drafts
are encouraged to show up in case some response or clarification
is needed, but should not expect to have any presentation time.


   draft-kanada-diffserv-qospifmib-00.txt
   draft-bonaventure-diffserv-rashaper-01.txt
   draft-bless-diffserv-lbe-phb-00.txt
   draft-bless-diffserv-multicast-00.txt
   draft-fang-diffserv-tc-tswtcm-00.txt
   draft-fu-diffserv-security-00.txt 
   draft-lin-diffserv-gtc-01.txt
   draft-nadas-diffserv-experience-01.txt

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



From diffserv-admin@ietf.org  Tue Nov  2 22:33:19 1999
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 WAA21088
	for <diffserv-archive@ietf.org>; Tue, 2 Nov 1999 22:33:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA28896;
	Tue, 2 Nov 1999 21:42:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA28859
	for <diffserv@optimus.ietf.org>; Tue, 2 Nov 1999 21:42:17 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26274
	for <diffserv@ietf.org>; Tue, 2 Nov 1999 21:42:18 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Tue, 2 Nov 1999 21:40:29 -0500
Received: from zcard008.ca.nortel.com ([47.127.82.62]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V865YG7R; Tue, 2 Nov 1999 21:40:28 -0500
Received: from nortelnetworks.com (CR306449-A [47.199.34.140]) 
          by zcard008.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VCZCZH0D; Tue, 2 Nov 1999 21:40:27 -0500
Message-ID: <381FAFF5.64966ACE@nortelnetworks.com>
Date: Tue, 02 Nov 1999 22:45:57 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en,zh-CN,zh,zh-TW,af
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: diffserv <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECECAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:
> 
> > Thanks for description, i'm taking a closer look. I have
> > to say that
> > i've concerns about ATM style reservations though, since
> > it maintains
> > reservation states per group.
> 
> Of course, the ATM solution is not compatible with diffserv exactly.
> You certainly don't want to maintain state per flow or microflow.
Agree, the multicast provisioning proposal does not require state to be
maintained per group.

> But the concept of how QoS is provided in a macro sense might be
> applicable. 

Yes, i believe so too.

> So it seems to me that an IP implementation of QoS-aware multicast
> could work similar to ATM's leaf-initiated join, where the network,
> acting as the source, establishes the QoS requirement. 
Yes, in this proposal the source determines the QOS requirement.

cheers,
cyl

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



From diffserv-admin@ietf.org  Wed Nov  3 03:58:52 1999
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 DAA10035
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 03:58:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA11862;
	Wed, 3 Nov 1999 03:12:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA11830
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 03:12:03 -0500 (EST)
Received: from etri.re.kr (mail.etri.re.kr [129.254.113.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23434
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 03:12:05 -0500 (EST)
Received: from etri.re.kr (choits.etri.re.kr [129.254.191.165])
	by etri.re.kr (8.9.3/8.9.3) with ESMTP id RAA14493
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 17:09:15 +0900 (KST)
Message-ID: <381FEEC8.C9882381@etri.re.kr>
Date: Wed, 03 Nov 1999 17:14:01 +0900
From: Taesang Choi <choits@etri.re.kr>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Comments on draft-ietf-diffserv-mib-01.txt
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

According to the second paragraph of the section 3.3, it says "The
result of metering traffic is always some action."  And if you look at
the the description part of the diffServTBMeterSucceedNext attribute in
diffServTBMeter table, it says "The 'Succeed Next' pointer selects which
action OR QUEUE on the interface that to be used with the message."

Does this mean that conformed packets can be directed to a queue
bypassing a certain action?  If so, the two parts conflict each other.
Any clarifications will be appreciated.  Thanks in advance.

Taesang
ETRI


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



From diffserv-admin@ietf.org  Wed Nov  3 05:46:13 1999
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 FAA21693
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 05:46:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA15849;
	Wed, 3 Nov 1999 05:04:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA15817
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 05:04:15 -0500 (EST)
Received: from old-callisto.ftel.co.uk (big-relay-1.ftel.co.uk [192.65.220.123])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07558
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 05:04:15 -0500 (EST)
Received: (from root@localhost)
	by old-callisto.ftel.co.uk (8.9.3/8.9.3/Revision:1.42) id KAA15276
	for diffserv@ietf.org; Wed, 3 Nov 1999 10:04:07 GMT
Received: from callisto.ftel.co.uk (root@callisto.ftel.co.uk [172.16.2.99])
	by old-callisto.ftel.co.uk (8.9.3/8.9.3/Revision:1.42/scanin/yp) with ESMTP id KAA15257
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:04:05 GMT
Received: from ftel.co.uk (gcope@localhost.ftel.co.uk [127.0.0.1])
	by callisto.ftel.co.uk (8.8.7/8.8.7/Revision:1.48/yp) with ESMTP id KAA25761;
	Wed, 3 Nov 1999 10:01:52 GMT
Message-ID: <3820080F.49C9FB1F@ftel.co.uk>
Date: Wed, 03 Nov 1999 10:01:51 +0000
From: Graham Cope <G.Cope@ftel.co.uk>
Organization: Fujitsu Telecommunications Europe Ltd
X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4u)
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: Cheng-Yin Lee <leecy@nortelnetworks.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Are there not some similar, but reverse direction problems with RSVP
shared reservations?

By multicast I assume that you mean pt-to-multipoint, and reveiving
hosts join the tree.

With RSVP you may have shared reservations 'merging' downstream towards
the reveiver. Suppose that a number of such flows merge within a
diffserv domain. It is not entirely obvious to me what the SLS would
look like, and indeed how you would provision internal resources. For
instance, an SLS could be 'another flow may join a session at this
ingress, provided that there is already another flow using resources
from another ingress'. Pt-to-pt distinct reservations are much nicer!



Graham






Albert Manfredi wrote:

> You know, this is a rather fascinating thread, because this problem
> with leaf-initiated multicast, and how to accommodate potentially
> different QoS requests such a multicast environment, is exactly the
> same problem one would encounter in ATM's UNI 4.0 style of
> leaf-initiated multicast.
>
> It seems to me that the answers are going to look similar: either
> you set up different trees at the different QoS levels as leaves
> send in join requests (ugh), or you allow only less-than-or-equal-to
> branches to be added to the multicast tree (which means that
> multicasts will tend to degrade to BE), or you simply only construct
> the multicast tree based on the source's QoS needs, potentially
> meaning that some would-be sinks will never get their join messages
> honored.
>
> Bert
> manfredi@arl.bna.boeing.com




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



From diffserv-admin@ietf.org  Wed Nov  3 11:10:18 1999
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 LAA10291
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:10:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA25171;
	Wed, 3 Nov 1999 10:26:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA25062
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 10:26:38 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24360
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:26:39 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA56740 for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:26:08 GMT
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA27274 for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:26:06 GMT
Message-ID: <38205407.BC63F31@hursley.ibm.com>
Date: Wed, 03 Nov 1999 09:25:59 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Graham,

Multicast in the IP model is conceptually multipoint-to-multipoint.
I know this makes it harder, but it's not a theoretical
consideration: a 10-party conference needs to be provisioned
on a multipoint basis. (Unless you want to be bound to the
concept of a conference bar for ever.)

My personal take is that trying to solve this problem exclusively
at the network layer is a doomed enterprise; it is only the
applications that actually understand the provisioning requirement.

We will touch briefly on this in the second session next week,
to judge the sense of the WG whether we can tackle this.

   Brian

Graham Cope wrote:
> 
> Are there not some similar, but reverse direction problems with RSVP
> shared reservations?
> 
> By multicast I assume that you mean pt-to-multipoint, and reveiving
> hosts join the tree.
> 
> With RSVP you may have shared reservations 'merging' downstream towards
> the reveiver. Suppose that a number of such flows merge within a
> diffserv domain. It is not entirely obvious to me what the SLS would
> look like, and indeed how you would provision internal resources. For
> instance, an SLS could be 'another flow may join a session at this
> ingress, provided that there is already another flow using resources
> from another ingress'. Pt-to-pt distinct reservations are much nicer!
> 
> Graham
> 
> Albert Manfredi wrote:
> 
> > You know, this is a rather fascinating thread, because this problem
> > with leaf-initiated multicast, and how to accommodate potentially
> > different QoS requests such a multicast environment, is exactly the
> > same problem one would encounter in ATM's UNI 4.0 style of
> > leaf-initiated multicast.
> >
> > It seems to me that the answers are going to look similar: either
> > you set up different trees at the different QoS levels as leaves
> > send in join requests (ugh), or you allow only less-than-or-equal-to
> > branches to be added to the multicast tree (which means that
> > multicasts will tend to degrade to BE), or you simply only construct
> > the multicast tree based on the source's QoS needs, potentially
> > meaning that some would-be sinks will never get their join messages
> > honored.
> >
> > Bert
> > manfredi@arl.bna.boeing.com
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Wed Nov  3 11:10:42 1999
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 LAA10457
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:10:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24635;
	Wed, 3 Nov 1999 10:15:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24603
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 10:15:38 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21647
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:15:38 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA15720 for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:15:06 GMT
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA31680 for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:15:05 GMT
Message-ID: <38205176.C3953EF0@hursley.ibm.com>
Date: Wed, 03 Nov 1999 09:15:02 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Diff Serv <diffserv@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] diffserv MIB -01
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

In case anyone has trouble with the ftp: URL for the MIB,
there is another copy at
http://www.adtech.icair.org/brian/draft-ietf-diffserv-mib-01.txt

Again apologies that it didn't make it into the Internet-Drafts
directory; from the email I saw it seems to have missed the
cutoff by a whisker.

    Brian

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



From diffserv-admin@ietf.org  Wed Nov  3 11:10:59 1999
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 LAA10580
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:10:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24775;
	Wed, 3 Nov 1999 10:19:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24749
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 10:19:29 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22667
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:19:31 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA17502
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 07:19:31 -0800 (PST)
Received: from [199.191.48.146] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 07:19:24 -0800
Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 11:18:57 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Graham Cope" <G.Cope@ftel.co.uk>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 10:19:14 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIECICAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <3820080F.49C9FB1F@ftel.co.uk>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: diffserv-admin@ietf.org
> [mailto:diffserv-admin@ietf.org]On Behalf
> Of Graham Cope

> Are there not some similar, but reverse direction
> problems with RSVP
> shared reservations?

Indeed. Isn't that called the PATH message in RSVP? That's what sets
the reservation requirement. So perhaps everyone is using that basic
approach.

> By multicast I assume that you mean pt-to-multipoint, and
> reveiving
> hosts join the tree.

In leaf-initiated join in ATM UNI 4.0, yes.

> With RSVP you may have shared reservations 'merging'
> downstream towards
> the reveiver. Suppose that a number of such flows merge within a
> diffserv domain. It is not entirely obvious to me what
> the SLS would
> look like, and indeed how you would provision internal
> resources. For
> instance, an SLS could be 'another flow may join a session at this
> ingress, provided that there is already another flow
> using resources
> from another ingress'. Pt-to-pt distinct reservations are
> much nicer!

Perhaps, though, in a diffserv setting, we're talking about setting
up multicast aggregate flows. Like tunnels, maybe, not individual
sinks doing RFC 1112 join requests? Not that this simplifies the
problem totally, but it does make it a little less dynamic.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 11:16:15 1999
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 LAA12631
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:16:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24903;
	Wed, 3 Nov 1999 10:23:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24874
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 10:23:33 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23574
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:23:36 -0500 (EST)
Received: from ascend.com ([152.148.89.11])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id KAA02633
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 10:22:59 -0500 (EST)
Message-ID: <38205287.9DF90975@ascend.com>
Date: Wed, 03 Nov 1999 10:19:35 -0500
From: Siamack Ayandeh <sayandeh@ascend.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: diffserv@ietf.org
Subject: Re: [Diffserv] agenda
References: <381F819B.CCE1187@cisco.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Re the session on Tuesday. Would it be possible for the authors to
put up a one slide "outline", and lead the question period.

Regards, Siamack

Kathleen Nichols wrote:

> Monday, 11/15, 19:30-22:00
>
> (10) Agenda bashing and status......Brian Carpenter and Kathie Nichols
>
> Working Group Drafts
> --------------------
>
> (15) Tterminology: diffserv-ietf-new-terms-01.txt ... Dan Grossman
> (15) PHB IDs: diffserv-ietf-phbid-00.txt ... Scott Brim
>
> (30) Model: draft-ietf-diffserv-model-01.txt ... Bernet, Blake, Smith
> (30) MIB: draft-ietf-diffserv-mib-01.txt ... Baker et al,
> (NOTE: the MIB draft appears not to have made the cut-off but must be
> discussed. A version is apparently available at:
> ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt,
> if you're not from Cisco. Fred will presumably make a version
> available for those of us from Cisco)
> (10) additional joint discussion of Model and MIB, if needed
>
> (20) Diffserv and Tunnels: draft-black-diffserv-tunnels-00.txt ... Black
> (NOTE: despite the name, this draft was solicited by the WG, but
> David chose to submit it as individual since he didn't have time to
> get the review of other WG members. We expect the next version to
> be title as a WG draft.)
>
> (15) Future work, looking for drafts ... Brian and Kathie
>
> Tuesday, 11/16, 13:00-14:00
>
> Unsolicited drafts
> ------------------
>
> If business on the WG drafts was concluded on Monday, we
> can discuss the unsolicited drafts. This session will be
> run by the WG co-chairs who will be looking for the "sense"
> of the WG on the following drafts. Authors of the drafts
> are encouraged to show up in case some response or clarification
> is needed, but should not expect to have any presentation time.
>
>    draft-kanada-diffserv-qospifmib-00.txt
>    draft-bonaventure-diffserv-rashaper-01.txt
>    draft-bless-diffserv-lbe-phb-00.txt
>    draft-bless-diffserv-multicast-00.txt
>    draft-fang-diffserv-tc-tswtcm-00.txt
>    draft-fu-diffserv-security-00.txt
>    draft-lin-diffserv-gtc-01.txt
>    draft-nadas-diffserv-experience-01.txt
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Wed Nov  3 11:48:15 1999
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 LAA24270
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:48:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26790;
	Wed, 3 Nov 1999 11:09:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26758
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:09:29 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09937
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:09:31 -0500 (EST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 11:01:46 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5BQX9K7; Wed, 3 Nov 1999 11:01:42 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLB8B; Wed, 3 Nov 1999 11:01:41 -0500
Message-ID: <38205C66.760FF127@nortel.com>
Date: Wed, 03 Nov 1999 11:01:42 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>,
        Graham Cope <G.Cope@ftel.co.uk>
CC: diffserv <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECICAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:

> > -----Original Message-----
> > From: diffserv-admin@ietf.org
> > [mailto:diffserv-admin@ietf.org]On Behalf
> > Of Graham Cope

> > With RSVP you may have shared reservations 'merging'
> > downstream towards
> > the reveiver. Suppose that a number of such flows merge within a
> > diffserv domain. It is not entirely obvious to me what
> > the SLS would
> > look like, and indeed how you would provision internal
> > resources.

Both
http://search.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt

http://search.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt

have examples of SLS.

> For
> > instance, an SLS could be 'another flow may join a session at this
> > ingress, provided that there is already another flow
> > using resources
> > from another ingress'.

http://search.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt
has examples of how to control the number of egress points, which i
believe is your question?

> > Pt-to-pt distinct reservations are much nicer!
>
> Perhaps, though, in a diffserv setting, we're talking about setting
> up multicast aggregate flows. Like tunnels, maybe, not individual
> sinks doing RFC 1112 join requests?

You can still send join requests and reserve for aggregate flows, to the
resource provisioning entity the resource allocation is analogous to
memory allocation, it doesn't need to know the groups it's reserving
because we can leverage the tree construction protocol (multicast rtg
protocol) to terminate those reservations.
This is described in Appendix A of
http://search.ietf.org/internet-drafts/draft-leecy-multicast-provisioning-00.txt



> Not that this simplifies the
> problem totally, but it does make it a little less dynamic.

If a mechanism similar to Appendix A is used, it can still be dynamic.

cheers,
cyl


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



From diffserv-admin@ietf.org  Wed Nov  3 11:53:39 1999
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 LAA26526
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 11:53:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26504;
	Wed, 3 Nov 1999 11:01:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26473
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:01:41 -0500 (EST)
Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06700
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:01:40 -0500 (EST)
Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1])
	by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id LAA17954
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:01:28 -0500 (EST)
Message-Id: <199911031601.LAA17954@castillo.torrentnet.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: diffserv@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 03 Nov 1999 11:01:28 -0500
From: Steve Blake <slblake@torrentnet.com>
Subject: [Diffserv] Changes to model-01
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Summary of changes between model-00 and -01:

Sec. 2 

  - added glossary of new or expanded terms

Sec. 3

  - clarified that classification, traffic conditioning, and queueing are
    funtions possibly (logically) associated with both ingress and
    egress i/fs

  - clarified function of routing core

Sec. 4

  - text shuffling

  - added section on fitting MPLS LSRs into the model

Sec. 5.

  - reorganized meter text into a separate section

  - added separate sub-sections on two-parameter (simple) token buckets and
    multi-parameter token buckets (network of two-parameter TBs)

Sec. 6

  - reorganized action elements into a separate section

  - defined new action elements: multiplexor, mirror, enqueueing element,
    null action

    - mux is self-explanatory

    - mirror splits the datapath into N streams

    - enqueueing element is a mux which sits in front of a queue and executes
      a buffer management algorithm

    - null action is defined if needed by the config/management interface

    - point out that a shaper action element is realized using a queue,
      move bulk of text to Sec. 7

Sec. 7

  - define queue parameters (priority, minimum guaranteed rate, maximum
    rate profile (non-work-conserving)

  - define queue sets (set of queues served by a single scheduler)

  - define queue superset (set of queue sets)

  - define shaping queue and max rate profile

Sec. 8 (was Sec. 6 in model-00)

  - clarify the flexibility available in configuring elements into TCB
    (e.g., no mandatory elements or order)

  - clarify that TCBs are 1:1 black-box elements

  - minor changes to TCB examples

Sec. 9

  - added open issues section

Sec. 10

  - added security boilerplate

Appendix A

  - added algorithmic description of a two-parameter token bucket meter/
    shaping profile consistent with [TRTCM]


Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <slblake@torrentnet.com>
Ericsson IP Infrastructure             (919)468-8466 x232



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



From diffserv-admin@ietf.org  Wed Nov  3 12:04:11 1999
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 MAA00824
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:04:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26551;
	Wed, 3 Nov 1999 11:02:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26525
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:02:08 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06880
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:02:10 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA14825; Wed, 3 Nov 1999 08:01:18 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210102b446096657bc@[10.19.130.188]>
In-Reply-To: <38205407.BC63F31@hursley.ibm.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
Date: Wed, 3 Nov 1999 08:01:24 -0800
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

The subject line of this thread caught my eye...

At 9:25 AM -0600 11/3/99, Brian E Carpenter wrote:
>Multicast in the IP model is conceptually multipoint-to-multipoint.

No, the IP multicast model is that of point-to-multipoint datagrams.
Higher layers can build multipoint-to-multipoint applications out of
the IP pt-to-mpt service.

>I know this makes it harder, but it's not a theoretical
>consideration: a 10-party conference needs to be provisioned
>on a multipoint basis.

Why is the diff-serv list discussing provisioning for a single conference
or per-flow resource reservations???

Diff-serv for IP multicast ought to work just like diff-serv for IP
unicast: the sender sets some bits to indicate how it would like the
packet to be handled; any router along the delivery tree may modify
those bits to indicate how the packet ought be handled from that point
onward, along one or more descendent branches of the delivery tree.
Along any branch of the delivery tree, the packet undergoes the same
diff-serv handling as would a unicast packet along that branch.  The
only significant difference is that, compared to replicated unicasts,
less provisioning is needed for multicast  What's the problem, exactly?

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 12:10:56 1999
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 MAA03812
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:10:56 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26936;
	Wed, 3 Nov 1999 11:12:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA26910
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:12:12 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10985
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:12:12 -0500 (EST)
Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA15807
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 08:11:41 -0800 (PST)
Message-ID: <38206207.36D302CC@cisco.com>
Date: Wed, 03 Nov 1999 08:25:43 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] agenda corrections and additions
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


diffservers,

Okay, that's what I get for doing this at the last minute and
quickly.

First: The dates are Nov 8&9, not 15&16 (but it would probably
be easier to get a hotel room on the 15&16...)

Second: Please add these two drafts to Tuesday's line-up:

draft-dieder-diffserv-phb-efd-00.txt
draft-medina-mmcm-00.txt


	Kathie

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



From diffserv-admin@ietf.org  Wed Nov  3 12:11:30 1999
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 MAA04115
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:11:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27158;
	Wed, 3 Nov 1999 11:17:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27126
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:17:45 -0500 (EST)
Received: from prch01.cas.prt.alcatel.pt (h50.n64.alcatel.pt [159.23.64.50] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13172
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:17:31 -0500 (EST)
From: davide.lourenco@alcatel.pt
Received: from localhost (root@localhost)
	by prch01.cas.prt.alcatel.pt (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA05552
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 16:24:15 GMT
X-OpenMail-Hops: 1
Date: Wed, 3 Nov 1999 16:24:01 +0000
Message-Id: <H000026800781262@MHS>
MIME-Version: 1.0
TO: diffserv@ietf.org
Content-Type: multipart/mixed; boundary="openmail-part-0105b370-00000001"
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.ietf.org>
X-BeenThere: diffserv@ietf.org


--openmail-part-0105b370-00000001
Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT"
Content-Disposition: inline; filename="BDY.TXT"
Content-Transfer-Encoding: 7bit


subscribe diffserv davide.lourenco@alcatel.pt
--openmail-part-0105b370-00000001--


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



From diffserv-admin@ietf.org  Wed Nov  3 12:12:58 1999
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 MAA04874
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:12:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27251;
	Wed, 3 Nov 1999 11:19:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27217
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:19:09 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13845
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:19:09 -0500 (EST)
Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA16395;
	Wed, 3 Nov 1999 08:18:07 -0800 (PST)
Message-ID: <38206389.BD914DDF@cisco.com>
Date: Wed, 03 Nov 1999 08:32:09 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Siamack Ayandeh <sayandeh@ascend.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] agenda
References: <381F819B.CCE1187@cisco.com> <38205287.9DF90975@ascend.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Siamack Ayandeh wrote:
> 
> Re the session on Tuesday. Would it be possible for the authors to
> put up a one slide "outline", and lead the question period.
> 
> Regards, Siamack

Due to the time constraints, authors can NOT lead the question
period. However, you may give the WG co-chairs a single slide
with some bullets about why the draft is important, what the
issues are, and what you'd like the WG to do. If the slide is
too "busy" to be unreadable, we won't use it. Please give either
Brian or I the slide sometime between the Monday diffserv session
and the start of the Tuesday diffserv session (I'll be there a
couple of minutes early). If you don't have a slide, give me a
note with your name and the draft name on it at the beginning
of the session so we know there's someone present to answer questions.
We'll skip the draft if there's no note and no slide. The WG
co-chairs will tend to give more time to drafts that got some
positive discussion on the mailing list.

	Kathie

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



From diffserv-admin@ietf.org  Wed Nov  3 12:13:26 1999
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 MAA05109
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:13:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28437;
	Wed, 3 Nov 1999 11:47:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28385
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:47:01 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23741
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:47:01 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA19060
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 08:46:50 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 08:46:43 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 12:46:22 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Steve Deering" <deering@cisco.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 11:46:34 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIECLCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <v04210102b446096657bc@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: diffserv-admin@ietf.org
> [mailto:diffserv-admin@ietf.org]On Behalf
> Of Steve Deering
>
> The subject line of this thread caught my eye...

I wonder why, Steve.

> At 9:25 AM -0600 11/3/99, Brian E Carpenter wrote:
> >Multicast in the IP model is conceptually
> multipoint-to-multipoint.
>
> No, the IP multicast model is that of point-to-multipoint
> datagrams.
> Higher layers can build multipoint-to-multipoint
> applications out of
> the IP pt-to-mpt service.

I had misread what Brian wrote. Indeed, mpt-mpt as allowed in IP
multicast is pt-mpt from any number of sources to the same set of
group members. This is in part _why_ the problem is not trivial,
when QoS is entered into the equation. It's why I brought up UNI 4.0
to begin with. Because now the problem is more similar to what ATM
has to do than it is to your RFC 1112. In the sense that _merging_
flows become as much a problem here as they are for the virtual
circuit-switched ATM. But the solution in diffserv must be entirely
different, I think.

> >I know this makes it harder, but it's not a theoretical
> >consideration: a 10-party conference needs to be provisioned
> >on a multipoint basis.
>
> Why is the diff-serv list discussing provisioning for a
> single conference
> or per-flow resource reservations???

Not necessarily on a per flow basis.

> Diff-serv for IP multicast ought to work just like
> diff-serv for IP
> unicast: the sender sets some bits to indicate how it
> would like the
> packet to be handled; any router along the delivery tree
> may modify
> those bits to indicate how the packet ought be handled
> from that point
> onward, along one or more descendent branches of the
> delivery tree.
> Along any branch of the delivery tree, the packet
> undergoes the same
> diff-serv handling as would a unicast packet along that
> branch.  The
> only significant difference is that, compared to
> replicated unicasts,
> less provisioning is needed for multicast  What's the
> problem, exactly?

I, for one, agree with you, which is why I have problems with
suggestions that the service provider has to set aside assets for
the multicast tree. Just like unicast, diffserv has to show that
merging multicast flows can have QoS provided only on the basis of
per hop behavior.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 12:13:42 1999
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 MAA05236
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:13:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28002;
	Wed, 3 Nov 1999 11:34:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27972
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:34:51 -0500 (EST)
Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19295
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:34:53 -0500 (EST)
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00234
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:34:53 -0500 (EST)
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA00227
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:34:53 -0500 (EST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2448.0)
	id <VP73MGLM>; Wed, 3 Nov 1999 11:34:53 -0500
Message-ID: <2E12619580C0D1118C6400805F9F4C95BABB1D@nj7460exch001u.ho.lucent.com>
From: "Chu, Thomas P (Thomas)" <tpchu@lucent.com>
To: "'diffserv@ietf.org'" <diffserv@ietf.org>
Date: Wed, 3 Nov 1999 11:34:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
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.ietf.org>
X-BeenThere: diffserv@ietf.org

confirm 369674

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



From diffserv-admin@ietf.org  Wed Nov  3 12:17:28 1999
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 MAA06906
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:17:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27816;
	Wed, 3 Nov 1999 11:31:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA27788
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:31:18 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18090
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:31:20 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 11:23:18 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V8655DCM; Wed, 3 Nov 1999 11:23:11 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLB09; Wed, 3 Nov 1999 11:23:12 -0500
Message-ID: <38206170.F0F2B48D@nortel.com>
Date: Wed, 03 Nov 1999 11:23:12 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote:

> Graham,
>
> Multicast in the IP model is conceptually multipoint-to-multipoint.
> I know this makes it harder, but it's not a theoretical
> consideration: a 10-party conference needs to be provisioned
> on a multipoint basis. (Unless you want to be bound to the
> concept of a conference bar for ever.)

Yes, each source can specify the service level it requires in multipoint to
multipoint communications. It's mp2mp at L3, but the service level need not
be specified as mp2mp service, that makes the problem easier for diffserv, i
believe. The drafts i posted have examples of mp2mp,  pls let me know if you
have concerns or if it's not clear.

> My personal take is that trying to solve this problem exclusively
> at the network layer is a doomed enterprise; it is only the
> applications that actually understand the provisioning requirement.

Agree. For eg sources may specify/negotiate the service level required.

> We will touch briefly on this in the second session next week,
> to judge the sense of the WG whether we can tackle this.

I think it's feasible, but we'll see what the WG says.

cheers,
cyl


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



From diffserv-admin@ietf.org  Wed Nov  3 12:33:01 1999
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 MAA12920
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:33:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28433;
	Wed, 3 Nov 1999 11:47:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28380
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:47:01 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23742
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:47:02 -0500 (EST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.11509-0@bells.cs.ucl.ac.uk>; Wed, 3 Nov 1999 16:45:18 +0000
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
In-reply-to: Your message of "Wed, 03 Nov 1999 09:25:59 CST." <38205407.BC63F31@hursley.ibm.com>
Date: Wed, 03 Nov 1999 16:45:15 +0000
Message-ID: <10605.941647515@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


In message <38205407.BC63F31@hursley.ibm.com>, Brian E Carpenter typed:

 >>Multicast in the IP model is conceptually multipoint-to-multipoint.
 >>I know this makes it harder, but it's not a theoretical
 >>consideration: a 10-party conference needs to be provisioned
 >>on a multipoint basis. (Unless you want to be bound to the
 >>concept of a conference bar for ever.)
 
 >>My personal take is that trying to solve this problem exclusively
 >>at the network layer is a doomed enterprise; it is only the
 >>applications that actually understand the provisioning requirement.

 >>We will touch briefly on this in the second session next week,
 >>to judge the sense of the WG whether we can tackle this.

   Brian

in steve deering's model (see his response)
each sender is independant - however, in many applications, senders
are not, and you require a level of traffic engineering, or
reservation, or whatever, for each source in a multicast session for
it to be useable - but you don't need the same level - but you might
not want to indulge in an n*(n-1)/2 negotiation before knowing....
the models of rsvp present what were thouht to be a common subset of
useful patterns of multiple source....(well, a very small subset) coz
we havnt seen much multicpast deployment, we havent really got an idea
for multiple source sessions beyond some of those models - games might
be quite diffeent from conferences - as steve says, single source is
easy - it all just works..

other evidence its hard:
given we haev no real clue how to do multi-source multicast congestion
control, having only just an inkling how to do single source multicast
congestion control (e..g pt-multipoint), how could we really haev a 
plusible claim to know how to provision a reservation 

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



From diffserv-admin@ietf.org  Wed Nov  3 12:37:11 1999
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 MAA14446
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:37:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA29474;
	Wed, 3 Nov 1999 12:08:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA29446
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 12:08:01 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02416
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 12:08:02 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA04421
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 09:08:01 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 09:07:58 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 13:07:35 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 12:07:47 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMCECMCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <3820667C.8F19515C@nortel.com>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: diffserv-admin@ietf.org
> [mailto:diffserv-admin@ietf.org]On Behalf
> Of Cheng-Yin Lee

Steve Deering wrote:

> > The only significant difference is that, compared to
> replicated unicasts,
> > less provisioning is needed for multicast  What's the
> problem, exactly?
>
> How to provision for multicast groups?

You don't, Cheng-Yin. In a diffserv environment, in principle,
you're not supposed to provision anything after you've installed the
network hardware. Unless you want to make multicast dramatically
different from unicast in the diffserv network. Which sort of
defeats the purpose, I think.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 12:40:25 1999
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 MAA15781
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 12:40:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28757;
	Wed, 3 Nov 1999 11:53:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28726
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 11:53:40 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26558
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:53:42 -0500 (EST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 11:44:49 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5BQYDC1; Wed, 3 Nov 1999 11:44:44 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLCC8; Wed, 3 Nov 1999 11:44:43 -0500
Message-ID: <3820667C.8F19515C@nortel.com>
Date: Wed, 03 Nov 1999 11:44:44 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> Why is the diff-serv list discussing provisioning for a single conference
> or per-flow resource reservations???

i think we are discussing aggregated resource reservations.

> Diff-serv for IP multicast ought to work just like diff-serv for IP
> unicast: the sender sets some bits to indicate how it would like the
> packet to be handled;

yes.

> any router along the delivery tree may modify
> those bits to indicate how the packet ought be handled from that point
> onward, along one or more descendent branches of the delivery tree.

i'm not clear  how this will work in a diffserv network. Could you elaborate
pls?

> Along any branch of the delivery tree, the packet undergoes the same
> diff-serv handling as would a unicast packet along that branch.

Agree.

> The only significant difference is that, compared to replicated unicasts,
> less provisioning is needed for multicast  What's the problem, exactly?

How to provision for multicast groups?

cheers,
cyl



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



From diffserv-admin@ietf.org  Wed Nov  3 13:05:34 1999
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 NAA26277
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:05:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00067;
	Wed, 3 Nov 1999 12:30:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00027
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 12:29:57 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11512
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 12:29:58 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA21799; Wed, 3 Nov 1999 09:29:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210109b4461d4c05df@[10.19.130.188]>
In-Reply-To: <3820667C.8F19515C@nortel.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>
Date: Wed, 3 Nov 1999 09:29:18 -0800
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 11:44 AM -0500 11/3/99, Cheng-Yin Lee wrote:
>i think we are discussing aggregated resource reservations.

Cyl,

What I saw was Brian's comment about "a 10-party conference needs to be
provisioned on a multipoint basis", and Albert drawing analogies to
ATM pt-to-mpt flows, which made me think you were talking about
per-(micro)flow reservations.  That's what I get for dropping in
without sufficient context.

By then why are you discussing "reservations" at all?  Isn't that the
domain of int-serv?


> > any router along the delivery tree may modify
> > those bits to indicate how the packet ought be handled from that point
> > onward, along one or more descendent branches of the delivery tree.
>
>i'm not clear  how this will work in a diffserv network. Could you elaborate
>pls?

I would elaborate if I understood what you think the problem is.  You
provision resources in your networks for certain amounts of traffic
labelled in certain ways.  Multicast packets carrying such labels consume
the corresponding resources along the branches of their delivery trees,
and are accounted for, just like unicast packets that happen to flow along
the same paths.

>How to provision for multicast groups?

You don't provision for multicast groups.  You provision for aggregate
flows of traffic, to a potential multiplicity of destinations, both
unicast and multicast.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 13:19:37 1999
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 NAA02784
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:19:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA01126;
	Wed, 3 Nov 1999 12:49:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA01095
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 12:49:39 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19469
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 12:49:41 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA45194; Wed, 3 Nov 1999 17:49:09 GMT
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA33354; Wed, 3 Nov 1999 17:49:05 GMT
Message-ID: <3820758A.C628E022@hursley.ibm.com>
Date: Wed, 03 Nov 1999 11:48:58 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Siamack Ayandeh <sayandeh@ascend.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] agenda
References: <381F819B.CCE1187@cisco.com> <38205287.9DF90975@ascend.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Siamack,

With eight drafts to consider in 60 minutes, we don't think that 
works, so we plan to run the discussion as Kathie indicated. 

   Brian

Siamack Ayandeh wrote:
> 
> Re the session on Tuesday. Would it be possible for the authors to
> put up a one slide "outline", and lead the question period.
> 
> Regards, Siamack
> 
> Kathleen Nichols wrote:
> 
> > Monday, 11/15, 19:30-22:00
> >
> > (10) Agenda bashing and status......Brian Carpenter and Kathie Nichols
> >
> > Working Group Drafts
> > --------------------
> >
> > (15) Tterminology: diffserv-ietf-new-terms-01.txt ... Dan Grossman
> > (15) PHB IDs: diffserv-ietf-phbid-00.txt ... Scott Brim
> >
> > (30) Model: draft-ietf-diffserv-model-01.txt ... Bernet, Blake, Smith
> > (30) MIB: draft-ietf-diffserv-mib-01.txt ... Baker et al,
> > (NOTE: the MIB draft appears not to have made the cut-off but must be
> > discussed. A version is apparently available at:
> > ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt,
> > if you're not from Cisco. Fred will presumably make a version
> > available for those of us from Cisco)
> > (10) additional joint discussion of Model and MIB, if needed
> >
> > (20) Diffserv and Tunnels: draft-black-diffserv-tunnels-00.txt ... Black
> > (NOTE: despite the name, this draft was solicited by the WG, but
> > David chose to submit it as individual since he didn't have time to
> > get the review of other WG members. We expect the next version to
> > be title as a WG draft.)
> >
> > (15) Future work, looking for drafts ... Brian and Kathie
> >
> > Tuesday, 11/16, 13:00-14:00
> >
> > Unsolicited drafts
> > ------------------
> >
> > If business on the WG drafts was concluded on Monday, we
> > can discuss the unsolicited drafts. This session will be
> > run by the WG co-chairs who will be looking for the "sense"
> > of the WG on the following drafts. Authors of the drafts
> > are encouraged to show up in case some response or clarification
> > is needed, but should not expect to have any presentation time.
> >
> >    draft-kanada-diffserv-qospifmib-00.txt
> >    draft-bonaventure-diffserv-rashaper-01.txt
> >    draft-bless-diffserv-lbe-phb-00.txt
> >    draft-bless-diffserv-multicast-00.txt
> >    draft-fang-diffserv-tc-tswtcm-00.txt
> >    draft-fu-diffserv-security-00.txt
> >    draft-lin-diffserv-gtc-01.txt
> >    draft-nadas-diffserv-experience-01.txt
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Wed Nov  3 13:24:48 1999
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 NAA05506
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:24:47 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00935;
	Wed, 3 Nov 1999 12:46:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA00904
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 12:46:03 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17887
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 12:46:07 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 12:42:06 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V8655RAT; Wed, 3 Nov 1999 12:42:03 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLC2F; Wed, 3 Nov 1999 12:42:04 -0500
Message-ID: <382073EC.38156C1@nortel.com>
Date: Wed, 03 Nov 1999 12:42:04 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com> <v04210109b4461d4c05df@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> What I saw was Brian's comment about "a 10-party conference needs to be
> provisioned on a multipoint basis", and Albert drawing analogies to
> ATM pt-to-mpt flows, which made me think you were talking about
> per-(micro)flow reservations.  That's what I get for dropping in
> without sufficient context.
>
> By then why are you discussing "reservations" at all?  Isn't that the
> domain of int-serv?

I think i have a terminology problem here.

> > > any router along the delivery tree may modify
> > > those bits to indicate how the packet ought be handled from that point
> > > onward, along one or more descendent branches of the delivery tree.
> >
> >i'm not clear  how this will work in a diffserv network. Could you elaborate
> >pls?
>
> I would elaborate if I understood what you think the problem is.  You
> provision resources in your networks for certain amounts of traffic
> labelled in certain ways.  Multicast packets carrying such labels consume
> the corresponding resources along the branches of their delivery trees,
> and are accounted for, just like unicast packets that happen to flow along
> the same paths.

Yes i understand your explanation above.
But i 'm not sure of modifying bits in interior /core routers.

>
> >How to provision for multicast groups?
>
> You don't provision for multicast groups.  You provision for aggregate
> flows of traffic, to a potential multiplicity of destinations, both
> unicast and multicast.

Yes, i see the misunderstanding, i meant provisioning for multicast groups for
aggregated traffic which was what i think we are discussing. Actually the
proposal i posted allows provisioning for aggregate flows of traffic, but
leverages multicast tree construction to do this.

cheers,
cyl



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



From diffserv-admin@ietf.org  Wed Nov  3 13:32:16 1999
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 NAA09064
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:32:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA01816;
	Wed, 3 Nov 1999 13:00:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA01737
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 13:00:40 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24029
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 13:00:43 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA22658 for <diffserv@ietf.org>; Wed, 3 Nov 1999 18:00:07 GMT
Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA36518 for <diffserv@ietf.org>; Wed, 3 Nov 1999 18:00:01 GMT
Message-ID: <38207817.FB0DA437@hursley.ibm.com>
Date: Wed, 03 Nov 1999 11:59:51 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <10605.941647515@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Exactly. As long as you don't think about provisioning,
senders are independent - my point that Steve reacted to is
that in a group with multiple senders, as soon as you add QOS
provisioning to the mix, you have to consider mp2mp provisioning
for the diffserv traffic class concerned.

The reason we are discussing it here is that it is a real
problem; however one very plausible option IMHO is to spin off
a separate activity or kick the problem over to the TE working
group, rather than follow up in diffserv. As Steve correctly
observed, it doesn't affect the atomic forwarding behaviour
of diffserv routers.

  Brian

Jon Crowcroft wrote:
> 
> In message <38205407.BC63F31@hursley.ibm.com>, Brian E Carpenter typed:
> 
>  >>Multicast in the IP model is conceptually multipoint-to-multipoint.
>  >>I know this makes it harder, but it's not a theoretical
>  >>consideration: a 10-party conference needs to be provisioned
>  >>on a multipoint basis. (Unless you want to be bound to the
>  >>concept of a conference bar for ever.)
> 
>  >>My personal take is that trying to solve this problem exclusively
>  >>at the network layer is a doomed enterprise; it is only the
>  >>applications that actually understand the provisioning requirement.
> 
>  >>We will touch briefly on this in the second session next week,
>  >>to judge the sense of the WG whether we can tackle this.
> 
>    Brian
> 
> in steve deering's model (see his response)
> each sender is independant - however, in many applications, senders
> are not, and you require a level of traffic engineering, or
> reservation, or whatever, for each source in a multicast session for
> it to be useable - but you don't need the same level - but you might
> not want to indulge in an n*(n-1)/2 negotiation before knowing....
> the models of rsvp present what were thouht to be a common subset of
> useful patterns of multiple source....(well, a very small subset) coz
> we havnt seen much multicpast deployment, we havent really got an idea
> for multiple source sessions beyond some of those models - games might
> be quite diffeent from conferences - as steve says, single source is
> easy - it all just works..
> 
> other evidence its hard:
> given we haev no real clue how to do multi-source multicast congestion
> control, having only just an inkling how to do single source multicast
> congestion control (e..g pt-multipoint), how could we really haev a
> plusible claim to know how to provision a reservation

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: brian@icair.org

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



From diffserv-admin@ietf.org  Wed Nov  3 13:32:19 1999
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 NAA09089
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:32:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA02101;
	Wed, 3 Nov 1999 13:04:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA02067
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 13:04:01 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25589
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 13:04:05 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA25069; Wed, 3 Nov 1999 10:01:14 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v0421010bb44625c7049c@[10.19.130.188]>
In-Reply-To: <382073EC.38156C1@nortel.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>
 <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com>
Date: Wed, 3 Nov 1999 10:01:20 -0800
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 12:42 PM -0500 11/3/99, Cheng-Yin Lee wrote:
>But i 'm not sure of modifying bits in interior /core routers.

It was my understanding (is it still correct?) that routers were allowed
to modify the diff-serv (DHCP) bits in transit, particularly routers at
administrative boundaries.  Thus, multicast packets traveling along a
delivery branch that crossed such a router would undergo DHCP modification
just like unicast packets.  That's all I was referring to.

>Yes, i see the misunderstanding, i meant provisioning for multicast groups for
>aggregated traffic which was what i think we are discussing. Actually the
>proposal i posted allows provisioning for aggregate flows of traffic, but
>leverages multicast tree construction to do this.

Hmm.  It sounds wrong to me to call out multicast as something that needs
separate provisioning.  I would expect a model in which you measure/predict
the amount of traffic flowing along a given link or path (regardless of
whether it's unicast or multicast), and provision the link accordingly.
Adjusting the provisioning in response to fine-grain activities such as
building multicast delivery branches in response to join/leave requests
doesn't sound like it fits within the goals of diff-serv.  Int-serv, yes.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 13:46:05 1999
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 NAA16018
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 13:46:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA02962;
	Wed, 3 Nov 1999 13:19:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA02931
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 13:19:52 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02962
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 13:19:55 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA27012; Wed, 3 Nov 1999 10:19:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v0421010cb4462aa529a7@[10.19.130.188]>
In-Reply-To: <38207817.FB0DA437@hursley.ibm.com>
References: <10605.941647515@cs.ucl.ac.uk>
 <38207817.FB0DA437@hursley.ibm.com>
Date: Wed, 3 Nov 1999 10:19:18 -0800
To: Brian E Carpenter <brian@hursley.ibm.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 11:59 AM -0600 11/3/99, Brian E Carpenter wrote:
>Exactly. As long as you don't think about provisioning,
>senders are independent - my point that Steve reacted to is
>that in a group with multiple senders, as soon as you add QOS
>provisioning to the mix, you have to consider mp2mp provisioning
>for the diffserv traffic class concerned.

Brian,

This is completely orthogonal to "multicast-ness".  The same issues
arise with multi-party applications that only use unicast.

I thought the philosophy behind diff-serv was to get beyond the level of
caring about the individual traffic patterns of particular applications
or particular instances of applications, and just deal with the
resulting aggregate traffic flows that occur as a result of all the
applications doing whatever they do.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 14:29:40 1999
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 OAA09887
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:29:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA04791;
	Wed, 3 Nov 1999 14:01:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA04759
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:01:15 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23482
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:01:19 -0500 (EST)
Message-Id: <199911031901.OAA23482@ietf.org>
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 14:00:58 -0500
Received: from zcard00f.ca.nortel.com ([47.208.128.127]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V86558C5; Wed, 3 Nov 1999 14:00:55 -0500
Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VA6M2GBL; Wed, 3 Nov 1999 14:00:57 -0500
Date: Wed, 3 Nov 1999 14:00:40 -0500 (EST)
From: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Reply-To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Subject: re:[Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
To: deering@cisco.com
cc: brian@hursley.ibm.com, diffserv@ietf.org
X-Mailer: Rosa 2.1.1 HP-UXB.10.20
X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-ID: <Rosa.HP-UXB.10..2.1.1.991103140040.6846C@zcarh014>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA04760
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit



Steve Deering wrote:

>
>Why is the diff-serv list discussing provisioning for a single
>conference or per-flow resource reservations???
>

The Diffserv WG doesn't have resource provisioning as
part of its mandate. However, since this issue is important
for Diffserv deployment, it might be worth some consideration.

On another note,  the resource provisioning issue for multipoint
to multipoint seems more difficult than single pt to multi-point.
Hence the initial focus on single point to multi-point.

>Diff-serv for IP multicast ought to work just like diff-serv for IP
>unicast: the sender sets some bits to indicate how it would like the
>packet to be handled; any router along the delivery tree may modify
>those bits to indicate how the packet ought be handled from that point
>onward, along one or more descendent branches of the delivery tree.
>Along any branch of the delivery tree, the packet undergoes the same
>diff-serv handling as would a unicast packet along that branch.  The
>only significant difference is that, compared to replicated unicasts,
>less provisioning is needed for multicast  What's the problem, exactly?

>

Not quite sure that Diffserv for unicast can work exactly the same way
as Diffserv for multicast. In unicast, the ingress nodes can
police/shape based on destination IP addresses amongst other things. In
multicast this type of policing will merely restrict/remark the traffic
load. Once the traffic is within the domain, it can replicate at will
depending on  receiver joins. As of now, the Diffserv network mechanisms

have no way of restricting the number of receivers of a multicast tree.
Depending on the number of branches and breadth of the multicast tree
within a domain, the tree will require varied resources thus making the 
traffic engineering problem more difficult. If all the receivers were
static and never changed then maybe this is isn't a problem. 

Since a key part of multicast is the dynamic nature of receiver
subscription some form of admission control appears important - or at
least more  important than in the unicast case.

Regards
Nabil Seddigh
nseddigh@nortelnetworks.com


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



From diffserv-admin@ietf.org  Wed Nov  3 14:29:49 1999
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 OAA09981
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:29:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA04041;
	Wed, 3 Nov 1999 13:46:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA04011
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 13:46:49 -0500 (EST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16332
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 13:46:46 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Wed, 3 Nov 1999 12:45:49 -0600
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V865559K; Wed, 3 Nov 1999 13:45:45 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLCPH; Wed, 3 Nov 1999 13:45:45 -0500
Message-ID: <382082DA.639F1FCB@nortel.com>
Date: Wed, 03 Nov 1999 13:45:46 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com> <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com> <v0421010bb44625c7049c@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> >Yes, i see the misunderstanding, i meant provisioning for multicast groups for
> >aggregated traffic which was what i think we are discussing. Actually the
> >proposal i posted allows provisioning for aggregate flows of traffic, but
> >leverages multicast tree construction to do this.
>
> Hmm.  It sounds wrong to me to call out multicast as something that needs
> separate provisioning.  I would expect a model in which you measure/predict
> the amount of traffic flowing along a given link or path (regardless of
> whether it's unicast or multicast),

Multicast groups can be dynamic, it seems difficult to predict the traffic. Could
someone provide a pointer to such models for multicast traffic?

> and provision the link accordingly.
> Adjusting the provisioning in response to fine-grain activities such as
> building multicast delivery branches in response to join/leave requests
> doesn't sound like it fits within the goals of diff-serv.  Int-serv, yes.

The  resource provisioning proposed is quite generic, in the sense that it allows
provisioning from the granulariy of per group to traffic aggregates. If resources
have been allocated for a traffic aggregate at a node, no further resource
allocation is needed, ie there are no 'fine-grain activities'  for the group.

The same mechanism can be used for traffic aggregates provisioning and int-serv
fine-grain kind of reservations.

cheers,
cyl


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



From diffserv-admin@ietf.org  Wed Nov  3 14:30:00 1999
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 OAA10077
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:29:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA04617;
	Wed, 3 Nov 1999 13:59:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA04586
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 13:59:49 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22828
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 13:59:53 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA01830; Wed, 3 Nov 1999 10:59:08 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v0421010eb44634456d23@[10.19.130.188]>
In-Reply-To: <382082DA.639F1FCB@nortel.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>
 <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com>
 <v0421010bb44625c7049c@[10.19.130.188]> <382082DA.639F1FCB@nortel.com>
Date: Wed, 3 Nov 1999 10:59:14 -0800
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 1:45 PM -0500 11/3/99, Cheng-Yin Lee wrote:
>Multicast groups can be dynamic, it seems difficult to predict the traffic. 

cyl,

The set of destinations to which unicast packets are sent can also be,
and usually is, dynamic.  What's so special about multicast in this regard?

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 14:30:35 1999
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 OAA10457
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:30:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA04902;
	Wed, 3 Nov 1999 14:03:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA04871
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:03:44 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24574
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:03:47 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA19756
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 11:03:46 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 11:03:35 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 15:03:10 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Steve Deering" <deering@cisco.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 14:03:22 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMAECOCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <v0421010cb4462aa529a7@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> At 11:59 AM -0600 11/3/99, Brian E Carpenter wrote:
> >Exactly. As long as you don't think about provisioning,
> >senders are independent - my point that Steve reacted to is
> >that in a group with multiple senders, as soon as you add QOS
> >provisioning to the mix, you have to consider mp2mp provisioning
> >for the diffserv traffic class concerned.
>
> Brian,
>
> This is completely orthogonal to "multicast-ness".  The
> same issues
> arise with multi-party applications that only use unicast.

Yes, except that in a pt-mpt multicast scenario, the sender cannot
readjust his QoS desirements for every new flow. In unicast, a
sender's request might simply be rejected by the network, and the
sender can request something less demanding. In a pt-mpt multicast,
the sender is already engaged.

In  mpt-mpt scenario, merging flows become a problem that doesn't
exist with unicast. If you remember our discussions in the ION
working group (MARS, EARTH, MOON, and URANUS), you might recall that
merging flows over the NBMA network caused people to propose sending
frames, to save on VC requirements.

Well, we're up against the same fundamental problem, I think.
Proposing use of frames over NBMA was simply a way of bypassing the
QoS guarantee that the underlying NBMA net supported. It wasn't a
solution, it was a shortcut.

In support of multicast, diffserv would presumably still want to
make the QoS "guarantees," so now we have that nagging problem back
again.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 14:34:39 1999
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 OAA12441
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:34:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05078;
	Wed, 3 Nov 1999 14:07:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05044
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:07:46 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26348
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:07:36 -0500 (EST)
Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA12785;
	Wed, 3 Nov 1999 11:07:03 -0800 (PST)
Message-ID: <38208B21.E731C33A@cisco.com>
Date: Wed, 03 Nov 1999 11:21:05 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
	 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
	 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>
	 <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com> <v0421010bb44625c7049c@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Steve Deering wrote:
> 
> At 12:42 PM -0500 11/3/99, Cheng-Yin Lee wrote:
> >But i 'm not sure of modifying bits in interior /core routers.
> 
> It was my understanding (is it still correct?) that routers were allowed
> to modify the diff-serv (DHCP) bits in transit, particularly routers at
> administrative boundaries.  Thus, multicast packets traveling along a
> delivery branch that crossed such a router would undergo DHCP modification
> just like unicast packets.  That's all I was referring to.

This is correct except its DSCP for Differentiated Services
CodePoint. DHCP is something different. In fact, when Van
gave Lixia and I his white board talk about diffserv QoS with
multicast, he made a reasonable argument for using different
markings where the multicast flow branched. (However, this
was two years ago, so that particular contention may have
undergone "drift".)

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



From diffserv-admin@ietf.org  Wed Nov  3 14:42:26 1999
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 OAA15346
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:42:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05451;
	Wed, 3 Nov 1999 14:13:21 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05416
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:13:16 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00523
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:13:19 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA03369; Wed, 3 Nov 1999 11:12:43 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210110b4463965a1cf@[10.19.130.188]>
In-Reply-To: <38208B21.E731C33A@cisco.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>	
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>	
 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>	
 <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com>
 <v0421010bb44625c7049c@[10.19.130.188]> <38208B21.E731C33A@cisco.com>
Date: Wed, 3 Nov 1999 11:12:49 -0800
To: Kathleen Nichols <kmn@cisco.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 11:21 AM -0800 11/3/99, Kathleen Nichols wrote:
>Steve Deering wrote:
> > to modify the diff-serv (DHCP) bits in transit, particularly routers at
>
>This is correct except its DSCP for Differentiated Services
>CodePoint. DHCP is something different.

Yes, that's what I meant.  I suffer from distypia.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 14:42:42 1999
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 OAA15444
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 14:42:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05506;
	Wed, 3 Nov 1999 14:13:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA05481
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:13:34 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00669
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:13:37 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 14:10:38 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V86559TL; Wed, 3 Nov 1999 14:10:34 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLCSW; Wed, 3 Nov 1999 14:10:35 -0500
Message-ID: <382088AC.36F0B0C3@nortel.com>
Date: Wed, 03 Nov 1999 14:10:36 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com> <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com> <v0421010bb44625c7049c@[10.19.130.188]> <382082DA.639F1FCB@nortel.com> <v0421010eb44634456d23@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> The set of destinations to which unicast packets are sent can also be,
> and usually is, dynamic.  What's so special about multicast in this regard?

Do we have a model that we can use to do provisioning for multicast traffic?

thanks,
cyl


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



From diffserv-admin@ietf.org  Wed Nov  3 15:16:58 1999
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 PAA02251
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 15:16:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06650;
	Wed, 3 Nov 1999 14:42:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06628
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:42:07 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15257
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:42:09 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA06623; Wed, 3 Nov 1999 11:41:23 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210111b4463e7fd4d9@[10.19.130.188]>
In-Reply-To: <382088AC.36F0B0C3@nortel.com>
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com>
 <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com>
 <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com>
 <v0421010bb44625c7049c@[10.19.130.188]> <382082DA.639F1FCB@nortel.com>
 <v0421010eb44634456d23@[10.19.130.188]> <382088AC.36F0B0C3@nortel.com>
Date: Wed, 3 Nov 1999 11:41:29 -0800
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: "diffserv@ietf.org" <diffserv@ietf.org>
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 2:10 PM -0500 11/3/99, Cheng-Yin Lee wrote:
>Do we have a model that we can use to do provisioning for multicast traffic?

Do you have a model that you can use to do provisioning for unicast traffic?

If the usefulness of diff-serv hinges on whether or not you have such a
model, what happens when the unicast traffic patterns change radically
because of some new killer app that takes over the net?

No, I am not aware of any good models for multicast traffic, presumably
because there is very little multicast traffic today from which to
construct such a model.  That means that you can mostly ignore multicast
for provisioning today, and if/when there's a lot more multicast traffic,
people will be able to start to build models for it.  But a sensible
network operator won't wait for such a model to be developed, but rather
will monitor actual traffic (unicast and multicast) and add capacity as
necessary to keep the customers satisfied (or at least enough to keep
them from defecting to the competition).

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 15:33:14 1999
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 PAA09644
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 15:33:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA07294;
	Wed, 3 Nov 1999 14:59:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA07187
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:59:48 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23572
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:59:51 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA08313; Wed, 3 Nov 1999 11:57:50 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210112b44640a5565a@[10.19.130.188]>
In-Reply-To: <199911031901.OAA23482@ietf.org>
References: <199911031901.OAA23482@ietf.org>
Date: Wed, 3 Nov 1999 11:57:56 -0800
To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: re:[Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 2:00 PM -0500 11/3/99, Nabil Seddigh wrote:
>On another note,  the resource provisioning issue for multipoint
>to multipoint seems more difficult than single pt to multi-point.
>Hence the initial focus on single point to multi-point.

Well, I still don't see it.  The resource provisioning issue is coping
with the total flux of traffic flowing through the network, which is
the sum of unicast and multicast traffic of various DSCP values from
multiple sources to multiple destinations.

>Not quite sure that Diffserv for unicast can work exactly the same way
>as Diffserv for multicast. In unicast, the ingress nodes can
>police/shape based on destination IP addresses amongst other things. In
>multicast this type of policing will merely restrict/remark the traffic
>load. Once the traffic is within the domain, it can replicate at will
>depending on  receiver joins.

And unicast traffic can go along links and/or out of egress points
that you didn't anticipate, unless you also disable the routing protocol's
ability to route around failures.  Either you need interior policing or
(better in my opinion) you limit the "guaranteed" traffic to a small
fraction of your capacity on any link, so you can meet your guarantees
no matter which path(s) the traffic takes.

>Depending on the number of branches and breadth of the multicast tree
>within a domain, the tree will require varied resources thus making the 
>traffic engineering problem more difficult. If all the receivers were
>static and never changed then maybe this is isn't a problem. 

The receivers of unicast traffic are not static either, so you adjust your
traffic engineering/provisioning in response to long-term, observed trends.
The same ought to be true of multicast.

>Since a key part of multicast is the dynamic nature of receiver
>subscription some form of admission control appears important - or at
>least more  important than in the unicast case.

I disagree.  Unicast also has "dynamic receiver subscription", in that
sources dynamically change who they send packets to.  It's just that,
in the case of unicast, it's not revealed to the network like it is
with multicast.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 15:33:26 1999
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 PAA09743
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 15:33:26 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06881;
	Wed, 3 Nov 1999 14:49:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA06850
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 14:49:26 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18162
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 14:49:24 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 14:48:22 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V8656FCP; Wed, 3 Nov 1999 14:48:19 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLCW9; Wed, 3 Nov 1999 14:48:20 -0500
Message-ID: <38209185.DD8BA15@nortel.com>
Date: Wed, 03 Nov 1999 14:48:21 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]> <3820667C.8F19515C@nortel.com> <v04210109b4461d4c05df@[10.19.130.188]> <382073EC.38156C1@nortel.com> <v0421010bb44625c7049c@[10.19.130.188]> <382082DA.639F1FCB@nortel.com> <v0421010eb44634456d23@[10.19.130.188]> <382088AC.36F0B0C3@nortel.com> <v04210111b4463e7fd4d9@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Deering wrote:

> No, I am not aware of any good models for multicast traffic, presumably
> because there is very little multicast traffic today from which to
> construct such a model.  That means that you can mostly ignore multicast
> for provisioning today,

:-), i rest my case then.

cheers,
cyl



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



From diffserv-admin@ietf.org  Wed Nov  3 15:44:13 1999
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 PAA14539
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 15:44:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA07653;
	Wed, 3 Nov 1999 15:07:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA07610
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 15:07:40 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27631
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:07:43 -0500 (EST)
Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA09177; Wed, 3 Nov 1999 12:05:45 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210114b446451b62f9@[10.19.130.188]>
In-Reply-To: <NDBBIBKKCLEFDFDGHCNMAECOCAAA.albert.e.manfredi@boeing.com>
References: <NDBBIBKKCLEFDFDGHCNMAECOCAAA.albert.e.manfredi@boeing.com>
Date: Wed, 3 Nov 1999 12:05:41 -0800
To: "Albert Manfredi" <albert.e.manfredi@boeing.com>
From: Steve Deering <deering@cisco.com>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: <diffserv@ietf.org>
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 2:03 PM -0500 11/3/99, Albert Manfredi wrote:
>Yes, except that in a pt-mpt multicast scenario, the sender cannot
>readjust his QoS desirements for every new flow. In unicast, a
>sender's request might simply be rejected by the network, and the
>sender can request something less demanding. In a pt-mpt multicast,
>the sender is already engaged.

What's this got to do with diff-serv?  The only "rejection" that a
diff-serv network can perform on a unicast flow is to drop its packets.
(Per-flow signalling is in the int-serv domain, right?)  The same
mechanism works fine for multicast flows, too.

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 16:21:35 1999
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 QAA00387
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 16:21:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08987;
	Wed, 3 Nov 1999 15:44:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA08950
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 15:44:13 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14568
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:44:16 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA15339
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 12:44:15 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 12:44:02 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 16:43:40 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Steve Deering" <deering@cisco.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 15:43:52 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMOEDACAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <v04210114b446451b62f9@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Steve Deering wrote:
>
> At 2:03 PM -0500 11/3/99, Albert Manfredi wrote:
> >Yes, except that in a pt-mpt multicast scenario, the
> sender cannot
> >readjust his QoS desirements for every new flow. In unicast, a
> >sender's request might simply be rejected by the network, and the
> >sender can request something less demanding. In a pt-mpt
> multicast,
> >the sender is already engaged.
>
> What's this got to do with diff-serv?  The only "rejection" that a
> diff-serv network can perform on a unicast flow is to
> drop its packets.
> (Per-flow signalling is in the int-serv domain, right?)  The same
> mechanism works fine for multicast flows, too.

Diffserv does provide for access control, though: SLS (used to be
SLA). So a source can be rejected if it requests too much in setting
up its service contract with the diffserv net. This is before any
issues might arise with non-conforming traffic. At least, that's how
I read RFC 2475, Para. 2.3.

Now, take the pt-mpt (i.e. simple) multicast environment. A source
is sending its mcast traffic to one diffserv net as its first branch
or the tree, perhaps as part of a traffic aggregate. A sink
somewhere else in the world does IGMP join, which will cause a new
branch to have to be grafted onto the mcast tree, a branch which the
ISP might need to send through a different diffserv network from the
original one(s). Are the new diffserv nets capable of granting this
new flow?

I claim that this is a different scenario from the unicast scenario,
because in the unicast scenario, any failure in coming to an
agreeable contract occurs only at time 0. In this case, it can occur
at any time. No?

Mpt-mpt, as discussed previously, has the
merging-flows-while-meeting-QoS problems that we've seen before. As
I thought was the case in ION, the fundamental problem is not the
inadequacy of virtual circuits as much as it is the difficulty in
merging flows while maintaining QoS in each one.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 16:37:46 1999
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 QAA06682
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 16:37:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09740;
	Wed, 3 Nov 1999 16:08:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA09709
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 16:08:23 -0500 (EST)
Received: from Monitor.firstcom.cl (mail.firstcom.cl [200.27.20.89])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25503
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 16:08:22 -0500 (EST)
Received: from hbreinbauer ([200.27.20.65]) by Monitor.firstcom.cl
          (Post.Office MTA v3.5 release 216 ID# 0-51810U1000L100S0V35)
          with SMTP id cl for <diffserv@ietf.org>;
          Wed, 3 Nov 1999 17:08:19 -0500
Reply-To: <hernan.breinbauer@firstcom.cl>
From: hbreinbauer@firstcom.cl (Hernan Breinbauer)
To: <diffserv@ietf.org>
Date: Wed, 3 Nov 1999 18:09:56 -0400
Message-ID: <000401bf2648$2a725520$520911ac@hbreinbauer.firstcom.cl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Content-Transfer-Encoding: 7bit
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

unsubcribe


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



From diffserv-admin@ietf.org  Wed Nov  3 17:26:37 1999
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 RAA27210
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 17:26:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA11195;
	Wed, 3 Nov 1999 16:50:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA11160
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 16:49:59 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12471
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 16:50:01 -0500 (EST)
Message-Id: <199911032150.QAA12471@ietf.org>
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 16:49:44 -0500
Received: from zcard00f.ca.nortel.com ([47.208.128.127]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5BQZC70; Wed, 3 Nov 1999 16:49:44 -0500
Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VA6M2HD6; Wed, 3 Nov 1999 16:49:44 -0500
Date: Wed, 3 Nov 1999 16:49:36 -0500 (EST)
From: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Reply-To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Subject: re:[Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
To: Steve Deering <deering@cisco.com>
cc: diffserv@ietf.org
X-Mailer: Rosa 2.1.1 HP-UXB.10.20
X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-ID: <Rosa.HP-UXB.10..2.1.1.991103164936.6846I@zcarh014>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA11161
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

In message "Problems with IP-Multicast in DiffServ-Networks", 
Steve Deering writes:

>At 2:00 PM -0500 11/3/99, Nabil Seddigh wrote:
>>On another note,  the resource provisioning issue for multipoint
>>to multipoint seems more difficult than single pt to multi-point.
>>Hence the initial focus on single point to multi-point.
>
>Well, I still don't see it.  The resource provisioning issue is coping
>with the total flux of traffic flowing through the network, which is
>the sum of unicast and multicast traffic of various DSCP values from
>multiple sources to multiple destinations.

Let me see if I can rephrase what I see as the problem.
Diffserv policing mechanisms (remark/drop) serve two purposes:

1. Assist with charging from a provider's perspective. Presumably,
   the charging is based on some notion of the resource level
   utilized by the traffic stream -either based on BW, PHB etc.

   In multicast, depending on the # of receivers & breadth of the
   tree, more resources will be utilized. Traditional 
   classifiers (source IP/dest IP etc) cannot tell us whether 
   a multicast tree causes traffic to go through 1,2, 15 or 100
   routers in a particular provider's domain.  Are we assuming
   that providers will charge the sender the same amount
   of money regardless of whether the tree goes through
   5 routers or 100? 

   The draft mentioned by cyl provides an example of 
   network mechanisms that enable SLAs to either
   charge extra based on # of receivers or to limit
   the # of receivers.

2. Limit (or remark) the amount of traffic injected into a 
   network by sources thus shielding traffic of other users.

   In the unicast model, you can limit the amount of traffic 
   injected by a particular host based on some type of 
   classifier. In the multicast case, you can certainly limit
   the amount of traffic injected into the network. However,
   how will you limit or at least put some bounds on how
   many routers the traffic visits? With current Diffserv 
   mechanisms (edge policing/marking and simple core 
   treatment based on DSCP),  it seems as though the 
   provider is unable to prevent this. 

BTW, maybe a separate PHB or set of PHBs might be required to shield
unicast from multicast - for those providers who are concerned with the
problem. Those who are comfortable carrying multicast and unicast
together can lump them to be served by the same PHB. Others can use the

separate PHB(s). I have seen a number of presentations by people looking

to  create services. In quite a few of these, the AF classes are already

spoken for and so, despite what was mentioned some time back on the
Diffserv list, a separate PHB might be required.

-
Regards
Nabil Seddigh
nseddigh@nortelnetworks.com



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



From diffserv-admin@ietf.org  Wed Nov  3 18:04:14 1999
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 SAA12176
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 18:04:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12447;
	Wed, 3 Nov 1999 17:40:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12418
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 17:40:27 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02961
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 17:40:28 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA25582; Wed, 3 Nov 1999 14:39:46 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210119b446667039c9@[10.19.130.188]>
In-Reply-To: <199911032149.NAA14446@kickme.cisco.com>
References: <199911032149.NAA14446@kickme.cisco.com>
Date: Wed, 3 Nov 1999 14:39:52 -0800
To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: re:[Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Cc: diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 4:49 PM -0500 11/3/99, Nabil Seddigh wrote:
>   In multicast, depending on the # of receivers & breadth of the
>   tree, more resources will be utilized. Traditional 
>   classifiers (source IP/dest IP etc) cannot tell us whether 
>   a multicast tree causes traffic to go through 1,2, 15 or 100
>   routers in a particular provider's domain.  Are we assuming
>   that providers will charge the sender the same amount
>   of money regardless of whether the tree goes through
>   5 routers or 100?

If you want to charge based on fan-out, count the packets at the egress
routers, not the ingress routers.

However, I thought another point of diff-serv (as opposed to int-serv) was
to avoid all the overhead of book-keeping individual packets or flows,
to not fall into the "90% of the cost of the network is the billing system"
quagmire.

>   In the unicast model, you can limit the amount of traffic 
>   injected by a particular host based on some type of 
>   classifier. In the multicast case, you can certainly limit
>   the amount of traffic injected into the network. However,
>   how will you limit or at least put some bounds on how
>   many routers the traffic visits?

Assuming the multicast routing protocol is loop-free, there's clearly
a bound on the number of routers any multicast packet will visit.
I guess you think that's not a useful bound.

Anyway, it sounds like at least some people are trying to morph diff-serv
into something quite different from the original goals.  That means
my context is too out-of-date for me to be barging in here, so please
excuse the interruption and carry on....

Steve


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



From diffserv-admin@ietf.org  Wed Nov  3 18:15:17 1999
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 SAA15905
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 18:15:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12617;
	Wed, 3 Nov 1999 17:47:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12588
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 17:47:39 -0500 (EST)
Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05844
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 17:47:41 -0500 (EST)
Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43])
	by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id RAA23576;
	Wed, 3 Nov 1999 17:46:35 -0500 (EST)
Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0)
	id <WGA61ZHB>; Wed, 3 Nov 1999 17:57:10 -0500
Message-ID: <729D927EF825D311961000E029101CCC258DE8@mxclsa>
From: Black_David@emc.com
To: albert.e.manfredi@boeing.com, deering@cisco.com
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network
	s
Date: Wed, 3 Nov 1999 17:46:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> Diffserv does provide for access control, though: SLS (used to be
> SLA). So a source can be rejected if it requests too much in setting
> up its service contract with the diffserv net. This is before any
> issues might arise with non-conforming traffic. At least, that's how
> I read RFC 2475, Para. 2.3.
> 
> Now, take the pt-mpt (i.e. simple) multicast environment. A source
> is sending its mcast traffic to one diffserv net as its first branch
> or the tree, perhaps as part of a traffic aggregate. A sink
> somewhere else in the world does IGMP join, which will cause a new
> branch to have to be grafted onto the mcast tree, a branch which the
> ISP might need to send through a different diffserv network from the
> original one(s). Are the new diffserv nets capable of granting this
> new flow?
>
> I claim that this is a different scenario from the unicast scenario,
> because in the unicast scenario, any failure in coming to an
> agreeable contract occurs only at time 0. In this case, it can occur
> at any time. No?

No, not as envisioned by that RFC.  The SLS reflects a long-lived contract
covering a large number of flows.  It would not in general be 
negotiated on the fly, although it (or more likely parts of it) could be.
See draft-ietf-issll-diffserv-rsvp-03.txt for one approach to this sort of
dynamic negotiation, but with a caveat: that draft describes one of
a number of ways that diffserv can be used/deployed, and there will
be diffserv deployments that don't support the mechanisms described there.
I would expect that most unicast flows in current networks will be
covered under prenegotiated SLSs, not ones that are set up as part of
deciding whether to initiate the flow.  If such a flow exceeds the
prenegotiated SLS, then the excess traffic is handled as specified
by the SLS.

--David (one of the RFC's authors)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com
---------------------------------------------------


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



From diffserv-admin@ietf.org  Wed Nov  3 18:15:54 1999
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 SAA16146
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 18:15:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12758;
	Wed, 3 Nov 1999 17:52:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA12729
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 17:52:48 -0500 (EST)
Received: from gwu.ericy.com (gwu.ericy.com [208.196.3.162])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07542
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 17:52:49 -0500 (EST)
Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100])
	by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id QAA24080
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 16:51:32 -0600 (CST)
Received: from louiexm.axa100.am.ericsson.se ([138.85.181.247])
	by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id QAA01880
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 16:51:32 -0600 (CST)
Received: by louiexm.axa100.am.ericsson.se with Internet Mail Service (5.5.2448.0)
	id <V6VP92BZ>; Wed, 3 Nov 1999 16:47:27 -0600
Message-ID: <178C92B1B3DCD211AAE90090273C1A423D4255@louiexm.axa100.am.ericsson.se>
From: Vishwanath Edavayyanaamath
	 <vishu.edavayyanaamath@axa100.am.ericsson.se>
To: diffserv@ietf.org
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network
	s
Date: Wed, 3 Nov 1999 16:47:25 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF264D.660EC226"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF264D.660EC226
Content-Type: text/plain;
	charset="iso-8859-1"



1. Assist with charging from a provider's perspective. Presumably,
   the charging is based on some notion of the resource level
   utilized by the traffic stream -either based on BW, PHB etc.

   In multicast, depending on the # of receivers & breadth of the
   tree, more resources will be utilized. Traditional 
   classifiers (source IP/dest IP etc) cannot tell us whether 
   a multicast tree causes traffic to go through 1,2, 15 or 100
   routers in a particular provider's domain.  Are we assuming
   that providers will charge the sender the same amount
   of money regardless of whether the tree goes through
   5 routers or 100? 

   The draft mentioned by cyl provides an example of 
   network mechanisms that enable SLAs to either
   charge extra based on # of receivers or to limit
   the # of receivers.

-----------
I am not sure of how exactly provider can charge multicast, as Host
memberships are dynamically changing in the multicast tree. Did read couple
of papers long back, but then Multicast as in MBone works through tunnels
(Unicast). Is native multicast a complete reality as of now?

-vishwa

------_=_NextPart_001_01BF264D.660EC226
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: [Diffserv] Re: Problems with IP-Multicast in =
DiffServ-Networks</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>1. Assist with charging from a provider's =
perspective. Presumably,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the charging is based on some notion of =
the resource level</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; utilized by the traffic stream -either =
based on BW, PHB etc.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; In multicast, depending on the # of =
receivers &amp; breadth of the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; tree, more resources will be utilized. =
Traditional </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; classifiers (source IP/dest IP etc) =
cannot tell us whether </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; a multicast tree causes traffic to go =
through 1,2, 15 or 100</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; routers in a particular provider's =
domain.&nbsp; Are we assuming</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; that providers will charge the sender =
the same amount</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; of money regardless of whether the tree =
goes through</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; 5 routers or 100? </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; The draft mentioned by cyl provides an =
example of </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; network mechanisms that enable SLAs to =
either</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; charge extra based on # of receivers or =
to limit</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the # of receivers.</FONT>
</P>

<P><FONT SIZE=3D2>-----------</FONT>
<BR><FONT SIZE=3D2>I am not sure of how exactly provider can charge =
multicast, as Host memberships are dynamically changing in the =
multicast tree. Did read couple of papers long back, but then Multicast =
as in MBone works through tunnels (Unicast). Is native multicast a =
complete reality as of now?</FONT></P>

<P><FONT SIZE=3D2>-vishwa</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF264D.660EC226--

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



From diffserv-admin@ietf.org  Wed Nov  3 18:40:22 1999
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 SAA25810
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 18:40:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13158;
	Wed, 3 Nov 1999 18:07:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13123
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 18:07:40 -0500 (EST)
Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13421
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 18:07:41 -0500 (EST)
Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP);
          Wed, 3 Nov 1999 23:06:52 +0000
Date: Wed, 3 Nov 1999 23:07:28 +0000 (GMT)
From: Lloyd Wood <L.Wood@surrey.ac.uk>
X-Sender: eep1lw@petra.ee.surrey.ac.uk
Reply-To: Lloyd Wood <L.Wood@surrey.ac.uk>
To: Steve Deering <deering@cisco.com>
cc: Cheng-Yin Lee <leecy@nortelnetworks.com>,
        "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
In-Reply-To: <v04210111b4463e7fd4d9@[10.19.130.188]>
Message-ID: <Pine.SOL.4.02.9911032256420.12882-100000@petra.ee.surrey.ac.uk>
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

On Wed, 3 Nov 1999, Steve Deering wrote:

> At 2:10 PM -0500 11/3/99, Cheng-Yin Lee wrote:
> >Do we have a model that we can use to do provisioning for multicast traffic?
> 
> Do you have a model that you can use to do provisioning for unicast
> traffic?

Well, if you do, and you're switching over from *applications doing
exactly the same thing using unicast*, the Chuang-Sirbu scaling law
may be of use.

[1] Chuang, J. and Sirbu, M. "Pricing Multicast Communications: A  
    Cost-Based Approach", presented at the Internet Society INET'98
    Conference, Geneva, Switzerland, July 21-24 1998.
    http://www.cs.cmu.edu/afs/andrew/usr9/sirbu/www/pubs.html
    http://www.isoc.org/inet98/proceedings/6d/6d_2.htm
 
[2] Philips, Shenker and Tangmunarunkit, Scaling of Multicast Trees:
    "Comments on the Chuang-Sirbu scaling law", SIGCOMM '99.
    http://www.acm.org/sigcomm/sigcomm99/papers/session2-1.html

Unfortunately, as far as large-scale unicast stuff goes, Pointcast
deployment was never successful enough to reach the unicast/multicast
changeover point (probably because it _was_ unicast), and I'm not
aware of anyone e.g. running comparisons between unicast and multicast
between Squid caches or engineering a multicast NFS version 4 to
really test this law out in real networks with real provisioning.

L.

oh, you wanted a general model that would cope with paradigm shifts?
Sorry, fresh out.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>





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



From diffserv-admin@ietf.org  Wed Nov  3 18:53:17 1999
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 SAA00370
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 18:53:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13573;
	Wed, 3 Nov 1999 18:19:27 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA13543
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 18:19:22 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17622
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 18:19:24 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA09740
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 15:19:21 -0800 (PST)
Received: from [199.191.48.146] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 3 Nov 1999 15:19:05 -0800
Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 3 Nov 1999 19:18:29 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: <Black_David@emc.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
Date: Wed, 3 Nov 1999 18:18:46 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMEEDFCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <729D927EF825D311961000E029101CCC258DE8@mxclsa>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

David Black wrote:

> To: albert.e.manfredi@boeing.com; deering@cisco.com
> Cc: diffserv@ietf.org
> Subject: RE: [Diffserv] Re: Problems with IP-Multicast in
> DiffServ-Networks
>
>
> > Diffserv does provide for access control, though: SLS
> (used to be
> > SLA). ... At least, that's how
> > I read RFC 2475, Para. 2.3.

> No, not as envisioned by that RFC.  The SLS reflects a
> long-lived contract
> covering a large number of flows.

Well, if diffserv does not provide for real-time acceptance or
rejection of new flows at the ingress points, based on local
congestion criteria, then I am with Steve Deering on this issue.
What makes multicast different? Just that there _might_ be several
branches in the diffserv net?

The charges should probably be much as Steve described. That is, a
charge on packets per egress and maybe also packets at the source.

I don't think there is any consensus yet to morph diffserv into
something else in support of multicast?

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov  3 19:47:51 1999
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 TAA16647
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 19:47:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA15775;
	Wed, 3 Nov 1999 19:23:21 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA15744
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 19:23:17 -0500 (EST)
Received: from emcmail.lss.emc.com (emcmail.lss.emc.com [168.159.48.78])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09604
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 19:23:20 -0500 (EST)
Received: from mxbh1.isus.emc.com (42s3043.isus.emc.com [168.159.211.43])
	by emcmail.lss.emc.com (8.9.3/8.9.3) with ESMTP id TAA11108;
	Wed, 3 Nov 1999 19:22:15 -0500 (EST)
Received: by 42s3043.isus.emc.com with Internet Mail Service (5.5.2448.0)
	id <WGA61ZRQ>; Wed, 3 Nov 1999 19:32:50 -0500
Message-ID: <729D927EF825D311961000E029101CCC258DE9@mxclsa>
From: Black_David@emc.com
To: albert.e.manfredi@boeing.com, Black_David@emc.com
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network
	s
Date: Wed, 3 Nov 1999 19:18:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> Well, if diffserv does not provide for real-time acceptance or
> rejection of new flows at the ingress points, based on local
> congestion criteria, then I am with Steve Deering on this issue.
> What makes multicast different? Just that there _might_ be several
> branches in the diffserv net?

I agree with the conclusion but want to point out that diffserv is
neutral on the underlying issue.  The architecture neither requires
nor forbids "real-time acceptance ..." -- in fact,  the traffic conditioning
mechanisms that are currently under discussion and the available
DSCP values are clearly sufficient to support this in some fashion.

The issll draft I referred to earlier describes one approach to supporting
this sort of functionality, but there are other approaches that have
been discussed on this list and/or written up as drafts.  In all cases,
they are extensions to the basic diffserv architecture and functionality;
some care was taken in RFC 2474 to make this sort of experimentation
possible.  

--David 

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com
---------------------------------------------------


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



From diffserv-admin@ietf.org  Wed Nov  3 20:25:03 1999
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 UAA01484
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 20:25:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA16944;
	Wed, 3 Nov 1999 19:48:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA16913
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 19:48:32 -0500 (EST)
Received: from george.arc.nasa.gov (george.arc.nasa.gov [128.102.194.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16866
	for <Diffserv@ietf.org>; Wed, 3 Nov 1999 19:48:34 -0500 (EST)
Received: from localhost by george.arc.nasa.gov (8.9.3/8.9.3) with SMTP id QAA15088
	for <Diffserv@ietf.org>; Wed, 3 Nov 1999 16:48:32 -0800 (PST)
X-Authentication-Warning: george.arc.nasa.gov: lamaster owned process doing -bs
Date: Wed, 3 Nov 1999 16:48:32 -0800 (PST)
From: Hugh LaMaster <lamaster@nren.nasa.gov>
X-Sender: lamaster@george.arc.nasa.gov
To: Diffserv List <Diffserv@ietf.org>
Subject: RE: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network s
Message-ID: <Pine.SOL.3.96.991103161304.12696A-100000@george.arc.nasa.gov>
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.ietf.org>
X-BeenThere: diffserv@ietf.org


On Wed, 3 Nov 1999, Vishwanath Edavayyanaamath wrote:

Apologies for reviving an old argument here, but, 
apparently the following perspective is missing.

> 1. Assist with charging from a provider's perspective. Presumably,
>    the charging is based on some notion of the resource level
>    utilized by the traffic stream -either based on BW, PHB etc.
>    
>    In multicast, depending on the # of receivers & breadth of the
>    tree, more resources will be utilized. Traditional
>    classifiers (source IP/dest IP etc) cannot tell us whether
>    a multicast tree causes traffic to go through 1,2, 15 or 100
>    routers in a particular provider's domain.  Are we assuming 
>    that providers will charge the sender the same amount
>    of money regardless of whether the tree goes through 
>    5 routers or 100?

In my view, at the most basic level (in an advertising-free world),
most traffic, unicast or multicast, benefits the receiver, rather
than the sender.  Or, since often they work together, both.

[Aside: and, you can still argue the same w/ advertising,
although it is uglier: e.g., I choose to pay the price of downloading
advertising junk from Altavista, say, because I consider the value
of using their search-engine to outweigh the cost.  The exception,
of course, is the SPAM I will receive for sending or posting anything
anywhere, sigh...]

For example, if I download linux from a linux ftp server
somewhere, I'm getting the benefit: nice of the site to provide
adequate bandwidth to me, the public.

And, I'm already paying an ISP for the service on the receiving side.  
So, just like multicast, which is *explicitly* receiver-driven, unicast 
is implicitly receiver-driven.

You should consider this when you consider multicast fan-out,
or, how customers should pay for priority service.


>    The draft mentioned by cyl provides an example of
>    network mechanisms that enable SLAs to either
>    charge extra based on # of receivers or to limit
>    the # of receivers.

Personally, I think this is a bad idea, not only because
multicast is receiver-driven, but also, because it is
too complicated.  Steve Deering already said this, but,
I have to repeat it: don't try to turn the Internet into
the telephone system by paying for every flow/packet/cell/etc.:
the cost of billing to that level vastly outweighs the cost
of forwarding IP packets.  

In my view, to date, no one has demonstrated any (economic) 
benefit to charging for anything other than the size of
the pipe.

Diffserv was supposed to make a modest improvement on that to allow
a sender (and, implicitly, the real customer, the receiver), 
to *prioritize* traffic within a network, and, hand over the
simple priority information to a downstream provider.
That *relative* prioritization will be possible for a downstream
provider to honor.

Please don't try turn it into a telephone-like billing system.
I don't want to pay 20 cents/minute for a 1 cent/minute call,
just so that I can be billed for it.  I'd rather pay a flat rate.



> I am not sure of how exactly provider can charge multicast, as Host
> memberships are dynamically changing in the multicast tree. Did read couple
> of papers long back, but then Multicast as in MBone works through tunnels  
> (Unicast). Is native multicast a complete reality as of now?

Yes.  Native multicast is fairly widely deployed in backbones today,
although, few consumer-level ISPs support it, so, consumer-oriented
content is lacking.  But, adequate technology is there, and high-bandwidth
flows are not uncommon, and, many universities are connected.  The main
technological hurdles left have to do with scalability to very large numbers
of senders.  (Scalability to *any* number of receivers is already present).


Additions/corrections/refutations welcome.



--
 Hugh LaMaster, M/S 233-21,    Email: lamaster@nren.nasa.gov
 NASA Ames Research Center     Or:    lamaster@nas.nasa.gov
 Moffett Field, CA 94035-1000  Or:    lamaster@george.arc.nasa.gov
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.


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



From diffserv-admin@ietf.org  Wed Nov  3 23:43:32 1999
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 XAA20511
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 23:43:32 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA21173;
	Wed, 3 Nov 1999 22:49:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA21141
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 22:49:45 -0500 (EST)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27352
	for <diffserv@ietf.org>; Wed, 3 Nov 1999 22:49:46 -0500 (EST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Wed, 3 Nov 1999 21:47:23 -0600
Received: from zcard008.ca.nortel.com ([47.127.82.62]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5BQZVC6; Wed, 3 Nov 1999 22:47:22 -0500
Received: from nortelnetworks.com (zmerh02h.ca.nortel.com [47.169.33.100]) 
          by zcard008.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VCZCZ2H2; Wed, 3 Nov 1999 22:47:20 -0500
Message-ID: <382102EF.8D01645B@nortelnetworks.com>
Date: Wed, 03 Nov 1999 22:52:15 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en,zh-CN,zh,zh-TW,af
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: Black_David <Black_David@emc.com>, diffserv <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMEEDFCAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:
>
> The charges should probably be much as Steve described. That is, a
> charge on packets per egress and maybe also packets at the source.
Do you mean counting pkts?

> I don't think there is any consensus yet to morph diffserv into
> something else in support of multicast?
May i know what exactly is being morphed?

thanks,
cyl

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



From diffserv-admin@ietf.org  Wed Nov  3 23:57:54 1999
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 XAA26415
	for <diffserv-archive@ietf.org>; Wed, 3 Nov 1999 23:57:54 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA21958;
	Wed, 3 Nov 1999 23:25:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA21925
	for <diffserv@optimus.ietf.org>; Wed, 3 Nov 1999 23:25:06 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12112
	for <Diffserv@ietf.org>; Wed, 3 Nov 1999 23:25:07 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Wed, 3 Nov 1999 23:24:53 -0500
Received: from zcard008.ca.nortel.com ([47.127.82.62]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V8657V0M; Wed, 3 Nov 1999 23:24:52 -0500
Received: from nortelnetworks.com (zmerh02h.ca.nortel.com [47.169.33.100]) 
          by zcard008.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VCZCZ2HP; Wed, 3 Nov 1999 23:24:51 -0500
Message-ID: <38210BB3.360BCCCD@nortelnetworks.com>
Date: Wed, 03 Nov 1999 23:29:39 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en,zh-CN,zh,zh-TW,af
MIME-Version: 1.0
To: Hugh LaMaster <lamaster@nren.nasa.gov>
CC: Diffserv List <Diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network s
References: <Pine.SOL.3.96.991103161304.12696A-100000@george.arc.nasa.gov>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hugh LaMaster wrote:
> >    The draft mentioned by cyl provides an example of
> >    network mechanisms that enable SLAs to either
> >    charge extra based on # of receivers or to limit
> >    the # of receivers.
> 
> Personally, I think this is a bad idea, not only because
> multicast is receiver-driven, but also, because it is
> too complicated.  Steve Deering already said this, but,
> I have to repeat it: don't try to turn the Internet into
> the telephone system by paying for every flow/packet/cell/etc.:
> the cost of billing to that level vastly outweighs the cost
> of forwarding IP packets.
Hmmm, i thought Steve Deering suggested counting pkts.
(BTW, we don't count pkts in our proposal, so i'm very puzzled by your
comment).

> Diffserv was supposed to make a modest improvement on that to allow
> a sender (and, implicitly, the real customer, the receiver),
> to *prioritize* traffic within a network, and, hand over the
> simple priority information to a downstream provider.
> That *relative* prioritization will be possible for a downstream
> provider to honor.
Yes... the sender set the TOS in pkts.

> Please don't try turn it into a telephone-like billing system.
> I don't want to pay 20 cents/minute for a 1 cent/minute call,
> just so that I can be billed for it.  I'd rather pay a flat rate.
I don't follow this, how is it being turned into a telephone-like
billing system?

cheers,
cyl

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



From diffserv-admin@ietf.org  Thu Nov  4 00:40:45 1999
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 AAA14502
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 00:40:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA23006;
	Thu, 4 Nov 1999 00:06:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA22974
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 00:06:43 -0500 (EST)
Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00017
	for <Diffserv@ietf.org>; Thu, 4 Nov 1999 00:06:47 -0500 (EST)
Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA26219; Wed, 3 Nov 1999 21:05:38 -0800 (PST)
Mime-Version: 1.0
X-Sender: deering@postoffice
Message-Id: <v04210125b446c02f55a2@[10.19.130.188]>
In-Reply-To: <38210BB3.360BCCCD@nortelnetworks.com>
References: <Pine.SOL.3.96.991103161304.12696A-100000@george.arc.nasa.gov>
 <38210BB3.360BCCCD@nortelnetworks.com>
Date: Wed, 3 Nov 1999 21:05:45 -0800
To: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
From: Steve Deering <deering@cisco.com>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Network
 s
Cc: Hugh LaMaster <lamaster@nren.nasa.gov>, Diffserv List <Diffserv@ietf.org>
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 11:29 PM -0500 11/3/99, Cheng-Yin Lee wrote:
>Hmmm, i thought Steve Deering suggested counting pkts.

No, that was someone else.  I just said how to do it better, and then
went on to question the wisdom of doing it at all.

>(BTW, we don't count pkts in our proposal, so i'm very puzzled by your
>comment).

I think it was in response to messages from people other than you.

Steve


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



From diffserv-admin@ietf.org  Thu Nov  4 02:37:20 1999
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 CAA17411
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 02:37:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA01489;
	Thu, 4 Nov 1999 02:03:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA01380
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 02:03:38 -0500 (EST)
Received: from netdns.netas.com.tr ([195.142.217.254])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27983
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 02:03:29 -0500 (EST)
Received: from mimoza.netas.com.tr ([193.140.191.48]) by netdns.netas.com.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id VVZ263R2; Thu, 4 Nov 1999 09:05:41 +0200
Received: from rnd.netas.com.tr (bahrio@bisthy30 [193.140.184.148]) by mimoza.netas.com.tr with ESMTP (8.8.6 (PHNE_17135)/8.7.1) id JAA17442 for <diffserv@ietf.org>; Thu, 4 Nov 1999 09:02:48 +0200 (EET)
Message-ID: <38212F96.FB25810F@rnd.netas.com.tr>
Date: Thu, 04 Nov 1999 09:02:47 +0200
From: Bahri Okuroglu <bahrio@netdns.netas.com.tr>
X-Mailer: Mozilla 4.06 [en] (X11; I; HP-UX B.10.20 9000/712)
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: multipart/alternative; boundary="------------441C7BC8D024FFE575CEE470"
Subject: [Diffserv] Service class of ACK packets
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


--------------441C7BC8D024FFE575CEE470
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi diffservers,

Are the ACK packets of any flow (AF, EF or BE) always served as BE? Is
there any work on making the ACK of EF flow served as EF also?

regards,

--

__________________________________________________________
Bahri OKUROGLU

Software Design Engineer                     Netas R&D RT6
mailto:bahrio@rnd.netas.com.tr     http://www.netas.com.tr
mailto:bahrio@nortelnetworks.com   mailto:bahrio@yahoo.com
Netas   Alemdag Cad.   Umraniye 81244      ISTANBUL TURKEY
__________________________________________________________



--------------441C7BC8D024FFE575CEE470
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Hi diffservers,
<P>Are the ACK packets of any flow (AF, EF or BE) always served as BE?
Is there any work on making the ACK&nbsp;of EF&nbsp;flow served as EF also?
<P>regards,
<PRE>--&nbsp;

__________________________________________________________
Bahri OKUROGLU

Software Design Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Netas R&amp;D RT6
<A HREF="mailto:bahrio@rnd.netas.com.tr">mailto:bahrio@rnd.netas.com.tr</A>&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.netas.com.tr">http://www.netas.com.tr</A>
<A HREF="mailto:bahrio@nortelnetworks.com">mailto:bahrio@nortelnetworks.com</A>&nbsp;&nbsp; <A HREF="mailto:bahrio@yahoo.com">mailto:bahrio@yahoo.com</A>
Netas&nbsp;&nbsp; Alemdag Cad.&nbsp;&nbsp; Umraniye 81244&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ISTANBUL TURKEY
__________________________________________________________</PRE>
&nbsp;</HTML>

--------------441C7BC8D024FFE575CEE470--


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



From diffserv-admin@ietf.org  Thu Nov  4 03:29:45 1999
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 DAA08019
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 03:29:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA02979;
	Thu, 4 Nov 1999 03:00:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA02938
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 03:00:15 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26763
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 03:00:18 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id HAA20320; Thu, 4 Nov 1999 07:59:45 GMT
Received: from hursley.ibm.com ([9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA24058; Wed, 3 Nov 1999 19:49:46 GMT
Message-ID: <382091AE.CADD99B5@hursley.ibm.com>
Date: Wed, 03 Nov 1999 13:49:02 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <10605.941647515@cs.ucl.ac.uk>
	 <38207817.FB0DA437@hursley.ibm.com> <v0421010cb4462aa529a7@[10.19.130.188]>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve,

Steve Deering wrote:
> 
> At 11:59 AM -0600 11/3/99, Brian E Carpenter wrote:
> >Exactly. As long as you don't think about provisioning,
> >senders are independent - my point that Steve reacted to is
> >that in a group with multiple senders, as soon as you add QOS
> >provisioning to the mix, you have to consider mp2mp provisioning
> >for the diffserv traffic class concerned.
> 
> Brian,
> 
> This is completely orthogonal to "multicast-ness".  The same issues
> arise with multi-party applications that only use unicast.

It's orthogonal to "Deering multicast-ness" indeed. Which is exactly
why I said a while back that I don't believe we can solve this
purely at the network layer.
 
> I thought the philosophy behind diff-serv was to get beyond the level of
> caring about the individual traffic patterns of particular applications
> or particular instances of applications, and just deal with the
> resulting aggregate traffic flows that occur as a result of all the
> applications doing whatever they do.

Absolutely. However I have to dispute the assertion made by Bert
Manfredi:

> > How to provision for multicast groups?
> 
> You don't, Cheng-Yin. In a diffserv environment, in principle,
> you're not supposed to provision anything after you've installed the
> network hardware.

There is no "supposed" about it and lots of people believe we will
evolve towards dynamic provisioning of diffserv aggregates. That is
where multi-sender applications make the provisioning computation
hard.

   Brian

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



From diffserv-admin@ietf.org  Thu Nov  4 03:39:30 1999
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 DAA11870
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 03:39:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA03268;
	Thu, 4 Nov 1999 03:07:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA03235
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 03:06:58 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00107
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 03:07:00 -0500 (EST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.03007-0@bells.cs.ucl.ac.uk>; Thu, 4 Nov 1999 08:06:50 +0000
To: Lloyd Wood <L.Wood@surrey.ac.uk>
cc: Steve Deering <deering@cisco.com>,
        Cheng-Yin Lee <leecy@nortelnetworks.com>,
        "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
In-reply-to: Your message of "Wed, 03 Nov 1999 23:07:28 GMT." <Pine.SOL.4.02.9911032256420.12882-100000@petra.ee.surrey.ac.uk>
Date: Thu, 04 Nov 1999 08:06:47 +0000
Message-ID: <6151.941702807@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


i think the issue is not one obciously of cost - the problem of
costing multicast sessions with multiple senders is that one needs to
know the value of the quality of content as a funciton of the overal
lifetime of the set of receivers and the set of senders-  for a
business phone conference call, this is easy - it realyl is onyl worth having 
if ALL the members are able to send and receive for the whole lifetime
of the session, so its a fairly simple thing to provision for whether
for diffserv or int-serv - either tyou haev video, and you need n
pt-multipoint
calls worth, or audio with 1 speaker and you need 1 senders and n
receivers worth or audio with a mixer and n unicast senders 
and 1 1-n multipoiint

but for other applications usage (e.g. ones with heterogeiy - some
media only go to some people, layered media, a lot of early
leavers and late join, etc etc) its not obvious at all how to provision
(or price).....not at all...there's nothing in the literature that i
know of gives an answer- all the work on advance reservations only
works for known groups...

In message <Pine.SOL.4.02.9911032256420.12882-100000@petra.ee.surrey.ac.uk>, Ll
oyd Wood typed:

 >>On Wed, 3 Nov 1999, Steve Deering wrote:
 >>
 >>> At 2:10 PM -0500 11/3/99, Cheng-Yin Lee wrote:
 >>> >Do we have a model that we can use to do provisioning for multicast traffic?
 >>> 
 >>> Do you have a model that you can use to do provisioning for unicast
 >>> traffic?
 >>
 >>Well, if you do, and you're switching over from *applications doing
 >>exactly the same thing using unicast*, the Chuang-Sirbu scaling law
 >>may be of use.
 >>
 >>[1] Chuang, J. and Sirbu, M. "Pricing Multicast Communications: A  
 >>    Cost-Based Approach", presented at the Internet Society INET'98
 >>    Conference, Geneva, Switzerland, July 21-24 1998.
 >>    http://www.cs.cmu.edu/afs/andrew/usr9/sirbu/www/pubs.html
 >>    http://www.isoc.org/inet98/proceedings/6d/6d_2.htm
 >> 
 >>[2] Philips, Shenker and Tangmunarunkit, Scaling of Multicast Trees:
 >>    "Comments on the Chuang-Sirbu scaling law", SIGCOMM '99.
 >>    http://www.acm.org/sigcomm/sigcomm99/papers/session2-1.html
 >>
 >>Unfortunately, as far as large-scale unicast stuff goes, Pointcast
 >>deployment was never successful enough to reach the unicast/multicast
 >>changeover point (probably because it _was_ unicast), and I'm not
 >>aware of anyone e.g. running comparisons between unicast and multicast
 >>between Squid caches or engineering a multicast NFS version 4 to
 >>really test this law out in real networks with real provisioning.
 >>
 >>L.
 >>
 >>oh, you wanted a general model that would cope with paradigm shifts?
 >>Sorry, fresh out.
 >>
 >><L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
 >>
 >>
 >>
 >>
 >>
 >>_______________________________________________
 >>diffserv mailing list
 >>diffserv@ietf.org
 >>http://www.ietf.org/mailman/listinfo/diffserv
 >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
 >>

 cheers

   jon


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



From diffserv-admin@ietf.org  Thu Nov  4 03:52:52 1999
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 DAA15687
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 03:52:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA03507;
	Thu, 4 Nov 1999 03:14:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA03466
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 03:13:55 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02397
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 03:13:58 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11jI1t-0003Se-00; Thu, 04 Nov 1999 09:13:57 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id JAA15860;
	Thu, 4 Nov 1999 09:13:52 +0100 (MET)
Message-Id: <199911040813.JAA15860@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Graham Cope <G.Cope@ftel.co.uk>
cc: Albert Manfredi <albert.e.manfredi@boeing.com>,
        Cheng-Yin Lee <leecy@nortelnetworks.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks 
In-reply-to: Your message of "Wed, 03 Nov 1999 10:01:51 GMT."
             <3820080F.49C9FB1F@ftel.co.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Thu, 04 Nov 1999 09:11:57 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

> With RSVP you may have shared reservations 'merging' downstream towards
> the reveiver. Suppose that a number of such flows merge within a
> diffserv domain. It is not entirely obvious to me what the SLS would
> look like, and indeed how you would provision internal resources. For
> instance, an SLS could be 'another flow may join a session at this
> ingress, provided that there is already another flow using resources
> from another ingress'. Pt-to-pt distinct reservations are much nicer!

Indeed, as mentioned in our draft draft-bless-diffserv-multicast-00.txt, 
within a DiffServ environment there is no easy way to provide shared 
style reservations, because currently it cannot be assured that only one 
sender is actually sending data while all other senders are quiet.
In IntServ you don't have those problems, because every router can check
for the amount of currently used resources within a shared reservation style 
mc group.

-- 
Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097



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



From diffserv-admin@ietf.org  Thu Nov  4 05:05:06 1999
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 FAA06192
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 05:05:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA05439;
	Thu, 4 Nov 1999 04:31:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA05408
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 04:31:06 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26463
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 04:31:11 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11jJEd-00077Q-00; Thu, 04 Nov 1999 10:31:11 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA16849;
	Thu, 4 Nov 1999 10:31:11 +0100 (MET)
Message-ID: <38215414.C40441AE@telematik.informatik.uni-karlsruhe.de>
Date: Thu, 04 Nov 1999 10:38:28 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: Institut =?iso-8859-1?Q?f=FCr?= Telematik - 
	=?iso-8859-1?Q?Universit=E4t?= Karlsruhe
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Cheng-Yin Lee <leecy@nortelnetworks.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com> <381F43A2.3F6085C7@nortel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hello,

Cheng-Yin Lee wrote:

> Albert Manfredi wrote:
> Should we attempt to provide different QOS on a tree or should we use
> other alternatives e.g layer encoding?  The latter seems easier.

I agree. In my opinion, there should be used different mc-groups for
different service classes. There could also be used layered encoding, if the
data supports this, e.g. mpeg.
Each receiver can choose his quality by joining a certain group (or certain
groups when layered encoding is used)

> Even if you use the same service level within a multicast tree/group,
> there is still the problem where
> a host can join a multicast group, and get multicast data before
> resources have been allocated for the branch leading to the host (as
> implied by Klaus Wehrle as well). The draft i posted earlier allocates
> resources (if a group requires a certain service level) as the tree is
> constructed, so data is not sent on a path where resources have not been
> allocated yet and there is no need to remark pkts in interior routers as
> a result.


One advantage of our draft is, that a user can join a group without
reserving ressources - but in this case he would only get
(Lower-than-)BestEffort. I call it "snooping into the group".
If the receiver want some quality later, he can make a reservation and the
entry in the mc-routing-table will be set to the service class -> he gets
the qos.

Supporting different service classes in one mc-group is no good solution,
because we still dont know how the different services of diffserv can be
mapped on each other - for example: can I "tunnel" AF over EF, if one
DS-Domain do not support AF?
What effects on the quality of AF will result. (I dont want to look on EF
over AF...)

Bye,
Klaus


--

 Klaus Wehrle
 Institut für Telematik, Universität Karlsruhe (TH)
 Zirkel 2, 76128 Karlsruhe, Germany
 Phone: +49 721 608 6414, Fax: +49 721 388097
 mailto:wehrle@telematik.informatik.uni-karlsruhe.de
 http://www.telematik.informatik.uni-karlsruhe.de/~wehrle



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



From diffserv-admin@ietf.org  Thu Nov  4 05:34:33 1999
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 FAA15050
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 05:34:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA06034;
	Thu, 4 Nov 1999 04:52:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA06002
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 04:51:55 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02122
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 04:52:00 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11jJYn-0000Mo-00; Thu, 04 Nov 1999 10:52:01 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA17130;
	Thu, 4 Nov 1999 10:52:00 +0100 (MET)
Message-ID: <382158F5.BF983C56@telematik.informatik.uni-karlsruhe.de>
Date: Thu, 04 Nov 1999 10:59:17 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: Institut =?iso-8859-1?Q?f=FCr?= Telematik - 
	=?iso-8859-1?Q?Universit=E4t?= Karlsruhe
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Steve Deering <deering@cisco.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
	 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hello Steve,

Steve Deering wrote:

> Why is the diff-serv list discussing provisioning for a single conference
> or per-flow resource reservations???
>
> Diff-serv for IP multicast ought to work just like diff-serv for IP
> unicast: the sender sets some bits to indicate how it would like the
> packet to be handled; any router along the delivery tree may modify
> those bits to indicate how the packet ought be handled from that point
> onward, along one or more descendent branches of the delivery tree.
> Along any branch of the delivery tree, the packet undergoes the same
> diff-serv handling as would a unicast packet along that branch.  The
> only significant difference is that, compared to replicated unicasts,
> less provisioning is needed for multicast  What's the problem, exactly?
>

If a new subtree is added by a join, the router just duplicates the packet
(with the codepoint). For example it is an EF-Codepoint and the aggregated
EF-bandwidth was (before the new subtree was added) at 100% of the allowed
EF-bandwidth - that means no more EF-traffic is allowed.
Now the new mc-flow on the subtree increases the aggregated EF-bandwidth to
(lets say) 150% of the allowed EF-bandwidth. If the routers use
priority-queueing (and I think EF has the highest priority) the other
services will be disadvantaged.
If you have a look in the draft (draft-bless-diffserv-multicast-00.txt) ,
there are some meassurements described, that I made with our
DiffServ-Implementation (KIDS). You can see, that AF looses a lot of
bandwidth, because EF is over his limit.

Now, we want to change the codepoint for the new subtree, until the
ressources are reserved and free.
The provisioning of multicast in diffserv-networks is the same as for unicast
(same codepoints, same mechanisms), but we have to take a look on the
expansion of mc-trees. QoS should only be given,when a reservation is made
(it doesn't matter, if the sender or the receiver sets up the reservation.)

ciao,
Klaus

--

 Klaus Wehrle
 Institut für Telematik, Universität Karlsruhe (TH)
 Zirkel 2, 76128 Karlsruhe, Germany
 Phone: +49 721 608 6414, Fax: +49 721 388097
 mailto:wehrle@telematik.informatik.uni-karlsruhe.de
 http://www.telematik.informatik.uni-karlsruhe.de/~wehrle



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



From diffserv-admin@ietf.org  Thu Nov  4 10:00:51 1999
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 KAA12848
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 10:00:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA13019;
	Thu, 4 Nov 1999 09:04:41 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA12980
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 09:04:30 -0500 (EST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25940
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 09:04:35 -0500 (EST)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id JAA29463;
	Thu, 4 Nov 1999 09:03:50 -0500 (EST)
Received: from njb140bh3.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA00398; Thu, 4 Nov 1999 09:03:14 -0500 (EST)
Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.2448.0)
	id <V9NF10X5>; Thu, 4 Nov 1999 09:03:41 -0500
Message-ID: <E5B80B001D76D211879C00E02910776102EF7844@njc240po05.ho.att.com>
From: "Sikora, John J, ALSVC" <jjsikora@att.com>
To: "'Bahri Okuroglu'" <bahrio@netdns.netas.com.tr>, diffserv@ietf.org
Subject: RE: [Diffserv] Service class of ACK packets
Date: Thu, 4 Nov 1999 09:03:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi Bahri:
I believe this was discussed before and the conclusion was that each
direction must be handled separately, since diffserv was defined for one
direction of flow. However, to get desired performance for priority flows,
it will probably be necessary to give priority to the ACKs as well. We have
found this to be true in our lab experiments. Exactly how to link the two
directions to get the desired performance for an application I believe is an
item that needs further study. Also, consider that when many flows converge
on a corporate data center, potentially a huge number of ACK flows must be
sorted out (MF classified) in the outgoing direction from the data center.
        John Sikora
        AT&T Labs
 
 

Bahri Okuroglu wrote:
 
Hi diffservers, 

Are the ACK packets of any flow (AF, EF or BE) always served as BE? Is there
any work on making the ACK of EF flow served as EF also? 


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



From diffserv-admin@ietf.org  Thu Nov  4 10:38:01 1999
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 KAA27810
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 10:38:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14674;
	Thu, 4 Nov 1999 10:00:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14644
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 10:00:31 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12733
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 10:00:35 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA14388; Thu, 4 Nov 1999 15:00:04 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA37194; Thu, 4 Nov 1999 15:00:00 GMT
Message-ID: <38219F1F.644D9AF2@hursley.ibm.com>
Date: Thu, 04 Nov 1999 08:58:39 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Bahri Okuroglu <bahrio@netdns.netas.com.tr>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Service class of ACK packets
References: <38212F96.FB25810F@rnd.netas.com.tr>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Diffserv really doesn't define this, since diffserv is a one-way
mechanism. However there is an issue in TCP
(see draft-xiao-tcp-prec-00.txt ) and in general with a windowing
protocol it would make sense to use the same class of service for
the acks. 

In practice that means that with symmetric diffserv policies, things
will work better than with assymmetric policies.

  Brian

Bahri Okuroglu wrote:
> 
> Hi diffservers,
> 
> Are the ACK packets of any flow (AF, EF or BE) always served as BE? Is
> there any work on making the ACK of EF flow served as EF also?
> 
> regards,
> 
> --
> 
> __________________________________________________________
> Bahri OKUROGLU
> 
> Software Design Engineer                     Netas R&D RT6
> mailto:bahrio@rnd.netas.com.tr     http://www.netas.com.tr
> mailto:bahrio@nortelnetworks.com   mailto:bahrio@yahoo.com
> Netas   Alemdag Cad.   Umraniye 81244      ISTANBUL TURKEY
> __________________________________________________________
> 
>

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



From diffserv-admin@ietf.org  Thu Nov  4 10:43:04 1999
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 KAA29896
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 10:43:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA15325;
	Thu, 4 Nov 1999 10:12:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA15288
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 10:11:58 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17539
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 10:12:01 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA73136 for <diffserv@ietf.org>; Thu, 4 Nov 1999 15:11:31 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA22284 for <diffserv@ietf.org>; Thu, 4 Nov 1999 15:11:30 GMT
Message-ID: <3821A1CF.1FA1CF5@hursley.ibm.com>
Date: Thu, 04 Nov 1999 09:10:07 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: diffserv@ietf.org
References: <NDBBIBKKCLEFDFDGHCNMIECACAAA.albert.e.manfredi@boeing.com>
		 <3820080F.49C9FB1F@ftel.co.uk> <38205407.BC63F31@hursley.ibm.com> <v04210102b446096657bc@[10.19.130.188]> <382158F5.BF983C56@telematik.informatik.uni-karlsruhe.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Enough [was Re: Problems with IP-Multicast in DiffServ-Networks
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

We've been round this topic enough I think, for this mailing list
and WG.

There are some BOFs coming up next week (especially decides)
where these questions are of interest, which is why I didn't
try to stop this discussion sooner, and even joined in.

However as has been observed by several people, we are *not*
planning any changes to the basic diffserv model. How provisioning
will be done, in unicast and/or multicast scenarios, is another
layer above basic diffserv.

This particular discussion should probably now move over to the
diffserv-interest list.

Thanks

  Brian Carpenter
  diffserv co-chair

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



From diffserv-admin@ietf.org  Thu Nov  4 11:15:29 1999
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 LAA12077
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 11:15:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16117;
	Thu, 4 Nov 1999 10:28:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16081
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 10:28:08 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23904
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 10:28:11 -0500 (EST)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Thu, 4 Nov 1999 10:27:23 -0500
Received: from zcard00p.ca.nortel.com ([47.141.0.104]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V8659AB7; Thu, 4 Nov 1999 10:27:19 -0500
Received: from nortel.com (zcars02x.ca.nortel.com [47.23.81.10]) 
          by zcard00p.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id V5HJLD0T; Thu, 4 Nov 1999 10:27:18 -0500
Message-ID: <3821A5D7.79E2567F@nortel.com>
Date: Thu, 04 Nov 1999 10:27:19 -0500
From: "Cheng-Yin Lee" <leecy@nortelnetworks.com>
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: Steve Deering <deering@cisco.com>, diffserv@ietf.org
Subject: Re: [Diffserv] Re: Problems with IP-Multicast in DiffServ-Networks
References: <10605.941647515@cs.ucl.ac.uk> <38207817.FB0DA437@hursley.ibm.com> <v0421010cb4462aa529a7@[10.19.130.188]> <382091AE.CADD99B5@hursley.ibm.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote:

> > > How to provision for multicast groups?
> >
> > You don't, Cheng-Yin. In a diffserv environment, in principle,
> > you're not supposed to provision anything after you've installed the
> > network hardware.
>
> There is no "supposed" about it and lots of people believe we will
> evolve towards dynamic provisioning of diffserv aggregates.

At this point i should reiterate that we are provisioning for traffic
aggregates in our proposal, whether resources are provisioned statically or
dynamically.


cheers,
cyl


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



From diffserv-admin@ietf.org  Thu Nov  4 19:10:49 1999
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 TAA27739
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 19:10:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA00350;
	Thu, 4 Nov 1999 18:28:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA00315
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 18:28:16 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12283
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 18:28:18 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA31814 for <diffserv@ietf.org>; Thu, 4 Nov 1999 23:27:48 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA25622 for <diffserv@ietf.org>; Thu, 4 Nov 1999 23:27:47 GMT
Message-ID: <382215B9.A134535F@hursley.ibm.com>
Date: Thu, 04 Nov 1999 17:24:41 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Diff Serv <diffserv@ietf.org>
Content-Type: multipart/mixed;
 boundary="------------92247AC8B78097B969FE1233"
Subject: [Diffserv] [Fwd: 46th IETF-Breakout Rooms]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This is a multi-part message in MIME format.
--------------92247AC8B78097B969FE1233
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
--------------92247AC8B78097B969FE1233
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [9.20.62.15]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA34396 for <brian@sp3at21.hursley.ibm.com>; Thu, 4 Nov 1999 22:43:44 GMT
Received: from hecky.acns.nwu.edu (hecky.acns.nwu.edu [129.105.16.51]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA35320 for <brian@hursley.ibm.com>; Thu, 4 Nov 1999 22:43:41 GMT
Received: (from mailnull@localhost)
	by hecky.acns.nwu.edu (8.8.7/8.8.7) id QAA24352
	for <bca911@hecky.acns.nwu.edu>; Thu, 4 Nov 1999 16:43:39 -0600 (CST)
Received: from pineyard.acns.nwu.edu (pineyard.acns.nwu.edu [129.105.16.53]) by hecky.acns.nwu.edu via smap (V2.0)
	id xma024090; Thu, 4 Nov 99 16:43:23 -0600
Received: (from mailnull@localhost)
	by pineyard.acns.nwu.edu (8.8.7/8.8.7) id QAA27110
	for bca911@hecky.acns.nwu.edu; Thu, 4 Nov 1999 16:43:23 -0600 (CST)
Received: (from mailnull@localhost)
	by pineyard.acns.nwu.edu (8.8.7/8.8.7) id QAA27082
	for <brian@icair.org>; Thu, 4 Nov 1999 16:43:22 -0600 (CST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pineyard.acns.nwu.edu via smap (V2.0)
	id xma027066; Thu, 4 Nov 99 16:43:04 -0600
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11433;
	Thu, 4 Nov 1999 17:09:50 -0500 (EST)
Message-Id: <199911042209.RAA11433@ietf.org>
X-Phforward: V2.0@pineyard
To: wgchairs@ietf.org, bofchairs@ietf.org
From: agenda@ietf.org
Subject: 46th IETF-Breakout Rooms
Date: Thu, 04 Nov 1999 17:09:49 -0500
Sender: mbeaulie@cnri.reston.va.us
X-Mozilla-Status2: 00000000
MIME-Version: 1.0

Just a reminder that all meeting rooms will be equipped
with an overhead projector and a data projector.

Marcia

--------------92247AC8B78097B969FE1233--


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



From diffserv-admin@ietf.org  Thu Nov  4 23:10:52 1999
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 XAA21547
	for <diffserv-archive@ietf.org>; Thu, 4 Nov 1999 23:10:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA10197;
	Thu, 4 Nov 1999 22:39:30 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA10165
	for <diffserv@optimus.ietf.org>; Thu, 4 Nov 1999 22:39:25 -0500 (EST)
Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08321
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 22:39:29 -0500 (EST)
Received: (from dovrolis@localhost)
	by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) id VAA00358;
	Thu, 4 Nov 1999 21:39:23 -0600 (CST)
From: Constantinos <dovrolis@hertz.ece.wisc.edu>
Message-Id: <199911050339.VAA00358@hertz.ece.wisc.edu>
Subject: Re: [Diffserv] EF RFC and loss
To: istoica+@cs.cmu.edu (Ion Stoica)
Date: Thu, 4 Nov 1999 21:39:23 -0600 (CST)
Cc: diffserv@ietf.org, salsano@coritel.it
In-Reply-To: <3819D5FA.4046ECCD@cs.cmu.edu> from "Ion Stoica" at Oct 29, 99 01:14:34 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Ion,

A (late) comment about your last note. 

I think that your analysis for the EF buffer requirements in
a router leads to very conservative results. One reason is that
you assume that we can have more than one EF flow in each
interface (perhaps you think about microflows?).
The second reason is that you don't take into account that
that the EF traffic should be regulated at each hop.
Let me first, though, describe how the EF traffic should be
aggregated in a router, at least in my understanding.

Each input or output interface carries at most one EF aggregate.
In the case of an edge router, the EF aggregate at an input
interface can be EF microflows, of course.

Now, in the context of a VLL-type of service, the (explicit or
sometimes implicit) assumption is that the routes of the EF
flows are known and fixed. This means that for a certain router,
the network manager knows how much of the EF traffic from each
input interface will go to each output interface.

To simplify slightly, say that a specific output interface receives
N aggregates of EF traffic, from N input interfaces respectively,
each having an EF capacity R. In this case, the EF capacity that
should be reserved in that output interface is N*R (statistical multiplexing
games with EF traffic are a "no-no"). Additionally, the EF traffic
that is forwarded to that output interface should be regulated by a
leaky-bucket shaper with the following parameters:
	service rate: N*R packets per second
	max burstiness: 1 packet
	# of buffers: N-1 packets 
                                                                                The regulation is necessary so that we avoid the clumping effect that
Stefano talks about. The queueing delay in the regulator, which can
be at most (N-1)/(N*R) with GPS, or N/C with strict-priority
(C is the link's capacity),  is within the queueing delay
bound of 1/R seconds that EF requires.

Going back to your example with the 32kbps EF microflows: I think that 
the only case in which we can need 15000 packet buffers or so is in a 
router with 15000 input ports.                 

Cheers,

Constantinos

> 
> Hi,
> 
> I just want to make a clarification with respect to the burstiness and
> buffer requirements at core routers for the premium service. In
> particular, the burstiness at an input/output port of a core router can
> be as high as the _number_ of EF flows that share that link.
> 
> Assume you have a router with N ports, and assume that EF traffic with
> a burst size of M packets arrives at each input port (i.e., there are
> M consecutive packets belonging to the EF traffic arriving at each
> input).  Then, if the EF traffic from all inputs is going to the same
> output, the burstiness of the EF traffic at that output will be M1 =
> N*M.
> 
> Thus, even if you start with perfectly regulated flows at each ingress
> (i.e., with burstiness 1), the burstiness at the output link of the
> s-th hop can be as high as N^s. 
> 
> On the other hand, the burst cannot exceed the total number of flows
> on the output link. Let m be the number of flows on the output
> link. Then the traffic burstiness at the s-th hop is
> 
>       min(m, N^s) (1)
> 
> Since at least theoretically we can arbitrarily increase s, let us
> consider that the burstiness is bounded by m.
> 
> Now, let us compute the buffer requirements. For this consider again
> the one router case in which EF traffic with burst size of M packets
> arrives at each input port, and the EF traffic from all inputs goes to
> the same output. Assume that the link speeds of the outputs and inputs
> are the same. This means that during the time it takes M consecutive
> packets to arrive at an input, the output will transmit at most M
> packets. Thus, at the end of the bursts the output will still have at
> least
> 
> 
>       (N-1)*M  = N*M - M = M1 - M1/N (2)
> 
> buffered packets waiting to be transmitted.
> 
> Since the burstiness on the output link M1 is bounded by m, i.e., the
> number of EF flows at the output port, from (2) it results that the
> buffer requirements at the output can be as high as
> 
>       m - m / N
> 
> EXAMPLE: Assume an OC-48 (2.4 Gbps) link and 32 Kbps EF flows. Further
> assume that the EF traffic is limited to 20 percents of the link
> bandwidth. Let C denote the link capacity and let r denote a flow
> rate. Then, the number of flows at the output port can be as high as
> 
>     m = 0.2 * C / r = 0.2 * 2.4Gbps / 32 Kbps = 15000
> 
> If we assume that the router has N=32 ports, then the buffer size should
> be at least 
> 
>     m - m / N = 14531 packets
> 
> Finally, I have two comments:
> 
> 1. If you regulate the aggregate EF traffic at each output, this will
> not help in the context of the above example. In particular, assume
> that you restrict the EF traffic to 30% of the link capacity. But then
> you can still have M packets arriving at each input at the rate
> 0.3*C. Since the output cannot send more than M packets during the
> same time interval it takes an input to receive M packets (as the EF
> traffic at the output is also rate limited to 0.3*C) the number of
> packets that needs to be buffered at the output at the end of the burst
> is still m*(1 - 1/N). Worse yet, regulating the EF traffic will increase
> the end-to-end delay.
> 
> 
> 2. The above "bound" is only for feed-forward networks; for general
> networks (in which the paths of several flows can result in cycles,
> e.g., flow f1 shares a common sub-path with f2, which shares a common
> sub-path with f3, which shares a common sub-path with f1) they can be
> much worse. For more details see
> 
>   R. Cruz, A Calculus for Network Delay, Part {II} : Network Analysis,
>   IEEE Transaction of Information Theory, 37, 1, 121-141, 1991.
> 
> 
> Ion
> 
> 
> Scott W Brim wrote:
> > 
> > At 14:34 10/28/1999 -0700, Kathleen Nichols wrote:
> > >Scott W Brim wrote:
> > > >
> > >...In a properly managed network very
> > > > little excess EF traffic will be admitted.  So if you're seeing a lot of
> > > > excess traffic, either your hardware is broken, your capacity management
> > > > is broken, or someone is sneaking packets in.
> > > >
> > >
> > >I would say "In a properly managed network NO excess EF traffic
> > >will be admitted." But perhaps you have a different definition
> > >of "excess" that I do.
> > >
> > >I think dealing with the excess traffic in a reasonable way is
> > >what the "better effort" or "class of service" services are
> > >all about. Traffic marked for the EF aggregate shouldn't have
> > >any of this excess.
> > >
> > >         Kathie
> > 
> > :nods
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 


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



From diffserv-admin@ietf.org  Fri Nov  5 00:41:51 1999
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 AAA28116
	for <diffserv-archive@ietf.org>; Fri, 5 Nov 1999 00:41:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA12770;
	Fri, 5 Nov 1999 00:13:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA12734
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 00:13:47 -0500 (EST)
Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15732
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 00:13:53 -0500 (EST)
Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0)
	id <V5HZ2LQH>; Thu, 4 Nov 1999 21:13:56 -0800
Message-ID: <337055FBC675D311A85D00508B5A9C4F01A4F6@u-mail.rd.francetelecom.com>
From: CATANZARITI Sergio FTR&D/TI
	 <sergio.catanzariti@rd.francetelecom.com>
To: diffserv@ietf.org
Date: Thu, 4 Nov 1999 21:13:49 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF274C.8F40FF24"
Subject: [Diffserv] AF and PHB mutability requirements
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF274C.8F40FF24
Content-Type: text/plain

In the AF PHB Group spec, there is no specific PHB mutability section. But
the possibility is given under Traffic Conditioning Actions:
> A DS domain MAY at the edge of a domain control the amount of AF traffic
that enters or exits the domain at various levels of drop precedence. Such
traffic conditioning actions MAY include traffic shaping, discarding of
packets, increasing or decreasing the drop precedence of packets, and
reassigning of packets to other AF classes. However, the traffic
conditioning actions MUST NOT cause reordering of packets of the same
microflow.>
So, is it possible to reassign packets ONLY to different AF classes as
action of traffic conditioning?
What about other SLS-based boundary service semantics changing reasons? The
latter case seems in sync with the principles of the architecture of the
diff serv model where PHB/DSCP mapping looks like more a service definition
and implementation issue, although EF prohibits that:
>Mutability Packets marked for EF PHB MAY be remarked at a DS domain
boundary only to other codepoints that satisfy the EF PHB. Packets marked
for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain>
Please, could somebody from the AF document authors team clarify that and
put it in a PHB mutability section?

The problem is that looking at both the DS framework and the architecture
document, this PHB/DSCP re-marking/changing issue looks really confusing (at
least to me): 

From the architecture document:

>2.3.3.2 Markers Packet markers set the DS field of a packet to a particular
codepoint, adding the marked packet to a particular DS behavior aggregate.
The marker may be configured to mark all packets which are steered to it to
a single codepoint, or may be configured to mark a packet to one of a set of
codepoints used to select a PHB in a PHB group, according to the state of a
meter. When the marker changes the codepoint in a packet it is said to have
"re-marked" the packet.>

From the framework document:

>Markers police by re-marking the traffic with a different codepoint either
- to demote out-of-profile traffic to a different PHB, - as a result of an
SLS which specifies codepoint mutation, or - to ensure that only valid
codepoints are used within the domain.>
So, is it possible to change DSCP as long it is PHB service semantic
compatible? Is it possible to change DSCP as long it is SLS-compatible? Is
it possible to change DSCP as long it is PHB-group compatible? All of the
above, none of the above, open issue, out of scope issues, etc..
Please, an explanation short and as simple as possible considering that I
have attended only the elementary school (but a public one, luckily enough),
not a discussions flame.
Thanks,
Sergio
> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:sergio.catanzariti@rd.francetelecom.com 
> --------------------------------------------------------------------
> 
> 

------_=_NextPart_001_01BF274C.8F40FF24
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>AF and PHB mutability requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the AF PHB Group spec, there is no =
specific PHB mutability section. But the possibility is given under =
Traffic Conditioning Actions:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; A DS domain MAY at the edge of a =
domain control the amount of AF traffic that enters or exits the domain =
at various levels of drop precedence. Such traffic conditioning actions =
MAY include traffic shaping, discarding of packets, increasing or =
decreasing the drop precedence of packets,<B> and reassigning of =
packets to other AF classes.</B> However, the traffic =
conditioning<B></B> actions MUST NOT cause reordering of packets of the =
same microflow.&gt;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, is it possible to reassign packets =
ONLY to different AF classes as action of traffic conditioning?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">What about other SLS-based boundary =
service semantics changing reasons? The latter case seems in sync with =
the principles of the architecture of the diff serv model where =
PHB/DSCP mapping looks like more a service definition and =
implementation issue, although EF prohibits that:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;Mutability Packets marked for EF =
PHB MAY be remarked at a DS domain boundary only to other codepoints =
that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be =
demoted or promoted to another PHB by a DS domain&gt;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please, could somebody from the AF =
document authors team clarify that and put it in a PHB mutability =
section?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The problem is that looking at both =
the DS framework and the architecture document, this PHB/DSCP =
re-marking/changing issue looks really confusing (at least to me): =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From the architecture document:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;2.3.3.2 Markers Packet markers set =
the DS field of a packet to a particular codepoint, adding the marked =
packet to a particular DS behavior aggregate. The marker may be =
configured to mark all packets which are steered to it to a single =
codepoint, or may be configured to mark a packet to one of a set of =
codepoints used to select a PHB in a PHB group, according to the state =
of a meter. When the marker changes the codepoint in a packet it is =
said to have &quot;re-marked&quot; the packet.&gt;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">From the framework document:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;Markers police by re-marking the =
traffic with a different codepoint either - to demote out-of-profile =
traffic to a different PHB, - as a result of an SLS which specifies =
codepoint mutation, or - to ensure that only valid codepoints are used =
within the domain.&gt;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, is it possible to change DSCP as =
long it is PHB service semantic compatible? Is it possible to change =
DSCP as long it is SLS-compatible? Is it possible to change DSCP as =
long it is PHB-group compatible? All of the above, none of the above, =
open issue, out of scope issues, etc..</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please, an explanation short and as =
simple as possible considering that I have attended only the elementary =
school (but a public one, luckily enough), not a discussions =
flame.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sergio</FONT>
<UL>
<P><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sergio =
Catanzariti</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Senior Project =
Manager, Technology Integration</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">France Telecom =
R&amp;D </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1000 Marina =
Boulevard Suite 300 </FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brisbane CA =
94005</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tel. =
650-875-1526</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax. =
650-875-1505</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">email:sergio.catanzariti@rd.francetelecom.com =
</FONT></I>
<BR><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT></I>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BF274C.8F40FF24--

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



From diffserv-admin@ietf.org  Fri Nov  5 06:07:25 1999
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 GAA26861
	for <diffserv-archive@ietf.org>; Fri, 5 Nov 1999 06:07:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA24759;
	Fri, 5 Nov 1999 05:33:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA24728
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 05:33:29 -0500 (EST)
Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18058
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 05:33:32 -0500 (EST)
Received: from hermes2.fty.cstelecom.com (hermes2.fty.cstelecom.com [172.17.68.52])
	by oass09.cstelecom.cie-signaux.fr  with ESMTP id LAA12510
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 11:32:12 +0100 (MET)
Received: from cstelecom.com ([172.17.70.69]) by hermes2.fty.cstelecom.com
          (Netscape Messaging Server 3.62)  with ESMTP id 128;
          Fri, 5 Nov 1999 11:33:56 +0100
Message-ID: <3822B2AA.1BE01892@cstelecom.com>
Date: Fri, 05 Nov 1999 11:34:18 +0100
From: "Alain BURGAIN" <alain.burgain@cstelecom.com>
Organization: CS-TELECOM[GROUPE CS - Compagnie des Signaux]
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Diffserv] Alternative congestion avoidance parameterization (diffserv-mib-01)
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hello,

========================================================================

Proposal of an alternative congestion avoidance parameterization for a
more precise queuing delay control.
========================================================================

In term of service differentiation, at least for some service classes,
the number of packets in a queue has not a clear meaning for the user
(or for the network administrator). What is important is the control
over the queuing delay for each class of service.

To trigger drop decision, the evaluation of the pre-congestion level
should then be performed according to the current (instantaneous or
average) queuing delay. That is to say drop thresholds are (optionally)
configured in microseconds, in the diffServActionTable.
When a variable bit rate subnetwork is used, the implementation is then
able to take into account the exact [average] queuing delay for each
packet (provided that the current rate of the subnetwork connection is
known. Suitable purge actions may also be needed after a sudden decrease
of this service rate).

To keep compatibility with congestion avoidance implementations taking
into account the number of packets in the queue, we can propose two
possibilities :
- The MIB thresholds parameters, expressed in microseconds in the MIB,
are converted by the router into a number of packets, provided that the
service rate of the queue, and the average packet size are known by the
router.
- The new behavior is optional in the MIB : a
“diffServQueueFillingControl” parameter, indicating whether to use
packet number thresholds or queuing delay thresholds can be specified in
the diffServQueueTable entry that is pointed by the diffServActionTable
entry.

Bye
Alain BURGAIN


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



From diffserv-admin@ietf.org  Fri Nov  5 06:18:49 1999
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 GAA00079
	for <diffserv-archive@ietf.org>; Fri, 5 Nov 1999 06:18:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA25095;
	Fri, 5 Nov 1999 05:45:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA24992
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 05:45:48 -0500 (EST)
Received: from nausicaa.coritel.it ([193.205.242.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21588
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 05:45:29 -0500 (EST)
Received: from coritel.it (hobbes.coritel.it [193.205.242.28])
	by nausicaa.coritel.it (8.9.3/8.9.3) with ESMTP id LAA09990;
	Fri, 5 Nov 1999 11:12:08 +0100 (MET)
Message-ID: <3822B4BC.59E4BB2A@coritel.it>
Date: Fri, 05 Nov 1999 11:43:08 +0100
From: Stefano Salsano <salsano@coritel.it>
Reply-To: salsano@coritel.it
Organization: CORITEL - COnsorzio di RIcerca sulle TELecomunicazioni
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Constantinos <dovrolis@hertz.ece.wisc.edu>
CC: Ion Stoica <istoica@cs.cmu.edu>, diffserv@ietf.org
Subject: Re: [Diffserv] EF RFC and loss
References: <199911050339.VAA00358@hertz.ece.wisc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Dear Constantinos,

shaping is of no effect with respect to worst case analysis.
In general it make things even worse, because it increases
the average delay. 

Here is a simple example where you you cannot avoid worst case
clumping and you need more buffer than you assume. 


You have N input interfaces, each one having an aggregate EF rate of R.
From each interface, a VLL of rate R/N is directed to a
specific output port X, therefore you reserve the rate R on the
output port. 

If you assume shaping you have the following parameters on the 
output port 1X:
        service rate: R packets per second
        max burstiness: 1 packet
        # of buffers: N-1 packets 

Assume that at given time (T=0 s.) a packet appears on each input
interface, belonging to the VLL directed to the output port 1X.
The more unlucky VLL, say on input port 11, will have to wait (N-1)
packets. At time T=N/R s. a packet appears on port 1 directed 
to output port X, while no packets of the other VLL directed to
port 1X appear. Therefore you will have two consecutive packets
of a given VLL which appear at "istantaneous" rate R on the output 
line 1X. (Remember that the contractual rate of the VLL is R/N).

Assume that you combine N lines like the output line 1X as input
to a second level router, and assume that for each inpur port a VLL 
of contractual rate R/N is directed to output port 2X.
In a short interval 2/R s. you can receive 2N packets directed to
the output port 2X. In this interval you can output only 2 packets,
therefore you need to buffer (2N-2) packets.

I agree that this worst case is very conservative ... but if
you promise deterministic no loss you need the worst case.

Regards,
Stefano

Constantinos wrote:
> 
> Ion,
> 
> A (late) comment about your last note.
> 
> I think that your analysis for the EF buffer requirements in
> a router leads to very conservative results. One reason is that
> you assume that we can have more than one EF flow in each
> interface (perhaps you think about microflows?).
> The second reason is that you don't take into account that
> that the EF traffic should be regulated at each hop.
> Let me first, though, describe how the EF traffic should be
> aggregated in a router, at least in my understanding.
> 
> Each input or output interface carries at most one EF aggregate.
> In the case of an edge router, the EF aggregate at an input
> interface can be EF microflows, of course.
> 
> Now, in the context of a VLL-type of service, the (explicit or
> sometimes implicit) assumption is that the routes of the EF
> flows are known and fixed. This means that for a certain router,
> the network manager knows how much of the EF traffic from each
> input interface will go to each output interface.
> 
> To simplify slightly, say that a specific output interface receives
> N aggregates of EF traffic, from N input interfaces respectively,
> each having an EF capacity R. In this case, the EF capacity that
> should be reserved in that output interface is N*R (statistical multiplexing
> games with EF traffic are a "no-no"). Additionally, the EF traffic
> that is forwarded to that output interface should be regulated by a
> leaky-bucket shaper with the following parameters:
>         service rate: N*R packets per second
>         max burstiness: 1 packet
>         # of buffers: N-1 packets
>                                                                                 The regulation is necessary so that we avoid the clumping effect that
> Stefano talks about. The queueing delay in the regulator, which can
> be at most (N-1)/(N*R) with GPS, or N/C with strict-priority
> (C is the link's capacity),  is within the queueing delay
> bound of 1/R seconds that EF requires.
> 
> Going back to your example with the 32kbps EF microflows: I think that
> the only case in which we can need 15000 packet buffers or so is in a
> router with 15000 input ports.
> 
> Cheers,
> 
> Constantinos
> 
> >
> > Hi,
> >
> > I just want to make a clarification with respect to the burstiness and
> > buffer requirements at core routers for the premium service. In
> > particular, the burstiness at an input/output port of a core router can
> > be as high as the _number_ of EF flows that share that link.
> >
> > Assume you have a router with N ports, and assume that EF traffic with
> > a burst size of M packets arrives at each input port (i.e., there are
> > M consecutive packets belonging to the EF traffic arriving at each
> > input).  Then, if the EF traffic from all inputs is going to the same
> > output, the burstiness of the EF traffic at that output will be M1 =
> > N*M.
> >
> > Thus, even if you start with perfectly regulated flows at each ingress
> > (i.e., with burstiness 1), the burstiness at the output link of the
> > s-th hop can be as high as N^s.
> >
> > On the other hand, the burst cannot exceed the total number of flows
> > on the output link. Let m be the number of flows on the output
> > link. Then the traffic burstiness at the s-th hop is
> >
> >       min(m, N^s) (1)
> >
> > Since at least theoretically we can arbitrarily increase s, let us
> > consider that the burstiness is bounded by m.
> >
> > Now, let us compute the buffer requirements. For this consider again
> > the one router case in which EF traffic with burst size of M packets
> > arrives at each input port, and the EF traffic from all inputs goes to
> > the same output. Assume that the link speeds of the outputs and inputs
> > are the same. This means that during the time it takes M consecutive
> > packets to arrive at an input, the output will transmit at most M
> > packets. Thus, at the end of the bursts the output will still have at
> > least
> >
> >
> >       (N-1)*M  = N*M - M = M1 - M1/N (2)
> >
> > buffered packets waiting to be transmitted.
> >
> > Since the burstiness on the output link M1 is bounded by m, i.e., the
> > number of EF flows at the output port, from (2) it results that the
> > buffer requirements at the output can be as high as
> >
> >       m - m / N
> >
> > EXAMPLE: Assume an OC-48 (2.4 Gbps) link and 32 Kbps EF flows. Further
> > assume that the EF traffic is limited to 20 percents of the link
> > bandwidth. Let C denote the link capacity and let r denote a flow
> > rate. Then, the number of flows at the output port can be as high as
> >
> >     m = 0.2 * C / r = 0.2 * 2.4Gbps / 32 Kbps = 15000
> >
> > If we assume that the router has N=32 ports, then the buffer size should
> > be at least
> >
> >     m - m / N = 14531 packets
> >
> > Finally, I have two comments:
> >
> > 1. If you regulate the aggregate EF traffic at each output, this will
> > not help in the context of the above example. In particular, assume
> > that you restrict the EF traffic to 30% of the link capacity. But then
> > you can still have M packets arriving at each input at the rate
> > 0.3*C. Since the output cannot send more than M packets during the
> > same time interval it takes an input to receive M packets (as the EF
> > traffic at the output is also rate limited to 0.3*C) the number of
> > packets that needs to be buffered at the output at the end of the burst
> > is still m*(1 - 1/N). Worse yet, regulating the EF traffic will increase
> > the end-to-end delay.
> >
> >
> > 2. The above "bound" is only for feed-forward networks; for general
> > networks (in which the paths of several flows can result in cycles,
> > e.g., flow f1 shares a common sub-path with f2, which shares a common
> > sub-path with f3, which shares a common sub-path with f1) they can be
> > much worse. For more details see
> >
> >   R. Cruz, A Calculus for Network Delay, Part {II} : Network Analysis,
> >   IEEE Transaction of Information Theory, 37, 1, 121-141, 1991.
> >
> >
> > Ion
> >
> >
> > Scott W Brim wrote:
> > >
> > > At 14:34 10/28/1999 -0700, Kathleen Nichols wrote:
> > > >Scott W Brim wrote:
> > > > >
> > > >...In a properly managed network very
> > > > > little excess EF traffic will be admitted.  So if you're seeing a lot of
> > > > > excess traffic, either your hardware is broken, your capacity management
> > > > > is broken, or someone is sneaking packets in.
> > > > >
> > > >
> > > >I would say "In a properly managed network NO excess EF traffic
> > > >will be admitted." But perhaps you have a different definition
> > > >of "excess" that I do.
> > > >
> > > >I think dealing with the excess traffic in a reasonable way is
> > > >what the "better effort" or "class of service" services are
> > > >all about. Traffic marked for the EF aggregate shouldn't have
> > > >any of this excess.
> > > >
> > > >         Kathie
> > >
> > > :nods
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > diffserv@ietf.org
> > > http://www.ietf.org/mailman/listinfo/diffserv
> > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
*******************************************************************
Stefano Salsano
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
                  
E-mail  : salsano@coritel.it      URL     : http://www.coritel.it
Tel.    : +39 06 20410029         Address : Via di Tor Vergata, 135     
Fax.    : +39 06 20410037                   00133 Roma - ITALY          
*******************************************************************

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



From diffserv-admin@ietf.org  Fri Nov  5 07:17:25 1999
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 HAA18389
	for <diffserv-archive@ietf.org>; Fri, 5 Nov 1999 07:17:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA26281;
	Fri, 5 Nov 1999 06:38:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA26251
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 06:38:44 -0500 (EST)
Received: from oass09.cstelecom.cie-signaux.fr (mailhub.cie-signaux.fr [194.2.40.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05098
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 06:38:48 -0500 (EST)
Received: from hermes2.fty.cstelecom.com (hermes2.fty.cstelecom.com [172.17.68.52])
	by oass09.cstelecom.cie-signaux.fr  with ESMTP id MAA16498
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 12:37:44 +0100 (MET)
Received: from cstelecom.com ([172.17.70.69]) by hermes2.fty.cstelecom.com
          (Netscape Messaging Server 3.62)  with ESMTP id 146;
          Fri, 5 Nov 1999 12:39:28 +0100
Message-ID: <3822C206.1F9D5F49@cstelecom.com>
Date: Fri, 05 Nov 1999 12:39:50 +0100
From: "Alain BURGAIN" <alain.burgain@cstelecom.com>
Organization: CS-TELECOM[GROUPE CS - Compagnie des Signaux]
X-Mailer: Mozilla 4.5 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
Subject: Re: [Diffserv] multi-level traffic control
References: <3815D5CB.24C1B8BC@cstelecom.com> <3815F4D3.992CE1FF@hursley.ibm.com>
Content-Type: multipart/alternative;
 boundary="------------78252461D8968689FEA61A24"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


--------------78252461D8968689FEA61A24
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

===========================
Need of a multi-level traffic conditioning
===========================

We agree that, for optimal performances, it is better to perform MF
classification in the source host, or in a first router, and to perform only
BA classification in the border router of the ISP.

But we also think that more complex cases might happen (a simple one would be
a non-diffserv aware host directly connected to a border router of a DiffServ
network).

So we think that the MIB should make it possible, either at an ingress
interface of a router, or at an egress one, to perform classification and
control of the traffic both at the « multi field » (application, end user,…)
level and at the « aggregate » (TCS per interface…) level.

The document “A Conceptual Model for DiffServ Routers”
(draft-ietf-diffserv-model-01.txt), presents an architecture, in paragraph
8.3, with a two-level traffic conditioning.

To be exhaustive, the “aggregate” level of traffic classification, might need
a MF classification, when the TCS is not associated only to the network
ingress point, but also to a specific (list of) network egress point(s). So,
we could theorically need a three level traffic conditioning (MF
application-user, MF aggregate toward destination, BA) , though in a real
network, we can probably avoid to do this on a unique router interface.

====================================
Adaptation of the MIB (diffserv-mib-01) to this need
====================================
After the following analysis, the MIB draft can effectively cover most of the
possible cases (but not all), by use of the RowPointer. Some clarification
might still be useful.

MF TCB (Traffic Conditioning Bloc) :
                                      | Action
1.MF classifier -->( 2.Meter ) --> 3. | Marker         --> (4.Queue–if
shaping-) ->
                       (MF)           | MF Counters
                                      | (Queue thresholds)


BA TCB :
                                                      |Action
->5 : BA TCB |--> 5a.(BA classifier) -->6.|Meter -->7.|(Marker)    -->
8.Queue or forwarding
             |--> 5b.MF classifier        |BA         |BA counters
                if the TCS of the                     |Queue thresholds
                aggregate is toward a
                specific network exit point


When the BA TCB is to be performed after a MF TCB, the Behavior Aggregate is
already known, and it is then possible to skip step 5a. This is not true in
the 5b case, as the aggregate is selected according to the destination
address.

The RowPointer in the -01 MIB effectively seem to allow all cases excepted
5b.

=========
Clarifications
=========
In paragraph 3.5 (Queue Table), the definition of the “TCB” (= “Traffic
Control Block”) seems not to be consistent with the one that used above (=
“Traffic Conditioning Block”), and that can be found in various DiffServ
documents.

To my understanding, in some RowPointer comments, like those of
diffServActionNext, and diffServQueueNextTCB, we should understand that the
pointer can (also) point to the Meter of the “Traffic Conditioning Block” of
the Behavior Aggregate that has been selected by the current (in case of an
Action entry) or previous (in case of a Queue entry) Action.

That is to say (cause I’m not sure that was so clear !), if we refer to
paragraph 2 above :

The RowPointer of Action number 3 (or the RowPointer of Queue number 4) can
point to the Meter number 6, which is the Meter of the Traffic Conditioning
Block of the BA selected in Action number 3…

=============================================================
Alternative proposal of extension to DiFFServ MIB to allow multi
level-traffic conditioning
=============================================================
Just in case it would be found useful, either for a clearer and easier to
manage view of two (or more) levels of Traffic Conditioning blocs, or to
allow Multilevel traffic conditioning over a “multifield Aggregate” (case 5b
above)…

In DiffServClassifierEntry (page 10 to 12), add  “diffServClassifierLevel”
(Unsigned32, read-create, current, DEFVAL { 0 } ), before (or after)
“diffServClassifierSequence” :

“ The level of the classifier. Level 0 is the Behavior Aggregate level. Other
levels are Multifield levels. Most often, there is either no multifield
level, or a single one, which is level 1. The highest level is fully
processed first, then, if other levels are present, processing is made in
decreasing order. Only classifiers indicated with the current level are
searched for matching the packet (with respect to the search sequence
specified below), then, as a classifier is found, it is processed with its
associated meter and action and the treatment resumes with the next level of
classification. ”

This object may be added at the end of the index list.

Alain

Brian E Carpenter wrote:

> Alain BURGAIN wrote:
> ...
> > It should be possible to classify and control the traffic both at the «
> > multi field » (application, end user,…) level and at the « aggregate »
> > (TCS per interface…) level.
>
> However, there is no reason why both these stages must occur
> in the same router.
>
> In fact it would seem more natural to do the full MF classification
> in the source host (or possibly the first router) and then do
> the BA classification in an ISP border router.
>
> If you do want to cascade them both at the same router ingress,
> doesn't the RowPointer in the -01 MIB allow this?
>
>   Brian
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--------------78252461D8968689FEA61A24
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
===========================
<br>Need of a multi-level traffic conditioning
<br>===========================
<p>We agree that, for optimal performances, it is better to perform MF
classification in the source host, or in a first router, and to perform
only BA classification in the border router of the ISP.
<p>But we also think that more complex cases might happen (a simple one
would be a non-diffserv aware host directly connected to a border router
of a DiffServ network).
<p>So we think that the MIB should make it possible, either at an ingress
interface of a router, or at an egress one, to perform classification and
control of the traffic both at the &laquo; multi field &raquo; (application,
end user,…) level and at the &laquo; aggregate &raquo; (TCS per interface…)
level.
<p>The document “A Conceptual Model for DiffServ Routers” (draft-ietf-diffserv-model-01.txt),
presents an architecture, in paragraph 8.3, with a two-level traffic conditioning.
<p>To be exhaustive, the “aggregate” level of traffic classification, might
need a MF classification, when the TCS is not associated only to the network
ingress point, but also to a specific (list of) network egress point(s).
So, we could theorically need a three level traffic conditioning (MF application-user,
MF aggregate toward destination, BA) , though in a real network, we can
probably avoid to do this on a unique router interface.
<p>====================================
<br>Adaptation of the MIB (diffserv-mib-01) to this need
<br>====================================
<br>After the following analysis, the MIB draft can effectively cover most
of the possible cases (but not all), by use of the RowPointer. Some clarification
might still be useful.
<p><font face="Courier New,Courier"><font size=-1>MF TCB (Traffic Conditioning
Bloc) :</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| Action</font></font>
<br><font face="Courier New,Courier"><font size=-1>1.MF classifier -->(
2.Meter ) --> 3. | Marker&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--> (4.Queue–if shaping-) -></font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(MF)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | MF Counters</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| (Queue thresholds)</font></font>
<br><font face="Courier New,Courier"><font size=-1></font></font>&nbsp;<font face="Courier New,Courier"><font size=-1></font></font>
<p><font face="Courier New,Courier"><font size=-1>BA TCB :</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|Action</font></font>
<br><font face="Courier New,Courier"><font size=-1>->5 : BA TCB |--> 5a.(BA
classifier) -->6.|Meter -->7.|(Marker)&nbsp;&nbsp;&nbsp; --> 8.Queue or
forwarding</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--> 5b.MF classifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |BA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|BA counters</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
if the TCS of the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|Queue thresholds</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
aggregate is toward a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font></font>
<br><font face="Courier New,Courier"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specific network exit point</font></font>
<br><font face="Courier New,Courier"><font size=-1></font></font>&nbsp;<font face="Courier New,Courier"><font size=-1></font></font>
<p>When the BA TCB is to be performed after a MF TCB, the Behavior Aggregate
is already known, and it is then possible to skip step 5a. This is not
true in the 5b case, as the aggregate is selected according to the destination
address.
<p>The RowPointer in the -01 MIB effectively seem to allow all cases excepted
5b.
<p>=========
<br>Clarifications
<br>=========
<br>In paragraph 3.5 (Queue Table), the definition of the “TCB” (= “Traffic
Control Block”) seems not to be consistent with the one that used above
(= “Traffic Conditioning Block”), and that can be found in various DiffServ
documents.
<p>To my understanding, in some RowPointer comments, like those of diffServActionNext,
and diffServQueueNextTCB, we should understand that the pointer can (also)
point to the Meter of the “Traffic Conditioning Block” of the Behavior
Aggregate that has been selected by the current (in case of an Action entry)
or previous (in case of a Queue entry) Action.
<p>That is to say (cause I’m not sure that was so clear !), if we refer
to paragraph 2 above :
<p>The RowPointer of Action number 3 (or the RowPointer of Queue number
4) can point to the Meter number 6, which is the Meter of the Traffic Conditioning
Block of the BA selected in Action number 3…
<p>=============================================================
<br>Alternative proposal of extension to DiFFServ MIB to allow multi level-traffic
conditioning
<br>=============================================================
<br>Just in case it would be found useful, either for a clearer and easier
to manage view of two (or more) levels of Traffic Conditioning blocs, or
to allow Multilevel traffic conditioning over a “multifield Aggregate”
(case 5b above)…
<p>In DiffServClassifierEntry (page 10 to 12), add&nbsp; “diffServClassifierLevel”
(Unsigned32, read-create, current, DEFVAL { 0 } ), before (or after) “diffServClassifierSequence”
:
<p>“ The level of the classifier. Level 0 is the Behavior Aggregate level.
Other levels are Multifield levels. Most often, there is either no multifield
level, or a single one, which is level 1. The highest level is fully processed
first, then, if other levels are present, processing is made in decreasing
order. Only classifiers indicated with the current level are searched for
matching the packet (with respect to the search sequence specified below),
then, as a classifier is found, it is processed with its associated meter
and action and the treatment resumes with the next level of classification.
”
<p>This object may be added at the end of the index list.
<p>Alain
<p>Brian E Carpenter wrote:
<blockquote TYPE=CITE>Alain BURGAIN wrote:
<br>...
<br>> It should be possible to classify and control the traffic both at
the &laquo;
<br>> multi field &raquo; (application, end user,…) level and at the &laquo;
aggregate &raquo;
<br>> (TCS per interface…) level.
<p>However, there is no reason why both these stages must occur
<br>in the same router.
<p>In fact it would seem more natural to do the full MF classification
<br>in the source host (or possibly the first router) and then do
<br>the BA classification in an ISP border router.
<p>If you do want to cascade them both at the same router ingress,
<br>doesn't the RowPointer in the -01 MIB allow this?
<p>&nbsp; Brian
<p>_______________________________________________
<br>diffserv mailing list
<br>diffserv@ietf.org
<br><a href="http://www.ietf.org/mailman/listinfo/diffserv">http://www.ietf.org/mailman/listinfo/diffserv</a>
<br>Archive: <a href="http://www-nrg.ee.lbl.gov/diff-serv-arch/">http://www-nrg.ee.lbl.gov/diff-serv-arch/</a></blockquote>
</html>

--------------78252461D8968689FEA61A24--


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



From diffserv-admin@ietf.org  Fri Nov  5 10:41:03 1999
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 KAA21352;
	Fri, 5 Nov 1999 10:41:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA00565;
	Fri, 5 Nov 1999 09:35:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA00534
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 09:35:48 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03311
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 09:35:51 -0500 (EST)
Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.27189-0@bells.cs.ucl.ac.uk>; Fri, 5 Nov 1999 14:35:23 +0000
X-Mailer: exmh version 2.0.2
To: salsano@coritel.it, diffserv@ietf.org
cc: P.Gevros@cs.ucl.ac.uk, Ion Stoica <istoica@cs.cmu.edu>
X-Organization: Dept. of Computer Science, University College London
X-Phone: +44 (0)171 419 3666
X-URL: http://www.cs.ucl.ac.uk/staff/P.Gevros/
Subject: Re: [Diffserv] EF RFC and loss
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Nov 1999 14:35:24 +0000
Message-ID: <5788.941812524@cs.ucl.ac.uk>
From: Panos GEVROS <P.Gevros@cs.ucl.ac.uk>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> > I just want to make a clarification with respect to the burstiness and
> > buffer requirements at core routers for the premium service. In
> > particular, the burstiness at an input/output port of a core router can
> > be as high as the _number_ of EF flows that share that link.
> >
> > Assume you have a router with N ports, and assume that EF traffic with
> > a burst size of M packets arrives at each input port (i.e., there are
> > M consecutive packets belonging to the EF traffic arriving at each
> > input).  Then, if the EF traffic from all inputs is going to the same
> > output, the burstiness of the EF traffic at that output will be M1 =
> > N*M.



if you think in terms of rates instead of packets is there any reason why the 
arrival process from the N input ports cannot be abstracted -from the point of 
the output interface- as a single arrival process with arrival rate the sum of 
the arrival rates of the input ports?
(in a properly engineered ef phb the input sum will be slightly less than 
service rate of the output port) and everything will work as intended ...

even if the packets appear in in Input Ports "simultaneously" they will be 
presented to the output port in sequence..

also the delay/jitter for moving packets from in->out i/faces in the router 
are orders of magnitude less compared to end to end delay so it doesn't matter
or is it very simplistic?

Panos



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



From diffserv-admin@ietf.org  Fri Nov  5 11:21:02 1999
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 LAA11204;
	Fri, 5 Nov 1999 11:21:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA02259;
	Fri, 5 Nov 1999 10:38:33 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA02230
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 10:38:29 -0500 (EST)
Received: from ws9.cdotb.ernet.in ([202.41.72.121])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20361
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 10:38:21 -0500 (EST)
Received: from ws61.cdotb.ernet.in (ws61 [202.41.72.173])
	by ws9.cdotb.ernet.in (8.9.3/8.9.3) with SMTP id OAA07919
	for <diffserv@ietf.org>; Thu, 4 Nov 1999 14:05:04 +0500 (GMT+0500)
Received: from nirvana.cdotb.ernet.in by ws61.cdotb.ernet.in (5.65v4.0/1.1.19.2/22Oct99-0433PM)
	id AA30748; Thu, 4 Nov 1999 13:58:25 +0500
Message-Id: <3821924E.A45B025D@cdotb.ernet.in>
Date: Thu, 04 Nov 1999 14:03:58 +0000
From: Prakash R <rprakash@cdotb.ernet.in>
Reply-To: rprakash@cdotb.ernet.in
Organization: C-DOT (Center for Development of Telematics)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i686)
X-Accept-Language: en
Mime-Version: 1.0
To: diffserv@ietf.org
Cc: Prakash R <rprakash@cdotb.ernet.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Reference/Example implementation for DiffServ.
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

I've recently joined the group. So please do bear with me if the
questions are repeated.

General aspects:
----------------
1) Is there a FAQ for this mailing list?

DiffServ Deployment:
--------------------

2) Is DiffServ already being used anywhere?

3) Is there a reference/example implementation of DiffServ which one can 
   use as a model? Specifically with respect to the
provisioning/charging
   aspects.

DiffServ/QoS basics:
--------------------

4) List of papers that one must've read to understand the QoS issues
   involved in DiffServ?

5) What sort of Mathematics will I need to learn to understand the
   theoretical issues behind the various decisions taken in DiffServ WG?

I would appreciate information regarding the above.

- Thanks in advance,
-- 
Prakash R	
Co-ordinating Engineer, Internet Telephony Group
===========================================================================
C-DOT (Centre for Development of Telematics)	
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256 
===========================================================================

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



From diffserv-admin@ietf.org  Fri Nov  5 12:10:32 1999
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 MAA02708;
	Fri, 5 Nov 1999 12:10:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04105;
	Fri, 5 Nov 1999 11:40:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04067
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 11:40:02 -0500 (EST)
Received: from dragonfly.corp.home.net (dragonfly.corp.home.net [24.0.31.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19343
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 11:40:00 -0500 (EST)
Received: from dragonfly.corp.home.net (rja@localhost [127.0.0.1])
	by dragonfly.corp.home.net (8.9.3/8.9.3) with ESMTP id LAA10828;
	Fri, 5 Nov 1999 11:38:18 -0500 (EST)
Message-Id: <199911051638.LAA10828@dragonfly.corp.home.net>
X-Mailer: exmh version 2.1.0 09/18/1999
To: rprakash@cdotb.ernet.in
cc: diffserv@ietf.org
Subject: Re: [Diffserv] Reference/Example implementation for DiffServ. 
In-Reply-To: Message from Prakash R <rprakash@cdotb.ernet.in> 
   of "Thu, 04 Nov 1999 14:03:58 GMT." <3821924E.A45B025D@cdotb.ernet.in> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Nov 1999 11:38:18 -0500
From: Ran Atkinson <rja@corp.home.net>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


% 2) Is DiffServ already being used anywhere?

The "Classic DiffServ" defined in the original RFC definition
of the IP Precedence bits was first deployed operationally in
the 80s and continues to be used in several all-continents
private internetworks.  Proteon routers had a particularly elegant
implementation of OSPF that supported the IP Precedence bits,
for example.  Classic DiffServ has not been widely deployed 
in full form in any commercial networks as far as I know.

The "Network Control" and "Internet Control" precedence settings
in "Classic DiffServ" ARE widely deployed in most networks,
private and commercial -- most IP routers implement this by default 
to ensure that routing protocol traffic is given preference 
over non-network-control traffic.  New "DiffServ" has been designed
to protect this important widespread use.

Ran
rja@corp.home.net



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



From diffserv-admin@ietf.org  Fri Nov  5 12:23:23 1999
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 MAA07788;
	Fri, 5 Nov 1999 12:23:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04264;
	Fri, 5 Nov 1999 11:42:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04225
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 11:42:18 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20286
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 11:42:19 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA70666; Fri, 5 Nov 1999 16:41:42 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA25594; Fri, 5 Nov 1999 16:41:40 GMT
Message-ID: <38230870.3CE0C292@hursley.ibm.com>
Date: Fri, 05 Nov 1999 10:40:16 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: CATANZARITI Sergio FTR&D/TI <sergio.catanzariti@rd.francetelecom.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] AF and PHB mutability requirements
References: <337055FBC675D311A85D00508B5A9C4F01A4F6@u-mail.rd.francetelecom.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Sergio,

The diffserv architecture doesn't place any limits on re-marking,
as long as the re-marking conforms with the traffic conditioning
specification in place.

It is quite acceptable for individual PHB specifications to
place limits on re-marking (for example the re-ordering constraint
mentioned in AF).

There is nothing that I can see that stops a TCS specifying
that AF traffic should be re-marked as EF to cross a VLL, but then it
might need to go through an MF classifier at the other end to restore
the AF marking.

  Brian

> CATANZARITI Sergio FTR&D/TI wrote:
> 
> In the AF PHB Group spec, there is no specific PHB mutability section.
> But the possibility is given under Traffic Conditioning Actions:
> 
> > A DS domain MAY at the edge of a domain control the amount of AF
> traffic that enters or exits the domain at various levels of drop
> precedence. Such traffic conditioning actions MAY include traffic
> shaping, discarding of packets, increasing or decreasing the drop
> precedence of packets, and reassigning of packets to other AF classes.
> However, the traffic conditioning actions MUST NOT cause reordering of
> packets of the same microflow.>
> 
> So, is it possible to reassign packets ONLY to different AF classes as
> action of traffic conditioning?
> What about other SLS-based boundary service semantics changing
> reasons? The latter case seems in sync with the principles of the
> architecture of the diff serv model where PHB/DSCP mapping looks like
> more a service definition and implementation issue, although EF
> prohibits that:
> 
> >Mutability Packets marked for EF PHB MAY be remarked at a DS domain
> boundary only to other codepoints that satisfy the EF PHB. Packets
> marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by
> a DS domain>
> 
> Please, could somebody from the AF document authors team clarify that
> and put it in a PHB mutability section?
> 
> The problem is that looking at both the DS framework and the
> architecture document, this PHB/DSCP re-marking/changing issue looks
> really confusing (at least to me):
> 
> From the architecture document:
> 
> >2.3.3.2 Markers Packet markers set the DS field of a packet to a
> particular codepoint, adding the marked packet to a particular DS
> behavior aggregate. The marker may be configured to mark all packets
> which are steered to it to a single codepoint, or may be configured to
> mark a packet to one of a set of codepoints used to select a PHB in a
> PHB group, according to the state of a meter. When the marker changes
> the codepoint in a packet it is said to have "re-marked" the packet.>
> 
> From the framework document:
> 
> >Markers police by re-marking the traffic with a different codepoint
> either - to demote out-of-profile traffic to a different PHB, - as a
> result of an SLS which specifies codepoint mutation, or - to ensure
> that only valid codepoints are used within the domain.>
> 
> So, is it possible to change DSCP as long it is PHB service semantic
> compatible? Is it possible to change DSCP as long it is
> SLS-compatible? Is it possible to change DSCP as long it is PHB-group
> compatible? All of the above, none of the above, open issue, out of
> scope issues, etc..
> 
> Please, an explanation short and as simple as possible considering
> that I have attended only the elementary school (but a public one,
> luckily enough), not a discussions flame.
> 
> Thanks,
> Sergio
> 
>      --------------------------------------------------------------------
> 
>      Sergio Catanzariti
>      Senior Project Manager, Technology Integration
>      France Telecom R&D
>      1000 Marina Boulevard Suite 300
>      Brisbane CA 94005
>      Tel. 650-875-1526
>      Fax. 650-875-1505
>      email:sergio.catanzariti@rd.francetelecom.com
>      --------------------------------------------------------------------

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



From diffserv-admin@ietf.org  Fri Nov  5 12:33:55 1999
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 MAA12027;
	Fri, 5 Nov 1999 12:33:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04700;
	Fri, 5 Nov 1999 11:50:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA04664
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 11:49:59 -0500 (EST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23398
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 11:50:01 -0500 (EST)
Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Fri Nov  5 11:49:39 EST 1999
Received: from caip.rutgers.edu (blhobvmpc [135.180.161.189])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA28178;
	Fri, 5 Nov 1999 11:49:37 -0500 (EST)
Message-ID: <38230C85.7D3AF386@caip.rutgers.edu>
Date: Fri, 05 Nov 1999 11:57:41 -0500
From: Arni Raghu <arni@caip.rutgers.edu>
Organization: Rutgers Univ..
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rprakash@cdotb.ernet.in
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Reference/Example implementation for DiffServ.
References: <3821924E.A45B025D@cdotb.ernet.in>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Prakash R wrote:
> 
> I've recently joined the group. So please do bear with me if the
> questions are repeated.
> 
> General aspects:
> ----------------
> 1) Is there a FAQ for this mailing list?

Nope...

> 
> DiffServ Deployment:
> --------------------
> 
> 2) Is DiffServ already being used anywhere?

Not that I know of..used in many test networks..but not on any revenue
based networks..pls correct me here..

> 
> 3) Is there a reference/example implementation of DiffServ which one can
>    use as a model? Specifically with respect to the
> provisioning/charging
>    aspects.

There have been many implementations on Linux/freeBSD etc..on the
Diffserv PHBs and various components..

You might want to look at::

http://www.INDEX.Berkeley.EDU/public/index.phtml

> 
> DiffServ/QoS basics:
> --------------------
> 
> 4) List of papers that one must've read to understand the QoS issues
>    involved in DiffServ?

REad the papers that talk about the evaluation of teh Diffserv
PHBs..there are so many of them now..

> 
> 5) What sort of Mathematics will I need to learn to understand the
>    theoretical issues behind the various decisions taken in DiffServ WG?

Just read the drafts/RFCs..u do not need to be a math expert to
understand that.

The one paper is::

ftp://gaia.cs.umass.edu/pub/Sahu99_Diffserv-TR-99-09.ps.gz


hth,
Arni
> 
> I would appreciate information regarding the above.
> 
> - Thanks in advance,
> --
> Prakash R
> Co-ordinating Engineer, Internet Telephony Group
> ===========================================================================
> C-DOT (Centre for Development of Telematics)
> 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
> Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
> ===========================================================================
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Fri Nov  5 14:30:07 1999
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 OAA04847;
	Fri, 5 Nov 1999 14:30:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA10825;
	Fri, 5 Nov 1999 14:04:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA10790
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 14:04:04 -0500 (EST)
Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23891
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 14:04:08 -0500 (EST)
Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0)
	id <W1A4Q1DF>; Fri, 5 Nov 1999 14:03:37 -0500
Message-ID: <75ADD7496F0BD211ADC000104B8846CF789515@rerun.lucentctc.com>
From: "Weiss, Walter" <WWeiss@lucentctc.com>
To: "'CATANZARITI Sergio FTR&D/TI'"
	 <sergio.catanzariti@rd.francetelecom.com>,
        diffserv@ietf.org
Subject: RE: [Diffserv] AF and PHB mutability requirements
Date: Fri, 5 Nov 1999 14:03:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Sergio,
 
The AF and EF PHBs allow specific behaviors. However, services are
constructed by configuring these behaviors (bandwidth, delay/queue depth,
drop thresholds, etc.). These variations in configuring the behaviors allow
for relatively unique services in any given DS domain. It is the intent of
the services that determines the ideal choices of PHB and configuration
values. This variation in the structure of services across domains leads to
potential mapping (re-marking) requirements. Both the EF and AF RFCs assume
that because these PHBs were choosen by the folks defining the service, it
makes the most sense to preserve the concepts of EF and AF across domains,
even if the packets require re-marking, shaping or dropping due to some SLS
restrictions.
 
If mappings of the service characteristics across domains are such that the
key elements of AF or EF are not the ones that best represent the service,
then there is nothing to prevent such a remarking. For example, if a
VLL-like service is provided using an AF PHB and the next domain only
supports VLL with EF, then it may be quite reasonable to remark from AF to
EF. However, the most compelling characteristic of AF is not its VLL
capability but its congestion management mechanism (drop precedence). If a
service was constructed to use drop precedence, it would be inappropriate to
map that to EF at a domain boundary. Although there nothing to preclude a
domain from remarking between EF and AF, it is not the optimal choice.
Hence, it is discouraged in both RFCs (explicitly in EF and implicitly in
AF).
 
regards,
 
-Walter

-----Original Message-----
From: CATANZARITI Sergio FTR&D/TI
[mailto:sergio.catanzariti@rd.francetelecom.com]
Sent: Friday, November 05, 1999 12:14 AM
To: diffserv@ietf.org <mailto:diffserv@ietf.org> 
Subject: [Diffserv] AF and PHB mutability requirements



In the AF PHB Group spec, there is no specific PHB mutability section. But
the possibility is given under Traffic Conditioning Actions:

> A DS domain MAY at the edge of a domain control the amount of AF traffic
that enters or exits the domain at various levels of drop precedence. Such
traffic conditioning actions MAY include traffic shaping, discarding of
packets, increasing or decreasing the drop precedence of packets, and
reassigning of packets to other AF classes. However, the traffic
conditioning actions MUST NOT cause reordering of packets of the same
microflow.>

So, is it possible to reassign packets ONLY to different AF classes as
action of traffic conditioning? 
What about other SLS-based boundary service semantics changing reasons? The
latter case seems in sync with the principles of the architecture of the
diff serv model where PHB/DSCP mapping looks like more a service definition
and implementation issue, although EF prohibits that:

>Mutability Packets marked for EF PHB MAY be remarked at a DS domain
boundary only to other codepoints that satisfy the EF PHB. Packets marked
for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain>

Please, could somebody from the AF document authors team clarify that and
put it in a PHB mutability section? 

The problem is that looking at both the DS framework and the architecture
document, this PHB/DSCP re-marking/changing issue looks really confusing (at
least to me): 

From the architecture document: 

>2.3.3.2 Markers Packet markers set the DS field of a packet to a particular
codepoint, adding the marked packet to a particular DS behavior aggregate.
The marker may be configured to mark all packets which are steered to it to
a single codepoint, or may be configured to mark a packet to one of a set of
codepoints used to select a PHB in a PHB group, according to the state of a
meter. When the marker changes the codepoint in a packet it is said to have
"re-marked" the packet.>

From the framework document: 

>Markers police by re-marking the traffic with a different codepoint either
- to demote out-of-profile traffic to a different PHB, - as a result of an
SLS which specifies codepoint mutation, or - to ensure that only valid
codepoints are used within the domain.>

So, is it possible to change DSCP as long it is PHB service semantic
compatible? Is it possible to change DSCP as long it is SLS-compatible? Is
it possible to change DSCP as long it is PHB-group compatible? All of the
above, none of the above, open issue, out of scope issues, etc..

Please, an explanation short and as simple as possible considering that I
have attended only the elementary school (but a public one, luckily enough),
not a discussions flame.

Thanks, 
Sergio 


	--------------------------------------------------------------------

Sergio Catanzariti 
Senior Project Manager, Technology Integration 
France Telecom R&D 
1000 Marina Boulevard Suite 300 
Brisbane CA 94005 
Tel. 650-875-1526 
Fax. 650-875-1505 
email:sergio.catanzariti@rd.francetelecom.com 
-------------------------------------------------------------------- 



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



From diffserv-admin@ietf.org  Fri Nov  5 15:31:17 1999
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 PAA25084;
	Fri, 5 Nov 1999 15:31:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12586;
	Fri, 5 Nov 1999 15:00:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12558
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 15:00:27 -0500 (EST)
Received: from n1.sp.cs.cmu.edu (N1.SP.CS.CMU.EDU [128.2.191.178])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14887
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 15:00:31 -0500 (EST)
Received: from NOSSDAV.CMCL.CS.CMU.EDU by n1.sp.cs.cmu.edu id aa05259;
          5 Nov 99 14:59 EST
Message-ID: <3823373B.2201035A@cs.cmu.edu>
Date: Fri, 05 Nov 1999 14:59:55 -0500
From: Ion Stoica <istoica+@cs.cmu.edu>
Organization: School of Computer Science, Carnegie Mellon University
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Constantinos <dovrolis@hertz.ece.wisc.edu>
CC: diffserv@ietf.org, salsano@coritel.it, P.Gevros@cs.ucl.ac.uk
Subject: Re: [Diffserv] EF RFC and loss
References: <199911050339.VAA00358@hertz.ece.wisc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi Constantinos,

Even if you ignore the "clumping" effect, an interior node still needs
to have a buffer whose size is proportional to the number of flows
that traverse that node. As it was mentioned before, per aggregate
regulation will not help. Even if you regulate the EF aggregates at
both the inputs and outputs, the buffer requirements still depend on
the number of flows. In particular, regulating the traffic from each
input to each output, as I believe you proposed, will just result in
having large buffers at the inputs, instead of outputs.

NOTE: To eliminate any confusion, in the followings I will use the
word "flow" to denote the aggregate traffic between an input of an
ingress and an output of an egress node, i.e., the traffic that
follows the same path through a diffserv domain.

For clarity, consider the following simple topology, where 1, 2, 3,
and 4, are ingress routers, and 5, 6, and 7, are interior routers. For
simplicity, assume that all packets have unit size, and that all the
input/output ports run at the same speed. Finally, assume that the
time is divided in slots, where a slot represents the time it takes to
send a packet.

Now, let "o" denote a time slot during which a packet that reaches the
first output of router 7 is sent, and let "." denote a time slot
during which no such packet is sent. The packets are moving from left
to right.

              --
 ........o --|  |
             |1 |                ---
 ........o --|  |-- .......oo --|   |
              --                |   |
                                | 5 |
              --                |   |
 ........o --|  |-- .......oo --|   |-- .....oooo -
             |2 |                ---               \
 ........o --|  |                                   \   --
              --                                     --|  |-- .oooooooo
                                                       |7 |
              --                                     --|  |
 ........o --|  |                                   /   --
             |3 |                ---               /
 ........o --|  |-- .......oo --|   |-- .....oooo -
              --                |   |
                                | 6 |
              --                |   |
 ........o --|  |-- .......oo --|   |
             |4 |                ---
 ........o --|  |
              --

Next, let us concentrate our attention on router 7.  Consider the
following cases:

- no regulation (the EF traffic has strict priority). Then, during the
first four time slots each of the inputs of router 7 receives exactly
four packets, while the output can send at most four packets (recall
that both inputs and outputs run at the same speed).  As a result, the
output needs a buffer of at least four packets.

In general, if you have a router with N inputs, then the output of the
s-th hop needs a buffer of at least (N - 1)*N^{s-1} packets. In our
example, we have N=2, s=3, which gives us a four packet buffer, as
mentioned above.

- each output is restricted to use a certain fraction of the link
capacity (e.g., 20%) for the EF traffic. This case reduces to the
previous one. The only difference is that it will take longer to send
one packet (assuming an idealized fluid flow system). As was mentioned
before this will not decrease the buffer requirements; it will only
increase the delay.

- each output is regulated at slightly more than the aggregated EF
traffic rate. This case can be reduces to the previous one, i.e., the
case in which we allocate the same rate to EF on each link. To achieve
this, just assume enough EF cross traffic (following different paths)
to drive the aggregate on each link to the same value.

- both the inputs and outputs are regulated at slightly more than the
aggregate rates. In particular, an input will regulate the traffic at
its aggregate reserved rate before sending it to the output. While
this will reduce the amount of buffers at the output to a level that
you are mentioning, i.e., the amount of buffer space is equal to the
number of inputs, it will increase the buffer requirements at the
input.

To see this, assume a router that receives at input i aggregate EF
traffic at a rate R, and assume that this consists of n flows of rate
r, i.e., R = n*r. Then assume that n/K of these flows go to the
output j. As a result the traffic from input i to output j will be
regulated to R/K. Now assume that all packets of these n/K flows are
received back-to-back, i.e., it will take

                    t = (n / K)/ R = n / (K*R)

to receive these packets. In contrast, since the rate between input i
and output j is limited to R/K, during the same time input i can
transfer to output j only

                     m = (R/K)*t = n/K^2

packets. Thus, at the end of this interval the input i has to store

                     n/K - m = n/K (1 - 1/K)

packets for output j. It is easy to see that this value is maximized
for K=2. Thus even if you regulate the traffic at the inputs you still
need a buffer of size proportional to the number of flows. And recall
that this is only for one output; the input has to eventually maintain
a buffer for each output port.

Finally, as Stefano noted, taking into account "clumping" will only
increase the buffer requirements.

To summarize, the main points of this discussion are: (a) if you are
concerned with the worst case, then buffer requirements can be
quit large, and (b) per aggregate regulation is of little help in
reducing these buffer requirements.

Please let me know if you have any other comment(s) or question(s).

Thanks,

Ion
 

Constantinos wrote:
> 
> Ion,
> 
> A (late) comment about your last note.
> 
> I think that your analysis for the EF buffer requirements in
> a router leads to very conservative results. One reason is that
> you assume that we can have more than one EF flow in each
> interface (perhaps you think about microflows?).
> The second reason is that you don't take into account that
> that the EF traffic should be regulated at each hop.
> Let me first, though, describe how the EF traffic should be
> aggregated in a router, at least in my understanding.
> 
> Each input or output interface carries at most one EF aggregate.
> In the case of an edge router, the EF aggregate at an input
> interface can be EF microflows, of course.
> 
> Now, in the context of a VLL-type of service, the (explicit or
> sometimes implicit) assumption is that the routes of the EF
> flows are known and fixed. This means that for a certain router,
> the network manager knows how much of the EF traffic from each
> input interface will go to each output interface.
> 
> To simplify slightly, say that a specific output interface receives
> N aggregates of EF traffic, from N input interfaces respectively,
> each having an EF capacity R. In this case, the EF capacity that
> should be reserved in that output interface is N*R (statistical multiplexing
> games with EF traffic are a "no-no"). Additionally, the EF traffic
> that is forwarded to that output interface should be regulated by a
> leaky-bucket shaper with the following parameters:
>         service rate: N*R packets per second
>         max burstiness: 1 packet
>         # of buffers: N-1 packets
>                                                                                 The regulation is necessary so that we avoid the clumping effect that
> Stefano talks about. The queueing delay in the regulator, which can
> be at most (N-1)/(N*R) with GPS, or N/C with strict-priority
> (C is the link's capacity),  is within the queueing delay
> bound of 1/R seconds that EF requires.
> 
> Going back to your example with the 32kbps EF microflows: I think that
> the only case in which we can need 15000 packet buffers or so is in a
> router with 15000 input ports.
> 
> Cheers,
> 
> Constantinos
>

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



From diffserv-admin@ietf.org  Fri Nov  5 15:51:49 1999
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 PAA04861;
	Fri, 5 Nov 1999 15:51:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12817;
	Fri, 5 Nov 1999 15:07:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12787
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 15:07:22 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17808
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 15:07:26 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA12539
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 12:06:57 -0800 (PST)
Message-ID: <382338F5.339D0325@cisco.com>
Date: Fri, 05 Nov 1999 12:07:17 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Note for Tuesday draft authors
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Sorry to send this to the entire list, but I
don't know which co-authors are planning on
being present for the Tuesday diffserv session.

In my note, where I said give me or Brian a copy of
your slide *between* the start of the Monday diffserv
session and the start of the Tuesday diffserv session,
I meant that quite literally. I appreciate it if you
send me an e-copy in advance, but I will not be making
hard copy to take to Tuesday's session. That is your
responsibility. I promise not to lose anything given
to me in the above time frame only.

	Kathie

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



From diffserv-admin@ietf.org  Fri Nov  5 16:10:38 1999
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 QAA12250;
	Fri, 5 Nov 1999 16:10:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA13900;
	Fri, 5 Nov 1999 15:45:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA13869
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 15:45:20 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02212
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 15:45:24 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA17950;
	Fri, 5 Nov 1999 12:44:55 -0800 (PST)
Message-ID: <382341DB.BE78CB35@cisco.com>
Date: Fri, 05 Nov 1999 12:45:15 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] draft-ietf-diffserv-model-01.txt
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Mostly I thought this was a good document and I think
the upfront statement "It is not intended as a guide to hardware
implementation." means that one can take a fairly relaxed
view on some of the stickier points. However, I have some
points to bring up, a few of which are possibly "nits", but
it would be nice to know what other folks think.

1. A minor terminology nit. The term "mirror" seems a
a bit strange to me since you seem to be defining a packet
replication function. It seems like "replicator" would be
more descriptive, but perhaps there is some other justification
behind the choice of "mirror"?

2. The definition of "monitor" is an element that only counts up or
increments; don't you think it might sometime need to count down?
For example, monitoring a queue size?

3. The definition of TCB seems to need work. In the definitions, you
say: 

"A logical datapath element consisting of a number of
other functional datapath elements interconnected in
such a way as to perform a specific set of traffic
conditioning functions on an incoming traffic stream.
A TCB can be thought of as a "black box" with a single
input and output."

and in section 8. you say:
"The classifiers, meters, action elements, and queueing elements
described above can be combined into traffic conditioning blocks
(TCBs).  The TCB is an abstraction of a functional element that may
be used to facilitate the definition of specific traffic conditioning
functionality."

So, I believe the notion is to use the TCB to allow one to define
some grouping of diffserv primitives, possibly with a specific
set of settings for some of their parameters, so that it is
later possible to just refer to that TCB and to just configure
the parameters of it that have been externalized, thus simplifying
configuration. So, the TCB is not an "element" in the same sense
you use that word for diffserv primitives. It is an abstraction, 
allowing you to build up a hierarchy more "cleanly". This is
fine, it just needs to be cleaned up in your text. I also rather
take issue with calling it "black box": when I was in engineering
school, a black box was used to refer to something where you
don't know what's inside it and characterize it by the input-
output relationship. A TCB is actually the opposite, you know
what's in it, you're just chosing to ignore that detail. You
say a "logical datapath element" - I'd suggest perhaps a "logical
datapah entity".

4. Figure 1 and the RSVP-optional box. In diffserv, we have
not made any limitation on what kind of "QoS agent" configures
the diffserv-specific forwarding path primitives. I would
be much more comfortable with a model that showed that there
has to be some functional block that does this and then you
might say, "for example, one could use RSVP to do this as...."

5. Section 4.3 is about considerations for an MPLS router in
doing diffserv classification. This is not a strong objection,
but my feeling is that the MPLS working group should be
defing such functionality in their documents and perhaps
be refering to this document and saying how they differ.
After all, we could specify "other flavors" each time one
came up.

6. Section 7 talks about queue sets and scheduling and does
not mention the CSC PHB group defined in rfc2474. This should
probably be corrected.

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



From diffserv-admin@ietf.org  Fri Nov  5 17:08:58 1999
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 RAA01688;
	Fri, 5 Nov 1999 17:08:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA17080;
	Fri, 5 Nov 1999 16:38:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA17044
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 16:38:21 -0500 (EST)
Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22251
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 16:38:23 -0500 (EST)
Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0)
	id <WHDCL47N>; Fri, 5 Nov 1999 13:37:55 -0800
Message-ID: <D0805D3B448BD211A7990008C7B181300257B890@ftp.extremenetworks.com>
From: Andrew Smith <andrew@extremenetworks.com>
To: "'Kathleen Nichols'" <kmn@cisco.com>, diffserv@ietf.org
Subject: RE: [Diffserv] draft-ietf-diffserv-model-01.txt
Date: Fri, 5 Nov 1999 13:37:55 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Kathie,

In your point 6, I'm not quite sure what "CSC" is but I assume you mean the
old precedence PHB group. In general we tried to be PHB-agnostic in this
draft: where specific PHBs are mentioned is where we thought they provided
useful examples. 

We wrote explicitly about EF and AF in section 7 because we felt that they
have some numerical configuration parameters to them. Precedence PHB group
does not really have those. We say e.g.

"However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
   configuration parameters which strongly suggest the sort of queue
   scheduling algorithm needed to implement them."

The definition of precedence PHBs from RFC2474 does not really supply us
with any knobs to tweak: that's why this was not mentioned.

Now whether we have chosen the right sorts of knobs to discuss for EF and AF
is a separate issue and I think we probably have another round to do on
that.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
****************************************************************


 
> -----Original Message-----
> From: Kathleen Nichols [mailto:kmn@cisco.com]
> Sent: Friday, November 05, 1999 12:45 PM
> To: diffserv@ietf.org
> Subject: [Diffserv] draft-ietf-diffserv-model-01.txt 
...
> 
> 6. Section 7 talks about queue sets and scheduling and does
> not mention the CSC PHB group defined in rfc2474. This should
> probably be corrected.
 

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



From diffserv-admin@ietf.org  Fri Nov  5 17:14:15 1999
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 RAA03400;
	Fri, 5 Nov 1999 17:14:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA16979;
	Fri, 5 Nov 1999 16:37:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA16937
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 16:37:27 -0500 (EST)
Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21856
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 16:37:29 -0500 (EST)
Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1])
	by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id QAA15954;
	Fri, 5 Nov 1999 16:37:25 -0500 (EST)
Message-Id: <199911052137.QAA15954@castillo.torrentnet.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Kathleen Nichols <kmn@cisco.com>
cc: diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt 
In-reply-to: Your message of "Fri, 05 Nov 1999 12:45:15 PST."
             <382341DB.BE78CB35@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Nov 1999 16:37:25 -0500
From: Steve Blake <slblake@torrentnet.com>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Kathleen Nichols wrote:


> 1. A minor terminology nit. The term "mirror" seems a
> a bit strange to me since you seem to be defining a packet
> replication function. It seems like "replicator" would be
> more descriptive, but perhaps there is some other justification
> behind the choice of "mirror"?

Well, someone asked that mirroring be incorporated in the model.
I agree with the need of a better term.

> 2. The definition of "monitor" is an element that only counts up or
> increments; don't you think it might sometime need to count down?
> For example, monitoring a queue size?

As of now this function is assumed to be performed in the enqueueing
element (another term in need of a better replacement IMO).  This could
be considered a parameter of a queue as well.

> 3. The definition of TCB seems to need work. In the definitions, you
> say: 
> 
> "A logical datapath element consisting of a number of
> other functional datapath elements interconnected in
> such a way as to perform a specific set of traffic
> conditioning functions on an incoming traffic stream.
> A TCB can be thought of as a "black box" with a single
> input and output."
> 
> and in section 8. you say:
> "The classifiers, meters, action elements, and queueing elements
> described above can be combined into traffic conditioning blocks
> (TCBs).  The TCB is an abstraction of a functional element that may
> be used to facilitate the definition of specific traffic conditioning
> functionality."
> 
> So, I believe the notion is to use the TCB to allow one to define
> some grouping of diffserv primitives, possibly with a specific
> set of settings for some of their parameters, so that it is
> later possible to just refer to that TCB and to just configure
> the parameters of it that have been externalized, thus simplifying

Right.

> configuration. So, the TCB is not an "element" in the same sense
> you use that word for diffserv primitives. It is an abstraction, 
> allowing you to build up a hierarchy more "cleanly". This is
> fine, it just needs to be cleaned up in your text. I also rather
> take issue with calling it "black box": when I was in engineering
> school, a black box was used to refer to something where you
> don't know what's inside it and characterize it by the input-
> output relationship. A TCB is actually the opposite, you know
> what's in it, you're just chosing to ignore that detail. You
> say a "logical datapath element" - I'd suggest perhaps a "logical
> datapah entity".

Ok.

> 4. Figure 1 and the RSVP-optional box. In diffserv, we have
> not made any limitation on what kind of "QoS agent" configures
> the diffserv-specific forwarding path primitives. I would
> be much more comfortable with a model that showed that there
> has to be some functional block that does this and then you
> might say, "for example, one could use RSVP to do this as...."

Well, I think my co-authors might object, so I will let them argue that
point.  :)

> 5. Section 4.3 is about considerations for an MPLS router in
> doing diffserv classification. This is not a strong objection,
> but my feeling is that the MPLS working group should be
> defing such functionality in their documents and perhaps
> be refering to this document and saying how they differ.
> After all, we could specify "other flavors" each time one
> came up.

This draft takes a pretty liberal view about what bits one could classify
to invoke Diffserv functionality, and IMO MPLS labels fits right into that
set, which is why they were added to Sec. 4.  The intent was only to fold
LSRs into the family of Diffserv routers, without specifying the details.

> 6. Section 7 talks about queue sets and scheduling and does
> not mention the CSC PHB group defined in rfc2474. This should
> probably be corrected.

Ok, but what queue parameters are implied by the definition of the class
selectors?  I don't think any additional ones are, but I will add the
reference.


Thanks for the feedback,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <slblake@torrentnet.com>
Ericsson IP Infrastructure             (919)468-8466 x232



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



From diffserv-admin@ietf.org  Fri Nov  5 19:00:05 1999
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 TAA05243;
	Fri, 5 Nov 1999 19:00:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20355;
	Fri, 5 Nov 1999 18:02:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20319
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 18:02:46 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17641
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 18:02:47 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA82632; Fri, 5 Nov 1999 23:02:12 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA42840; Fri, 5 Nov 1999 23:02:08 GMT
Message-ID: <38236179.353A6F4@hursley.ibm.com>
Date: Fri, 05 Nov 1999 17:00:09 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Andrew Smith <andrew@extremenetworks.com>
CC: "'Kathleen Nichols'" <kmn@cisco.com>, diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
References: <D0805D3B448BD211A7990008C7B181300257B890@ftp.extremenetworks.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

CSC is indeed the class selectors and since they are the only
diffserv out there in the real world today, I think they
should be mentioned whenever generic examples are needed.

   Brian

Andrew Smith wrote:
> 
> Kathie,
> 
> In your point 6, I'm not quite sure what "CSC" is but I assume you mean the
> old precedence PHB group. In general we tried to be PHB-agnostic in this
> draft: where specific PHBs are mentioned is where we thought they provided
> useful examples.
> 
> We wrote explicitly about EF and AF in section 7 because we felt that they
> have some numerical configuration parameters to them. Precedence PHB group
> does not really have those. We say e.g.
> 
> "However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
>    configuration parameters which strongly suggest the sort of queue
>    scheduling algorithm needed to implement them."
> 
> The definition of precedence PHBs from RFC2474 does not really supply us
> with any knobs to tweak: that's why this was not mentioned.
> 
> Now whether we have chosen the right sorts of knobs to discuss for EF and AF
> is a separate issue and I think we probably have another round to do on
> that.
> 
> Andrew
> 
> ****************************************************************
> Andrew Smith                              tel: +1 (408) 579-2821
> Extreme Networks                          fax: +1 (408) 579-3000
> 3585 Monroe St.                   http://www.extremenetworks.com
> Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
> ****************************************************************
> 
> 
> > -----Original Message-----
> > From: Kathleen Nichols [mailto:kmn@cisco.com]
> > Sent: Friday, November 05, 1999 12:45 PM
> > To: diffserv@ietf.org
> > Subject: [Diffserv] draft-ietf-diffserv-model-01.txt
> ...
> >
> > 6. Section 7 talks about queue sets and scheduling and does
> > not mention the CSC PHB group defined in rfc2474. This should
> > probably be corrected.
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Fri Nov  5 19:00:09 1999
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 TAA05261;
	Fri, 5 Nov 1999 19:00:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20501;
	Fri, 5 Nov 1999 18:05:04 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20466
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 18:05:00 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18207
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 18:05:01 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA105450; Fri, 5 Nov 1999 23:04:27 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA13988; Fri, 5 Nov 1999 23:04:26 GMT
Message-ID: <38236204.A885EC2A@hursley.ibm.com>
Date: Fri, 05 Nov 1999 17:02:28 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Steve Blake <slblake@torrentnet.com>
CC: Kathleen Nichols <kmn@cisco.com>, diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
References: <199911052137.QAA15954@castillo.torrentnet.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Steve Blake wrote:
...
> 
> > 4. Figure 1 and the RSVP-optional box. In diffserv, we have
> > not made any limitation on what kind of "QoS agent" configures
> > the diffserv-specific forwarding path primitives. I would
> > be much more comfortable with a model that showed that there
> > has to be some functional block that does this and then you
> > might say, "for example, one could use RSVP to do this as...."
> 
> Well, I think my co-authors might object, so I will let them argue that
> point.  :)

Kathie is absolutely right. As Yoram knows, I've had my doubts about
this part of the model for a long time, and Kathie has articulated
why. The optional box is some sort of QOS manager, which might
be RSVP based or (in at least one product I could mention) might
not be.

   Brian

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



From diffserv-admin@ietf.org  Fri Nov  5 19:03:14 1999
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 TAA06497;
	Fri, 5 Nov 1999 19:03:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA21419;
	Fri, 5 Nov 1999 18:40:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA21393
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 18:40:02 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28018
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 18:39:59 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA12187;
	Fri, 5 Nov 1999 15:38:39 -0800 (PST)
Message-ID: <38236A92.C10831B6@cisco.com>
Date: Fri, 05 Nov 1999 15:38:58 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: Steve Blake <slblake@torrentnet.com>, diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
References: <199911052137.QAA15954@castillo.torrentnet.com> <38236204.A885EC2A@hursley.ibm.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


But I do want to point out that I have no problems (I think) with
including most of the text about using RSVP, but it needs to be
done as an *example* of *one way* to configure or implement the
box's QoS agent/manager.

	Kathie

Brian E Carpenter wrote:
> 
> Steve Blake wrote:
> ...
> >
> > > 4. Figure 1 and the RSVP-optional box. In diffserv, we have
> > > not made any limitation on what kind of "QoS agent" configures
> > > the diffserv-specific forwarding path primitives. I would
> > > be much more comfortable with a model that showed that there
> > > has to be some functional block that does this and then you
> > > might say, "for example, one could use RSVP to do this as...."
> >
> > Well, I think my co-authors might object, so I will let them argue that
> > point.  :)
> 
> Kathie is absolutely right. As Yoram knows, I've had my doubts about
> this part of the model for a long time, and Kathie has articulated
> why. The optional box is some sort of QOS manager, which might
> be RSVP based or (in at least one product I could mention) might
> not be.
> 
>    Brian

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



From diffserv-admin@ietf.org  Fri Nov  5 19:09:02 1999
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 TAA08501;
	Fri, 5 Nov 1999 19:09:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20782;
	Fri, 5 Nov 1999 18:13:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA20672
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 18:13:36 -0500 (EST)
Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20399
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 18:13:38 -0500 (EST)
Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2448.0)
	id <WHDCLVN3>; Fri, 5 Nov 1999 15:13:10 -0800
Message-ID: <D0805D3B448BD211A7990008C7B181300257B892@ftp.extremenetworks.com>
From: Andrew Smith <andrew@extremenetworks.com>
To: "'Brian E Carpenter'" <brian@hursley.ibm.com>
Cc: "'Kathleen Nichols'" <kmn@cisco.com>, diffserv@ietf.org
Subject: RE: [Diffserv] draft-ietf-diffserv-model-01.txt
Date: Fri, 5 Nov 1999 15:13:07 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

In the instance that Kathie cited, we were looking for *specific* examples
that needed numeric parameters, not for generic ones.

But we were trying to describe a model for the complete current set of
diffserv Proposed Standards, not just for today's deployments of them ...
your statement does come over as rather fatalistic in your expectations for
richer diffserv implementations and deployments using the other PHBs.

Andrew

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Friday, November 05, 1999 3:00 PM
> To: Andrew Smith
> Cc: 'Kathleen Nichols'; diffserv@ietf.org
> Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
> 
> 
> CSC is indeed the class selectors and since they are the only
> diffserv out there in the real world today, I think they
> should be mentioned whenever generic examples are needed.
> 
>    Brian
> 
> Andrew Smith wrote:
> > 
> > Kathie,
> > 
> > In your point 6, I'm not quite sure what "CSC" is but I 
> assume you mean the
> > old precedence PHB group. In general we tried to be 
> PHB-agnostic in this
> > draft: where specific PHBs are mentioned is where we 
> thought they provided
> > useful examples.
> > 
> > We wrote explicitly about EF and AF in section 7 because we 
> felt that they
> > have some numerical configuration parameters to them. 
> Precedence PHB group
> > does not really have those. We say e.g.
> > 
> > "However, PHBs such as EF [EF-PHB] and AF [AF-PHB] have
> >    configuration parameters which strongly suggest the sort of queue
> >    scheduling algorithm needed to implement them."
> > 
> > The definition of precedence PHBs from RFC2474 does not 
> really supply us
> > with any knobs to tweak: that's why this was not mentioned.
> > 
> > Now whether we have chosen the right sorts of knobs to 
> discuss for EF and AF
> > is a separate issue and I think we probably have another 
> round to do on
> > that.
> > 
> > Andrew
> > 
> > ****************************************************************
> > Andrew Smith                              tel: +1 (408) 579-2821
> > Extreme Networks                          fax: +1 (408) 579-3000
> > 3585 Monroe St.                   http://www.extremenetworks.com
> > Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
> > ****************************************************************
> > 
> > 
> > > -----Original Message-----
> > > From: Kathleen Nichols [mailto:kmn@cisco.com]
> > > Sent: Friday, November 05, 1999 12:45 PM
> > > To: diffserv@ietf.org
> > > Subject: [Diffserv] draft-ietf-diffserv-model-01.txt
> > ...
> > >
> > > 6. Section 7 talks about queue sets and scheduling and does
> > > not mention the CSC PHB group defined in rfc2474. This should
> > > probably be corrected.
> > 
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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



From diffserv-admin@ietf.org  Fri Nov  5 21:55:58 1999
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 VAA09565;
	Fri, 5 Nov 1999 21:55:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA26291;
	Fri, 5 Nov 1999 21:02:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA26260
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 21:02:22 -0500 (EST)
Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17529
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 21:02:27 -0500 (EST)
Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33])
	by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) with SMTP id UAA02196;
	Fri, 5 Nov 1999 20:02:15 -0600 (CST)
Message-Id: <199911060202.UAA02196@hertz.ece.wisc.edu>
Date: Fri, 5 Nov 1999 20:02:15 -0600 (CST)
From: Constantinos <dovrolis@hertz.ece.wisc.edu>
Reply-To: Constantinos <dovrolis@hertz.ece.wisc.edu>
Subject: Re: [Diffserv] EF RFC and loss
To: istoica+@cs.cmu.edu
Cc: diffserv@ietf.org, salsano@coritel.it, P.Gevros@cs.ucl.ac.uk
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pnpWAzvT1TF9pm1/Koyi8g==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hmm.. so what I had in mind is regulation at any multiplexing
and demultiplexing point (both output and input interfaces),
so that the burstiness of the EF aggregate never increases to more
than one packet per 1/R seconds, where R is the capacity of the
EF aggregate at that point. 

In this model, the regulator in the multiplexer of an output interface
would only require a buffer of N packets, where N is the number of
inputs to the multiplexer.

In the case of demultiplexing at an input interface, though,
Ion's last note convinced me that the number of required buffers
is indeed proportional to the number of (macro)flows present
in the EF aggregate of that interface. I refer to the following
part of his email:

> To see this, assume a router that receives at input i aggregate EF
> traffic at a rate R, and assume that this consists of n flows of rate
> r, i.e., R = n*r. Then assume that n/K of these flows go to the
> output j. As a result the traffic from input i to output j will be
> regulated to R/K. Now assume that all packets of these n/K flows are
> received back-to-back, i.e., it will take
> 
>                     t = (n / K)/ R = n / (K*R)
> 
> to receive these packets. In contrast, since the rate between input i
> and output j is limited to R/K, during the same time input i can
> transfer to output j only
> 
>                      m = (R/K)*t = n/K^2
> 
> packets. Thus, at the end of this interval the input i has to store
> 
>                      n/K - m = n/K (1 - 1/K)
> 
> packets for output j. It is easy to see that this value is maximized
> for K=2. Thus even if you regulate the traffic at the inputs you still
> need a buffer of size proportional to the number of flows. And recall
> that this is only for one output; the input has to eventually maintain
> a buffer for each output port.
> 


So, in the worst demultiplexing case (K=2), the input regulator needs n/4 
packet buffers, where n is the number of macroflows in the EF aggregate.
Which can be also thought of as a bound on how much aggregation of EF 
traffic is feasible at each link.

Interesting stuff (even at Friday's evening..)

Constantinos


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



From diffserv-admin@ietf.org  Fri Nov  5 22:23:46 1999
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 WAA22275;
	Fri, 5 Nov 1999 22:23:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA27247;
	Fri, 5 Nov 1999 21:55:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA27216
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 21:55:50 -0500 (EST)
Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09507
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 21:55:51 -0500 (EST)
Received: from hertz.ece.wisc.edu (hertz.ece.wisc.edu [128.104.183.33])
	by hertz.ece.wisc.edu (8.8.8+Sun/8.8.8) with SMTP id UAA02213;
	Fri, 5 Nov 1999 20:55:50 -0600 (CST)
Message-Id: <199911060255.UAA02213@hertz.ece.wisc.edu>
Date: Fri, 5 Nov 1999 20:55:50 -0600 (CST)
From: Constantinos <dovrolis@hertz.ece.wisc.edu>
Reply-To: Constantinos <dovrolis@hertz.ece.wisc.edu>
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt 
To: slblake@torrentnet.com, andrew@extremenetworks.com
Cc: diffserv@ietf.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eBy6HgyqyJWRhunN7q1oVw==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc 
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

A couple of comments on the model draft.

1) Regarding the Class Selectors, I also think that they should be
mentioned. Since these PHBs carry the precedence semantics of the
original TOS byte, they have to provide relative differentiation between
the existing 8 classes, in terms of delays and losses.

A relative differentiation scheme does not have to be "parameter-less",
as in strict-priorities. There are scheduling and buffer management
schemes that provide the "tweaking knobs", as Andrew calls them,
for adjusting the relative delay or loss priority between classes.
For the case of delays, for example, we can use Kleinrock's scheduler
(see "A Delay Dependent Queue Discipline", Journal of the ACM, 14(2), 1967,
which is also described in the 2nd volume of his Queueing Systems
textbook). In this mechanism, a relative-priority parameter is associated 
with each class, controlling the delay spacing between classes. 

Similar dynamic-priority schemes can be devised for buffer management,
differentiating the loss-rate between classes. Which brings me to
the next comment. 

2) As far as I understand, the draft describes the dropping action as 
something that can be performed only on the just arrived packet. 
Am I right? This restricts the loss-rate differentiation that can be 
achieved between classes. A different approach is to do something like:

	- a packet arrives
	- do we need to drop one or more packets? 
	(either because we run out of buffers, as in the drop-tail case, 
	or because the regulator (like RED) says that a packet needs to be
	dropped)
	- if we need to drop a packet, select a backlogged class
	to drop from, and remove a packet from the queue of that class.
	In this way, we have better control of the loss-rate differentiation 
	between classes, since the class-to-drop variable is decoupled from 
	the class-arrived variable.
	

My general feeling reading the draft was that it is very well-written
and concise. What is still not clear to me, though, is whether this model
is really implementation and services-independent. Which is also mentioned
at the "open issues" section, I think.


Constantinos


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



From diffserv-admin@ietf.org  Fri Nov  5 23:57:10 1999
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 XAA05445;
	Fri, 5 Nov 1999 23:57:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA28939;
	Fri, 5 Nov 1999 23:30:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA28908
	for <diffserv@optimus.ietf.org>; Fri, 5 Nov 1999 23:30:16 -0500 (EST)
Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22606
	for <diffserv@ietf.org>; Fri, 5 Nov 1999 23:30:17 -0500 (EST)
Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1])
	by castillo.torrentnet.com (8.9.1/8.9.1) with ESMTP id XAA19467;
	Fri, 5 Nov 1999 23:30:18 -0500 (EST)
Message-Id: <199911060430.XAA19467@castillo.torrentnet.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Constantinos <dovrolis@hertz.ece.wisc.edu>
cc: diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt 
In-reply-to: Your message of "Fri, 05 Nov 1999 20:55:50 CST."
             <199911060255.UAA02213@hertz.ece.wisc.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Nov 1999 23:30:17 -0500
From: Steve Blake <slblake@torrentnet.com>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> A couple of comments on the model draft.
> 
> 1) Regarding the Class Selectors, I also think that they should be
> mentioned. Since these PHBs carry the precedence semantics of the
> original TOS byte, they have to provide relative differentiation between
> the existing 8 classes, in terms of delays and losses.

To be precise, 2474 does not define any PHBs, but only requirements
on acceptable PHBs which could be mapped to by the Class Selector codepoints.
And I agree with Andrew in that I don't see any obvious parameters implied
by these requirements that differ significantly from what is specified in the
model.

> A relative differentiation scheme does not have to be "parameter-less",
> as in strict-priorities. There are scheduling and buffer management
> schemes that provide the "tweaking knobs", as Andrew calls them,
> for adjusting the relative delay or loss priority between classes.
> For the case of delays, for example, we can use Kleinrock's scheduler
> (see "A Delay Dependent Queue Discipline", Journal of the ACM, 14(2), 1967,
> which is also described in the 2nd volume of his Queueing Systems
> textbook). In this mechanism, a relative-priority parameter is associated 
> with each class, controlling the delay spacing between classes. 

The only parameter I see falling out of this scheme is relative average
delay ratios between queues.  That is worth considering.

> Similar dynamic-priority schemes can be devised for buffer management,
> differentiating the loss-rate between classes. Which brings me to
> the next comment. 
> 
> 2) As far as I understand, the draft describes the dropping action as 
> something that can be performed only on the just arrived packet. 
> Am I right? This restricts the loss-rate differentiation that can be 
> achieved between classes. A different approach is to do something like:

The text implies that the enqueueing element forwards or drops on arrival.
This cannot be changed without combining the enqueueing element and the
queue into a single element given the structure of how the model
interconnects elements.

And we are not specific about which parameters an enqueueing element
might support, so I could see relative loss ratios as feasible.

> 	- a packet arrives
> 	- do we need to drop one or more packets? 
> 	(either because we run out of buffers, as in the drop-tail case, 
> 	or because the regulator (like RED) says that a packet needs to be
> 	dropped)
> 	- if we need to drop a packet, select a backlogged class
> 	to drop from, and remove a packet from the queue of that class.
> 	In this way, we have better control of the loss-rate differentiation 
> 	between classes, since the class-to-drop variable is decoupled from 
> 	the class-arrived variable.

Sec. 6.6 is explicit in that an enqueueing element may make a discard
decision based on the state of all the queues in a queue set.  So assuming
that the different classes are in different queues, this is possible in
the model.

> My general feeling reading the draft was that it is very well-written
> and concise. What is still not clear to me, though, is whether this model
> is really implementation and services-independent. Which is also mentioned
> at the "open issues" section, I think.

Well, you point to a philosophical problem with the model and the MIB
drafts which I am very sympathetic with, namely why did we go to all the
trouble to standardize abstract PHBs when we are going to define fairly
detailed queueing parameters in the model and the MIB?  The argument in 
favor of the MIB/model parameters is that they are needed to manage actual
implementations, and that the exotic stuff is not getting implemented to
any significant extent.  The alternative to this approach is to define
PHB-specific MIBs, but that obviously comes at some non-trivial cost.


Regards,




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake                  <slblake@torrentnet.com>
Ericsson IP Infrastructure             (919)468-8466 x232



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



From diffserv-admin@ietf.org  Sun Nov  7 08:18:10 1999
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 IAA15128;
	Sun, 7 Nov 1999 08:18:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA04861;
	Sun, 7 Nov 1999 07:43:21 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA04829
	for <diffserv@optimus.ietf.org>; Sun, 7 Nov 1999 07:43:17 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03733
	for <diffserv@ietf.org>; Sun, 7 Nov 1999 07:43:22 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA21038; Sun, 7 Nov 1999 12:42:51 GMT
Received: from hursley.ibm.com (lig32-227-58-99.us.lig-dial.ibm.com [32.227.58.99]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA24262; Sun, 7 Nov 1999 12:42:49 GMT
Message-ID: <38256E05.42DDE5E3@hursley.ibm.com>
Date: Sun, 07 Nov 1999 06:18:13 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Kathleen Nichols <kmn@cisco.com>
CC: Steve Blake <slblake@torrentnet.com>, diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
References: <199911052137.QAA15954@castillo.torrentnet.com> <38236204.A885EC2A@hursley.ibm.com> <38236A92.C10831B6@cisco.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

No disagreement with that.

  Brian

Kathleen Nichols wrote:
> 
> But I do want to point out that I have no problems (I think) with
> including most of the text about using RSVP, but it needs to be
> done as an *example* of *one way* to configure or implement the
> box's QoS agent/manager.
> 
>         Kathie
> 
> Brian E Carpenter wrote:
> >
> > Steve Blake wrote:
> > ...
> > >
> > > > 4. Figure 1 and the RSVP-optional box. In diffserv, we have
> > > > not made any limitation on what kind of "QoS agent" configures
> > > > the diffserv-specific forwarding path primitives. I would
> > > > be much more comfortable with a model that showed that there
> > > > has to be some functional block that does this and then you
> > > > might say, "for example, one could use RSVP to do this as...."
> > >
> > > Well, I think my co-authors might object, so I will let them argue that
> > > point.  :)
> >
> > Kathie is absolutely right. As Yoram knows, I've had my doubts about
> > this part of the model for a long time, and Kathie has articulated
> > why. The optional box is some sort of QOS manager, which might
> > be RSVP based or (in at least one product I could mention) might
> > not be.
> >
> >    Brian



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



From diffserv-admin@ietf.org  Sun Nov  7 08:32:12 1999
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 IAA20958;
	Sun, 7 Nov 1999 08:32:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA04893;
	Sun, 7 Nov 1999 07:43:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA04854
	for <diffserv@optimus.ietf.org>; Sun, 7 Nov 1999 07:43:21 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03760
	for <diffserv@ietf.org>; Sun, 7 Nov 1999 07:43:26 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA105726; Sun, 7 Nov 1999 12:42:55 GMT
Received: from hursley.ibm.com (lig32-227-58-99.us.lig-dial.ibm.com [32.227.58.99]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA24272; Sun, 7 Nov 1999 12:42:53 GMT
Message-ID: <38256E96.C79D8C4C@hursley.ibm.com>
Date: Sun, 07 Nov 1999 06:20:38 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Steve Blake <slblake@torrentnet.com>
CC: Constantinos <dovrolis@hertz.ece.wisc.edu>, diffserv@ietf.org
Subject: Re: [Diffserv] draft-ietf-diffserv-model-01.txt
References: <199911060430.XAA19467@castillo.torrentnet.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I'd be perfectly happy if the draft said that the class selectors
don't [necessarily] need any parameters; my point is that people
tend to spend all their ink on AF and EF, and that is not right.

  Brian

Steve Blake wrote:
> 
> > A couple of comments on the model draft.
> >
> > 1) Regarding the Class Selectors, I also think that they should be
> > mentioned. Since these PHBs carry the precedence semantics of the
> > original TOS byte, they have to provide relative differentiation between
> > the existing 8 classes, in terms of delays and losses.
> 
> To be precise, 2474 does not define any PHBs, but only requirements
> on acceptable PHBs which could be mapped to by the Class Selector codepoints.
> And I agree with Andrew in that I don't see any obvious parameters implied
> by these requirements that differ significantly from what is specified in the
> model.
> 
> > A relative differentiation scheme does not have to be "parameter-less",
> > as in strict-priorities. There are scheduling and buffer management
> > schemes that provide the "tweaking knobs", as Andrew calls them,
> > for adjusting the relative delay or loss priority between classes.
> > For the case of delays, for example, we can use Kleinrock's scheduler
> > (see "A Delay Dependent Queue Discipline", Journal of the ACM, 14(2), 1967,
> > which is also described in the 2nd volume of his Queueing Systems
> > textbook). In this mechanism, a relative-priority parameter is associated
> > with each class, controlling the delay spacing between classes.
> 
> The only parameter I see falling out of this scheme is relative average
> delay ratios between queues.  That is worth considering.
> 
> > Similar dynamic-priority schemes can be devised for buffer management,
> > differentiating the loss-rate between classes. Which brings me to
> > the next comment.
> >
> > 2) As far as I understand, the draft describes the dropping action as
> > something that can be performed only on the just arrived packet.
> > Am I right? This restricts the loss-rate differentiation that can be
> > achieved between classes. A different approach is to do something like:
> 
> The text implies that the enqueueing element forwards or drops on arrival.
> This cannot be changed without combining the enqueueing element and the
> queue into a single element given the structure of how the model
> interconnects elements.
> 
> And we are not specific about which parameters an enqueueing element
> might support, so I could see relative loss ratios as feasible.
> 
> >       - a packet arrives
> >       - do we need to drop one or more packets?
> >       (either because we run out of buffers, as in the drop-tail case,
> >       or because the regulator (like RED) says that a packet needs to be
> >       dropped)
> >       - if we need to drop a packet, select a backlogged class
> >       to drop from, and remove a packet from the queue of that class.
> >       In this way, we have better control of the loss-rate differentiation
> >       between classes, since the class-to-drop variable is decoupled from
> >       the class-arrived variable.
> 
> Sec. 6.6 is explicit in that an enqueueing element may make a discard
> decision based on the state of all the queues in a queue set.  So assuming
> that the different classes are in different queues, this is possible in
> the model.
> 
> > My general feeling reading the draft was that it is very well-written
> > and concise. What is still not clear to me, though, is whether this model
> > is really implementation and services-independent. Which is also mentioned
> > at the "open issues" section, I think.
> 
> Well, you point to a philosophical problem with the model and the MIB
> drafts which I am very sympathetic with, namely why did we go to all the
> trouble to standardize abstract PHBs when we are going to define fairly
> detailed queueing parameters in the model and the MIB?  The argument in
> favor of the MIB/model parameters is that they are needed to manage actual
> implementations, and that the exotic stuff is not getting implemented to
> any significant extent.  The alternative to this approach is to define
> PHB-specific MIBs, but that obviously comes at some non-trivial cost.
> 
> Regards,
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steven L. Blake                  <slblake@torrentnet.com>
> Ericsson IP Infrastructure             (919)468-8466 x232
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/



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



From diffserv-admin@ietf.org  Mon Nov  8 06:58:04 1999
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 GAA26554;
	Mon, 8 Nov 1999 06:58:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA09639;
	Mon, 8 Nov 1999 06:17:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA09606
	for <diffserv@optimus.ietf.org>; Mon, 8 Nov 1999 06:17:31 -0500 (EST)
Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08447
	for <diffserv@ietf.org>; Mon, 8 Nov 1999 06:17:22 -0500 (EST)
Received: from paulista.di.ufpe.br (paulista [150.161.2.50])
	by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id JAA07423;
	Mon, 8 Nov 1999 09:16:25 -0200 (EDT)
Received: (from cak@localhost)
	by paulista.di.ufpe.br (8.9.1/8.9.1) id JAA23867;
	Mon, 8 Nov 1999 09:16:24 -0200 (EDT)
Date: Mon, 8 Nov 1999 09:16:24 -0200 (EDT)
From: Carlos Alberto Kamienski <cak@di.ufpe.br>
X-Sender: cak@paulista
To: Bahri Okuroglu <bahrio@netdns.netas.com.tr>
cc: diffserv@ietf.org
Subject: Re: [Diffserv] Service class of ACK packets
In-Reply-To: <38212F96.FB25810F@rnd.netas.com.tr>
Message-ID: <Pine.GSO.4.02.9911080913170.6504-100000@paulista>
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 GAA09607
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Hi Bahri

Actually there is a paper about this subject, written by Stefan Köhler and
Uwe Schäfer, named:
"Performance Comparison of different Class-and-Drop treatment of Data and
Acknowledgements in DiffServ IP Networks."

You can download it from:
http://www.informatik.uni-wuerzburg.de/reports/tr.html#TR237

Carlos


---------------------------------------------
Carlos Alberto Kamienski       cak@di.ufpe.br

Doutorando em Ciencia da Computacao
Ph.D. Student
Departamento de Informatica - UFPE
---------------------------------------------

On Thu, 4 Nov 1999, Bahri Okuroglu wrote:

> Hi diffservers,
> 
> Are the ACK packets of any flow (AF, EF or BE) always served as BE? Is
> there any work on making the ACK of EF flow served as EF also?
> 
> regards,
> 
> --
> 
> __________________________________________________________
> Bahri OKUROGLU
> 
> Software Design Engineer                     Netas R&D RT6
> mailto:bahrio@rnd.netas.com.tr     http://www.netas.com.tr
> mailto:bahrio@nortelnetworks.com   mailto:bahrio@yahoo.com
> Netas   Alemdag Cad.   Umraniye 81244      ISTANBUL TURKEY
> __________________________________________________________
> 
> 
> 


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



From diffserv-admin@ietf.org  Mon Nov  8 22:48:34 1999
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 WAA26655;
	Mon, 8 Nov 1999 22:48:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA10052;
	Mon, 8 Nov 1999 21:57:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA10021
	for <diffserv@optimus.ietf.org>; Mon, 8 Nov 1999 21:57:49 -0500 (EST)
Received: from natadm.apptitude.com (IDENT:root@natadm.apptitude.com [192.190.175.254])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04554
	for <diffserv@ietf.org>; Mon, 8 Nov 1999 21:57:56 -0500 (EST)
Received: from us-exch2-210.apptitude.com (us-exch2-210.apptitude.com [192.190.175.202])
	by natadm.apptitude.com (8.9.3/8.9.3) with ESMTP id SAA09037
	for <diffserv@ietf.org>; Mon, 8 Nov 1999 18:57:58 -0800
Received: by us-exch2-210.apptitude.com with Internet Mail Service (5.5.2448.0)
	id <T7SLBHFP>; Mon, 8 Nov 1999 18:57:28 -0800
Message-ID: <1E06B998E00BD311A7410008C7BF2D8F01508A@us-exch2-210.apptitude.com>
From: Russell Dietz <rsdietz@apptitude.com>
To: "'diffserv@ietf.org'" <diffserv@ietf.org>
Date: Mon, 8 Nov 1999 18:57:27 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF2A5E.28141D44"
Subject: [Diffserv] Current location of draft-ietf-diffserv-mib-01.txt?
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF2A5E.28141D44
Content-Type: text/plain;
	charset="iso-8859-1"

Hello draft-ietf-diffserv-mib-01.txt authors,

The location which was supplied...

ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.tx
t

... is no longer available.  Please post this document to some place where
we can all review.  Thanks!

Regards,

Russ

Russell Dietz
VP & Chief Technology Officer
Apptitude, Inc.
6330 San Ignacio Ave
San Jose, CA, USA 95119-1209
Tel: +1-408-574-2256
Fax: +1-408-224-1038
mailto: rsdietz@apptitude.com
http://www.apptitude.com 


------_=_NextPart_001_01BF2A5E.28141D44
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Current location of draft-ietf-diffserv-mib-01.txt?</TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Century Gothic">Hello draft-ietf-diffserv-mib-01.txt =
authors,</FONT>
</P>

<P><FONT FACE=3D"Century Gothic">The location which was =
supplied...</FONT>
</P>

<P><FONT FACE=3D"Century Gothic"><A =
HREF=3D"ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffse=
rv-mib-01.txt" =
TARGET=3D"_blank">ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-i=
etf-diffserv-mib-01.txt</A></FONT>
</P>

<P><FONT FACE=3D"Century Gothic">... is no longer available.&nbsp; =
Please post this document to some place where we can all review.&nbsp; =
Thanks!</FONT>
</P>

<P><FONT FACE=3D"Century Gothic">Regards,</FONT>
</P>

<P><FONT FACE=3D"Century Gothic">Russ</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Lucida Handwriting">Russell =
Dietz</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">VP &amp; Chief =
Technology Officer</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D4 FACE=3D"Garamond">Apptitude, =
Inc.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">6330 San Ignacio =
Ave</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">San Jose, CA, USA =
95119-1209</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">Tel: =
+1-408-574-2256</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">Fax: =
+1-408-224-1038</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">mailto: =
rsdietz@apptitude.com</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"http://www.apptitude.com" =
TARGET=3D"_blank">http://www.apptitude.com</A> </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF2A5E.28141D44--

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



From diffserv-admin@ietf.org  Tue Nov  9 07:40:54 1999
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 HAA27401;
	Tue, 9 Nov 1999 07:40:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA28310;
	Tue, 9 Nov 1999 06:51:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA28284
	for <diffserv@optimus.ietf.org>; Tue, 9 Nov 1999 06:51:50 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06855
	for <diffserv@ietf.org>; Tue, 9 Nov 1999 06:51:57 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA14632; Tue, 9 Nov 1999 11:51:21 GMT
Received: from hursley.ibm.com (lig32-227-59-12.us.lig-dial.ibm.com [32.227.59.12]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA41232; Tue, 9 Nov 1999 11:51:06 GMT
Message-ID: <38280A39.C554579D@hursley.ibm.com>
Date: Tue, 09 Nov 1999 05:49:13 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Russell Dietz <rsdietz@apptitude.com>
CC: "'diffserv@ietf.org'" <diffserv@ietf.org>
Subject: Re: [Diffserv] Current location of draft-ietf-diffserv-mib-01.txt?
References: <1E06B998E00BD311A7410008C7BF2D8F01508A@us-exch2-210.apptitude.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

As I said recently

> In case anyone has trouble with the ftp: URL for the MIB,
> there is another copy at
> http://www.adtech.icair.org/brian/draft-ietf-diffserv-mib-01.txt
> 
> Again apologies that it didn't make it into the Internet-Drafts
> directory; from the email I saw it seems to have missed the
> cutoff by a whisker.
> 

This will be removed once the official version is in the
IETF directory.

  Brian


> Russell Dietz wrote:
> 
> Hello draft-ietf-diffserv-mib-01.txt authors,
> 
> The location which was supplied...
> 
> ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt
> 
> ... is no longer available.  Please post this document to some place
> where we can all review.  Thanks!
> 
> Regards,
> 
> Russ
> 
> Russell Dietz
> VP & Chief Technology Officer
> Apptitude, Inc.
> 6330 San Ignacio Ave
> San Jose, CA, USA 95119-1209
> Tel: +1-408-574-2256
> Fax: +1-408-224-1038
> mailto: rsdietz@apptitude.com
> http://www.apptitude.com

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



From diffserv-admin@ietf.org  Tue Nov  9 22:11:18 1999
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 WAA14232;
	Tue, 9 Nov 1999 22:11:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA26448;
	Tue, 9 Nov 1999 21:35:14 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA26415
	for <diffserv@optimus.ietf.org>; Tue, 9 Nov 1999 21:35:04 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26053
	for <diffserv@ietf.org>; Tue, 9 Nov 1999 21:35:08 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id SAA25001
	for <diffserv@external.cisco.com>; Tue, 9 Nov 1999 18:33:28 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by proxy2.cisco.com with SMTP (MailShield v1.5); Tue, 09 Nov 1999 18:36:57 -0800
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <WTH9KJ0D>; Tue, 9 Nov 1999 18:27:35 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A606AD2D63@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: slblake@torrentnet.com, andrew@extremenetworks.com
Cc: diffserv@external.cisco.com
Date: Tue, 9 Nov 1999 18:11:04 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF2B23.2436F276"
X-SMTP-HELO: dfssl.exchange.microsoft.com
X-SMTP-MAIL-FROM: yoramb@Exchange.Microsoft.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: dfssl.exchange.microsoft.com [131.107.88.59]
Subject: [Diffserv] Summary of feedback on conceptual model draft
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF2B23.2436F276
Content-Type: text/plain;
	charset="iso-8859-1"

Steve, Andrew:

Brian presented Steve's slides at the diffserv WG meeting last night. I
attempted to represent your last round of changes to the draft as faithfully
as possible. Though i'm not the official scribe of the meeting, I took notes
regarding feedback on the draft. Others that attended - pls feel free to
jump in and correct as appropriate...

Here goes:

1. As noted by STeve, the term 'mirroring' needs to be replaced. Suggested
alternatives included:
splitter, tee, tap (as in wire-tap), inverse-mux... 
I think that the point is to use a term that makes it clear that this is a
logical copy, not a physical copy (as in for example, multicast).

2. Some expressed the opinion that the abstraction of queus in terms of max
rate/min rate is too simplistic to implement the queuing mechanisms that
they envisioned. Others (including at least on emajor router
vendor/implementor) indicated that the queuing abstraction in the draft
enables the expression of a variety of queuing mechanisms including those
that are most used. Suggestion to those who are not happy with the current
abstraction - write to the mailing list. Dan Grossman offered to submit text
on this to the list. 

Aside: A recurring theme realted to the purpose of the draft and the nature
of indirection intended. The draft attempts to identify the *types* of
traffic conditioning elements (e.g. meter, classifier, etc.) and to offer a
minimal set of *sub-types* of these types, with the parameter set that would
be appropriate. For example - a 'classifier' is a TC element and a BA
classifier is a sub-type of a classifier that has a six-bit field as its
only parameter. The draft *does not* state that the set of sub-types is
exhaustive. On the contrary, it suggests that anybody can define a new
sub-type, by specifying the parameter set that is appropriate (and the name
of the new sub-type). The draft *offers* a minimal set of sub-types that is
believed to be useful and necessary for realizing basic implementations of a
diffserv router. 

Some suggested that the draft should not define any 'sub-types'. However,
the counterpoint presented is that without specifying a minimal set of
sub-types, the draft would not go far enough as it would not fulfill its
purpose of  specifying the basis of a diffserv MIB needed to implement a
diffserv router. Since the draft allows for additional sub-types to be
defined in other drafts, there is no harm in offering a minimal subset in
this draft.

3. There was a discussion of whether the queuing parameters should include 
a. a value and a flag indicating whether that value is a max rate or a min
rate.  
b. two values, one for max rate, one for min rate
Suggestion was made that 'b' is preferrable, as it would allow for the
specification of both a max and min rate simultaneously. It would also allow
for a special value to indicate 'unspecified' min rate and/or max rate.

4. There are words in the Glossary  (section 2) to the effect that a TCB has
a "single input and output". This conflicts with some of the sample TCB
diagrams and was believed by the group to be overly restrictive. A TCB
should be allowed to have an arbitrarty number of inputs/outputs. One of the
slides presented, suggested a 1:1 nature of a TCB. Nobody really understood
what was meant by this. We assumed that it referred to the 1 input, 1 output
restriction, which should be removed.

5. There are words in the draft to the effect that a monitor 'increments'
for every packet passing through it. This was also believed to be overly
restrictive and the suggestion was made that it be specified as something
that simply 'counts', with no specification as to whether it counts 'up' or
'down'.

6. There was a suggestion that we look at the 'RFC for the cable device MIB'
for an example of traffic conditioning abstractions.

7. There was some discussion regarding the emphasis/de-emphasis of RSVP as a
configuration mechanism. The following points were made:
a. to the extent that it is mentioned, it should be cited as an *example of
one mechanism* to effect configuration.
b. that it should be captured as a 'qos configuration box'.
c. that it should not simply be captured as a 'qos configuration box'
because there is already a box titled 'diffserv config and management
interface' and that the box labeled RSVP is sufficiently different because
it represents a configuration mechanism that tends to be much more dynamic
and much finer grain (per-microflow) a mechanism than represented by its
diffserv config counterpart.
d. that MPLS is another example of the need for a dynamic, finer grain
configuration mechanism that justifies using two boxes to represent the
different types of configuration.

8. The question was asked as to whether MPLS support required anything
additional. Response was that the only requirement for MPLS appears to be
that the model support a classifier sub-type for MPLS.

That's all I have.

Yoram

------_=_NextPart_001_01BF2B23.2436F276
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>Summary of feedback on conceptual model draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Steve, Andrew:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Brian presented Steve's slides at the =
diffserv WG meeting last night. I attempted to represent your last =
round of changes to the draft as faithfully as possible. Though i'm not =
the official scribe of the meeting, I took notes regarding feedback on =
the draft. Others that attended - pls feel free to jump in and correct =
as appropriate...</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here goes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. As noted by STeve, the term =
'mirroring' needs to be replaced. Suggested alternatives =
included:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">splitter, tee, tap (as in wire-tap), =
inverse-mux... </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I think that the point is to use a =
term that makes it clear that this is a logical copy, not a physical =
copy (as in for example, multicast).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. Some expressed the opinion that the =
abstraction of queus in terms of max rate/min rate is too simplistic to =
implement the queuing mechanisms that they envisioned. Others =
(including at least on emajor router vendor/implementor) indicated that =
the queuing abstraction in the draft enables the expression of a =
variety of queuing mechanisms including those that are most used. =
Suggestion to those who are not happy with the current abstraction - =
write to the mailing list. Dan Grossman offered to submit text on this =
to the list. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Aside: A recurring theme realted to =
the purpose of the draft and the nature of indirection intended. The =
draft attempts to identify the *types* of traffic conditioning elements =
(e.g. meter, classifier, etc.) and to offer a minimal set of =
*sub-types* of these types, with the parameter set that would be =
appropriate. For example - a 'classifier' is a TC element and a BA =
classifier is a sub-type of a classifier that has a six-bit field as =
its only parameter. The draft *does not* state that the set of =
sub-types is exhaustive. On the contrary, it suggests that anybody can =
define a new sub-type, by specifying the parameter set that is =
appropriate (and the name of the new sub-type). The draft *offers* a =
minimal set of sub-types that is believed to be useful and necessary =
for realizing basic implementations of a diffserv router. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Some suggested that the draft should =
not define any 'sub-types'. However, the counterpoint presented is that =
without specifying a minimal set of sub-types, the draft would not go =
far enough as it would not fulfill its purpose of&nbsp; specifying the =
basis of a diffserv MIB needed to implement a diffserv router. Since =
the draft allows for additional sub-types to be defined in other =
drafts, there is no harm in offering a minimal subset in this =
draft.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3. There was a discussion of whether =
the queuing parameters should include </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a. a value and a flag indicating =
whether that value is a max rate or a min rate.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">b. two values, one for max rate, one =
for min rate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Suggestion was made that 'b' is =
preferrable, as it would allow for the specification of both a max and =
min rate simultaneously. It would also allow for a special value to =
indicate 'unspecified' min rate and/or max rate.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">4. There are words in the =
Glossary&nbsp; (section 2) to the effect that a TCB has a &quot;single =
input and output&quot;. This conflicts with some of the sample TCB =
diagrams and was believed by the group to be overly restrictive. A TCB =
should be allowed to have an arbitrarty number of inputs/outputs. One =
of the slides presented, suggested a 1:1 nature of a TCB. Nobody really =
understood what was meant by this. We assumed that it referred to the 1 =
input, 1 output restriction, which should be removed.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">5. There are words in the draft to the =
effect that a monitor 'increments' for every packet passing through it. =
This was also believed to be overly restrictive and the suggestion was =
made that it be specified as something that simply 'counts', with no =
specification as to whether it counts 'up' or 'down'.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">6. There was a suggestion that we look =
at the 'RFC for the cable device MIB' for an example of traffic =
conditioning abstractions.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">7. There was some discussion regarding =
the emphasis/de-emphasis of RSVP as a configuration mechanism. The =
following points were made:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a. to the extent that it is mentioned, =
it should be cited as an *example of one mechanism* to effect =
configuration.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">b. that it should be captured as a =
'qos configuration box'.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">c. that it should not simply be =
captured as a 'qos configuration box' because there is already a box =
titled 'diffserv config and management interface' and that the box =
labeled RSVP is sufficiently different because it represents a =
configuration mechanism that tends to be much more dynamic and much =
finer grain (per-microflow) a mechanism than represented by its =
diffserv config counterpart.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">d. that MPLS is another example of the =
need for a dynamic, finer grain configuration mechanism that justifies =
using two boxes to represent the different types of =
configuration.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">8. The question was asked as to =
whether MPLS support required anything additional. Response was that =
the only requirement for MPLS appears to be that the model support a =
classifier sub-type for MPLS.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">That's all I have.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yoram</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF2B23.2436F276--


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



From diffserv-admin@ietf.org  Wed Nov 10 00:05:46 1999
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 AAA08449;
	Wed, 10 Nov 1999 00:05:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA00119;
	Tue, 9 Nov 1999 23:34:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA00086
	for <diffserv@optimus.ietf.org>; Tue, 9 Nov 1999 23:33:52 -0500 (EST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23392
	for <diffserv@ietf.org>; Tue, 9 Nov 1999 23:33:59 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Nov  9 23:32:09 EST 1999
Received: from dnrc.bell-labs.com ([135.255.32.234])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id XAA20557;
	Tue, 9 Nov 1999 23:32:04 -0500 (EST)
Message-ID: <3828F51F.25484DF8@dnrc.bell-labs.com>
Date: Tue, 09 Nov 1999 20:31:27 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: DiffServ <diffserv@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] EF with Drop ?
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

Intrigued by the brief treatment in today's DiffServ meeting I had
a read of draft-dieder-diffserv-phb-efd-00.txt.

Frankly I'm a little confused. There seems to be no reason to define
a new PHB, and the document appears to mix _service_ with per hop
_behavior_.

I understand the authors desire a 'low delay, low jitter' service
that also has a best-effort style drop probability. Fair enough.
(In the I-D it is referred to as Best Effort Low Delay - BELD)
I also understand their logic when they observe that the current
EF PHB can't do the job on face value, since the EF definition says
packet drops are a BadThing(tm) rather than an acceptable event.

But I dont follow the argument about why AF cannot be used. In
the body of the document AF is dismissed by reference to Appendix B.5,
and there it simply says:

   The Best-Effort Low Delay (BELD) Service cannot be constructed from
   existing PHBs: The AF PHB allows queueing to accommodate to bursty
   traffic, leading to a higher delay. 

Now here I think lies the confusion between a PHB and a service. The
AF PHB doesn't really define queuing and scheduling parameters. It
simply allows those parameters to be set in such a way that two or
three drop thresholds are supported and meaningful. So I believe this
document is incorrect in assert that using an AF PHB necessarily
forces the resulting service to have high delay.

It appears to me that a "BELD" service as envisoned by this I-D
could be achieved using routers having only AF PHB support, in
conjunction with appropriate scheduler weights, small queue sizes,
and ingress traffic shaping onto the chosen AF class.

No doubt I'm missing something here, and would be interested
to know what it is.

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies



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



From diffserv-admin@ietf.org  Wed Nov 10 03:39:34 1999
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 DAA29551;
	Wed, 10 Nov 1999 03:39:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA10534;
	Wed, 10 Nov 1999 02:51:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA10503
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 02:50:50 -0500 (EST)
Received: from scallop.baynetworks.com (ns5.baynetworks.com [194.133.90.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08076
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 02:50:53 -0500 (EST)
Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84])
	by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA07601;
	Wed, 10 Nov 1999 08:52:29 +0100 (MET)
Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6])
	by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id CAA27781;
	Wed, 10 Nov 1999 02:45:30 -0500 (EST)
Received: from aoife ([192.32.171.72])
	by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP
	id CAA24453; Wed, 10 Nov 1999 02:49:40 -0500
	for 
Message-Id: <3.0.32.19991110024309.00bac360@pobox.engeast.baynetworks.com>
X-Sender: khchan@pobox.engeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 10 Nov 1999 02:43:10 -0500
To: Russell Dietz <rsdietz@apptitude.com>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: [Diffserv] Current location of
  draft-ietf-diffserv-mib-01.txt?
Cc: "'diffserv@ietf.org'" <diffserv@ietf.org>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

I have also reposted at the original location indicated below.

Thanks!

-- Kwok --


At 06:57 PM 11/8/99 -0800, Russell Dietz wrote: 

>>>>

<excerpt>Current location of draft-ietf-diffserv-mib-01.txt? 


<fontfamily><param>Century</param>Hello draft-ietf-diffserv-mib-01.txt
authors,</fontfamily> 


<fontfamily><param>Century</param>The location which was
supplied...</fontfamily> 


<fontfamily><param>Century</param><<ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt>ftp://ftp.wellfleet.com/incoming/ietf_diffserv/draft-ietf-diffserv-mib-01.txt</fontfamily> 


<fontfamily><param>Century</param>... is no longer available.  Please
post this document to some place where we can all review. 
Thanks!</fontfamily> 


<fontfamily><param>Century</param>Regards,</fontfamily> 


<fontfamily><param>Century</param>Russ</fontfamily> 


<fontfamily><param>Lucida</param><bigger>Russell
Dietz</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>VP & Chief Technology
Officer</bigger></fontfamily> 

<fontfamily><param>Garamond</param><bigger><bigger><bigger>Apptitude,
Inc.</bigger></bigger></bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>6330 San Ignacio
Ave</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>San Jose, CA, USA
95119-1209</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>Tel:
+1-408-574-2256</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>Fax:
+1-408-224-1038</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger>mailto:
rsdietz@apptitude.com</bigger></fontfamily> 

<fontfamily><param>Tahoma</param><bigger><<http://www.apptitude.com>http://www.apptitude.com
</bigger></fontfamily> 

</excerpt>




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



From diffserv-admin@ietf.org  Wed Nov 10 11:24:00 1999
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 LAA29548;
	Wed, 10 Nov 1999 11:24:00 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24846;
	Wed, 10 Nov 1999 10:11:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA24817
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 10:11:33 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23243
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 10:11:37 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA23703
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 07:11:37 -0800 (PST)
Received: from [199.191.48.146] by slb-hub-01.boeing.com for diffserv@ietf.org; Wed, 10 Nov 1999 07:11:26 -0800
Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 10 Nov 1999 10:10:30 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Grenville Armitage" <gja@dnrc.bell-labs.com>,
        "DiffServ" <diffserv@ietf.org>
Subject: RE: [Diffserv] EF with Drop ?
Date: Wed, 10 Nov 1999 10:11:21 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMMEFJCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3828F51F.25484DF8@dnrc.bell-labs.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Grenville,

First, how can anybody think in a hall with 300 people and with a
long list of drafts to be force-fed to this mass?

I think I agree with your point, that AF after all is nothing but a
set of PHBs with drop precedence. But one issue that might or might
not be a problem is that AF PHBs are geared toward TCP (responsive)
traffic, yes? What happens to multicast traffic? None of it is TCP,
it's hard to justify making it "drop-proof" in the general case, so
how should it be sent? Is it okay to assume that multicast can be
sent using AF PHBs?

I was thinking yesterday that if we have EF for non-responsive
flows, we might need more than one EF class to handle multicast?
Maybe that's an application for BELD?

Bert
manfredi@arl.bna.boeing.com


> -----Original Message-----
> From: diffserv-admin@ietf.org
> [mailto:diffserv-admin@ietf.org]On Behalf
> Of Grenville Armitage
> Sent: Tuesday, November 09, 1999 11:31 PM
> To: DiffServ
> Subject: [Diffserv] EF with Drop ?
>
>
> Hi,
>
> Intrigued by the brief treatment in today's DiffServ meeting I had
> a read of draft-dieder-diffserv-phb-efd-00.txt.
>
> Frankly I'm a little confused. There seems to be no
> reason to define
> a new PHB, and the document appears to mix _service_ with per hop
> _behavior_.
>
> I understand the authors desire a 'low delay, low jitter' service
> that also has a best-effort style drop probability. Fair enough.
> (In the I-D it is referred to as Best Effort Low Delay - BELD)
> I also understand their logic when they observe that the current
> EF PHB can't do the job on face value, since the EF
> definition says
> packet drops are a BadThing(tm) rather than an acceptable event.
>
> But I dont follow the argument about why AF cannot be used. In
> the body of the document AF is dismissed by reference to
> Appendix B.5,
> and there it simply says:
>
>    The Best-Effort Low Delay (BELD) Service cannot be
> constructed from
>    existing PHBs: The AF PHB allows queueing to
> accommodate to bursty
>    traffic, leading to a higher delay.
>
> Now here I think lies the confusion between a PHB and a
> service. The
> AF PHB doesn't really define queuing and scheduling parameters. It
> simply allows those parameters to be set in such a way that two or
> three drop thresholds are supported and meaningful. So I
> believe this
> document is incorrect in assert that using an AF PHB necessarily
> forces the resulting service to have high delay.
>
> It appears to me that a "BELD" service as envisoned by this I-D
> could be achieved using routers having only AF PHB support, in
> conjunction with appropriate scheduler weights, small queue sizes,
> and ingress traffic shaping onto the chosen AF class.
>
> No doubt I'm missing something here, and would be interested
> to know what it is.
>
> cheers,
> gja
> __________________________________________________________
> ______________
> Grenville Armitage
> http://mh005.infi.net/~gja
> Bell Labs Research, Lucent Technologies
>
>
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>


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



From diffserv-admin@ietf.org  Wed Nov 10 12:02:09 1999
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 MAA17359;
	Wed, 10 Nov 1999 12:02:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28097;
	Wed, 10 Nov 1999 11:37:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA28064
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 11:37:13 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06213
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 11:37:21 -0500 (EST)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA07927;
	Wed, 10 Nov 1999 08:36:47 -0800 (PST)
Message-ID: <38299F32.BEA0B494@cisco.com>
Date: Wed, 10 Nov 1999 08:37:06 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Grenville Armitage <gja@dnrc.bell-labs.com>
CC: DiffServ <diffserv@ietf.org>
Subject: Re: [Diffserv] EF with Drop ?
References: <3828F51F.25484DF8@dnrc.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Grenville Armitage wrote:
> 
...
> But I dont follow the argument about why AF cannot be used. In
> the body of the document AF is dismissed by reference to Appendix B.5,
> and there it simply says:
> 
>    The Best-Effort Low Delay (BELD) Service cannot be constructed from
>    existing PHBs: The AF PHB allows queueing to accommodate to bursty
>    traffic, leading to a higher delay.
> 
> Now here I think lies the confusion between a PHB and a service. The
> AF PHB doesn't really define queuing and scheduling parameters. It
> simply allows those parameters to be set in such a way that two or
> three drop thresholds are supported and meaningful. So I believe this
> document is incorrect in assert that using an AF PHB necessarily
> forces the resulting service to have high delay.
> 
> It appears to me that a "BELD" service as envisoned by this I-D
> could be achieved using routers having only AF PHB support, in
> conjunction with appropriate scheduler weights, small queue sizes,
> and ingress traffic shaping onto the chosen AF class.

I completely agree. Further, I think you could configure a Class
Selector the same way. Give it a short queue, control the
service rate and control the amount of the BA stamped for that CS
admitted to the network.

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



From diffserv-admin@ietf.org  Wed Nov 10 16:14:13 1999
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 QAA15865;
	Wed, 10 Nov 1999 16:14:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA06070;
	Wed, 10 Nov 1999 15:37:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA06038
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 15:37:13 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01279
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 15:37:19 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id MAA09149
	for <diffserv@external.cisco.com>; Wed, 10 Nov 1999 12:37:19 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 10 Nov 1999 12:38:58 -0800
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id WAA21654;
	Wed, 10 Nov 1999 22:36:25 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14377.55113.421321.667034@lohi.eng.telia.fi>
Date: Wed, 10 Nov 1999 22:36:25 +0200 (EET)
To: "Jamel H. Sadok" <jamel@di.ufpe.br>
Cc: Grenville Armitage <gja@dnrc.bell-labs.com>,
        "Tony Hain (Exchange)" <tonyhain@microsoft.com>,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <Pine.GSO.4.02.9910231532190.25700-100000@paulista>
References: <3811D1E8.FCF72C84@dnrc.bell-labs.com>
	<Pine.GSO.4.02.9910231532190.25700-100000@paulista>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Jamel H. Sadok writes:

 > I have a problem  getting to  terms with the idea  that an existing
 > domain would need to establish some AF SLAs  in order to forward
 > its existing BE traffic. Is this  a  conensus or  am  I missing the
 > point? IMHO, I would rather think that todays
 > traffic would be tomorrow's default  and let  AF handle the new higher
 > priority stuff. That  way if my  domain is A-DiffServ it may go on for a
 > while (life as normal). 

there doesn't need to be any concensus on how diff-serv phbs are used to
implement services.  to me best effort SERVICE is a special case of
assured bandwidth SERVICE where the assured bandwidth is zero.  if i
implement assured bandwidth service using af class 1, then i would
simply tell to my routers that the precedence code point 000 is an alias
of af 1, dp level yellow code point.

-- juha


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



From diffserv-admin@ietf.org  Wed Nov 10 16:14:21 1999
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 QAA15938;
	Wed, 10 Nov 1999 16:14:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05899;
	Wed, 10 Nov 1999 15:32:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05865
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 15:32:45 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29215
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 15:32:53 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id MAA06241
	for <diffserv@external.cisco.com>; Wed, 10 Nov 1999 12:32:51 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy2.cisco.com with SMTP (MailShield v1.5); Wed, 10 Nov 1999 12:34:30 -0800
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id WAA21646;
	Wed, 10 Nov 1999 22:32:05 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14377.54853.645061.843527@lohi.eng.telia.fi>
Date: Wed, 10 Nov 1999 22:32:05 +0200 (EET)
To: Grenville Armitage <gja@dnrc.bell-labs.com>
Cc: "Jamel H. Sadok" <jamel@di.ufpe.br>,
        "Tony Hain (Exchange)" <tonyhain@microsoft.com>,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <3811D1E8.FCF72C84@dnrc.bell-labs.com>
References: <Pine.GSO.4.02.9910230922370.1214-100000@paulista>
	<3811D1E8.FCF72C84@dnrc.bell-labs.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Grenville Armitage writes:

 > new mythical 'background traffic'

i don't see any mythical in definition of background SERVICE.  it is a
service to which no promises nor even expectations are made.  it can be
IMPLEMENTED as an af class that has been allocated some buffering
resources, but no scheduling resources, i.e., packets from the
background queue would be served only is all other queues are empty.  it
would thus be possible for the other traffic to totally starve the
background traffic.  provided that background traffic is cheaper than
best effor ttraffic, it would have uses.  one could, for example, try to
download some content during the nigth and consume it in the morning
provided that it has arrived.

-- juha


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



From diffserv-admin@ietf.org  Wed Nov 10 16:18:11 1999
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 QAA17669;
	Wed, 10 Nov 1999 16:18:10 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05627;
	Wed, 10 Nov 1999 15:28:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA05599
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 15:28:08 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26854
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 15:28:11 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id MAA03581
	for <diffserv@external.cisco.com>; Wed, 10 Nov 1999 12:28:21 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy3.cisco.com with SMTP (MailShield v1.5); Wed, 10 Nov 1999 12:24:29 -0800
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id WAA21629;
	Wed, 10 Nov 1999 22:22:17 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <14377.54265.681826.39255@lohi.eng.telia.fi>
Date: Wed, 10 Nov 1999 22:22:17 +0200 (EET)
To: "Jamel H. Sadok" <jamel@di.ufpe.br>
Cc: Grenville Armitage <gja@dnrc.bell-labs.com>,
        "Tony Hain (Exchange)" <tonyhain@microsoft.com>,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <Pine.GSO.4.02.9910230922370.1214-100000@paulista>
References: <381135A8.B700D2BB@dnrc.bell-labs.com>
	<Pine.GSO.4.02.9910230922370.1214-100000@paulista>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA05601
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Jamel H. Sadok writes:

 > It may  be that many users won't be able to *afford*  the price of
 > remarking their existing legacy traffic  to a suitable AF class and yet
 > would still like to see their "ïmportant traffic" differenciated from
 > backgound traffic.

i'm not sure it i understand you, but if a user wants to send some of
its packets as background, then it must mark those with a code point
that is different from best effort.

-- juha


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



From diffserv-admin@ietf.org  Wed Nov 10 16:37:58 1999
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 QAA27433;
	Wed, 10 Nov 1999 16:37:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA06325;
	Wed, 10 Nov 1999 15:46:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA06298
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 15:46:04 -0500 (EST)
Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05077
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 15:46:11 -0500 (EST)
Received: from kelts.ibr.cs.tu-bs.de (IDENT:root@kelts [134.169.34.131])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA15163;
	Wed, 10 Nov 1999 21:45:32 +0100 (MET)
Received: (from dieder@localhost)
	by kelts.ibr.cs.tu-bs.de (8.9.3/8.9.3) id VAA08023;
	Wed, 10 Nov 1999 21:45:32 +0100
To: gja@dnrc.bell-labs.com (Grenville Armitage)
CC: diffserv@ietf.org
Subject: Re: [Diffserv] EF with Drop ?
References: <3828F51F.25484DF8.diff-serv@dnrc.bell-labs.com>
From: Joerg Diederich <dieder@ibr.cs.tu-bs.de>
Date: 10 Nov 1999 21:45:32 +0100
In-Reply-To: gja@dnrc.bell-labs.com's message of "10 Nov 1999 06:44:12 +0100"
Message-ID: <yj84seurs7n.fsf@kelts.ibr.cs.tu-bs.de>
Lines: 95
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Grenville Armitage writes:

Grenville> Frankly I'm a little confused. There seems to be no reason
Grenville> to define a new PHB, and the document appears to mix
Grenville> _service_ with per hop _behavior_.

The intention of describing the example services in the draft was to
motivate, why in our opinion the current PHBs cannot be used to create
such services. I tried to separate services and behaviors strictly but
there may be places in the draft where I did not succeed with
this. Could you please be more concrete at which places you think
services and behaviors have been mixed? Is it only where we state
that AF cannot been used (as you mention below)?

Grenville> [...]
Grenville> But I dont follow the argument about why AF cannot be
Grenville> used. In the body of the document AF is dismissed by
Grenville> reference to Appendix B.5, and there it simply says:

Grenville>    The Best-Effort Low Delay (BELD) Service cannot be
Grenville> constructed from existing PHBs: The AF PHB allows queueing
Grenville> to accommodate to bursty traffic, leading to a higher
Grenville> delay.

Grenville> Now here I think lies the confusion between a PHB and a
Grenville> service. The AF PHB doesn't really define queuing and
Grenville> scheduling parameters. It simply allows those parameters to
Grenville> be set in such a way that two or three drop thresholds are
Grenville> supported and meaningful. So I believe this document is
Grenville> incorrect in assert that using an AF PHB necessarily forces
Grenville> the resulting service to have high delay.

In my understanding, the fundamental difference between EF and AF is
that services built with EF relies heavily on traffic conditioning at
the network's boundary so that excess traffic and (almost all)
congestion within the EF BA is kept out of the network. In contrast,
services built with AF let excess traffic enter the network and use
buffer management means at each network to handle congestion within
each AF class.

In my eyes, you _can_ apply the same traffic conditioning actions to
packets marked for an AF class as to packets marked for EF so that you
model EF using AF. In this way, you simply do not need the buffer
management from AF since almost no queues arise. And if you do so, you
get 'EF with two drop precedences' so that you do not need EFD
anymore.

But then, you could in my opinion also ask why you need EF at all
since you can create Premium Service the same way using an
over-provisioned AF class with appropriate small buffers, strict
traffic conditioning etc, However, you will in my opinion end up with
almost the same statements on the buffer size, how to dimension the
link capacities etc as stated in the EF RFC.

I assume that there already was some discussion on this point but I
don't know, since I haven't been in the DiffServ working group from
the beginning. Since both, EF and AF, are on the standard track, I
assume that there was consensus that it is useful to have both
separate. I would agree with this since both RFCs use fundamentally
different principles (EF: let excess traffic out to avoid congestion
vs. AF: let excess traffic in and handle congestion).

However, I definitely do not want to be the initiator of a discussion,
which has (probably) already taken place some time ago. 

Thus, the EFD draft assumes that EF should be used to build a
low-delay service such as Premium service and we want to build a
service with _exactly_ the same delay characteristics as Premium
service using EF but allowing dropping. I do not think that you can
achieve the delay requirement by using AF for BELD traffic and EF
for Premium service simultaneously.

Grenville> It appears to me that a "BELD" service as envisoned by this
Grenville> I-D could be achieved using routers having only AF PHB
Grenville> support, in conjunction with appropriate scheduler weights,
Grenville> small queue sizes, and ingress traffic shaping onto the
Grenville> chosen AF class.

I agree with you, but since we assume that EF is used (or should be
used) to built low-delay services which rely on avoidance of
congestion by traffic conditioning (see above), AF seems to be not the
right way to implement a low-delay service which allows dropping but
does not allow congestion.

Grenville> No doubt I'm missing something here, and would be
Grenville> interested to know what it is.

Same for me, since I am very probably not the best and most experienced
'DiffServer' :-) However, I am glad to get some input about this draft
and I am looking forward to discussing it further to improve it.

Ciao,

/J"org


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



From diffserv-admin@ietf.org  Wed Nov 10 17:44:30 1999
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 RAA00537;
	Wed, 10 Nov 1999 17:44:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA08803;
	Wed, 10 Nov 1999 17:03:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA08771
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 17:03:19 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10130
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 17:03:26 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id OAA17185
	for <diffserv@external.cisco.com>; Wed, 10 Nov 1999 14:01:41 -0800 (PST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by proxy3.cisco.com with SMTP (MailShield v1.5); Wed, 10 Nov 1999 13:59:42 -0800
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA13534
	for <diffserv@external.cisco.com>; Wed, 10 Nov 1999 13:53:23 -0800 (PST)
Received: from [199.191.48.146] by slb-hub-01.boeing.com for diffserv@external.cisco.com; Wed, 10 Nov 1999 13:53:15 -0800
Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 10 Nov 1999 16:52:20 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Juha Heinanen" <jh@lohi.eng.telia.fi>
Cc: <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
Date: Wed, 10 Nov 1999 16:53:11 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMCEFNCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
In-Reply-To: <14377.54853.645061.843527@lohi.eng.telia.fi>
X-SMTP-HELO: slb-smtpout-01.boeing.com
X-SMTP-MAIL-FROM: albert.e.manfredi@boeing.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: slb-smtpout-01.boeing.com [12.13.237.21]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Juha Heinanen wrote:

> Grenville Armitage writes:
>
>  > new mythical 'background traffic'
>
> i don't see any mythical in definition of background
> SERVICE.  it is a
> service to which no promises nor even expectations are
> made.  it can be
> IMPLEMENTED as an af class that has been allocated some buffering
> resources, but no scheduling resources, i.e., packets from the
> background queue would be served only is all other queues
> are empty.

Which is a good description of standard BE traffic handling.

I think the real issue here is that some feel that TOS 00000000
should _not_ map into DSCP 000000, but rather into some "slightly
higher" DSCP. If that's the case, then at the interface between the
edge and the DiffServ, that translation can always be accomplished,
no? It's of course an exercise for the student to know just what
incoming TOS is mapped to this new DSCP BE, vs what incoming TOS
becomes the bottom-feeder DSCP.

Perhaps this can be filtered based on Source IP Address.

> it
> would thus be possible for the other traffic to totally starve the
> background traffic.  provided that background traffic is
> cheaper than
> best effor ttraffic, it would have uses.  one could, for
> example, try to
> download some content during the nigth and consume it in
> the morning
> provided that it has arrived.

And again, this can be accomplished by somehow mapping TOS 0 to some
slightly better than 0 DSCP. Assuming you can still differentiate
the incoming packets.

Bert
manfredi@arl.bna.boeing.com



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



From diffserv-admin@ietf.org  Wed Nov 10 18:03:55 1999
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 SAA09832;
	Wed, 10 Nov 1999 18:03:55 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA09514;
	Wed, 10 Nov 1999 17:25:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA09482
	for <diffserv@optimus.ietf.org>; Wed, 10 Nov 1999 17:25:11 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20714
	for <diffserv@ietf.org>; Wed, 10 Nov 1999 17:25:18 -0500 (EST)
Received: from ascend.com ([152.148.171.85])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id RAA00090;
	Wed, 10 Nov 1999 17:23:58 -0500 (EST)
Message-ID: <3829EFAA.E9EDC6B5@ascend.com>
Date: Wed, 10 Nov 1999 17:20:27 -0500
From: Siamack Ayandeh <sayandeh@ascend.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Constantinos <dovrolis@hertz.ece.wisc.edu>
CC: istoica+@cs.cmu.edu, diffserv@ietf.org, salsano@coritel.it,
        P.Gevros@cs.ucl.ac.uk
Subject: Re: [Diffserv] EF RFC and loss
References: <199911060202.UAA02196@hertz.ece.wisc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


I think this thread is not complete without the following  point:

What is the likelihood of the worst case scenario actually occurring. Using
your notation let z = (N-1)^s.  Then if the link share of the EF aggregate in
an
interior hop s, is given by "a" (which say is 0.1 or so) then the probability

of the worst case traffic scenario, assuming independent sources, is (a/z)^z.

So the probability drops off much faster than the buffer requirement!

If sources are not independent then you probably have a security issue
on your hands.

Regards, Siamack

Constantinos wrote:

> Hmm.. so what I had in mind is regulation at any multiplexing
> and demultiplexing point (both output and input interfaces),
> so that the burstiness of the EF aggregate never increases to more
> than one packet per 1/R seconds, where R is the capacity of the
> EF aggregate at that point.
>
> In this model, the regulator in the multiplexer of an output interface
> would only require a buffer of N packets, where N is the number of
> inputs to the multiplexer.
>
> In the case of demultiplexing at an input interface, though,
> Ion's last note convinced me that the number of required buffers
> is indeed proportional to the number of (macro)flows present
> in the EF aggregate of that interface. I refer to the following
> part of his email:
>
> > To see this, assume a router that receives at input i aggregate EF
> > traffic at a rate R, and assume that this consists of n flows of rate
> > r, i.e., R = n*r. Then assume that n/K of these flows go to the
> > output j. As a result the traffic from input i to output j will be
> > regulated to R/K. Now assume that all packets of these n/K flows are
> > received back-to-back, i.e., it will take
> >
> >                     t = (n / K)/ R = n / (K*R)
> >
> > to receive these packets. In contrast, since the rate between input i
> > and output j is limited to R/K, during the same time input i can
> > transfer to output j only
> >
> >                      m = (R/K)*t = n/K^2
> >
> > packets. Thus, at the end of this interval the input i has to store
> >
> >                      n/K - m = n/K (1 - 1/K)
> >
> > packets for output j. It is easy to see that this value is maximized
> > for K=2. Thus even if you regulate the traffic at the inputs you still
> > need a buffer of size proportional to the number of flows. And recall
> > that this is only for one output; the input has to eventually maintain
> > a buffer for each output port.
> >
>
> So, in the worst demultiplexing case (K=2), the input regulator needs n/4
> packet buffers, where n is the number of macroflows in the EF aggregate.
> Which can be also thought of as a bound on how much aggregation of EF
> traffic is feasible at each link.
>
> Interesting stuff (even at Friday's evening..)
>
> Constantinos
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Thu Nov 11 04:42:02 1999
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 EAA25511;
	Thu, 11 Nov 1999 04:42:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA00853;
	Thu, 11 Nov 1999 03:59:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id DAA00817
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 03:59:48 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05993
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 03:59:58 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id IAA20180 for <diffserv@ietf.org>; Thu, 11 Nov 1999 08:59:27 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA34994 for <diffserv@ietf.org>; Wed, 10 Nov 1999 19:02:46 GMT
Message-ID: <3829C0CB.E18757DC@hursley.ibm.com>
Date: Wed, 10 Nov 1999 13:00:27 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Diff Serv <diffserv@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] LBE using RFC 2474
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Kathie and I discussed the less than best effort requirement expressed
by some people, and concluded that this can be done using RFC 2474
with no change:

In the DSCP to PHB mapping table, map the DSCP value 0 (default)
to the PHB Class Selector 2. Then classify the "LBE" tarffic
into a BA that receives PHB Class Selector 1.

This usage overrides the SHOULD in RFC 2474, section 4.2.2.2,
but that is why we use SHOULD instead of MUST.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82

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



From diffserv-admin@ietf.org  Thu Nov 11 05:40:07 1999
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 FAA21556;
	Thu, 11 Nov 1999 05:40:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA03867;
	Thu, 11 Nov 1999 05:18:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA03837
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 05:18:48 -0500 (EST)
Received: from gd2w08.swissptt.ch (outmail3.swisscom.com [138.190.3.30])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12301
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 05:18:58 -0500 (EST)
From: Andreas.Schmid1@swisscom.com
Received: from sbe2173.swissptt.ch (138.190.170.55) by gd2w08.swissptt.ch (MX
          V5.1-X AnHp) with SMTP for <diffserv@ietf.org>;
          Thu, 11 Nov 1999 11:18:56 +0100
Received: by gd2yee.swissptt.ch with Internet Mail Service (5.5.2448.0) id
          <WHL60HL5>; Thu, 11 Nov 1999 11:02:35 +0100
Message-ID: <21C15D5AE757D011AFBF0000F830A4A9048B28F6@gd3i5y.swissptt.ch>
To: diffserv@ietf.org
Date: Thu, 11 Nov 1999 11:02:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Subject: [Diffserv] WG: DiffServ
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> I am wondering about admission control concepts if DiffServ is applied in
> a network backbone, ...
> 
> - Is all traffic arriving at an DS domain ingress node part of a TCS/TCA?
> - If no, what happens with traffic from customers without TCA? Is this
> traffic dropped or just given the least priority? Can this behavior be
> configured by the network administrator? How? Static or dynamic?
> 
> - How can the traffic from a customer be identified? Is this done
> dynamically by IP sender lookup? Or has the network operator to look that
> every incoming traffic is always covered by a TCA, and therefore, as every
> incoming traffic is part of a TCA the routers only need to perform
> priorised queueing?
> 
> - Is admission control therefore done in a static way (operator makes
> contracts / agreements with network users before this is able to use his
> network -> static control with human intervention)? Could dynamic
> admission control be possible if a bandwidth broker controls all the
> bandwidth in one network? Are there other scenarios for dynamic admission
> control?
> 
> with best regards
> Andi
> 

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



From diffserv-admin@ietf.org  Thu Nov 11 06:25:22 1999
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 GAA12097;
	Thu, 11 Nov 1999 06:25:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA04645;
	Thu, 11 Nov 1999 05:41:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA04613
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 05:41:39 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22090
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 05:41:49 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11lrfm-0004QG-00; Thu, 11 Nov 1999 11:41:46 +0100
Received: from telematik.informatik.uni-karlsruhe.de (tpc17.telematik.informatik.uni-karlsruhe.de [129.13.42.117])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id LAA06753;
	Thu, 11 Nov 1999 11:41:44 +0100 (MET)
Message-ID: <382A9F2F.48A58626@telematik.informatik.uni-karlsruhe.de>
Date: Thu, 11 Nov 1999 11:49:19 +0100
From: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Organization: Institut =?iso-8859-1?Q?f=FCr?= Telematik - 
	=?iso-8859-1?Q?Universit=E4t?= Karlsruhe
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: diffserv@ietf.org, bless@telematik.informatik.uni-karlsruhe.de
Subject: Re: [Diffserv] LBE using RFC 2474
References: <3829C0CB.E18757DC@hursley.ibm.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Brian E Carpenter wrote:

> Kathie and I discussed the less than best effort requirement expressed
> by some people, and concluded that this can be done using RFC 2474
> with no change:

When you override the SHOULD  in RFC 2474, section 4.2.2.2 this would be a
change ;-)

>
> In the DSCP to PHB mapping table, map the DSCP value 0 (default)
> to the PHB Class Selector 2. Then classify the "LBE" tarffic
> into a BA that receives PHB Class Selector 1.

nice trick, but if an ISP do not use this mapping, the LBE-traffic would
not be treated lower than Best-Effort.

If you use a seperate Codepoint for LBE, every router can distinguish it
from BE, independant from the mapping of LBE-traffic into a BA that
receives lower than BE.
I think, there are enough Codepoints left, so why don't we assign one to
LBE.

If you map BE to ClassSel 2, LBE to ClassSel 1, then you can map EF to the
highest ClassSelector and we can forget RFC 2598. I think, that is not was
the people on the DiffServ-WG-list want.

I don't know, if every ISP wants to offer services, that only bases on AF
or EF or the ClassSelectors.

>
> This usage overrides the SHOULD in RFC 2474, section 4.2.2.2,
> but that is why we use SHOULD instead of MUST.

--------------------
Ciao,
Klaus

--

 Klaus Wehrle
 Institut für Telematik, Universität Karlsruhe (TH)
 Zirkel 2, 76128 Karlsruhe, Germany
 Phone: +49 721 608 6414, Fax: +49 721 388097
 mailto:wehrle@telematik.informatik.uni-karlsruhe.de
 http://www.telematik.informatik.uni-karlsruhe.de/~wehrle



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



From diffserv-admin@ietf.org  Thu Nov 11 07:45:41 1999
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 HAA17918;
	Thu, 11 Nov 1999 07:45:40 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA07724;
	Thu, 11 Nov 1999 07:13:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA07698
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 07:13:53 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04180
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 07:14:04 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id EAA20358
	for <diffserv@external.cisco.com>; Thu, 11 Nov 1999 04:14:16 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy2.cisco.com with SMTP (MailShield v1.5); Thu, 11 Nov 1999 04:15:54 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA79014; Thu, 11 Nov 1999 12:07:49 GMT
Received: from hursley.ibm.com (lig32-225-110-215.us.lig-dial.ibm.com [32.225.110.215]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA33270; Thu, 11 Nov 1999 12:07:42 GMT
Message-ID: <382AB165.76CE45D3@hursley.ibm.com>
Date: Thu, 11 Nov 1999 06:07:01 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: Juha Heinanen <jh@lohi.eng.telia.fi>, diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <NDBBIBKKCLEFDFDGHCNMCEFNCAAA.albert.e.manfredi@boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi wrote:
...
> I think the real issue here is that some feel that TOS 00000000
> should _not_ map into DSCP 000000, but rather into some "slightly
........................^PHB
> higher" DSCP. 
..........^PHB

   Brian


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



From diffserv-admin@ietf.org  Thu Nov 11 07:51:20 1999
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 HAA20341;
	Thu, 11 Nov 1999 07:51:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA07568;
	Thu, 11 Nov 1999 07:07:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA07536
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 07:07:18 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01142
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 07:07:29 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA74352; Thu, 11 Nov 1999 12:04:56 GMT
Received: from hursley.ibm.com (lig32-225-110-215.us.lig-dial.ibm.com [32.225.110.215]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA38194; Thu, 11 Nov 1999 12:04:53 GMT
Message-ID: <382AB0C0.7DD4D2DA@hursley.ibm.com>
Date: Thu, 11 Nov 1999 06:04:16 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
CC: diffserv@ietf.org, bless@telematik.informatik.uni-karlsruhe.de
Subject: Re: [Diffserv] LBE using RFC 2474
References: <3829C0CB.E18757DC@hursley.ibm.com> <382A9F2F.48A58626@telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Klaus Wehrle wrote:
> 
> Brian E Carpenter wrote:
> 
> > Kathie and I discussed the less than best effort requirement expressed
> > by some people, and concluded that this can be done using RFC 2474
> > with no change:
> 
> When you override the SHOULD  in RFC 2474, section 4.2.2.2 this would be a
> change ;-)

No, there is no law against overriding a SHOULD. I mean literally that
not one word in 2474 needs to be changed.
> 
> >
> > In the DSCP to PHB mapping table, map the DSCP value 0 (default)
> > to the PHB Class Selector 2. Then classify the "LBE" tarffic
> > into a BA that receives PHB Class Selector 1.
> 
> nice trick, but if an ISP do not use this mapping, the LBE-traffic would
> not be treated lower than Best-Effort.

That applies to every PHB not implemented by any ISP. Nothing new here.

> 
> If you use a seperate Codepoint for LBE, every router can distinguish it
> from BE, independant from the mapping of LBE-traffic into a BA that
> receives lower than BE.

Only if operators choose to implement it. PHBs are not compulsory.

> I think, there are enough Codepoints left, so why don't we assign one to
> LBE.

Because we already have too many defined.

> 
> If you map BE to ClassSel 2, LBE to ClassSel 1, then you can map EF to the
> highest ClassSelector and we can forget RFC 2598. I think, that is not was
> the people on the DiffServ-WG-list want.

No, there is a very clear distinction between EF and the class
selectors,
and we spent months getting consensus on that. 

> 
> I don't know, if every ISP wants to offer services, that only bases on AF
> or EF or the ClassSelectors.

Neither do I, but what I hear from ISPs is that there are already
plenty of PHBs, thankyou, and what they need to offer services
are service management mechanisms, not new PHBs.

  Brian

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



From diffserv-admin@ietf.org  Thu Nov 11 09:48:11 1999
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 JAA19006;
	Thu, 11 Nov 1999 09:48:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA12428;
	Thu, 11 Nov 1999 08:55:28 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA12322
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 08:55:18 -0500 (EST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22554
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 08:55:29 -0500 (EST)
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <WTH9LWG2>; Thu, 11 Nov 1999 05:54:43 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A606F418EB@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>,
        Brian E Carpenter <brian@hursley.ibm.com>
Cc: diffserv@ietf.org, bless@telematik.informatik.uni-karlsruhe.de
Subject: RE: [Diffserv] LBE using RFC 2474
Date: Thu, 11 Nov 1999 05:54:40 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF2C4C.4DFC692C"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF2C4C.4DFC692C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree with Klaus here.=20

The point is to have a barin-dead simple way of getting certain traffic =
to
be downgraded in priority.=20

We're working with our IT group to roll out differentiated services. We =
have
to find the least painful way to roll this stuff out. We need to =
reconfigure
as few routers as possible. Those that do need reconfiguring should =
require
the simplest possible reconfiguration. In addition, we need to worry
(initially) about as few applications as possible. That means that the
applications that get special treatment need to be the exception, =
rather
than the rule.

This begs for routers that 'out of the box' just recognize an LBE mark =
and
downgrade it relative to other traffic. That in turn, requires =
standardizing
an LBE DSCP.=20


Yoram

> -----Original Message-----
> From: Klaus Wehrle=20
> [mailto:wehrle@telematik.informatik.uni-karlsruhe.de]
> Sent: Thursday, November 11, 1999 2:49 AM
> To: Brian E Carpenter
> Cc: diffserv@ietf.org; bless@telematik.informatik.uni-karlsruhe.de
> Subject: Re: [Diffserv] LBE using RFC 2474
>=20
>=20
> Brian E Carpenter wrote:
>=20
> > Kathie and I discussed the less than best effort=20
> requirement expressed
> > by some people, and concluded that this can be done using RFC 2474
> > with no change:
>=20
> When you override the SHOULD  in RFC 2474, section 4.2.2.2=20
> this would be a
> change ;-)
>=20
> >
> > In the DSCP to PHB mapping table, map the DSCP value 0 (default)
> > to the PHB Class Selector 2. Then classify the "LBE" tarffic
> > into a BA that receives PHB Class Selector 1.
>=20
> nice trick, but if an ISP do not use this mapping, the=20
> LBE-traffic would
> not be treated lower than Best-Effort.
>=20
> If you use a seperate Codepoint for LBE, every router can=20
> distinguish it
> from BE, independant from the mapping of LBE-traffic into a BA that
> receives lower than BE.
> I think, there are enough Codepoints left, so why don't we=20
> assign one to
> LBE.
>=20
> If you map BE to ClassSel 2, LBE to ClassSel 1, then you can=20
> map EF to the
> highest ClassSelector and we can forget RFC 2598. I think,=20
> that is not was
> the people on the DiffServ-WG-list want.
>=20
> I don't know, if every ISP wants to offer services, that only=20
> bases on AF
> or EF or the ClassSelectors.
>=20
> >
> > This usage overrides the SHOULD in RFC 2474, section 4.2.2.2,
> > but that is why we use SHOULD instead of MUST.
>=20
> --------------------
> Ciao,
> Klaus
>=20
> --
>=20
>  Klaus Wehrle
>  Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH)
>  Zirkel 2, 76128 Karlsruhe, Germany
>  Phone: +49 721 608 6414, Fax: +49 721 388097
>  mailto:wehrle@telematik.informatik.uni-karlsruhe.de
>  http://www.telematik.informatik.uni-karlsruhe.de/~wehrle
>=20
>=20
>=20
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>=20

------_=_NextPart_001_01BF2C4C.4DFC692C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: [Diffserv] LBE using RFC 2474</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with Klaus here. </FONT>
</P>

<P><FONT SIZE=3D2>The point is to have a barin-dead simple way of =
getting certain traffic to be downgraded in priority. </FONT>
</P>

<P><FONT SIZE=3D2>We're working with our IT group to roll out =
differentiated services. We have to find the least painful way to roll =
this stuff out. We need to reconfigure as few routers as possible. =
Those that do need reconfiguring should require the simplest possible =
reconfiguration. In addition, we need to worry (initially) about as few =
applications as possible. That means that the applications that get =
special treatment need to be the exception, rather than the =
rule.</FONT></P>

<P><FONT SIZE=3D2>This begs for routers that 'out of the box' just =
recognize an LBE mark and downgrade it relative to other traffic. That =
in turn, requires standardizing an LBE DSCP. </FONT></P>
<BR>

<P><FONT SIZE=3D2>Yoram</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Klaus Wehrle </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:wehrle@telematik.informatik.uni-karlsruhe.de">mailto:wehr=
le@telematik.informatik.uni-karlsruhe.de</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, November 11, 1999 2:49 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Brian E Carpenter</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: diffserv@ietf.org; =
bless@telematik.informatik.uni-karlsruhe.de</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [Diffserv] LBE using RFC =
2474</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Brian E Carpenter wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Kathie and I discussed the less than best =
effort </FONT>
<BR><FONT SIZE=3D2>&gt; requirement expressed</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; by some people, and concluded that this =
can be done using RFC 2474</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with no change:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; When you override the SHOULD&nbsp; in RFC 2474, =
section 4.2.2.2 </FONT>
<BR><FONT SIZE=3D2>&gt; this would be a</FONT>
<BR><FONT SIZE=3D2>&gt; change ;-)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In the DSCP to PHB mapping table, map the =
DSCP value 0 (default)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to the PHB Class Selector 2. Then classify =
the &quot;LBE&quot; tarffic</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; into a BA that receives PHB Class Selector =
1.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; nice trick, but if an ISP do not use this =
mapping, the </FONT>
<BR><FONT SIZE=3D2>&gt; LBE-traffic would</FONT>
<BR><FONT SIZE=3D2>&gt; not be treated lower than Best-Effort.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you use a seperate Codepoint for LBE, every =
router can </FONT>
<BR><FONT SIZE=3D2>&gt; distinguish it</FONT>
<BR><FONT SIZE=3D2>&gt; from BE, independant from the mapping of =
LBE-traffic into a BA that</FONT>
<BR><FONT SIZE=3D2>&gt; receives lower than BE.</FONT>
<BR><FONT SIZE=3D2>&gt; I think, there are enough Codepoints left, so =
why don't we </FONT>
<BR><FONT SIZE=3D2>&gt; assign one to</FONT>
<BR><FONT SIZE=3D2>&gt; LBE.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If you map BE to ClassSel 2, LBE to ClassSel 1, =
then you can </FONT>
<BR><FONT SIZE=3D2>&gt; map EF to the</FONT>
<BR><FONT SIZE=3D2>&gt; highest ClassSelector and we can forget RFC =
2598. I think, </FONT>
<BR><FONT SIZE=3D2>&gt; that is not was</FONT>
<BR><FONT SIZE=3D2>&gt; the people on the DiffServ-WG-list want.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't know, if every ISP wants to offer =
services, that only </FONT>
<BR><FONT SIZE=3D2>&gt; bases on AF</FONT>
<BR><FONT SIZE=3D2>&gt; or EF or the ClassSelectors.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This usage overrides the SHOULD in RFC =
2474, section 4.2.2.2,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; but that is why we use SHOULD instead of =
MUST.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --------------------</FONT>
<BR><FONT SIZE=3D2>&gt; Ciao,</FONT>
<BR><FONT SIZE=3D2>&gt; Klaus</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Klaus Wehrle</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Institut f=FCr Telematik, Universit=E4t =
Karlsruhe (TH)</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Zirkel 2, 76128 Karlsruhe, Germany</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Phone: +49 721 608 6414, Fax: +49 721 =
388097</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; <A =
HREF=3D"mailto:wehrle@telematik.informatik.uni-karlsruhe.de">mailto:wehr=
le@telematik.informatik.uni-karlsruhe.de</A></FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; <A =
HREF=3D"http://www.telematik.informatik.uni-karlsruhe.de/~wehrle" =
TARGET=3D"_blank">http://www.telematik.informatik.uni-karlsruhe.de/~wehr=
le</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; diffserv mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/mailman/listinfo/diffserv" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/diffserv</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; Archive: <A =
HREF=3D"http://www-nrg.ee.lbl.gov/diff-serv-arch/" =
TARGET=3D"_blank">http://www-nrg.ee.lbl.gov/diff-serv-arch/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF2C4C.4DFC692C--

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



From diffserv-admin@ietf.org  Thu Nov 11 09:51:25 1999
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 JAA20648;
	Thu, 11 Nov 1999 09:51:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA13161;
	Thu, 11 Nov 1999 09:19:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA13126
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 09:18:56 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04422
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 09:19:06 -0500 (EST)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA01534;
	Thu, 11 Nov 1999 06:18:24 -0800 (PST)
Message-ID: <382AD051.BDAC48DB@cisco.com>
Date: Thu, 11 Nov 1999 06:18:57 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474
References: <3829C0CB.E18757DC@hursley.ibm.com> <382A9F2F.48A58626@telematik.informatik.uni-karlsruhe.de> <382AB0C0.7DD4D2DA@hursley.ibm.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Brian E Carpenter wrote:
> 
> Klaus Wehrle wrote:
> >
> > Brian E Carpenter wrote:
> >
...
> 
> >
> > If you map BE to ClassSel 2, LBE to ClassSel 1, then you can map EF to the
> > highest ClassSelector and we can forget RFC 2598. I think, that is not was
> > the people on the DiffServ-WG-list want.
> 
> No, there is a very clear distinction between EF and the class
> selectors,
> and we spent months getting consensus on that.
> 

Just to clarify this slightly minor point: You can certainly map
traffic which is marked for the EF PHB to the same queue as Class
Selector 7 (though I think CS 5 would be a better choice), but
then you must ensure that the behavior aggregate of that queue
is getting the treatment described in RFC2598. RFC 2598 isn't
meant to say that there must be another queue if you have 8
CS-compliant ones, it is not meant to say that you must use
the recommended DSCP for it. It just give rules for how a particular
behavior aggregate must be treated at each diffserv node in order
for it to be getting the "EF per hop forwarding treatment". The
reason RFC2598 calls out the specific details of that PHB is that
it is thought to be a useful building block that allows you to
build services whose behavior can then be characterized explicitly
assuming each node has been properly configured according to
RFC2598.

	Kathie

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



From diffserv-admin@ietf.org  Thu Nov 11 12:01:59 1999
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 MAA28304;
	Thu, 11 Nov 1999 12:01:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA15871;
	Thu, 11 Nov 1999 10:49:45 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA15837
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 10:49:41 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20398
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 10:49:50 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11lwTv-0003WO-00; Thu, 11 Nov 1999 16:49:51 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id QAA10406;
	Thu, 11 Nov 1999 16:49:50 +0100 (MET)
Message-Id: <199911111549.QAA10406@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Kathleen Nichols <kmn@cisco.com>
cc: Grenville Armitage <gja@dnrc.bell-labs.com>, DiffServ <diffserv@ietf.org>
Subject: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
In-reply-to: Your message of "Wed, 10 Nov 1999 08:37:06 PST."
             <38299F32.BEA0B494@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Nov 1999 16:47:41 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> I completely agree. Further, I think you could configure a Class
> Selector the same way. Give it a short queue, control the
> service rate and control the amount of the BA stamped for that CS
> admitted to the network.

I suppose that it is true that one could also realize the EF PHB with a
Class Selector Compliant PHB if one applies the additional constraints
of having nearly empty queues for this service due to the condition that
"the departure rate of the aggregate's packets from any diffserv node
must equal or exceed a configurable rate". From this point of view one
could argue that RFC 2598 is not a PHB specification but a SERVICE
definition, namely that of Premium Service that is described in section
1, and it could be realized by a Class Selector Compliant PHB satisfying
the additional requirements quoted above.

So if we have a description of an "externally observable forwarding
treatment applied at a differentiated services-compliant node to a
behavior aggregate" (PHB-Def.) that defines some additional requirements
compared to already existing PHBs, but one could also realize this new
behavior by extending an existing PHB with these additions, what do we 
have: a new PHB or a service definition? If the latter is true, then
RFC 2598 is a service definition and not a PHB definition.
Are there clear distinction criteria for services and PHBs?

Roland



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



From diffserv-admin@ietf.org  Thu Nov 11 12:41:38 1999
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 MAA19493;
	Thu, 11 Nov 1999 12:41:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA17697;
	Thu, 11 Nov 1999 11:32:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA17666
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 11:32:38 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12823
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 11:32:47 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11lx9T-0005E2-00; Thu, 11 Nov 1999 17:32:47 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id RAA10945;
	Thu, 11 Nov 1999 17:32:47 +0100 (MET)
Message-Id: <199911111632.RAA10945@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Albert Manfredi" <albert.e.manfredi@boeing.com>
Cc: "DiffServ" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF with Drop ? 
In-reply-to: Your message of "Wed, 10 Nov 1999 10:11:21 EST."
             <NDBBIBKKCLEFDFDGHCNMMEFJCAAA.albert.e.manfredi@boeing.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Nov 1999 17:30:38 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi,

was it you that asked for how to enable other services than LBE for
multicast in the discussion of diffserv WG session 2? I wanted to
personally comment on this, but I had another discussion and you were
already gone. There are concepts mentioned in our draft how to provide
other PHBs within multicast groups. It is really not a problem for
having a MC group using the EF PHB. The problems which arise have to do
with resource usage and management mainly. The proposed LBE PHB simply
allows JOINs/GRAFTs to be processed in their usual way (as opposed to
requiring their interception) at first. So you get LBE behavior by
default, i.e., without a reservation. If there are resources provisioned
for a "better" PHB or this better PHB is requested explicitly and
corresponding resources are allotted, the branching router simply is
instructed to use another DSCP for the wanted PHB which could be EF
for example. Therefore, LBE also supports heterogeneous mc groups
to same extent.

> traffic, yes? What happens to multicast traffic? None of it is TCP,
> it's hard to justify making it "drop-proof" in the general case, so
> how should it be sent? Is it okay to assume that multicast can be
> sent using AF PHBs?

Yes, why not? Nothing prevents you from using UDP and multicast 
with AF.

> I was thinking yesterday that if we have EF for non-responsive
> flows, we might need more than one EF class to handle multicast?

No, not IMHO. Because you'll typically have admission control and
resource management for EF, there is no problem having responsive and
non-responsive flows within the same EF BA.

> Maybe that's an application for BELD?

I don't think that's necessary.

 Roland
-- 
Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097



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



From diffserv-admin@ietf.org  Thu Nov 11 13:52:44 1999
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 NAA28032;
	Thu, 11 Nov 1999 13:52:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21409;
	Thu, 11 Nov 1999 12:57:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21374
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 12:57:23 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28014
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 12:57:32 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id KAA00380
	for <diffserv@external.cisco.com>; Thu, 11 Nov 1999 10:04:54 -0800 (PST)
Message-Id: <199911111804.KAA00380@sj-mailhub-3.cisco.com>
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by proxy1.cisco.com with SMTP (MailShield v1.5); Thu, 11 Nov 1999 09:57:52 -0800
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Thu, 11 Nov 1999 12:45:53 -0500
Received: from zcard00f.ca.nortel.com ([47.208.128.127]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id WQGKV5X8; Thu, 11 Nov 1999 12:45:51 -0500
Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VA6MJAV7; Thu, 11 Nov 1999 12:45:51 -0500
Date: Thu, 11 Nov 1999 12:45:27 -0500 (EST)
From: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Reply-To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
To: jh@lohi.eng.telia.fi
cc: gja@dnrc.bell-labs.com, jamel@di.ufpe.br, tonyhain@microsoft.com,
        diffserv@external.cisco.com
X-Mailer: Rosa 2.1.1 HP-UXB.10.20
X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-ID: <Rosa.HP-UXB.10..2.1.1.991111124527.19456g@zcarh014>
X-SMTP-HELO: smtprtp1.ntcom.nortel.net
X-SMTP-MAIL-FROM: nseddigh@nortelnetworks.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: smtprtp1.ntcom.nortel.net [137.118.22.14]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21375
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Juha Heinanen writes:


>i don't see any mythical in definition of background SERVICE.  it is a
>service to which no promises nor even expectations are made.  it can be
>IMPLEMENTED as an af class that has been allocated some buffering
>resources, but no scheduling resources,

LBE can certainly be implemented as an AF class. However, I have seen a
number of different service proposals for Diffserv. In many of these,
the AF classes are already spoken for by services that require better
than LBE. So, while in principle, AF can be used, if there are  enough
people who want to use all the AF classes for other services, we may
want to consider a different solution.

-
Regards,
Nabil Seddigh
nseddigh@nortelnetworks.com



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



From diffserv-admin@ietf.org  Thu Nov 11 14:32:15 1999
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 OAA18590;
	Thu, 11 Nov 1999 14:32:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23411;
	Thu, 11 Nov 1999 13:54:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23381
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 13:54:39 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29206
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 13:54:47 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA40022; Thu, 11 Nov 1999 18:54:17 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA19366; Thu, 11 Nov 1999 18:54:15 GMT
Message-ID: <382B10AF.84D09618@hursley.ibm.com>
Date: Thu, 11 Nov 1999 12:53:35 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
CC: DiffServ <diffserv@ietf.org>
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
References: <199911111549.QAA10406@blackfoot.telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Roland,

Need I say again that services are outside the diffserv WG charter?
We should perhaps rephrase your question in terms of behavior
aggregates, which seem to be a lot easier to identify than services.

   Brian

Roland Bless wrote:
> 
> > I completely agree. Further, I think you could configure a Class
> > Selector the same way. Give it a short queue, control the
> > service rate and control the amount of the BA stamped for that CS
> > admitted to the network.
> 
> I suppose that it is true that one could also realize the EF PHB with a
> Class Selector Compliant PHB if one applies the additional constraints
> of having nearly empty queues for this service due to the condition that
> "the departure rate of the aggregate's packets from any diffserv node
> must equal or exceed a configurable rate". From this point of view one
> could argue that RFC 2598 is not a PHB specification but a SERVICE
> definition, namely that of Premium Service that is described in section
> 1, and it could be realized by a Class Selector Compliant PHB satisfying
> the additional requirements quoted above.
> 
> So if we have a description of an "externally observable forwarding
> treatment applied at a differentiated services-compliant node to a
> behavior aggregate" (PHB-Def.) that defines some additional requirements
> compared to already existing PHBs, but one could also realize this new
> behavior by extending an existing PHB with these additions, what do we
> have: a new PHB or a service definition? If the latter is true, then
> RFC 2598 is a service definition and not a PHB definition.
> Are there clear distinction criteria for services and PHBs?
> 
> Roland
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82

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



From diffserv-admin@ietf.org  Thu Nov 11 14:38:24 1999
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 OAA21529;
	Thu, 11 Nov 1999 14:38:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23289;
	Thu, 11 Nov 1999 13:52:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA23257
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 13:52:46 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28190
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 13:52:56 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA87126; Thu, 11 Nov 1999 18:51:50 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA34914; Thu, 11 Nov 1999 18:51:47 GMT
Message-ID: <382B101C.76D89A7@hursley.ibm.com>
Date: Thu, 11 Nov 1999 12:51:08 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
CC: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>,
        diffserv@ietf.org, bless@telematik.informatik.uni-karlsruhe.de
Subject: Re: [Diffserv] LBE using RFC 2474
References: <078292D50C98D2118D090008C7E9C6A606F418EB@STAY.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Yoram,

I wouldn't expect any routers to recognise anything except default
out of the box, except maybe the high class selectors for routing
traffic.
I have running code proof that current routers from a major router
vendor default to rewriting the DSCP to zero, out of the box. So
I really think you are asking for the impossible, and routers
providing an LBE behavior aggregate will definitely need to be
configured.

That being so, there doesn't seem to be any advantage in defining
a recommended DSCP for a BA that we can construct using an existing
PHB.

  Brian

"Yoram Bernet (Exchange)" wrote:
> 
> I agree with Klaus here.
> 
> The point is to have a barin-dead simple way of getting certain traffic to
> be downgraded in priority.
> 
> We're working with our IT group to roll out differentiated services. We have
> to find the least painful way to roll this stuff out. We need to reconfigure
> as few routers as possible. Those that do need reconfiguring should require
> the simplest possible reconfiguration. In addition, we need to worry
> (initially) about as few applications as possible. That means that the
> applications that get special treatment need to be the exception, rather
> than the rule.
> 
> This begs for routers that 'out of the box' just recognize an LBE mark and
> downgrade it relative to other traffic. That in turn, requires standardizing
> an LBE DSCP.
> 
> Yoram
> 
> > -----Original Message-----
> > From: Klaus Wehrle
> > [mailto:wehrle@telematik.informatik.uni-karlsruhe.de]
> > Sent: Thursday, November 11, 1999 2:49 AM
> > To: Brian E Carpenter
> > Cc: diffserv@ietf.org; bless@telematik.informatik.uni-karlsruhe.de
> > Subject: Re: [Diffserv] LBE using RFC 2474
> >
> >
> > Brian E Carpenter wrote:
> >
> > > Kathie and I discussed the less than best effort
> > requirement expressed
> > > by some people, and concluded that this can be done using RFC 2474
> > > with no change:
> >
> > When you override the SHOULD  in RFC 2474, section 4.2.2.2
> > this would be a
> > change ;-)
> >
> > >
> > > In the DSCP to PHB mapping table, map the DSCP value 0 (default)
> > > to the PHB Class Selector 2. Then classify the "LBE" tarffic
> > > into a BA that receives PHB Class Selector 1.
> >
> > nice trick, but if an ISP do not use this mapping, the
> > LBE-traffic would
> > not be treated lower than Best-Effort.
> >
> > If you use a seperate Codepoint for LBE, every router can
> > distinguish it
> > from BE, independant from the mapping of LBE-traffic into a BA that
> > receives lower than BE.
> > I think, there are enough Codepoints left, so why don't we
> > assign one to
> > LBE.
> >
> > If you map BE to ClassSel 2, LBE to ClassSel 1, then you can
> > map EF to the
> > highest ClassSelector and we can forget RFC 2598. I think,
> > that is not was
> > the people on the DiffServ-WG-list want.
> >
> > I don't know, if every ISP wants to offer services, that only
> > bases on AF
> > or EF or the ClassSelectors.
> >
> > >
> > > This usage overrides the SHOULD in RFC 2474, section 4.2.2.2,
> > > but that is why we use SHOULD instead of MUST.
> >
> > --------------------
> > Ciao,
> > Klaus
> >
> > --
> >
> >  Klaus Wehrle
> >  Institut fur Telematik, Universitat Karlsruhe (TH)
> >  Zirkel 2, 76128 Karlsruhe, Germany
> >  Phone: +49 721 608 6414, Fax: +49 721 388097
> >  mailto:wehrle@telematik.informatik.uni-karlsruhe.de
> >  http://www.telematik.informatik.uni-karlsruhe.de/~wehrle
> >
> >
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82

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



From diffserv-admin@ietf.org  Thu Nov 11 14:47:51 1999
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 OAA26022;
	Thu, 11 Nov 1999 14:47:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA23782;
	Thu, 11 Nov 1999 14:02:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA23755
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 14:02:46 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03719
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 14:02:56 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id LAA23895
	for <diffserv@external.cisco.com>; Thu, 11 Nov 1999 11:00:55 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy2.cisco.com with SMTP (MailShield v1.5); Thu, 11 Nov 1999 11:04:32 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA18476; Thu, 11 Nov 1999 18:58:18 GMT
Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA33014; Thu, 11 Nov 1999 18:58:06 GMT
Message-ID: <382B1198.6D10747B@hursley.ibm.com>
Date: Thu, 11 Nov 1999 12:57:28 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Nabil Seddigh <nseddigh@nortelnetworks.com>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <199911111804.KAA00380@sj-mailhub-3.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Nabil,

You can create as many AF classes as you want, subject to the size
of the 6 bit DSCP field. 21 AF classes would use up 63 code points,
leaving one free for default. Obviously this is arguing from the
absurd, but a given deployment is not limited to 4 AF classes.

  Brian

Nabil Seddigh wrote:
> 
> Juha Heinanen writes:
> 
> >i don't see any mythical in definition of background SERVICE.  it is a
> >service to which no promises nor even expectations are made.  it can be
> >IMPLEMENTED as an af class that has been allocated some buffering
> >resources, but no scheduling resources,
> 
> LBE can certainly be implemented as an AF class. However, I have seen a
> number of different service proposals for Diffserv. In many of these,
> the AF classes are already spoken for by services that require better
> than LBE. So, while in principle, AF can be used, if there are  enough
> people who want to use all the AF classes for other services, we may
> want to consider a different solution.
> 
> -
> Regards,
> Nabil Seddigh
> nseddigh@nortelnetworks.com
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82


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



From diffserv-admin@ietf.org  Thu Nov 11 17:18:27 1999
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 RAA09669;
	Thu, 11 Nov 1999 17:18:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA00228;
	Thu, 11 Nov 1999 16:29:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA00188
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 16:29:52 -0500 (EST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17309
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 16:30:01 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Nov 11 16:28:46 EST 1999
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.33.72])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA14413;
	Thu, 11 Nov 1999 16:28:42 -0500 (EST)
Message-ID: <382B3545.34107722@dnrc.bell-labs.com>
Date: Thu, 11 Nov 1999 13:29:41 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: DiffServ <diffserv@ietf.org>
Subject: Re: [Diffserv] EF with Drop ?
References: <NDBBIBKKCLEFDFDGHCNMMEFJCAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Albert Manfredi wrote:
> 
> Grenville,
> 
> First, how can anybody think in a hall with 300 people and with a
> long list of drafts to be force-fed to this mass?

Dont you know? We all formulate our opinions before coming to
the meetings, and simply state them as many times as needed to
be the last speaker standing ;-)

But seriously...

> I think I agree with your point, that AF after all is nothing but a
> set of PHBs with drop precedence. But one issue that might or might
> not be a problem is that AF PHBs are geared toward TCP (responsive)
> traffic, yes? What happens to multicast traffic? None of it is TCP,
> it's hard to justify making it "drop-proof" in the general case, so
> how should it be sent? Is it okay to assume that multicast can be
> sent using AF PHBs?

Sure, nothing stops AF from being used with multicast, and nothing
limits AF to TCP traffic. (It happens to be useful for bursty, latency
tolerant, and loss tolerant traffic in many envisaged deployments
but that's a different statement.)

> I was thinking yesterday that if we have EF for non-responsive
> flows, we might need more than one EF class to handle multicast?
> Maybe that's an application for BELD?

No. At least, not "BELD the PHB" but perhaps "BELD the service". Which
brings me back to my point that "BELD the service" can be supported
by "AF the PHB + appropriate provisioning and edge shaping".

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies

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



From diffserv-admin@ietf.org  Thu Nov 11 17:41:03 1999
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 RAA20474;
	Thu, 11 Nov 1999 17:41:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA03317;
	Thu, 11 Nov 1999 17:17:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA03280
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 17:17:51 -0500 (EST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09478
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 17:18:00 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Nov 11 17:16:51 EST 1999
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.33.48])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA16867;
	Thu, 11 Nov 1999 17:16:42 -0500 (EST)
Message-ID: <382B4047.1FAE1C4B@dnrc.bell-labs.com>
Date: Thu, 11 Nov 1999 14:16:39 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474
References: <078292D50C98D2118D090008C7E9C6A606F418EB@STAY.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Yoram,

> "Yoram Bernet (Exchange)" wrote:
> 
> I agree with Klaus here.
> 
> The point is to have a barin-dead simple way of getting certain traffic to be
> downgraded in priority.

Or certain other traffic to be upgraded in priority.

It appears to me that the motivating arguments boils down to the
following:

	- Many traditional applications (and their users) have been
	  lulled into experiencing Best Effort (BE) as the Actually
	  Pretty Good (APG) service.
	- Some people believe they have customers interested in a
	  service that isn't as good as the APG service they've come
	  to know (and ergo hopefully cheaper).
	- Some people have an IT department that wants to deploy some
	  new apps with 'in the background' priority so as not to
	  disturb the APG service being received by existing apps.
	- Both of the preceding points are legitimate concerns and
	  generate a demand for at least two distinct service
	  levels - APG and something less.

Our shared problem is that the APG service is being received by traffic
marked (by default or design) as BE. I can understand this has created
a conflict, since BE is _supposed_ to be the cheap-and-crappy
service.

I have a major problem with defining LBE because it cements in the
notion that BE actually isn't BE. It also implies some notion of
an APG service which to date is not being characterized anywhere
(except by circular definition of "the service that's better than
LBE", which doesn't really help much).

I also dont believe LBE is necessary. What is necessary is to
have those apps and customers who really desire an APG service
be remarked to a DSCP that will given it to them (whether a Class
Selector or AF codepoint). Leave BE as it has always been. Voila,
we have two levels of service as desired.

	[..]
> This begs for routers that 'out of the box' just recognize an LBE mark and
> downgrade it relative to other traffic. That in turn, requires standardizing
> an LBE DSCP.

I believe this begs for a diffserv deployment that actually uses
MF classifiers at the edges to assign DSCPs appropriately,
marking all current traffic as APG except those new services you're
worried about which can be assigned BE. Your core routers then dont
need an additional DSCP/PHB to worry about - just the existing BE,
ClassSelector, and/or AF groups.

cheers,
gja
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies


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



From diffserv-admin@ietf.org  Thu Nov 11 17:47:01 1999
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 RAA23524;
	Thu, 11 Nov 1999 17:47:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA02478;
	Thu, 11 Nov 1999 17:03:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA02449
	for <diffserv@optimus.ietf.org>; Thu, 11 Nov 1999 17:03:20 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02887
	for <diffserv@ietf.org>; Thu, 11 Nov 1999 17:03:29 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11m2JW-0003OD-00; Thu, 11 Nov 1999 23:03:30 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id XAA14537;
	Thu, 11 Nov 1999 23:03:30 +0100 (MET)
Message-Id: <199911112203.XAA14537@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Brian E Carpenter <brian@hursley.ibm.com>
cc: DiffServ <diffserv@ietf.org>
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?) 
In-reply-to: Your message of "Thu, 11 Nov 1999 12:53:35 CST."
             <382B10AF.84D09618@hursley.ibm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Nov 1999 23:01:20 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> Roland,
> 
> Need I say again that services are outside the diffserv WG charter?

No, we just wanted to know when we talk about PHBs and when not.
It was often argued that the LBE PHB is not a PHB but a service.
IMHO the LBE PHB is a PHB in relation to the PHB definition,
and we are still not convinced that this is not the case. We are
not saying (and never said, because it was already mentioned in the 
draft) that it could not be realized by an specific implementation of an
AF PHB (just as EF and CSC PHBs).

> We should perhaps rephrase your question in terms of behavior

To me it's not obvious how to do this and what the answer is.

> aggregates, which seem to be a lot easier to identify than services.

Roland
-- 
Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097



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



From diffserv-admin@ietf.org  Fri Nov 12 06:58:09 1999
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 GAA04178;
	Fri, 12 Nov 1999 06:58:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA01192;
	Fri, 12 Nov 1999 06:38:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id GAA01162
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 06:37:55 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29262
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 06:38:05 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id DAA08874
	for <diffserv@external.cisco.com>; Fri, 12 Nov 1999 03:45:42 -0800 (PST)
Received: from recife.di.ufpe.br (recife.di.ufpe.br [150.161.2.1]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 12 Nov 1999 03:38:33 -0800
Received: from zumbi.diufpe (zumbi [150.161.2.201])
	by recife.di.ufpe.br (8.9.3/8.9.3) with ESMTP id JAA27027;
	Fri, 12 Nov 1999 09:26:36 -0200 (EDT)
Received: (from jamel@localhost)
	by zumbi.diufpe (8.9.1b+Sun/8.9.1) id JAA26399;
	Fri, 12 Nov 1999 09:26:35 -0200 (EDT)
Date: Fri, 12 Nov 1999 09:26:33 -0200 (EDT)
From: "Jamel H. Sadok" <jamel@di.ufpe.br>
X-Sender: jamel@zumbi
To: Nabil Seddigh <nseddigh@nortelnetworks.com>
cc: jh@lohi.eng.telia.fi, gja@dnrc.bell-labs.com, tonyhain@microsoft.com,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <199911111752.PAA24418@recife.di.ufpe.br>
Message-ID: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SMTP-HELO: recife.di.ufpe.br
X-SMTP-MAIL-FROM: jamel@di.ufpe.br
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: recife.di.ufpe.br [150.161.2.1]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org



> 
> LBE can certainly be implemented as an AF class. However, I have seen a
> number of different service proposals for Diffserv. In many of these,
> the AF classes are already spoken for by services that require better
> than LBE. So, while in principle, AF can be used, if there are  enough
> people who want to use all the AF classes for other services, we may
> want to consider a different solution.


I think it is important to get to know *actual* examples of proposals
for DiffServ (and compile a list of these if possible). Knowing for a fact
which of the AF classes are spoken for could help getting closer to a
consensus on whether to create a new PHBs.

Jamel



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



From diffserv-admin@ietf.org  Fri Nov 12 07:32:05 1999
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 HAA12666;
	Fri, 12 Nov 1999 07:32:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA02633;
	Fri, 12 Nov 1999 07:16:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA02602
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 07:16:11 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08757
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 07:16:22 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id MAA03552; Fri, 12 Nov 1999 12:15:51 GMT
Received: from hursley.ibm.com (lig32-227-59-196.us.lig-dial.ibm.com [32.227.59.196]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA26256; Fri, 12 Nov 1999 12:15:45 GMT
Message-ID: <382C04C8.CD4AB465@hursley.ibm.com>
Date: Fri, 12 Nov 1999 06:15:04 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
CC: DiffServ <diffserv@ietf.org>
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
References: <199911112203.XAA14537@blackfoot.telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Roland,

We will be trying to come back to the list with a very precise
definition of how to identify and describe BAs.

   Brian

Roland Bless wrote:
> 
> > Roland,
> >
> > Need I say again that services are outside the diffserv WG charter?
> 
> No, we just wanted to know when we talk about PHBs and when not.
> It was often argued that the LBE PHB is not a PHB but a service.
> IMHO the LBE PHB is a PHB in relation to the PHB definition,
> and we are still not convinced that this is not the case. We are
> not saying (and never said, because it was already mentioned in the
> draft) that it could not be realized by an specific implementation of an
> AF PHB (just as EF and CSC PHBs).
> 
> > We should perhaps rephrase your question in terms of behavior
> 
> To me it's not obvious how to do this and what the answer is.
> 
> > aggregates, which seem to be a lot easier to identify than services.
> 
> Roland
> --
> Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
> Institute of Telematics, University of Karlsruhe, F.R. of Germany
> Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
> Phone: +49 721 608-6396 Fax: +49 721 388097

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



From diffserv-admin@ietf.org  Fri Nov 12 11:56:19 1999
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 LAA08154;
	Fri, 12 Nov 1999 11:56:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA11224;
	Fri, 12 Nov 1999 11:12:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA11193
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 11:12:09 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17974
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 11:12:18 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id IAA13305
	for <diffserv@external.cisco.com>; Fri, 12 Nov 1999 08:10:26 -0800 (PST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by proxy3.cisco.com with SMTP (MailShield v1.5); Fri, 12 Nov 1999 08:08:34 -0800
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Nov 12 10:36:26 EST 1999
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.37.233])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA18813;
	Fri, 12 Nov 1999 10:36:15 -0500 (EST)
Message-ID: <382C342B.C1A47001@dnrc.bell-labs.com>
Date: Fri, 12 Nov 1999 07:37:15 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jamel H. Sadok" <jamel@di.ufpe.br>
CC: Nabil Seddigh <nseddigh@nortelnetworks.com>, diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: crufty.research.bell-labs.com
X-SMTP-MAIL-FROM: gja@dnrc.bell-labs.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: crufty.research.bell-labs.com [204.178.16.49]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


AF classes are not being exhausted in the manner you both imply.
Depending on how you arrange your network, you could
be using AF1y for one service in one DS domain, and AF1y for an
entirely different service in another DS domain. And there's
nothing stopping you from assigning more DSCPs for additional
AF classes.

NB. Assigning new DSCPs to create additional instances of an
existing PHB is not the same as creating a new PHB.

cheers,
gja

"Jamel H. Sadok" wrote:
> 
> >
> > LBE can certainly be implemented as an AF class. However, I have seen a
> > number of different service proposals for Diffserv. In many of these,
> > the AF classes are already spoken for by services that require better
> > than LBE. So, while in principle, AF can be used, if there are  enough
> > people who want to use all the AF classes for other services, we may
> > want to consider a different solution.
> 
> I think it is important to get to know *actual* examples of proposals
> for DiffServ (and compile a list of these if possible). Knowing for a fact
> which of the AF classes are spoken for could help getting closer to a
> consensus on whether to create a new PHBs.
> 
> Jamel

-- 
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies


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



From diffserv-admin@ietf.org  Fri Nov 12 13:51:45 1999
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 NAA29426;
	Fri, 12 Nov 1999 13:51:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA14265;
	Fri, 12 Nov 1999 12:57:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA14236
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 12:56:56 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05416
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 12:57:07 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA24351
	for <diffserv@external.cisco.com>; Fri, 12 Nov 1999 09:57:20 -0800 (PST)
Received: from cisco.com (ssh.cisco.com [171.69.10.34])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA24456;
	Fri, 12 Nov 1999 09:50:01 -0800 (PST)
Message-ID: <382C537A.E30F20C8@cisco.com>
Date: Fri, 12 Nov 1999 09:50:50 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jamel H. Sadok" <jamel@di.ufpe.br>
CC: Nabil Seddigh <nseddigh@nortelnetworks.com>, jh@lohi.eng.telia.fi,
        gja@dnrc.bell-labs.com, tonyhain@microsoft.com,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



"Jamel H. Sadok" wrote:
> 
...
> > LBE can certainly be implemented as an AF class. However, I have seen a
> > number of different service proposals for Diffserv. In many of these,
> > the AF classes are already spoken for by services that require better
> > than LBE. 
...
> 
> I think it is important to get to know *actual* examples of proposals
> for DiffServ (and compile a list of these if possible). Knowing for a fact
> which of the AF classes are spoken for could help getting closer to a
> consensus on whether to create a new PHBs.
> 

Yes, I like this idea of avoiding "diffserv folklore". But what's
a good test for something to be more "known"? And when do we
think something has "global" significance rather than significance
within a single domain?

	Kathie

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



From diffserv-admin@ietf.org  Fri Nov 12 15:59:46 1999
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 PAA29663;
	Fri, 12 Nov 1999 15:59:46 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA17440;
	Fri, 12 Nov 1999 15:17:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA17410
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 15:17:35 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10288
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 15:17:45 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id MAA20913
	for <diffserv@external.cisco.com>; Fri, 12 Nov 1999 12:15:44 -0800 (PST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by proxy2.cisco.com with SMTP (MailShield v1.5); Fri, 12 Nov 1999 07:45:02 -0800
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Nov 12 10:36:26 EST 1999
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.37.233])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA18813;
	Fri, 12 Nov 1999 10:36:15 -0500 (EST)
Message-ID: <382C342B.C1A47001@dnrc.bell-labs.com>
Date: Fri, 12 Nov 1999 07:37:15 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jamel H. Sadok" <jamel@di.ufpe.br>
CC: Nabil Seddigh <nseddigh@nortelnetworks.com>, diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: crufty.research.bell-labs.com
X-SMTP-MAIL-FROM: gja@dnrc.bell-labs.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: crufty.research.bell-labs.com [204.178.16.49]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


AF classes are not being exhausted in the manner you both imply.
Depending on how you arrange your network, you could
be using AF1y for one service in one DS domain, and AF1y for an
entirely different service in another DS domain. And there's
nothing stopping you from assigning more DSCPs for additional
AF classes.

NB. Assigning new DSCPs to create additional instances of an
existing PHB is not the same as creating a new PHB.

cheers,
gja

"Jamel H. Sadok" wrote:
> 
> >
> > LBE can certainly be implemented as an AF class. However, I have seen a
> > number of different service proposals for Diffserv. In many of these,
> > the AF classes are already spoken for by services that require better
> > than LBE. So, while in principle, AF can be used, if there are  enough
> > people who want to use all the AF classes for other services, we may
> > want to consider a different solution.
> 
> I think it is important to get to know *actual* examples of proposals
> for DiffServ (and compile a list of these if possible). Knowing for a fact
> which of the AF classes are spoken for could help getting closer to a
> consensus on whether to create a new PHBs.
> 
> Jamel

-- 
________________________________________________________________________
Grenville Armitage                            http://mh005.infi.net/~gja
Bell Labs Research, Lucent Technologies


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



From diffserv-admin@ietf.org  Fri Nov 12 17:10:39 1999
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 RAA26298;
	Fri, 12 Nov 1999 17:10:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA19055;
	Fri, 12 Nov 1999 16:36:25 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA19020
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 16:36:21 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11367
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 16:36:25 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id NAA16492
	for <diffserv@external.cisco.com>; Fri, 12 Nov 1999 13:44:00 -0800 (PST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by proxy1.cisco.com with SMTP (MailShield v1.5); Fri, 12 Nov 1999 13:36:49 -0800
Received: from nbitar1 ([152.148.89.22])
	by alpo.casc.com (8.9.1a/8.9.1) with SMTP id QAA12302;
	Fri, 12 Nov 1999 16:12:54 -0500 (EST)
Received: by localhost with Microsoft MAPI; Fri, 12 Nov 1999 16:08:26 -0500
Message-ID: <01BF2D28.272DD4C0.nbitar@lucent.com>
From: Nabil Bitar <nbitar@lucent.com>
Reply-To: "nbitar@lucent.com" <nbitar@lucent.com>
To: "'Nabil Seddigh'" <nseddigh@nortelnetworks.com>,
        "jh@lohi.eng.telia.fi"
	 <jh@lohi.eng.telia.fi>
Cc: "gja@dnrc.bell-labs.com" <gja@dnrc.bell-labs.com>,
        "jamel@di.ufpe.br"
	 <jamel@di.ufpe.br>,
        "tonyhain@microsoft.com"
	 <tonyhain@microsoft.com>,
        "diffserv@external.cisco.com"
	 <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
Date: Fri, 12 Nov 1999 16:08:25 -0500
Organization: INS Lucent Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: alpo.casc.com
X-SMTP-MAIL-FROM: nbitar@lucent.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: alpo.casc.com [152.148.10.6]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,
I have a question about LBE. Is LBE supposed to have less share of 
bandwidth (whether excess or available) than BE and higher drop precedence 
than BE? Or is it different. If this the case, one can argue that BE  and 
LBE can possibly be implemented using two different instances of AF with 
the appropriate parameter settings.

Regarding the current number of AF classes and how they are perceived to be 
used, all that there is to the AF PHB is that it allows up 3 drop 
precedence levels for each class (preferably 3 and possibly 2). The number 
of 4 classes allows reservation of 12 DSCPs for AF. Thus, there is nothing 
that limits the configuration of more or less AF classes. So, if 4 AF 
classes are needed to run better than LBE and BE services, a 5th AF class 
can be configured to run an LBE service. I guess that the question is if 
there is need to grab DSCP(s) out of the non-experimental space for this AF 
class to provide LBE service (as done for the existing 4 AF classes). In 
addition, for this LBE service, do you need 3 drop precedence levels? That 
is, do you need to use three DSCPs? I am not sure what the this PHB is 
supposed to provide. If you need one drop precedence, then it can be 
configured as an AF class with one drop precedence level (i.e. possibly 
drop whenever you exceed a certain buffer size). In that case, do we still 
call it AF? That brings me to another point. It seems that anything can be 
configured using AF. Even EF, as some people claim, can be implemented 
using the AF PHB ! (although one may dispute that).  Is AF a universal PHB 
so that any PHB can be mapped to an appropriately configured instance of 
AF? Is it the way that is intended to be?

Nabil.
On Thursday, November 11, 1999 12:45 PM, Nabil Seddigh 
[SMTP:nseddigh@nortelnetworks.com] wrote:
> Juha Heinanen writes:
>
>
> >i don't see any mythical in definition of background SERVICE.  it is a
> >service to which no promises nor even expectations are made.  it can be
> >IMPLEMENTED as an af class that has been allocated some buffering
> >resources, but no scheduling resources,
>
> LBE can certainly be implemented as an AF class. However, I have seen a
> number of different service proposals for Diffserv. In many of these,
> the AF classes are already spoken for by services that require better
> than LBE. So, while in principle, AF can be used, if there are  enough
> people who want to use all the AF classes for other services, we may
> want to consider a different solution.
>
> -
> Regards,
> Nabil Seddigh
> nseddigh@nortelnetworks.com
>
>
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


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



From diffserv-admin@ietf.org  Fri Nov 12 20:11:12 1999
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 UAA20567;
	Fri, 12 Nov 1999 20:11:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA23966;
	Fri, 12 Nov 1999 19:50:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA23928
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 19:50:47 -0500 (EST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11829
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 19:50:54 -0500 (EST)
Received: from pzero.sandelman.ottawa.on.ca (dhcp10.sandelman.ottawa.on.ca [209.151.24.10])
	by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id TAA22107;
	Fri, 12 Nov 1999 19:50:54 -0500 (EST)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id RAA00516;
	Thu, 11 Nov 1999 17:24:01 -0500 (EST)
Message-Id: <199911112224.RAA00516@pzero.sandelman.ottawa.on.ca>
To: diffserv@ietf.org
cc: "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Thu, 11 Nov 1999 12:51:08 CST."
             <382B101C.76D89A7@hursley.ibm.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 11 Nov 1999 17:15:20 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


  Again, I do not understand why the problem expressed by Yoram is not
solveable by distinguishing between "DSCP == 0" and "BE"

  Why can't Yoram solve his problem by assigning DSCP==0 to be something
other than the BE queue? As one pointed out, with appropriate AF parameters,
you can get the behaviour that is wanted.

  I got silence at diffserv when I asked this. Some people commented
afterward to me that they didn't know either. Can someone answer me this? 
  The DSCP to PHB mapping is programmable by the administrator.

  If BE works for Yoram's network as it is now, then some "better" service
ought to work as well, right?

]         At IETF46 in Washington, DC  --- wireless             |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [




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



From diffserv-admin@ietf.org  Fri Nov 12 20:24:43 1999
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 UAA27076;
	Fri, 12 Nov 1999 20:24:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA23994;
	Fri, 12 Nov 1999 19:50:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA23929
	for <diffserv@optimus.ietf.org>; Fri, 12 Nov 1999 19:50:47 -0500 (EST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11827
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 19:50:53 -0500 (EST)
Received: from pzero.sandelman.ottawa.on.ca (dhcp10.sandelman.ottawa.on.ca [209.151.24.10])
	by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id TAA22058
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 19:50:50 -0500 (EST)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA00543
	for <diffserv@ietf.org>; Fri, 12 Nov 1999 09:14:08 -0500 (EST)
Message-Id: <199911121414.JAA00543@pzero.sandelman.ottawa.on.ca>
To: diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Thu, 11 Nov 1999 14:16:39 PST."
             <382B4047.1FAE1C4B@dnrc.bell-labs.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 12 Nov 1999 09:14:08 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


>>>>> "Grenville" == Grenville Armitage <gja@dnrc.bell-labs.com> writes:
    Grenville> I also dont believe LBE is necessary. What is necessary is to
    Grenville> have those apps and customers who really desire an APG service
    Grenville> be remarked to a DSCP that will given it to them (whether a Class
    Grenville> Selector or AF codepoint). Leave BE as it has always been. Voila,
    Grenville> we have two levels of service as desired.

  The problem is that this requires coordination for all user's of service
"X" that wanted APG, and with 200-300 distinct applications, it may not be
clear which services are most important. So, to do this right, you need
flag-days (maybe flag-months).

  This is not a way to endear diffserv to IT departments. 

  One solution is to remark all DSCP==0 traffic that arrives at any diffserv
aware router to a different code point for a period. But, why bother do that?
Just change the DSCP==0 mapping from the BE PHB to the APG PHB (whatever that 
means).

]         At IETF46 in Washington, DC  --- wireless             |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

  
  

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



From diffserv-admin@ietf.org  Sun Nov 14 06:38:27 1999
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 GAA12094;
	Sun, 14 Nov 1999 06:38:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA05325;
	Sun, 14 Nov 1999 05:52:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA05289
	for <diffserv@optimus.ietf.org>; Sun, 14 Nov 1999 05:52:38 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21052
	for <diffserv@ietf.org>; Sun, 14 Nov 1999 05:52:49 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id DAA21171
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 03:00:44 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy1.cisco.com with SMTP (MailShield v1.5); Sun, 14 Nov 1999 02:53:20 -0800
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id MAA02751;
	Sun, 14 Nov 1999 12:47:59 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14382.37727.423285.754324@lohi.eng.telia.fi>
Date: Sun, 14 Nov 1999 12:47:59 +0200 (EET)
To: Kathleen Nichols <kmn@cisco.com>
Cc: "Jamel H. Sadok" <jamel@di.ufpe.br>,
        Nabil Seddigh <nseddigh@nortelnetworks.com>, gja@dnrc.bell-labs.com,
        tonyhain@microsoft.com, diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <382C537A.E30F20C8@cisco.com>
References: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
	<382C537A.E30F20C8@cisco.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

it might be a good idea to start publishing service specifications as
informational rfcs in order to avoid having a new phb for each service.
should that happen inside or outside the diffserv working group?

-- juha


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



From diffserv-admin@ietf.org  Sun Nov 14 16:12:28 1999
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 QAA27490;
	Sun, 14 Nov 1999 16:12:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12210;
	Sun, 14 Nov 1999 15:33:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12179
	for <diffserv@optimus.ietf.org>; Sun, 14 Nov 1999 15:32:59 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08843
	for <diffserv@ietf.org>; Sun, 14 Nov 1999 15:33:08 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id MAA15829
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 12:31:07 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by proxy1.cisco.com with SMTP (MailShield v1.5); Sun, 14 Nov 1999 12:33:41 -0800
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA127284
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 15:28:03 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA32638
	for <diffserv%external.cisco.com@relay.us.ibm.com>; Sun, 14 Nov 1999 15:28:49 -0500
Message-Id: <199911142028.PAA32638@northrelay03.pok.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6104 ; Sun, 14 Nov 1999 13:27:46 MST
Date: Sun, 14 Nov 99 21:29:01 CET
From: "Bert Wijnen" <WIJNEN@vnet.ibm.com>
To: diffserv@external.cisco.com
X-SMTP-HELO: e3.ny.us.ibm.com
X-SMTP-MAIL-FROM: wijnen@vnet.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: e3.ny.us.ibm.com [32.97.182.103]
Subject: [Diffserv] discussion of requirments for configuration management
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

At the CFGMGMT BOF in Wahsinton D.C. we decided to continue the
discussion of requirements for configuration management.

We have opened a separate mailing list for this discussion.
This mailing list is at:

  confmgt@ops.ietf.org

To subscribe do one of the following:

  - send email to confmgt-request@ops.ietf.org
    in the body put a single line with text:  subscribe

  - send email to majordomo@ops.ietf.org
    in the body put a single line with:  subscribe confmgmt

Please do not discuss configuration management requirments on the
mumble mailing list anymore.

The current list of requirements can be found in section 3 of:

   http://www.ietf.org/internet-drafts/draft-ops-mumble-conf-management-00.txt

Several people at the BOF stated support for the requirements listed
in section 3 of the above document. It is good to hear from others
if they agree or disagree with that list of requirements.

Also, at the BOF, quite a few people stated additional requirements.
It would be nice if they could all prepare their requirement in
a concise posting to the new mailing list, so that others can then
indicate if they agree or disagree.

People who were not at the BOF and who want to state additional
requirements are invited to post them and contribute to the
discussion.

The draft-ops-mumble-conf-management-00.txt document also contains
two sections (4 and 5) in which COPS-PR/PIN and SNMP/MIB are
evaluated against the requirements in section 3. We do not currently
want more discussion on an evaluation. First we want to collect all
the requirements and include them in the list. Probably the
document with requirments can be posted as an informational RFC
later. After that... we may consider evaluating solutions against
the then consolidated list of requirements, but pls not now.

Thanks,
Bert


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



From diffserv-admin@ietf.org  Sun Nov 14 16:19:40 1999
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 QAA00908;
	Sun, 14 Nov 1999 16:19:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12361;
	Sun, 14 Nov 1999 15:46:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA12337
	for <diffserv@optimus.ietf.org>; Sun, 14 Nov 1999 15:46:36 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15338
	for <diffserv@ietf.org>; Sun, 14 Nov 1999 15:46:47 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id MAA27484
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 12:47:11 -0800 (PST)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by proxy3.cisco.com with SMTP (MailShield v1.5); Sun, 14 Nov 1999 12:43:01 -0800
Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210])
	by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA197518
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 15:41:41 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by southrelay03.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA103602
	for <diffserv%external.cisco.com@relay.us.ibm.com>; Sun, 14 Nov 1999 15:42:09 -0500
Message-Id: <199911142042.PAA103602@southrelay03.raleigh.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6139 ; Sun, 14 Nov 1999 13:41:24 MST
Date: Sun, 14 Nov 99 21:42:38 CET
From: "Bert Wijnen" <WIJNEN@vnet.ibm.com>
To: diffserv@external.cisco.com
X-SMTP-HELO: e2.ny.us.ibm.com
X-SMTP-MAIL-FROM: wijnen@vnet.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: e2.ny.us.ibm.com [32.97.182.102]
Subject: [Diffserv] discussion of terminology for policy based (network) management
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

At the POLTERM BOF in Wahsinton D.C. we decided to continue the
discussion of terminology for policy based network management.

We have opened a separate mailing list for this discussion.
This mailing list is at:

  polterm@ops.ietf.org

To subscribe do one of the following:

  - send email to polterm-request@ops.ietf.org
    in the body put a single line with text:  subscribe

  - send email to majordomo@ops.ietf.org
    in the body put a single line with:  subscribe polterm

Please do not send postings about terminology to the mumble list anymore.

There is an initial document that discusses some of this, but it
is far from complete. But for those who have not yet seen it:

   http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt

Several people at the BOF have made comments already, based on the
slides that Fran Reichmeijer presented. I would like Fran to make the
slides available for FTP or so. COuld the others post their
statements/points (in a concise form please), so that everybody can
take part in the full discussion.

We would like the Design Team who did the original work to continue
to collect the terminology input and write a document that gets
closer and closer to a commponly agreed set of terms.
Since this is a cross WG effort, I would like the Design Team to
report to the collective set of WG chairs of those WGs, and as
such, I need to discuss that first with the WG chairs before
I can give more details.

Thanks,
Bert


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



From diffserv-admin@ietf.org  Mon Nov 15 00:06:06 1999
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 AAA16524;
	Mon, 15 Nov 1999 00:06:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA21803;
	Sun, 14 Nov 1999 23:45:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA21772
	for <diffserv@optimus.ietf.org>; Sun, 14 Nov 1999 23:45:35 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06685
	for <diffserv@ietf.org>; Sun, 14 Nov 1999 23:45:45 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id UAA20227
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 20:53:46 -0800 (PST)
Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA24657
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 20:45:15 -0800 (PST)
Message-ID: <382F902F.CE96086B@cisco.com>
Date: Sun, 14 Nov 1999 20:46:39 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
References: <Pine.GSO.3.95.991112092030.25534D-100000@zumbi>
		<382C537A.E30F20C8@cisco.com> <14382.37727.423285.754324@lohi.eng.telia.fi>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit




Juha Heinanen wrote:
> 
> it might be a good idea to start publishing service specifications as
> informational rfcs in order to avoid having a new phb for each service.
> should that happen inside or outside the diffserv working group?
> 
> -- juha

At present, there is nothing about services in our charter. We are
working on a new charter and will be working to make it clear and
narrow for a fairly short time horizon. So, if you plan to specify a
service now, that would have to be outside the diffserv WG.

	Kathie

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



From diffserv-admin@ietf.org  Mon Nov 15 00:36:44 1999
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 AAA28897;
	Mon, 15 Nov 1999 00:36:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA22037;
	Sun, 14 Nov 1999 23:59:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id XAA22009
	for <diffserv@optimus.ietf.org>; Sun, 14 Nov 1999 23:59:20 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13607
	for <diffserv@ietf.org>; Sun, 14 Nov 1999 23:59:29 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id UAA29633
	for <diffserv@external.cisco.com>; Sun, 14 Nov 1999 20:59:53 -0800 (PST)
Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by proxy1.cisco.com with SMTP (MailShield v1.5); Sun, 14 Nov 1999 21:00:01 -0800
Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.E76CF610@mailer.syr.edu>; 14 Nov 1999 23:56:44 -0500
Received: from localhost (hamantar@localhost)
	by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id XAA14510;
	Sun, 14 Nov 1999 23:56:43 -0500 (EST)
X-Authentication-Warning: rodan.syr.edu: hamantar owned process doing -bs
Date: Sun, 14 Nov 1999 23:56:42 -0500 (EST)
From: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
X-Sender: hamantar@rodan.syr.edu
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
cc: diffserv@external.cisco.com
In-Reply-To: <382C537A.E30F20C8@cisco.com>
Message-ID: <Pine.SOL.4.10.9911142350220.11899-100000@rodan.syr.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SMTP-HELO: mailer.syr.edu
X-SMTP-MAIL-FROM: hamantar@mailbox.syr.edu
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mailer.syr.edu [128.230.18.29]
Subject: [Diffserv] MPLS vs Diff-Serv
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi

Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
For example: MPLS uses extended RSVP for reservation, Is there any this
kind of related or depended functions between Diff-Serv and MPLS.

Thanks


HACI ALI MANTAR



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



From diffserv-admin@ietf.org  Mon Nov 15 01:17:34 1999
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 BAA18668;
	Mon, 15 Nov 1999 01:17:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA22874;
	Mon, 15 Nov 1999 00:31:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA22846
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 00:31:47 -0500 (EST)
Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26664
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 00:31:59 -0500 (EST)
Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.D4AAEBE0@mailer.syr.edu>; Mon, 15 Nov 1999 0:32:00 -0500
Received: from localhost (hamantar@localhost)
	by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id AAA24833
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 00:31:58 -0500 (EST)
X-Authentication-Warning: rodan.syr.edu: hamantar owned process doing -bs
Date: Mon, 15 Nov 1999 00:31:58 -0500 (EST)
From: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
X-Sender: hamantar@rodan.syr.edu
To: diffserv@ietf.org
Message-ID: <Pine.SOL.4.10.9911150031320.23611-100000@rodan.syr.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Diffserv] MPLS vs Diff-Serv
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


Hi

Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
For example: MPLS uses extended RSVP for reservation, Is there any this
kind of related or depended functions between Diff-Serv and MPLS.

Thanks


HACI ALI MANTAR



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



From diffserv-admin@ietf.org  Mon Nov 15 09:45:07 1999
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 JAA27539;
	Mon, 15 Nov 1999 09:45:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA11505;
	Mon, 15 Nov 1999 08:49:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA11480
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 08:49:37 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14399
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 08:49:50 -0500 (EST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.25798-0@bells.cs.ucl.ac.uk>; Mon, 15 Nov 1999 13:49:41 +0000
To: diffserv@ietf.org
Date: Mon, 15 Nov 1999 13:49:40 +0000
Message-ID: <1613.942673780@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Subject: [Diffserv] Report on DECIDES BOF 2
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org




                            Report on DECIDES BOF 2
                                       
   This was a followup to the BOF held in Oslo at the 4th IETF. There' we
   had a consensus that we needed another BOF, but not one for a working
   group (yet). The purpose of this BOF was to allow work since then to
   be presented, and to then see if there were grounds for pursuing a
   working group, or else providing input to existing (or other proposed)
   working groups.
   
   The talks are available through links below.
   
   The outcome of the meeting was that we did not need a new BOF, nor did
   we need a working group. However, it was felt that:
   
     The community needs to continue to refine the traffic source models
   and information about traffic matrices (e.g. for the TE wg) so that
   simulations and analytical work are kept realistic and relevant to the
   IETF.
   
     We do need a path for measurement results to be reported to the
   various relvant IETF working groups. IPPM and Diff-serv and others
   need to liase w.r.t this.
   
     It is possible that soon, but not quite yet, an industrial forum for
   deploying class and quality of services may be needed -the IESG might
   consider a directorate perhaps sometime in the next year.
   
     There is a propsoed IRTF research group that can help with the first
   of these tasks to some extent. We expect new WGs to deal with more
   interim matters, such as composing edge-to-edge services from PHBs.
   Contact
jon@cs.ucl.ac.uk

   for information on that activity - if it comes about, look at the IRTF
   web page for details.
   
The Slides are avaialble from
http://www.cs.ucl.ac.uk/research/decides/report2.html

The Agenda was as follows:


Draft agenda for 2nd DECIDeS BOF, 46th IETF 

BOF Deployment Considerations of Implementing Differentiated Services (DeCIDeS)

60 Minutes.  14.15-15.15, Tuesday November 9, Empire, Omi Shoreham, DC

 
Problem Re-Statement and News (see the Document) - 		5 mins
	Jon Crowcroft 
	jon@cs.ucl.ac.uk

Measurement
	Terena/TF-TANT Report Tiziana Ferrari <Tiziana.Ferrari@cnaf.infn.it>
	(see www.cnaf.infn.it/~ferrari/tfng/ds-test.html) 	10 mins

	Snelnet ADSL diff-serv trial measurements
	"Wentink, M.M." <M.M.Wentink@research.kpn.com> 

	How does signaling based traffic conditioning scale?	5 mins
	Istvan.I.Cselenyi@telia.se, Telia Research - 5 mins

Simulation 
	TCP Diff Serve Results					5 mins
	A.L.Narasimha Reddy   "A.L.Narasimha Reddy" <reddy@dogmatix.tamu.edu>


	Traffic Engineering for IP Networks with Real-Time Traffic - 5 mins
	Prehofer Christian <Christian.Prehofer@icn.siemens.de>

	Simple scheme for admision control together with simulation  5 mins
		results for real-time traffic.  
	Lars Westberg, Ericsson Research       
	Zoltan.Turanyi@eth.ericsson.se, farm.westberg@telia.com

Operations

	Provisioning for multicast traffic in a diffserv network 5 mins
	Cheng-Yin Lee <leecy@nortelnetworks.com>


	 Title : "Diff-Serve and Bandwidth Broker Implementation 5 mins
          in JB Project"
	   Speaker : Hiroshi Esaki (WIDE Project)
	   Works : Univ.of Tokyo, UCLA, Osaka Univ., Keio Univ., NAIST,
           Hitachi, Fujitsu, Toshiba,  etc.,

Where does this work go next in the IETF?			5 mins
	J Crowcroft et al 

	1/ OAM WG to define protocols/procedures for diff serve deployment 
		e.g. like mboned, define tools for debugging (dtrace,
		dpathchar, etc)
	2/ TA WG to explore inter-domain exchange of diff serve capability
		e.g. look at bandwidth broker and survey family of
		protocols for brokering  - rsvp, snmp, rap/aaa, etc

 
 --------------------------------------------------->
 
BOF Deployment Considerations of Implementing Differentiated Services (DeCIDeS)


Motivation.

The IETF WG on Differentiated Services (diff-serv) has been meeting now for 
over a year now and has made excellent progress. The framework, architecture, 
DS Field definition, and format for traffic conditoners document, and most
importantly , two PHB definitions have been specified.

So what is the problem?

The Integrated Services WG (int-serv) (with its related groups such as 
ISSLL and RSVP and others), has also defined a set of protocols and 
mechanisms for enhanced services in the Internet. The difference between the 
int-serv and diff-serv approaches is that int-serv (at least the Guaranteed 
and Controlled Load services) is amenable to analysis. Effective bandwidth 
calcualations, and the thesis by Parekh shows how the admission tests for leaky
bucket characterised traffic and delay bound for the path can be
calculated. The difficulty with IS has been in designing
implementations that scale (hence a great deal of work in state
aggregation in RSVP, and in fast generalized port specification
classifiers, as well as  the work on efficient queue data structures
and insert/retrieve algorithms, such as WF2Q and approximations such
as SFQ). Indeed, there are network QoS calculi (by Rene Cruz and also
by Jean-Yves le Boudec).

Meanwhile, with diff-serv, the difference is that there can be no
obvious analytic theory of diff-serv. A path can be constructed out of
a sequence of hops each with a PHB and some associated SLA. However,
the service (and provisioning of service) necessarily depend on the
actual network topology and traffic conditions that prevail.

This is a positive aspect of diff-serv, since it gives providers (and
router vendors) a lot of design freedom in how they deploy actual
services (and associated tarrif structures).

However, to evaluate a diff-serv PHB is now a complex task, and
requires simulation or measurement. To date, only modest simulations
and measurements have been carried out.

[Aside: of course the exact same argument
applies to figuring out call blocking
probabilities in int-serv type networks]


Objectives.


To prepare a document that outlines evaluation framework for PHBs by
suggesting realistic topologies and traffic patterns for measurement
or simulation work. Note that there is a health warning associated
with simualtion - see reference [2] below.

Reading

0/ http://www.cs.ucl.ac.uk/research/decides/
Notes and most slides from previous BOF

1/ http://www.cs.columbia.edu/~hgs/internet/traffic.html

2/ Paxson, V., and Floyd, S., Why We Don't Know How To Simulate The
Internet, Proceedings of the 1997 Winter Simulation Conference,
December 1997. at
http://www.aciri.org/floyd/papers/wsc97.ps




------- End of Forwarded Message


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



From diffserv-admin@ietf.org  Mon Nov 15 11:27:18 1999
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 LAA20069;
	Mon, 15 Nov 1999 11:27:18 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16378;
	Mon, 15 Nov 1999 10:41:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA16348
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 10:41:15 -0500 (EST)
Received: from testfire.god.bel.alcatel.be (gatekeeper2.alcatel.be [195.207.101.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08066
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 10:41:20 -0500 (EST)
Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [138.203.144.168])
	by testfire.god.bel.alcatel.be (8.9.1a/8.9.1) with ESMTP id PAA09731
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 15:47:57 +0100 (MET)
Received: from btmq9s.rc.bel.alcatel.be (btmq9s.rc.bel.alcatel.be [138.203.65.182])
	by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id PAA06986
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 15:43:23 +0100 (MET)
Received: from alcatel.be ([138.203.66.143])
	by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id PAA13024
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 15:43:34 +0100 (MET)
Message-ID: <38301BAB.8051BA38@alcatel.be>
Date: Mon, 15 Nov 1999 15:41:48 +0100
From: Omar Elloumi <Omar.Elloumi@alcatel.be>
Organization: Alcatel Corporate Research Center
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I went through the emails on EF and losses but I'm still
confused. The original question was do we need absolute zero
loss in EF or not?
Some of you responded no (few losses are tolerated),
in that case how can we distinguish packet losses due
to possible attacks from tolerated losses??? do we
need to have a threshold above it we trigger an alarm
to check a possible attack?

My intention is NOT to trigger a new discussion but just
to have in few lines a definitive (formal if possible) answer to this.

kind regards.

--
____________________________________________________________
Omar Elloumi

Alcatel Research - Network Architecture - Traffic Technology

Francis Wellesplein 1, 2018 Antwerp, Belgium

Phone: + 32 3 240 78 33
Fax:   + 32 3 240 99 32
http://www.alcatel.com/crc/
____________________________________________________________

Opinions expressed are those of the sender and do not reflect Alcatel
policy or agreement



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



From diffserv-admin@ietf.org  Mon Nov 15 12:07:01 1999
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 MAA08260;
	Mon, 15 Nov 1999 12:07:01 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18064;
	Mon, 15 Nov 1999 11:21:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18027
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 11:21:48 -0500 (EST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18588
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 11:22:00 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 15 11:21:51 EST 1999
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.255.16.129])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA11925;
	Mon, 15 Nov 1999 11:21:47 -0500 (EST)
Message-ID: <3830335A.94DB8872@dnrc.bell-labs.com>
Date: Mon, 15 Nov 1999 08:22:50 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Omar Elloumi <Omar.Elloumi@alcatel.be>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
References: <38301BAB.8051BA38@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

If the question is solely "do we need absolute zero
loss in EF or not?" then an answer could go something like
this:

	- EF is intended for virtual leased line ('a wire
	  between two points') services
	- Wires dont drop packets, congested interfaces at
	  the ends of the wires drop packets (barring cosmic
	  radiation corrupting bits in transit along a wire)
	- Ergo EF's target packet drop rate ought to be
	  that of the equivalent 'wire' without cosmic
	  radiation -> i.e. zero.

(I didn't say it was a good line of argument, but it works for
me :)

cheers,
gja

Omar Elloumi wrote:
> 
> Hello,
> 
> I went through the emails on EF and losses but I'm still
> confused. The original question was do we need absolute zero
> loss in EF or not?
> Some of you responded no (few losses are tolerated),
> in that case how can we distinguish packet losses due
> to possible attacks from tolerated losses??? do we
> need to have a threshold above it we trigger an alarm
> to check a possible attack?
> 
> My intention is NOT to trigger a new discussion but just
> to have in few lines a definitive (formal if possible) answer to this.
> 
> kind regards.

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



From diffserv-admin@ietf.org  Mon Nov 15 12:28:36 1999
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 MAA18567;
	Mon, 15 Nov 1999 12:28:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA19587;
	Mon, 15 Nov 1999 11:58:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA19558
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 11:58:43 -0500 (EST)
Received: from mailgw.ust.hk (mailgw.ust.hk [143.89.14.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04530
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 11:58:48 -0500 (EST)
Received: from uxmail.ust.hk (root@uxmail.ust.hk [143.89.14.30])
	by mailgw.ust.hk (8.9.3/8.9.3) with ESMTP id AAA23501;
	Tue, 16 Nov 1999 00:53:33 +0800 (HKT)
Received: from ust.hk (dmy239.resnet.ust.hk [143.89.67.39])
	by uxmail.ust.hk (8.9.3/8.9.3) with ESMTP id AAA23765;
	Tue, 16 Nov 1999 00:55:51 +0800 (HKT)
Message-ID: <3830233A.44D1449C@ust.hk>
Date: Mon, 15 Nov 1999 23:14:02 +0800
From: Anurag <anurag@ust.hk>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Omar Elloumi <Omar.Elloumi@alcatel.be>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
References: <38301BAB.8051BA38@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi

As I understand, according to the present RFC on EF PHB, there is no way
to distinguish between packet losses due to buffer over flow or attack.
Both shall trigger alarm. 

regards
Anurag

Omar Elloumi wrote:
> 
> Hello,
> 
> I went through the emails on EF and losses but I'm still
> confused. The original question was do we need absolute zero
> loss in EF or not?
> Some of you responded no (few losses are tolerated),
> in that case how can we distinguish packet losses due
> to possible attacks from tolerated losses??? do we
> need to have a threshold above it we trigger an alarm
> to check a possible attack?
> 
> My intention is NOT to trigger a new discussion but just
> to have in few lines a definitive (formal if possible) answer to this.
> 
> kind regards.
> 
> --
> ____________________________________________________________
> Omar Elloumi
> 
> Alcatel Research - Network Architecture - Traffic Technology
> 
> Francis Wellesplein 1, 2018 Antwerp, Belgium
> 
> Phone: + 32 3 240 78 33
> Fax:   + 32 3 240 99 32
> http://www.alcatel.com/crc/
> ____________________________________________________________
> 
> Opinions expressed are those of the sender and do not reflect Alcatel
> policy or agreement
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Mon Nov 15 12:33:47 1999
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 MAA21188;
	Mon, 15 Nov 1999 12:33:47 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18834;
	Mon, 15 Nov 1999 11:43:20 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA18801
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 11:43:15 -0500 (EST)
Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27531
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 11:43:25 -0500 (EST)
Received: from zinin (amtsun.amt.ru [212.111.64.19]) by amtsun.amt.ru (8.8.8/8.7.3.1) with SMTP id TAA01728; Mon, 15 Nov 1999 19:42:07 +0300 (MSK)
Message-Id: <2.2.32.19991115163858.00c4f680@amtsun>
X-Sender: zinin@amtsun
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 15 Nov 1999 19:38:58 +0300
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>, diffserv@ietf.org
From: Alex Zinin <zinin@amt.ru>
Subject: Re: [Diffserv] MPLS vs Diff-Serv
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Haci,

In a word---yes, they are independent technologies.
This is to say that MPLS does not need DiffServ and
DiffServ doesn't need MPLS. However, we do have
several proposals on combining MPLS with DiffServ.

The fact that LSPs can be established by RSVP in
MPLS doesn't make MPLS an IntServ-aware technology
(RSVP is IntServ- rather than DiffServ-related)

You may want to explore the homepages and documents
of the corresponding WGs for more info.

Alex.

At 00:31 15.11.99 -0500, Haci A. Mantar wrote:
>
>Hi
>
>Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
>uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
>For example: MPLS uses extended RSVP for reservation, Is there any this
>kind of related or depended functions between Diff-Serv and MPLS.
>
>Thanks
>
>
>HACI ALI MANTAR
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>
>
------------------------------------------------------------------
Alex D. Zinin, Consultant
CCSI #98966
CCIE #4015


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



From diffserv-admin@ietf.org  Mon Nov 15 13:44:21 1999
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 NAA26062;
	Mon, 15 Nov 1999 13:44:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21457;
	Mon, 15 Nov 1999 12:58:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA21427
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 12:57:57 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04524
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 12:58:10 -0500 (EST)
Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.20591-0@bells.cs.ucl.ac.uk>; Mon, 15 Nov 1999 17:57:44 +0000
X-Mailer: exmh version 2.0.2
To: Grenville Armitage <gja@dnrc.bell-labs.com>
cc: diffserv@ietf.org, Omar.Elloumi@alcatel.be, P.Gevros@cs.ucl.ac.uk
Subject: Re: [Diffserv] EF RFC and loss
In-reply-to: Your message of "Mon, 15 Nov 1999 08:22:50 PST." <3830335A.94DB8872@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Nov 1999 17:57:43 +0000
Message-ID: <11317.942688663@cs.ucl.ac.uk>
From: Panos GEVROS <P.Gevros@cs.ucl.ac.uk>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org



Grenville Armitage writes:

 |
 |	- EF is intended for virtual leased line ('a wire
 |	  between two points') services
 |	- Wires dont drop packets, congested interfaces at
 |	  the ends of the wires drop packets (barring cosmic
 |	  radiation corrupting bits in transit along a wire)

may i add that
Wires also don't buffer packets

from previous discussion in this thread my understanding was that :
	-EF is about *no* loss and *no* queueing delay.
	-packets that arrive on different input interfaces and need to be forwarded 
on the same output interface EF queue may create instantaneous backlog and 
non-negligible queueing delays.

is this correct ? 
(if yes doesn't it break the service)
i hope there is a yes/no answer, if not pointers to relevant work would be 
appreciated.

Thanks in advance,
Panos


 |	- Ergo EF's target packet drop rate ought to be
 |	  that of the equivalent 'wire' without cosmic
 |	  radiation -> i.e. zero.
 |




 |Omar Elloumi wrote:
 |> 
 |> Hello,
 |> 
 |> I went through the emails on EF and losses but I'm still
 |> confused. The original question was do we need absolute zero
 |> loss in EF or not?
 |> Some of you responded no (few losses are tolerated),
 |> in that case how can we distinguish packet losses due
 |> to possible attacks from tolerated losses??? do we
 |> need to have a threshold above it we trigger an alarm
 |> to check a possible attack?
 |> 
 |> My intention is NOT to trigger a new discussion but just
 |> to have in few lines a definitive (formal if possible) answer to this.
 |> 
 |> kind regards.
 |
 |_______________________________________________
 |diffserv mailing list
 |diffserv@ietf.org
 |http://www.ietf.org/mailman/listinfo/diffserv
 |Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
 |





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



From diffserv-admin@ietf.org  Mon Nov 15 14:05:20 1999
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 OAA07444;
	Mon, 15 Nov 1999 14:05:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22190;
	Mon, 15 Nov 1999 13:21:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22158
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 13:21:02 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15836
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 13:21:15 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA21459
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 10:20:40 -0800 (PST)
Message-ID: <38304F48.88BCFB6A@cisco.com>
Date: Mon, 15 Nov 1999 10:22:00 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
References: <38301BAB.8051BA38@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Omar Elloumi wrote:
> 
> Hello,
> 
> I went through the emails on EF and losses but I'm still
> confused. The original question was do we need absolute zero
> loss in EF or not?
> Some of you responded no (few losses are tolerated),
> in that case how can we distinguish packet losses due
> to possible attacks from tolerated losses??? do we
> need to have a threshold above it we trigger an alarm
> to check a possible attack?
> 
> My intention is NOT to trigger a new discussion but just
> to have in few lines a definitive (formal if possible) answer to this.
> 

Perhaps the correct way to think of it is that the PRESUMPTION
has to be no loss. The construction of a VLL behavior
aggregate using the EF PHB is to eliminate congestive loss
for those packets. The work of preparing the traffic properly
is pushed to the edges where it can be shaped or policed or
whatever is appropriate for the type of traffic using it. That's
information that might be available at the edge.

	Kathie

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



From diffserv-admin@ietf.org  Mon Nov 15 14:06:08 1999
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 OAA07888;
	Mon, 15 Nov 1999 14:06:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22654;
	Mon, 15 Nov 1999 13:31:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22624
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 13:31:42 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20607
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 13:31:55 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id KAA24842
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 10:39:59 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 10:33:41 -0800
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <WMKC8AW5>; Mon, 15 Nov 1999 10:28:05 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A606F4210E@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
Cc: diffserv@external.cisco.com
Subject: RE: [Diffserv] MPLS vs Diff-Serv
Date: Mon, 15 Nov 1999 10:27:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
X-SMTP-HELO: doggate.exchange.microsoft.com
X-SMTP-MAIL-FROM: yoramb@Exchange.Microsoft.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: doggate.exchange.microsoft.com [131.107.88.55]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

The two are both related and yet - independent. For example - diffserv
assumes a network which can offer certain services to its customers. In
order to offer these seervices, the diffserv network must be provisioned
(either dynamically or statically). MPLS can be used to do the traffic
engineering necessary to provision a diffserv network. MPLS might use a
certain form of RSVP for this. Completely independently, RSVP might be used
from hosts ot gain admision to the diffserv services. 

There are other examples of how diffserv, MPLS and RSVP technologies work
together. I think that none of them *replace* any of the others. They just
have different roles in the grand scheme.
 
Yoram

> -----Original Message-----
> From: Haci A. Mantar [mailto:hamantar@mailbox.syr.edu]
> Sent: Sunday, November 14, 1999 8:57 PM
> To: Haci A. Mantar
> Cc: diffserv@external.cisco.com
> Subject: [Diffserv] MPLS vs Diff-Serv
> 
> 
> Hi
> 
> Are MPLS and Diff-Serv totally independent technologies? I 
> mean does MPLS
> uses Diff-Serv for some requirment, or Diff-Serv uses MPLS 
> for anything.
> For example: MPLS uses extended RSVP for reservation, Is 
> there any this
> kind of related or depended functions between Diff-Serv and MPLS.
> 
> Thanks
> 
> 
> HACI ALI MANTAR
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


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



From diffserv-admin@ietf.org  Mon Nov 15 14:27:52 1999
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 OAA19270;
	Mon, 15 Nov 1999 14:27:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22776;
	Mon, 15 Nov 1999 13:34:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA22745
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 13:34:13 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21631
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 13:34:25 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA19857
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 10:34:23 -0800 (PST)
Received: from [199.191.48.146] by slb-hub-01.boeing.com for diffserv@ietf.org; Mon, 15 Nov 1999 10:34:17 -0800
Received: by engr03.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Mon, 15 Nov 1999 13:33:15 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Panos GEVROS" <P.Gevros@cs.ucl.ac.uk>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] EF RFC and loss
Date: Mon, 15 Nov 1999 13:34:10 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMGEHGCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <11317.942688663@cs.ucl.ac.uk>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Panos GEVROS wrote:

> may i add that
> Wires also don't buffer packets

Well, even telephone systems are digital now, so even they suffer
from _some_ amount of packet delay. EF is supposed to emulate this
kind of service, as well as perhaps less stringent requirements.

> from previous discussion in this thread my understanding
> was that :
> 	-EF is about *no* loss and *no* queueing delay.
> 	-packets that arrive on different input interfaces
> and need to be forwarded
> on the same output interface EF queue may create
> instantaneous backlog and
> non-negligible queueing delays.

Uh, well, why not let's pick a packet size of, say, 53 bytes?
That'll keep delay low enough. :)

Everything I've read so far about interactive applications used by
human beings is that 150 msec is considered acceptable. This does
not necessarily apply to control systems, which may have much more
stringent requirements.

So EF if used for interactive multimedia applications does not need
to be _no_ delay. If used in a control system setting, delays in the
1 to 10 msec range or so are certainly within the realm of
possibility. But this would typically be over short distances/few
hops.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Mon Nov 15 14:49:29 1999
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 OAA01004;
	Mon, 15 Nov 1999 14:49:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA23553;
	Mon, 15 Nov 1999 14:02:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA23522
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 14:02:39 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06117
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 14:02:51 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id LAA07719
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 11:02:29 -0800 (PST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 10:57:44 -0800
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Nov 15 13:55:04 EST 1999
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA18862;
	Mon, 15 Nov 1999 13:55:01 -0500 (EST)
Message-ID: <38305778.8B2A8273@dnrc.bell-labs.com>
Date: Mon, 15 Nov 1999 10:56:56 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] MPLS vs Diff-Serv
References: <Pine.SOL.4.10.9911142350220.11899-100000@rodan.syr.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: dirty.research.bell-labs.com
X-SMTP-MAIL-FROM: gja@dnrc.bell-labs.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: dirty.research.bell-labs.com [204.178.16.6]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



"Haci A. Mantar" wrote:
> 
> Hi
> 
> Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
> uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
> For example: MPLS uses extended RSVP for reservation, Is there any this
> kind of related or depended functions between Diff-Serv and MPLS.

Think of diff-serv as providing more temporal control over
packet forwarding than 'best effort', and MPLS as providing
more topological control over packet forwarding than 'shortest
path forwarding'. You gain benefits from them independently or
together.

cheers,
gja


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



From diffserv-admin@ietf.org  Mon Nov 15 16:11:38 1999
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 QAA12286
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 16:11:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA25337;
	Mon, 15 Nov 1999 15:08:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA25300
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 15:08:25 -0500 (EST)
Received: from net.infocom.uniroma1.it (IDENT:root@net.infocom.uniroma1.it [151.100.37.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11213
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 15:08:36 -0500 (EST)
Received: from coritel.it (pc01.infocom.uniroma1.it [151.100.37.13])
	by net.infocom.uniroma1.it (8.8.7/8.8.7) with ESMTP id VAA20583;
	Mon, 15 Nov 1999 21:04:17 +0100
Message-ID: <38306957.4C68B232@coritel.it>
Date: Mon, 15 Nov 1999 21:13:11 +0100
From: Stefano Salsano <salsano@coritel.it>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Omar Elloumi <Omar.Elloumi@alcatel.be>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
References: <38301BAB.8051BA38@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Dear Omar,

here is the "formal" answer from my side:

1) EF PHB in itself, as described in RFC 2598 does not prescribe 
   anything related to loss, but simply that a router MUST guarantee 
   a configurable aggregate rate of outgoing EF packets.

2) The VLL or premium service which is described in RFC 2598 prescribes
   that you configure your network (with traffic conditioners at the
edge)
   in order to have NO LOSS. In a network that provides such a VLL
service
   a loss event can be caused only by: misconfigurations, phisical 
   transmission errors, security attacks...

After these formal statements, let me add my comments:

- the buffer requirements to provide a VLL service with DETERMINISTIC
  NO LOSS in a medium/large scale network are very high, or conversely
the
  utilization of EF traffic must be kept very low
- nothing prevents an ISP to provide different services based
  on the EF PHB where the NO LOSS constraint is relaxed... but none
  of this service is described in any RFC... I would call this service
  "statistical VLL"... I think this kind of services can be needed for
  example for Voice over IP if you want to have a reasonable
utilization...

Regards,
Stefano

Omar Elloumi wrote:
> 
> Hello,
> 
> I went through the emails on EF and losses but I'm still
> confused. The original question was do we need absolute zero
> loss in EF or not?
> Some of you responded no (few losses are tolerated),
> in that case how can we distinguish packet losses due
> to possible attacks from tolerated losses??? do we
> need to have a threshold above it we trigger an alarm
> to check a possible attack?
> 
> My intention is NOT to trigger a new discussion but just
> to have in few lines a definitive (formal if possible) answer to this.
> 
> kind regards.
> 
> --
> ____________________________________________________________
> Omar Elloumi
> 
> Alcatel Research - Network Architecture - Traffic Technology
> 
> Francis Wellesplein 1, 2018 Antwerp, Belgium
> 
> Phone: + 32 3 240 78 33
> Fax:   + 32 3 240 99 32
> http://www.alcatel.com/crc/
> ____________________________________________________________
> 
> Opinions expressed are those of the sender and do not reflect Alcatel
> policy or agreement
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Mon Nov 15 16:33:08 1999
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22919
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 16:33:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA26768;
	Mon, 15 Nov 1999 16:00:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA26741
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 16:00:43 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06855
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 16:00:54 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id MAA15481
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 12:58:43 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 12:57:02 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA54114; Mon, 15 Nov 1999 20:56:29 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA16242; Mon, 15 Nov 1999 20:56:28 GMT
Message-ID: <383072CF.20DBB7C5@hursley.ibm.com>
Date: Mon, 15 Nov 1999 14:53:35 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Bert Wijnen <WIJNEN@vnet.ibm.com>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] discussion of terminology for policy based (network) 
 management
References: <199911142042.PAA103602@southrelay03.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

fyi Dan Grossman, author of diffserv's own terminology draft
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-01.txt
is the diffserv person on the design team mentioned by Bert.

  Brian

Bert Wijnen wrote:
> 
> At the POLTERM BOF in Wahsinton D.C. we decided to continue the
> discussion of terminology for policy based network management.
> 
> We have opened a separate mailing list for this discussion.
> This mailing list is at:
> 
>   polterm@ops.ietf.org
> 
> To subscribe do one of the following:
> 
>   - send email to polterm-request@ops.ietf.org
>     in the body put a single line with text:  subscribe
> 
>   - send email to majordomo@ops.ietf.org
>     in the body put a single line with:  subscribe polterm
> 
> Please do not send postings about terminology to the mumble list anymore.
> 
> There is an initial document that discusses some of this, but it
> is far from complete. But for those who have not yet seen it:
> 
>    http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt
> 
> Several people at the BOF have made comments already, based on the
> slides that Fran Reichmeijer presented. I would like Fran to make the
> slides available for FTP or so. COuld the others post their
> statements/points (in a concise form please), so that everybody can
> take part in the full discussion.
> 
> We would like the Design Team who did the original work to continue
> to collect the terminology input and write a document that gets
> closer and closer to a commponly agreed set of terms.
> Since this is a cross WG effort, I would like the Design Team to
> report to the collective set of WG chairs of those WGs, and as
> such, I need to discuss that first with the WG chairs before
> I can give more details.
> 
> Thanks,
> Bert
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Mon Nov 15 16:34:42 1999
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 QAA23594
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 16:34:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA26520;
	Mon, 15 Nov 1999 15:54:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA26491
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 15:54:50 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03937
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 15:55:01 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id MAA22354
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 12:55:27 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 12:51:13 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA102834; Mon, 15 Nov 1999 20:50:39 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA19898; Mon, 15 Nov 1999 20:50:37 GMT
Message-ID: <38307174.BDFAE123@hursley.ibm.com>
Date: Mon, 15 Nov 1999 14:47:48 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] MPLS vs Diff-Serv
References: <Pine.SOL.4.10.9911142350220.11899-100000@rodan.syr.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

The MPLS working group is looking at a mapping from diffserv classes
to MPLS; it's best to think of them as two separate layers.

  Brian

"Haci A. Mantar" wrote:
> 
> Hi
> 
> Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
> uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
> For example: MPLS uses extended RSVP for reservation, Is there any this
> kind of related or depended functions between Diff-Serv and MPLS.
> 
> Thanks
> 
> HACI ALI MANTAR
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Mon Nov 15 17:13:39 1999
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 RAA09892
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 17:13:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27174;
	Mon, 15 Nov 1999 16:15:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27140
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 16:15:00 -0500 (EST)
Received: from daystrom.abatis-sys.com ([216.13.164.98])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14170
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 16:15:12 -0500 (EST)
Received: by daystrom.abatissys.com with Internet Mail Service (5.5.2448.0)
	id <W94AS6A6>; Mon, 15 Nov 1999 13:07:41 -0800
Message-ID: <811670B03A7DD211A2730008C709C20959F362@daystrom.abatissys.com>
From: "Li, Renwei" <rli@abatis-sys.com>
To: "'Albert Manfredi'" <albert.e.manfredi@boeing.com>,
        Panos GEVROS
	 <P.Gevros@cs.ucl.ac.uk>
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] EF RFC and loss
Date: Mon, 15 Nov 1999 13:07:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

I guess you have confused Panos' "no queuing delay"
with delay. 

When a packet is sent, the delay is 
the sum of a few finer delays: algorithmic delay (codecing),
architectural delay, transmission delay, queuing
delay, etc. 

I tend to agree with Panos to that EF is supposed to have
"zero queuing delay". But I am not very sure if the RFC
really means this. Zero queuing delay does not mean that
there will be no delay between two ends. Even the real 
leased lines still have a sort delay such as transmission 
delay, multiplexing delay, etc. The VLL just emulates such 
lines from the user's perspective. 

Comments?

Renwei


-----Original Message-----
From: Albert Manfredi [mailto:albert.e.manfredi@boeing.com]
Sent: Monday, November 15, 1999 10:34 AM
To: Panos GEVROS
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] EF RFC and loss


Panos GEVROS wrote:

> may i add that
> Wires also don't buffer packets

Well, even telephone systems are digital now, so even they suffer
from _some_ amount of packet delay. EF is supposed to emulate this
kind of service, as well as perhaps less stringent requirements.

> from previous discussion in this thread my understanding
> was that :
> 	-EF is about *no* loss and *no* queueing delay.
> 	-packets that arrive on different input interfaces
> and need to be forwarded
> on the same output interface EF queue may create
> instantaneous backlog and
> non-negligible queueing delays.

Uh, well, why not let's pick a packet size of, say, 53 bytes?
That'll keep delay low enough. :)

Everything I've read so far about interactive applications used by
human beings is that 150 msec is considered acceptable. This does
not necessarily apply to control systems, which may have much more
stringent requirements.

So EF if used for interactive multimedia applications does not need
to be _no_ delay. If used in a control system setting, delays in the
1 to 10 msec range or so are certainly within the realm of
possibility. But this would typically be over short distances/few
hops.

Bert
manfredi@arl.bna.boeing.com


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

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



From diffserv-admin@ietf.org  Mon Nov 15 17:13:52 1999
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 RAA09991
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 17:13:51 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27339;
	Mon, 15 Nov 1999 16:18:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA27316
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 16:18:09 -0500 (EST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15881
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 16:18:19 -0500 (EST)
Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.29976-0@bells.cs.ucl.ac.uk>; Mon, 15 Nov 1999 21:15:39 +0000
X-Mailer: exmh version 2.0.2
To: diffserv@ietf.org
cc: P.Gevros@cs.ucl.ac.uk
Subject: Re: [Diffserv] EF RFC and loss
In-reply-to: Your message of "Mon, 15 Nov 1999 15:06:14 EST." <199911152006.PAA32626@phobos.solidum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Nov 1999 21:15:38 +0000
Message-ID: <12932.942700538@cs.ucl.ac.uk>
From: Panos GEVROS <P.Gevros@cs.ucl.ac.uk>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

      Panos> may i add that
 |    Panos> Wires also don't buffer packets
 |
 |  wires with large bandwidth*delay values may buffer numerous packets.
 |

after i sent it i thought it might be misunderstood

true many packets may "flow" in a large bandwidth delay product link.

imo though, the *transmitter* and the *link* seeing as queueing systems are 
not exactly the same, i have to dig more evidence to be more convincing (so if 
anyone could help) ...
once a packet makes it on the wire, how long it will take it to leave the wire 
does *not* depend on how many packets are "on the wire" in front of it, 
nothing will make it travel faster/slower, it is physics laws .. and in this 
sense i insist that:
wires do not buffer 

Cheers
Panos


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



From diffserv-admin@ietf.org  Mon Nov 15 17:17:37 1999
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 RAA11354
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 17:17:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28145;
	Mon, 15 Nov 1999 16:49:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA28115
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 16:49:22 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00541
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 16:49:31 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA19890
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 13:49:31 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Mon, 15 Nov 1999 13:49:20 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Mon, 15 Nov 1999 16:48:25 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Li, Renwei" <rli@abatis-sys.com>
Cc: <diffserv@ietf.org>
Subject: RE: [Diffserv] EF RFC and loss
Date: Mon, 15 Nov 1999 16:49:17 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMOEHJCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <811670B03A7DD211A2730008C709C20959F362@daystrom.abatissys.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Li, Renwei wrote:

> I guess you have confused Panos' "no queuing delay"
> with delay.
>
> When a packet is sent, the delay is
> the sum of a few finer delays: algorithmic delay (codecing),
> architectural delay, transmission delay, queuing
> delay, etc.
>
> I tend to agree with Panos to that EF is supposed to have
> "zero queuing delay". But I am not very sure if the RFC
> really means this. Zero queuing delay does not mean that
> there will be no delay between two ends. Even the real
> leased lines still have a sort delay such as transmission
> delay, multiplexing delay, etc. The VLL just emulates such
> lines from the user's perspective.

"Leased lines" these days are also services run over Frame Relay or
ATM. Both of which will incorporate buffering and queuing delays, as
well as propagation delay.

Zero queueing delay means that no packet shall be held back by
another packet at any of the hops. But if flows merge anywhere along
the path, you will have a statistical probability, even if the links
are over-provisioned, that queueing will occur. I don't see too much
you can do about this other than reserve paths, and then synchronize
your admission control such that merging packets will not be
admitted into the diffserv net simultaneously.

Does anyone have any other real-world options?

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Mon Nov 15 18:21:16 1999
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 SAA08175
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 18:21:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA29800;
	Mon, 15 Nov 1999 17:44:32 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA29771
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 17:44:28 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21777
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 17:44:39 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA09679;
	Mon, 15 Nov 1999 14:43:25 -0800 (PST)
Message-ID: <38308CDD.5CD8D8A7@cisco.com>
Date: Mon, 15 Nov 1999 14:44:45 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Li, Renwei" <rli@abatis-sys.com>
CC: "'Albert Manfredi'" <albert.e.manfredi@boeing.com>,
        Panos GEVROS <P.Gevros@cs.ucl.ac.uk>, diffserv@ietf.org
Subject: Re: [Diffserv] EF RFC and loss
References: <811670B03A7DD211A2730008C709C20959F362@daystrom.abatissys.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



"Li, Renwei" wrote:
> 
...
> I tend to agree with Panos to that EF is supposed to have
> "zero queuing delay". But I am not very sure if the RFC
> really means this. Zero queuing delay does not mean that
> there will be no delay between two ends. Even the real
> leased lines still have a sort delay such as transmission
> delay, multiplexing delay, etc. The VLL just emulates such
> lines from the user's perspective.
> 

In fact 2598 does not say "zero queueing delay". There should
be no average or standing queue in any EF buffer (falls out from
the definition). Your last statement is the accurate one, though
the "user's perspective" might be arguable. The thing to look
at is how do the transitory queueing delays experienced show up
to the endpoints which are expecting a VLL of some rate which
should be considerably smaller than the bandwidths of the
links the packets traverse. If you expect a VLL of 64 kbps and
get delayed behind 10 packets at 100 Mbps someplace in your
path, how does that appear at the endpoints? If this doesn't
work for you, do something else.

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



From diffserv-admin@ietf.org  Mon Nov 15 19:10:11 1999
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 TAA02868
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 19:10:11 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01060;
	Mon, 15 Nov 1999 18:39:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01034
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 18:39:27 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17316
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 18:39:40 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id PAA11239
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 15:47:48 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by proxy2.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 15:41:36 -0800
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23])
	by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA85332
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 18:33:50 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id SAA137770
	for <diffserv%external.cisco.com@relay.us.ibm.com>; Mon, 15 Nov 1999 18:34:31 -0500
Message-Id: <199911152334.SAA137770@northrelay03.pok.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 4266 ; Mon, 15 Nov 1999 16:33:28 MST
Date: Tue, 16 Nov 99 00:34:42 CET
From: "Bert Wijnen" <WIJNEN@vnet.ibm.com>
To: diffserv@external.cisco.com
X-SMTP-HELO: e4.ny.us.ibm.com
X-SMTP-MAIL-FROM: wijnen@vnet.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: e4.ny.us.ibm.com [32.97.182.104]
Subject: [Diffserv] IESG decision on Configuration Management BOF
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

The document presented by the Design Team, the presentations and
discussion at the BOF and also the discussion in the hallways has
made it clear that we need to work some more on collecting and
documenting all the requirements for managing device configuration.

There for, the Design Team that presented the initial

   http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt

will continue to collect input from the community. This input can be
posted to and discussed on the mailing list:

   confmgt@ops.ietf.org

This Design Team is charged to produce an Informational RFC that lists
and discusses the requirements for Configuration Management.  The
sections of the internet-draft that are evaluations of the
different configuration management proposals will be removed so
that the resulting document just addresses the requirements.

At the same time, we do not want to stall the work that was already
started in the RAP WG. So we encourage that WG to continue to work
on COPS for Provisioning. This work is already part of the RAP WG
charter.

The work on a PIB for diffserve will be added to the diffserv
working group charter.

The SNMP-crowd (if I may call them so) has provided enough arguments
to make us believe that Configuration Management can be done with SNMP.
We have there for also decided to charter a WG for specifying how
we can do "Configuration Management with SNMP".
The exact charter for the WG needs to be worked out in the coming weeks.
We intend to quickly start-up a Design Team that will write some initial
internet drafts that can be used as a starter set of documents
for the WG when its formation is complete.

Thanks for all your input on this matter.

Bert Wijnen
IETF co-AD for Operations and Management


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



From diffserv-admin@ietf.org  Mon Nov 15 19:41:13 1999
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 TAA17376
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 19:41:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01331;
	Mon, 15 Nov 1999 18:58:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01300
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 18:58:35 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26564
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 18:58:12 -0500 (EST)
Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA12407
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 15:58:38 -0800 (PST)
Received: from jlawrenc-pc.cisco.com (melb-dhcp-189.cisco.com [144.254.136.189]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA13257; Mon, 15 Nov 1999 15:57:09 -0800 (PST)
Message-Id: <4.2.0.58.19991116104624.009ee5b0@farley.cisco.com>
X-Sender: jlawrenc@farley.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 16 Nov 1999 10:56:56 +1100
To: "Haci A. Mantar" <hamantar@mailbox.syr.edu>
From: Jeremy Lawrence <jlawrenc@cisco.com>
Subject: Re: [Diffserv] MPLS vs Diff-Serv
Cc: diffserv@external.cisco.com
In-Reply-To: <Pine.SOL.4.10.9911142350220.11899-100000@rodan.syr.edu>
References: <382C537A.E30F20C8@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Haci,

>Are MPLS and Diff-Serv totally independent technologies? I mean does MPLS
>uses Diff-Serv for some requirment, or Diff-Serv uses MPLS for anything.
>For example: MPLS uses extended RSVP for reservation, Is there any this
>kind of related or depended functions between Diff-Serv and MPLS.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-02.txt
will probably answer your questions.

Jeremy Lawrence

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



From diffserv-admin@ietf.org  Mon Nov 15 21:04:16 1999
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 VAA26112
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 21:04:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA06183;
	Mon, 15 Nov 1999 20:25:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id UAA06153
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 20:25:50 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07987
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 20:26:05 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id RAA25179
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 17:34:12 -0800 (PST)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 17:22:15 -0800
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id RAA23439
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 17:21:54 -0800 (PST)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <WX21MVG7>; Mon, 15 Nov 1999 17:21:54 -0800
Message-ID: <336ECDAFDF7DD311B9E30090277AEE41351417@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: diffserv@external.cisco.com
Date: Mon, 15 Nov 1999 17:20:17 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-SMTP-HELO: procyon.pmc-sierra.bc.ca
X-SMTP-MAIL-FROM: Shahram_Davari@pmc-sierra.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: procyon.pmc-sierra.bc.ca [134.87.115.1]
Subject: [Diffserv] Class Selector and BE
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi,

Since the standard DSCP=000000 is assigned to both Class Selector 0 and BE
does that mean that CS0 and BE are equivalent?

Shahram


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



From diffserv-admin@ietf.org  Mon Nov 15 23:15:15 1999
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 XAA28042
	for <diffserv-archive@ietf.org>; Mon, 15 Nov 1999 23:15:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA08988;
	Mon, 15 Nov 1999 22:10:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA08953
	for <diffserv@optimus.ietf.org>; Mon, 15 Nov 1999 22:10:01 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25787
	for <diffserv@ietf.org>; Mon, 15 Nov 1999 22:10:12 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id TAA06126
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 19:10:37 -0800 (PST)
Received: from pilot013.cl.msu.edu (pilot013.cl.msu.edu [35.9.5.113]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 15 Nov 1999 19:06:22 -0800
Received: from pilot.msu.edu (sydney.cse.msu.edu [35.9.24.111])
	by pilot013.cl.msu.edu (8.9.1a/8.9.1) with ESMTP id WAA64108
	for <diffserv@external.cisco.com>; Mon, 15 Nov 1999 22:05:19 -0500
Message-ID: <3830C9EF.224FA84B@pilot.msu.edu>
Date: Mon, 15 Nov 1999 22:05:19 -0500
From: Baijian Yang <yangbaij@pilot.msu.edu>
Organization: CSE,MSU
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: zh, en
MIME-Version: 1.0
To: diffserv@external.cisco.com
References: <199911152334.SAA137770@northrelay03.pok.ibm.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: pilot013.cl.msu.edu
X-SMTP-MAIL-FROM: yangbaij@pilot.msu.edu
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: pilot013.cl.msu.edu [35.9.5.113]
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Question about SLA
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I went through RFC-2475, and found that the concept of
SLA is rather vague. And also, I was very curious about
the implementation of these SLAs. Are they negosiated 
on per-flow basis, or periotically updated between the
upstream and downstream DS domain. Can anyone give me
some idea about it? thx!

Regards,
Baijian YANG


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



From diffserv-admin@ietf.org  Tue Nov 16 11:02:37 1999
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 LAA09951
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 11:02:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA02908;
	Tue, 16 Nov 1999 09:50:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA02877
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 09:50:55 -0500 (EST)
Received: from hns3.hns.com (hns3.hns.com [208.236.67.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06650
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 09:51:08 -0500 (EST)
From: pfoy@hns.com
Received: from hnssysb.md.hns.com (hnssysb.hns.com [139.85.212.101])
	by hns3.hns.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA19522;
	Tue, 16 Nov 1999 09:51:29 -0500 (EST)
Received: from ngw2.hns.com (ngw2.hns.com [139.85.177.38])
	by hnssysb.md.hns.com (8.9.0/8.8.7) with SMTP id JAA07251;
	Tue, 16 Nov 1999 09:50:29 -0500 (EST)
Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525682B.00517D38 ; Tue, 16 Nov 1999 09:50:04 -0500
X-Lotus-FromDomain: HNS
To: rsvp@ISI.EDU, diffserv@ietf.org
Message-ID: <8525682B.00517BED.00@ngw2.hns.com>
Date: Tue, 16 Nov 1999 09:50:13 -0500
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Diffserv] RSVP vs DiffServ
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org



I was browsing the iBand3 website (http://www.stardust.com/iband3/) and
discovered a section in the 'iBAND3 Network Showcase Tour Guide' that outlined
applications using QoS and Policy protocols.  Of the six applications that iBand
profiled, 5 applications are using DiffServ and 1 is using RSVP.
This was a bit surprising since I thought that RSVP was further along than
DiffServ (wrt standardization and deployment) and RSVP was actually gaining
momentum in the industry.  I understand the benefits of DiffServ over RSVP, but
I thought that RSVP's end-to-end guarantee outweighed the scalability and
overhead issues.

In a few years when these QoS methods become more mature, it makes sense that
certain applications would favor one over the other.  But in the early stages,
are the benefits clear enough that applications are focusing on DiffServ rather
than RSVP?

Any comments about this issue are appreciated.

Thanks.

Patrick Foy



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



From diffserv-admin@ietf.org  Tue Nov 16 11:25:58 1999
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 LAA21063
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 11:25:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04222;
	Tue, 16 Nov 1999 10:40:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04189
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 10:40:14 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29224
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 10:40:29 -0500 (EST)
From: tomi.engdahl@nokia.com
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id HAA08491
	for <diffserv@external.cisco.com>; Tue, 16 Nov 1999 07:48:40 -0800 (PST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by proxy2.cisco.com with SMTP (MailShield v1.5); Tue, 16 Nov 1999 07:42:23 -0800
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60])
	by mgw-x1.nokia.com (8.9.3/8.9.3) with ESMTP id RAA10867;
	Tue, 16 Nov 1999 17:28:42 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151])
	by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA25068;
	Tue, 16 Nov 1999 17:28:34 +0200 (EET)
Received: by esebh02nok with Internet Mail Service (5.5.2650.10)
	id <V428Y5DY>; Tue, 16 Nov 1999 17:26:50 +0200
Message-ID: <593F7F3472A5D211B99B0008C7EAA08A0305CDFD@eseis02nok>
To: hamantar@mailbox.syr.edu
Cc: diffserv@external.cisco.com
Subject: RE: [Diffserv] MPLS vs Diff-Serv
Date: Tue, 16 Nov 1999 17:26:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
X-SMTP-HELO: mgw-x1.nokia.com
X-SMTP-MAIL-FROM: tomi.engdahl@nokia.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mgw-x1.nokia.com [131.228.20.21]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


MPLS and Diff-Serv are totally independent technologies.
They work in somewhat different network layers. Diff-Serv
is layer 3 protocol which works on IP layer. 

MPLS works on a lower layer, somewhere between network layer
(layer 2) and IP layer (layer 3). In some sense you could call
MPLS as a layer 2.5 on the network stack, because it is not
clearly layer 2 or layer 3 technology, but something in between.

As far as I know MPLS as such doesen't require Diff-Serv to work.
To build a working network using MPLS will quite propably
require some kind of traffic control mechanism at layer 3,
for example Diff-Serv.

Diff-Serv doesen't need MPLS for anything. You can build
Diff-Serv network entirely without knowing anything about MPLS
or using it. If you are building an all IP network (IP over fiber etc.)
this might be the wisest choice.

If you happen to use some layer 2 network techology which provides
some network connections like functionality then using MPLS on such
system might be beneficial. So if you have an ATM or Frame Relay
based core network, MPLS might be useful in utilizing what that
network offers efficently. On ATM based network, it might be sensible
to use both Diffserv and MPLS on the same network.


The views shown at this article are my personal views on 
MPLS and Diff-Serv.


Tomi Engdahl
Nokia Research Center



> -----Original Message-----
> From: EXT Haci A. Mantar [mailto:hamantar@mailbox.syr.edu]
> Sent: 15. November 1999 6:57
> To: Haci A. Mantar
> Cc: diffserv@external.cisco.com
> Subject: [Diffserv] MPLS vs Diff-Serv
> 
> 
> Hi
> 
> Are MPLS and Diff-Serv totally independent technologies? I 
> mean does MPLS
> uses Diff-Serv for some requirment, or Diff-Serv uses MPLS 
> for anything.
> For example: MPLS uses extended RSVP for reservation, Is 
> there any this
> kind of related or depended functions between Diff-Serv and MPLS.
> 
> Thanks
> 
> 
> HACI ALI MANTAR
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


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



From diffserv-admin@ietf.org  Tue Nov 16 11:43:20 1999
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 LAA29484
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 11:43:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04790;
	Tue, 16 Nov 1999 10:59:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA04684
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 10:59:37 -0500 (EST)
Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08449
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 10:59:51 -0500 (EST)
Received: from shultz.argon.com by wodc7mr0.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: shultz.argon.com [208.234.161.2])
	id QQhppg14273
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 16:00:19 GMT
Received: from hochstetter (hochstetter.argon.com [208.234.161.53])
	by shultz.argon.com (8.8.6/8.8.6) with SMTP id KAA19904
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 10:59:52 -0500 (EST)
Message-Id: <3.0.3.32.19991116110202.00997830@shultz.argon.com>
X-Sender: kasten@shultz.argon.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 16 Nov 1999 11:02:02 -0500
To: diffserv@ietf.org
From: Frank Kastenholz <kasten@argon.com>
Subject: Re: [Diffserv] EF RFC and loss
In-Reply-To: <11317.942688663@cs.ucl.ac.uk>
References: <Your message of "Mon, 15 Nov 1999 08:22:50 PST." <3830335A.94DB8872@dnrc.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


The _ideal_ behavior for EF might be 0 packet loss and 0 delay (other
than cosmic-ray type losses and speed-of-light delays). However, this
will not be the case in the real world. Building applications that assume
that these characteristics will absolutely met would be living rather
dangerously.



EF will have some packet loss above and beyond Grenville's cosmic rays.
Routers fail and the packets in the failed router are lost, as are all
the packets that are sent to that router (until the routing protocols
reroute). Ditto for links failing (no amount of DiffServ specification
can prevent a backhoe from eating a fiber when it gets hungry).

Also, routing just isn't all that stable and packet-loss, connecticity-
loss, etc-loss, can happen for no apparent reason. Just look at the
periodic outages we had at the WDC IETF meeting last week. 

Long-term, these losses are probably in the noise. However, short-term
the loss-rates could be substantial

About all you can say about EF and packet-loss is
    If the network is properly traffic engineered (including the proper
    configuration for BE traffic) then there ought to be no loss due to 
    buffer overflow  -- i.e. no congestive loss



As to delay, again I hate to disappoint but there will be delay,
above and beyond the speed-of-light propagation delay.

There will be the intra-router delay.  Even if there is no load,
a router will take a certain, non-0, amount of time to do its thing.
High-speed routing technology optimizes for packet-rate by
increasing parallelism and therefore latency. The routing silicon
could have many 10's of packets 'in flight' at any one time waiting
for memory accesses to complete, etc, etc.

There will also be queueing delay. Consider a router with three
interfaces, A, B, and C. Two EF packets come in, one via interface
A and the other via interface B. They both are to go out interface C.
Only one will go out at a time. The other will have to wait.

Another possibility, consider an OC48 Packet-over-SONET line.
There could be an IPv6-jumbo-gram (which can be _real_ _huge_,
possibly taking several seconds on the link) going out when an
EF packet comes in. The EF packet will just have to wait...

In addition, real implementations of packet processing all have
some fifoing between the queuing logic and the physical link.
The queuing logic is where the EF/AF/.. decisions are made and
the next packet to be sent is selected. Then that packet sits in 
the fifo until it reaches the head of the fifo and then off it 
goes. Fifos may be several KB deep.

About all you can say about EF and delay is
    If the network is properly traffic engineered (including the proper
    configuration for BE traffic, such as for MTU) then delay should 
    be highly characterizable, and jitter will be minimized, but not 0.

Frank Kastenholz



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



From diffserv-admin@ietf.org  Tue Nov 16 12:09:42 1999
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 MAA09315
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 12:09:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05901;
	Tue, 16 Nov 1999 11:28:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05870
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 11:27:59 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22205
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 11:28:12 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id IAA03567
	for <diffserv@external.cisco.com>; Tue, 16 Nov 1999 08:36:19 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 16 Nov 1999 08:28:34 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA20612; Tue, 16 Nov 1999 16:21:51 GMT
Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA36708; Tue, 16 Nov 1999 16:21:49 GMT
Message-ID: <3831844B.34E5993D@hursley.ibm.com>
Date: Tue, 16 Nov 1999 10:20:27 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Baijian Yang <yangbaij@pilot.msu.edu>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] Question about SLA
References: <199911152334.SAA137770@northrelay03.pok.ibm.com> <3830C9EF.224FA84B@pilot.msu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Baijian,

SLAs ar outside the scope of the diffserv WG and therefore
outside the scope of this list.

Thanks

  Brian Carpenter
  diffserv co-chair

Baijian Yang wrote:
> 
> Hello,
> 
> I went through RFC-2475, and found that the concept of
> SLA is rather vague. And also, I was very curious about
> the implementation of these SLAs. Are they negosiated
> on per-flow basis, or periotically updated between the
> upstream and downstream DS domain. Can anyone give me
> some idea about it? thx!
> 
> Regards,
> Baijian YANG
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Tue Nov 16 12:10:30 1999
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 MAA09590
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 12:10:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05851;
	Tue, 16 Nov 1999 11:27:48 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05819
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 11:27:44 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22085
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 11:27:58 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id IAA28822
	for <diffserv@external.cisco.com>; Tue, 16 Nov 1999 08:25:42 -0800 (PST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by proxy3.cisco.com with SMTP (MailShield v1.5); Tue, 16 Nov 1999 08:24:04 -0800
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA102230; Tue, 16 Nov 1999 16:23:24 GMT
Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA15014; Tue, 16 Nov 1999 16:23:22 GMT
Message-ID: <383184C3.BD09F1E1@hursley.ibm.com>
Date: Tue, 16 Nov 1999 10:22:27 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
CC: diffserv@external.cisco.com
Subject: Re: [Diffserv] Class Selector and BE
References: <336ECDAFDF7DD311B9E30090277AEE41351417@nt-exchange-bby.pmc-sierra.bc.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: mail-gw.hursley.ibm.com
X-SMTP-MAIL-FROM: brian@hursley.ibm.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: mail-gw.hursley.ibm.com [194.196.110.15]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

That is the intention of RFC 2474.

  Brian

Shahram Davari wrote:
> 
> Hi,
> 
> Since the standard DSCP=000000 is assigned to both Class Selector 0 and BE
> does that mean that CS0 and BE are equivalent?
> 
> Shahram
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Tue Nov 16 12:11:13 1999
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 MAA09845
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 12:11:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05469;
	Tue, 16 Nov 1999 11:16:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA05436
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 11:16:22 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16618
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 11:16:37 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id IAA26286
	for <diffserv@external.cisco.com>; Tue, 16 Nov 1999 08:24:50 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by proxy2.cisco.com with SMTP (MailShield v1.5); Tue, 16 Nov 1999 08:18:33 -0800
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP 
          id <g.13462-0@bells.cs.ucl.ac.uk>; Tue, 16 Nov 1999 16:09:02 +0000
To: tomi.engdahl@nokia.com
cc: hamantar@mailbox.syr.edu, diffserv@external.cisco.com
Subject: Re: [Diffserv] MPLS vs Diff-Serv
In-reply-to: Your message of "Tue, 16 Nov 1999 17:26:47 +0200." <593F7F3472A5D211B99B0008C7EAA08A0305CDFD@eseis02nok>
Date: Tue, 16 Nov 1999 16:09:00 +0000
Message-ID: <28139.942768540@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
X-SMTP-HELO: bells.cs.ucl.ac.uk
X-SMTP-MAIL-FROM: J.Crowcroft@cs.ucl.ac.uk
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: bells.cs.ucl.ac.uk [128.16.5.31]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


In message <593F7F3472A5D211B99B0008C7EAA08A0305CDFD@eseis02nok>, tomi.engdahl@
nokia.com typed:

 >>MPLS and Diff-Serv are totally independent technologies.

however, if you believe the hype, mpls enables traffic engineering -
one reason for traffic engineering is to provide better control of
services, including meeting some sort of SLAs (at least within an ISPs
boundaries), and Diff Serve is aimed at (eventually) allowing some
sort of derivation of services from PHB behaviours, together with
source models, traffic matrix and the providers knowledge of their
provisioning, and topology

so they could be inextricalby intertwined in some people's minds and
implmenetations....i guess a switch router might even map DSCP +
egress to labels if one wants to cut to the chase...

of course, the fact tha you can do traffic engineering (and flow
aggregation) without mpls, and the fact that you can do provisioning
without diffserv is entirely orthogonal :-)

j.
my employer pays me to have opinions - so this must be the official
position, or they are wasting their money:-)


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



From diffserv-admin@ietf.org  Tue Nov 16 13:03:48 1999
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 NAA02444
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 13:03:48 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA08491;
	Tue, 16 Nov 1999 12:24:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA08460
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 12:24:07 -0500 (EST)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15317
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 12:24:20 -0500 (EST)
Received: from donald.fokus.gmd.de (donald [193.175.132.118])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA09191
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 18:24:16 +0100 (MET)
Received: from localhost (dor@localhost)
	by donald.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA06694
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 18:24:19 +0100 (MET)
Date: Tue, 16 Nov 1999 18:24:19 +0100 (MET)
From: Dorgham Sisalem <sisalem@fokus.gmd.de>
To: diffserv@ietf.org
Message-ID: <Pine.GSO.4.20.9911152211270.6418-100000@donald>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Diffserv] DiffServ simulation model
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi,

I am trying to assemble a NS simulation for the diffServ model with
marking, policing and buffer management. I have seen some papers
simulating one or the other feature. Is anywhere a complete test
simulation or at least a place where I can get some of the different
parts?

Regards
	Dorgham 

---
Dorgham Sisalem                   email:   sisalem@fokus.gmd.de
GMD-Fokus                         phone:   ++49 30 34 63 71 70
Kaiserin-Augusta-Allee 31         fax:     ++49 30 34 63 81 70
D-10589 Berlin 			  
URL:   http://www.fokus.gmd.de/usr/sisalem



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



From diffserv-admin@ietf.org  Tue Nov 16 13:29:27 1999
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 NAA14495
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 13:29:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA09328;
	Tue, 16 Nov 1999 12:57:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA09301
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 12:57:40 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29478
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 12:57:56 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA25581
	for <diffserv@external.cisco.com>; Tue, 16 Nov 1999 10:06:05 -0800 (PST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA11532;
	Tue, 16 Nov 1999 09:56:46 -0800 (PST)
Message-ID: <38319B26.F91B97C1@cisco.com>
Date: Tue, 16 Nov 1999 09:57:58 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian E Carpenter <brian@hursley.ibm.com>
CC: Shahram Davari <Shahram_Davari@pmc-sierra.com>,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] Class Selector and BE
References: <336ECDAFDF7DD311B9E30090277AEE41351417@nt-exchange-bby.pmc-sierra.bc.ca> <383184C3.BD09F1E1@hursley.ibm.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


With the caveat that we are using "BE" loosely since that is
a service or possibly a BA and Default is a PHB...

Brian E Carpenter wrote:
> 
> That is the intention of RFC 2474.
> 
>   Brian
> 
> Shahram Davari wrote:
> >
> > Hi,
> >
> > Since the standard DSCP=000000 is assigned to both Class Selector 0 and BE
> > does that mean that CS0 and BE are equivalent?
> >
> > Shahram
> >
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Tue Nov 16 13:38:12 1999
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 NAA19192
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 13:38:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA09391;
	Tue, 16 Nov 1999 12:59:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA09362
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 12:59:25 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00327
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 12:59:40 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA11946;
	Tue, 16 Nov 1999 09:58:38 -0800 (PST)
Message-ID: <38319B97.CDDC588F@cisco.com>
Date: Tue, 16 Nov 1999 09:59:51 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dorgham Sisalem <sisalem@fokus.gmd.de>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] DiffServ simulation model
References: <Pine.GSO.4.20.9911152211270.6418-100000@donald>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


Our stuff is out at: ftp://ftp-eng.cisco.com/ftp/kmn-group/ns-2/
but you have to put it into ns-2 to use it. Kedar (poduri@cisco.com)
promises to put out a script or two. No warranty on the code.

Dorgham Sisalem wrote:
> 
> Hi,
> 
> I am trying to assemble a NS simulation for the diffServ model with
> marking, policing and buffer management. I have seen some papers
> simulating one or the other feature. Is anywhere a complete test
> simulation or at least a place where I can get some of the different
> parts?
> 
> Regards
>         Dorgham
> 
> ---
> Dorgham Sisalem                   email:   sisalem@fokus.gmd.de
> GMD-Fokus                         phone:   ++49 30 34 63 71 70
> Kaiserin-Augusta-Allee 31         fax:     ++49 30 34 63 81 70
> D-10589 Berlin
> URL:   http://www.fokus.gmd.de/usr/sisalem
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Tue Nov 16 13:38:29 1999
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 NAA19344
	for <diffserv-archive@ietf.org>; Tue, 16 Nov 1999 13:38:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA08416;
	Tue, 16 Nov 1999 12:22:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA08385
	for <diffserv@optimus.ietf.org>; Tue, 16 Nov 1999 12:22:27 -0500 (EST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14648
	for <diffserv@ietf.org>; Tue, 16 Nov 1999 12:22:40 -0500 (EST)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19615;
	Tue, 16 Nov 1999 09:22:39 -0800 (PST)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost)
	by gra.isi.edu (8.8.7/8.8.6) id JAA06756;
	Tue, 16 Nov 1999 09:22:39 -0800 (PST)
Date: Tue, 16 Nov 1999 09:22:39 -0800 (PST)
Message-Id: <199911161722.JAA06756@gra.isi.edu>
To: rsvp@ISI.EDU, diffserv@ietf.org, pfoy@hns.com
X-Sun-Charset: US-ASCII
Subject: [Diffserv] Re: RSVP vs DiffServ
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


  *> 
  *> I was browsing the iBand3 website (http://www.stardust.com/iband3/) and
  *> discovered a section in the 'iBAND3 Network Showcase Tour Guide' that outlined
  *> applications using QoS and Policy protocols.  Of the six applications that iBand
  *> profiled, 5 applications are using DiffServ and 1 is using RSVP.
  *> This was a bit surprising since I thought that RSVP was further along than
  *> DiffServ (wrt standardization and deployment) and RSVP was actually gaining
  *> momentum in the industry.  I understand the benefits of DiffServ over RSVP, but
  *> I thought that RSVP's end-to-end guarantee outweighed the scalability and
  *> overhead issues.
  *> 
  *> In a few years when these QoS methods become more mature, it makes sense that
  *> certain applications would favor one over the other.  But in the early stages,
  *> are the benefits clear enough that applications are focusing on DiffServ rather
  *> than RSVP?
  *> 
  *> Any comments about this issue are appreciated.
  *> 
  *> Thanks.
  *> 
  *> Patrick Foy
  *> 
  *> 
  *> 
I do not think EITHER of these two lists is the appropriate forum
for such a discussion.  I can offer the end2end-interest@isi.edu
list as a possible alternative.

Bob Braden

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



From diffserv-admin@ietf.org  Wed Nov 17 11:34:41 1999
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 LAA27605
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 11:34:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14817;
	Wed, 17 Nov 1999 10:29:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14773
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 10:29:13 -0500 (EST)
Received: from rautu.eng.telia.fi (root@tnt-2-187.pops.easynet.fr [212.180.33.187] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26759
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 10:29:24 -0500 (EST)
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id VAA00292;
	Tue, 16 Nov 1999 21:33:53 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.45472.997856.781792@rautu.eng.telia.fi>
Date: Tue, 16 Nov 1999 21:33:52 +0200 (EET)
To: Joerg Diederich <dieder@ibr.cs.tu-bs.de>
Cc: gja@dnrc.bell-labs.com (Grenville Armitage), diffserv@ietf.org
Subject: Re: [Diffserv] EF with Drop ?
In-Reply-To: <yj84seurs7n.fsf@kelts.ibr.cs.tu-bs.de>
References: <3828F51F.25484DF8.diff-serv@dnrc.bell-labs.com>
	<yj84seurs7n.fsf@kelts.ibr.cs.tu-bs.de>
X-Mailer: VM 6.74 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Joerg Diederich writes:

 > In my eyes, you _can_ apply the same traffic conditioning actions to
 > packets marked for an AF class as to packets marked for EF so that you
 > model EF using AF. In this way, you simply do not need the buffer
 > management from AF since almost no queues arise. And if you do so, you
 > get 'EF with two drop precedences' so that you do not need EFD
 > anymore.

you can implement a behavior that is atleast close to ef by using an af
queue with a large weight (in order to guarantee low delay) and by
policing traffic at the ingress so that only green packets are allowed
to the network.

implementing an ef like behavior with drop is a bit more complicated
though, since i don't want the yellow packets to get all the bandwidth
that would be granted to them because of the large weight of the af
queue.  so what is needed in this case is red that starts to kick in not
when the queue size exceeds a threshold (which it never does), but when
the arrival rate of packets to that queue exceed a threshold.  for
example, if i want the "low delay with drop" packets not to consume more
than 20 mbps of a link's capacity, i would start dropping yellow packets
when the arrival rate of the packets exceeds 10 mbps.

 > I assume that there already was some discussion on this point but I
 > don't know, since I haven't been in the DiffServ working group from
 > the beginning. 

there was discussion about this, but to me it was more important to get
af done than to spend my time fighting against ef.

 > Thus, the EFD draft assumes that EF should be used to build a
 > low-delay service such as Premium service and we want to build a
 > service with _exactly_ the same delay characteristics as Premium
 > service using EF but allowing dropping. I do not think that you can
 > achieve the delay requirement by using AF for BELD traffic and EF
 > for Premium service simultaneously.

the customers don't care about af or ef.  they care about services and
it is my business which phbs i use to implement them.  the phbs used in
my network to implement a service don't need to be the same that the
next network is using.
 > 
 > I agree with you, but since we assume that EF is used (or should be
 > used) to built low-delay services which rely on avoidance of
 > congestion by traffic conditioning (see above), AF seems to be not the
 > right way to implement a low-delay service which allows dropping but
 > does not allow congestion.

see above for an implementation that uses an af class with red and
results in a low delay service with drop.  is there something wrong with
it?  what else you would need?

-- juha

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



From diffserv-admin@ietf.org  Wed Nov 17 11:34:54 1999
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 LAA27700
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 11:34:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14789;
	Wed, 17 Nov 1999 10:29:14 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14752
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 10:29:09 -0500 (EST)
Received: from rautu.eng.telia.fi (root@tnt-2-187.pops.easynet.fr [212.180.33.187] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26731
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 10:29:20 -0500 (EST)
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id RAA00392;
	Tue, 16 Nov 1999 17:19:14 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.30194.271518.555722@rautu.eng.telia.fi>
Date: Tue, 16 Nov 1999 17:19:14 +0200 (EET)
To: Kathleen Nichols <kmn@cisco.com>
Cc: Grenville Armitage <gja@dnrc.bell-labs.com>, DiffServ <diffserv@ietf.org>
Subject: Re: [Diffserv] EF with Drop ?
In-Reply-To: <38299F32.BEA0B494@cisco.com>
References: <3828F51F.25484DF8@dnrc.bell-labs.com>
	<38299F32.BEA0B494@cisco.com>
X-Mailer: VM 6.74 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Kathleen Nichols writes:

 > I completely agree. Further, I think you could configure a Class
 > Selector the same way. Give it a short queue, control the
 > service rate and control the amount of the BA stamped for that CS
 > admitted to the network.

one way to implement a low delay service with drop is to use an af queue
with a high weight, but limiting enqueing of packets into it by running
red against a rate threshold rather than queue length threshold.

-- juha

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



From diffserv-admin@ietf.org  Wed Nov 17 12:33:59 1999
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 MAA24028
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 12:33:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA17429;
	Wed, 17 Nov 1999 11:46:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA17392
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 11:46:32 -0500 (EST)
Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03488
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 11:46:47 -0500 (EST)
Received: from xantos (rcq.ne.mediaone.net [24.218.25.18])
	by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id LAA02240;
	Wed, 17 Nov 1999 11:46:39 -0500 (EST)
Message-Id: <4.1.19991116125325.01a81100@pop.tiac.net>
Message-Id: <4.1.19991116125325.01a81100@pop.tiac.net>
Message-Id: <4.1.19991116125325.01a81100@pop.tiac.net>
X-Sender: rcq@pop.tiac.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Nov 1999 11:46:37 -0500
To: pfoy@hns.com
From: Bob Quinn <rcq@stardust.com>
Subject: Re: [Diffserv] RSVP vs DiffServ
Cc: rsvp@ISI.EDU, diffserv@ietf.org
In-Reply-To: <8525682B.00517BED.00@ngw2.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hello Patrick,

The iBAND3 showcase was created by a design team whose focus was 
to demonstrate interoperability of QoS technologies--RSVP, DiffServ, 
802.1p, SBM--along with policy management, to provide end-to-end QoS. 
As you mention, RSVP has been stable and shipping in products to 
enable Integrated Services (IntServ) for some time now, so RSVP 
interoperability among vendors is largely a non-issue. 

DiffServ and these other QoS technologies, on the other hand, are 
relatively new. They are complements to RSVP, not replacements 
by any stretch. Hence, when DiffServ is used it doesn't preclude 
or eclipse the use of RSVP. They are both important parts of the 
QoS machinery designed to satisfy the needs of the full spectrum 
of QoS application and network requirements.

QoS requires traffic handling mechanisms and the ability to 
dynamically affect these mechanisms across multiple network 
devices between a sender/receiver pair. Diffserv, IntServ, 
802.1p or even ATM are all examples of traffic handling 
mechanisms and RSVP is a signaling protocol used to (dynamically) 
configure them. Hence, among other things, the iBAND3 showcase 
was designed to demonstrate RSVP in action in a combination 
DiffServ and IntServ enabled network.

So, bottom line, you mustn't read too much into the fact that 
DiffServ may have been emphasized in the descriptions of the 
showcase. It doesn't mean what you think.
Hope that helps, 
-- 
Bob Quinn 
rcq@stardust.com

At 09:50 AM 11/16/99 , pfoy@hns.com wrote:
>
>
>I was browsing the iBand3 website (http://www.stardust.com/iband3/) and
>discovered a section in the 'iBAND3 Network Showcase Tour Guide' that outlined
>applications using QoS and Policy protocols.  Of the six applications that 
>iBand
>profiled, 5 applications are using DiffServ and 1 is using RSVP.
>This was a bit surprising since I thought that RSVP was further along than
>DiffServ (wrt standardization and deployment) and RSVP was actually gaining
>momentum in the industry.  I understand the benefits of DiffServ over RSVP, but
>I thought that RSVP's end-to-end guarantee outweighed the scalability and
>overhead issues.
>
>In a few years when these QoS methods become more mature, it makes sense that
>certain applications would favor one over the other.  But in the early stages,
>are the benefits clear enough that applications are focusing on DiffServ rather
>than RSVP?
>
>Any comments about this issue are appreciated.
>
>Thanks.
>
>Patrick Foy
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>



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



From diffserv-admin@ietf.org  Wed Nov 17 13:38:50 1999
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 NAA25224
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 13:38:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19761;
	Wed, 17 Nov 1999 12:51:59 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA19735
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 12:51:55 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03072
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 12:52:06 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA02446;
	Wed, 17 Nov 1999 09:50:57 -0800 (PST)
Message-ID: <3832EB4B.8FCC7D7B@cisco.com>
Date: Wed, 17 Nov 1999 09:52:11 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Heinanen <jh@lohi.eng.telia.fi>
CC: Grenville Armitage <gja@dnrc.bell-labs.com>, DiffServ <diffserv@ietf.org>
Subject: Re: [Diffserv] EF with Drop ?
References: <3828F51F.25484DF8@dnrc.bell-labs.com>
		<38299F32.BEA0B494@cisco.com> <14385.30194.271518.555722@rautu.eng.telia.fi>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Juha Heinanen wrote:
> 
> Kathleen Nichols writes:
> 
>  > I completely agree. Further, I think you could configure a Class
>  > Selector the same way. Give it a short queue, control the
>  > service rate and control the amount of the BA stamped for that CS
>  > admitted to the network.
> 
> one way to implement a low delay service with drop is to use an af queue
> with a high weight, but limiting enqueing of packets into it by running
> red against a rate threshold rather than queue length threshold.
> 
> -- juha

...so we appear to have plenty of PHBs that fit the bill....

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



From diffserv-admin@ietf.org  Wed Nov 17 16:19:43 1999
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 QAA08344
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 16:19:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA24200;
	Wed, 17 Nov 1999 15:28:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA24170
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 15:28:34 -0500 (EST)
Received: from rautu.eng.telia.fi (root@tnt-101.pops.easynet.fr [212.180.30.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18560
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 15:28:46 -0500 (EST)
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id CAA00401;
	Wed, 17 Nov 1999 02:18:35 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.62555.711552.385172@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 02:18:35 +0200 (EET)
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>,
        DiffServ <diffserv@ietf.org>
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
In-Reply-To: <382B10AF.84D09618@hursley.ibm.com>
References: <199911111549.QAA10406@blackfoot.telematik.informatik.uni-karlsruhe.de>
	<382B10AF.84D09618@hursley.ibm.com>
X-Mailer: VM 6.74 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter writes:

 > Need I say again that services are outside the diffserv WG charter?

is there another wg to which they belong or can diffserv change its
charter?  the current situation is simply unbearable and will result in
countless new phb proposal when in fact they are proposing services.

-- juha

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



From diffserv-admin@ietf.org  Wed Nov 17 16:20:07 1999
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 QAA08519
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 16:20:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA24601;
	Wed, 17 Nov 1999 15:41:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA24572
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 15:41:05 -0500 (EST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23563
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 15:41:18 -0500 (EST)
Received: from stl-hub-01.boeing.com ([192.76.190.51])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA14037
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 14:41:18 -0600 (CST)
Received: from [199.191.48.134] by stl-hub-01.boeing.com for diffserv@ietf.org; Wed, 17 Nov 1999 14:41:15 -0600
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Wed, 17 Nov 1999 15:40:18 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Bob Quinn" <rcq@stardust.com>
Cc: <rsvp@ISI.EDU>, <diffserv@ietf.org>
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Wed, 17 Nov 1999 15:41:10 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIEIKCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4.1.19991116125325.01a81100@pop.tiac.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Bob Quinn wrote:

[ ... ]

> Diffserv, IntServ,
> 802.1p or even ATM are all examples of traffic handling
> mechanisms and RSVP is a signaling protocol used to (dynamically)
> configure them.

Dunno about you (plural, or y'all), but I find this confusing.

My description would be that RSVP is thought by some not to "scale
well" in very large networks, and that therefore diffserv is being
developed to provide QoS within the network core. RSVP is instead
used at the edges, which might include interfaces within diffserv
routers (after all, core routers are likely to be edge routers as
well).

802.1p is a priority scheme for a Layer 2 LAN environment, so it is
a different issue from IP QoS. But IP QoS could invoke IEEE 802.1p,
when appropriate.

Similarly, ATM might be an alternative to diffserv or to intserv
over datagram LANs, in that ATM could be used either in the core or
at the edges, instead of datagram nets like Ethernet or FDDI. So ATM
has proposals for mapping of RSVP and diffserv QoS into ATM QoS,
when IP is carried over ATM.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Wed Nov 17 16:23:41 1999
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 QAA10013
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 16:23:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA25197;
	Wed, 17 Nov 1999 15:57:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA25168
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 15:57:47 -0500 (EST)
Received: from yarilo.pluris.com (pluris.com [208.227.9.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00259
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 15:58:00 -0500 (EST)
Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17])
	by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA26179;
	Wed, 17 Nov 1999 12:57:34 -0800 (PST)
Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0)
	id <VHD01WB8>; Wed, 17 Nov 1999 12:57:34 -0800
Message-ID: <6342F12F9359D311990B009027A1B9B603E747@monterey.pluris.com>
From: Bora Akyol <akyol@pluris.com>
To: "'Juha Heinanen'" <jh@lohi.eng.telia.fi>,
        Brian E Carpenter
	 <brian@hursley.ibm.com>
Cc: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>,
        DiffServ
	 <diffserv@ietf.org>
Subject: RE: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
Date: Wed, 17 Nov 1999 12:57:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

I completely agree with Juha on this. 
One of the most frustrating things about the Diffserv WG is that it is
trying to define mechanisms without considering the services that may use
them. Should we have a vote for charter amendment?

Bora Akyol, Pluris
http://www.pluris.com/

-----Original Message-----
From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
Sent: Tuesday, November 16, 1999 4:19 PM
To: Brian E Carpenter
Cc: Roland Bless; DiffServ
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)

Brian E Carpenter writes:

 > Need I say again that services are outside the diffserv WG charter?

is there another wg to which they belong or can diffserv change its
charter?  the current situation is simply unbearable and will result in
countless new phb proposal when in fact they are proposing services.

-- juha

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

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



From diffserv-admin@ietf.org  Wed Nov 17 18:53:25 1999
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 SAA10909
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 18:53:25 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA00684;
	Wed, 17 Nov 1999 18:29:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA00649
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 18:28:58 -0500 (EST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02860
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 18:29:12 -0500 (EST)
Received: from [18.26.0.86] (callisto.lcs.mit.edu [18.26.0.86])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA18579;
	Wed, 17 Nov 1999 18:28:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw_ds@mercury.lcs.mit.edu
Message-Id: <v04220802b458e8b5390d@[204.179.128.78]>
In-Reply-To: <14385.45472.997856.781792@rautu.eng.telia.fi>
References: <3828F51F.25484DF8.diff-serv@dnrc.bell-labs.com>
 <yj84seurs7n.fsf@kelts.ibr.cs.tu-bs.de>
 <14385.45472.997856.781792@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 18:28:47 -0500
To: Juha Heinanen <jh@lohi.eng.telia.fi>,
        Joerg Diederich <dieder@ibr.cs.tu-bs.de>
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Re: [Diffserv] EF with Drop ?
Cc: gja@dnrc.bell-labs.com (Grenville Armitage), diffserv@ietf.org
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.ietf.org>
X-BeenThere: diffserv@ietf.org

At 9:33 PM +0200 11/16/99, Juha Heinanen wrote:

>  > I agree with you, but since we assume that EF is used (or should be
>  > used) to built low-delay services which rely on avoidance of
>  > congestion by traffic conditioning (see above), AF seems to be not the
>  > right way to implement a low-delay service which allows dropping but
>  > does not allow congestion.
>
>see above for an implementation that uses an af class with red and
>results in a low delay service with drop.  is there something wrong with
>it?  what else you would need?
>
>-- juha

Juha,

I suspect I'm missing your point here, but this doesn't make sense to me:

- if there is sufficient b/w available to the AF class to carry the 
traffic, it will go & there isn't much reason to drop it.

- if there is insufficient b/w to carry the traffic for whatever 
reason, it will queue, and if you would rather drop it than queue it 
you should be able to accomplish this by setting the AF parameters 
appropriately (small q size, short averaging interval.

So I'm not quite sure what is to be gained by specifically watching 
rate rather than q size.

(I believe this is pretty much what Grenville said in this thread 
some msgs ago..)

-john

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



From diffserv-admin@ietf.org  Wed Nov 17 19:12:32 1999
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 TAA18182
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 19:12:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01240;
	Wed, 17 Nov 1999 18:45:18 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA01210
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 18:45:14 -0500 (EST)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08405
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 18:45:27 -0500 (EST)
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id PAA12615;
	Wed, 17 Nov 1999 15:45:03 -0800 (PST)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <XBNSY5HG>; Wed, 17 Nov 1999 15:45:03 -0800
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135141D@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'John Wroclawski'" <jtw@lcs.mit.edu>,
        Juha Heinanen
	 <jh@lohi.eng.telia.fi>,
        Joerg Diederich <dieder@ibr.cs.tu-bs.de>
Cc: gja@dnrc.bell-labs.com, diffserv@ietf.org
Subject: RE: [Diffserv] EF with Drop ?
Date: Wed, 17 Nov 1999 15:43:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi John,

I think what Juha is proposing is that to reduce the delay, you could for
example assign 90% of the link BW to an AF class, but you don't want to
actually use that BW (because if you do other classes will get starved).
Let's say for example you want to use only 50% of the BW. Due to this
artificially available BW, there will be no queue buildup, and therefore you
can't use normal RED (which decides based on queue depth) to control the BW
usage. So you have to control the injection rate of high drop-precedence
traffic to the queue.

Regards,
Shahram


> -----Original Message-----
> From: John Wroclawski [mailto:jtw@lcs.mit.edu]
> Sent: Wednesday, November 17, 1999 3:29 PM
> To: Juha Heinanen; Joerg Diederich
> Cc: gja@dnrc.bell-labs.com; diffserv@ietf.org
> Subject: Re: [Diffserv] EF with Drop ?
> 
> 
> At 9:33 PM +0200 11/16/99, Juha Heinanen wrote:
> 
> >  > I agree with you, but since we assume that EF is used 
> (or should be
> >  > used) to built low-delay services which rely on avoidance of
> >  > congestion by traffic conditioning (see above), AF seems 
> to be not the
> >  > right way to implement a low-delay service which allows 
> dropping but
> >  > does not allow congestion.
> >
> >see above for an implementation that uses an af class with red and
> >results in a low delay service with drop.  is there 
> something wrong with
> >it?  what else you would need?
> >
> >-- juha
> 
> Juha,
> 
> I suspect I'm missing your point here, but this doesn't make 
> sense to me:
> 
> - if there is sufficient b/w available to the AF class to carry the 
> traffic, it will go & there isn't much reason to drop it.
> 
> - if there is insufficient b/w to carry the traffic for whatever 
> reason, it will queue, and if you would rather drop it than queue it 
> you should be able to accomplish this by setting the AF parameters 
> appropriately (small q size, short averaging interval.
> 
> So I'm not quite sure what is to be gained by specifically watching 
> rate rather than q size.
> 
> (I believe this is pretty much what Grenville said in this thread 
> some msgs ago..)
> 
> -john
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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



From diffserv-admin@ietf.org  Wed Nov 17 22:09:03 1999
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 WAA25354
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 22:09:02 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA08410;
	Wed, 17 Nov 1999 21:20:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA08379
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 21:20:19 -0500 (EST)
Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03279
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 21:20:32 -0500 (EST)
Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183])
	by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id SAA18137;
	Wed, 17 Nov 1999 18:19:57 -0800 (PST)
Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21)
	id <XBNSY6JC>; Wed, 17 Nov 1999 18:19:57 -0800
Message-ID: <336ECDAFDF7DD311B9E30090277AEE4135141E@nt-exchange-bby.pmc-sierra.bc.ca>
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
To: "'demir'" <demir@usc.edu>,
        Shahram Davari
	 <Shahram_Davari@pmc-sierra.com>
Cc: diffserv@ietf.org
Subject: RE: [Diffserv] EF with Drop ?
Date: Wed, 17 Nov 1999 18:18:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hi,

The reason of giving a higher weight than what is actually needed is to
emulate a priority scheduling. The 90% weight will make sure that almost all
incoming packets are processed immediately, while a rate controller makes
sure that only the provisioned EF BW is used. 

Note that if you use EF-PHB, you don't even need the rate controller, while
if you combine EF with EFD (EF with drop) then you need to rate control the
high drop-precedence.

Regards,
Shahram 


> -----Original Message-----
> From: demir [mailto:demir@usc.edu]
> Sent: Wednesday, November 17, 1999 6:08 PM
> To: Shahram Davari
> Cc: diffserv@ietf.org
> Subject: RE: [Diffserv] EF with Drop ?
> 
> 
> > I think what Juha is proposing is that to reduce the delay, 
> you could for
> > example assign 90% of the link BW to an AF class, but you 
> don't want to
> > actually use that BW (because if you do other classes will 
> get starved).
> > Let's say for example you want to use only 50% of the BW. 
> Due to this
> > artificially available BW, there will be no queue buildup, 
> and therefore you
> > can't use normal RED (which decides based on queue depth) 
> to control the BW
> > usage. So you have to control the injection rate of high 
> drop-precedence
> > traffic to the queue.
> Hi,
> Why do you assing 90% of the link BW to an AF class though 
> you want to use
> only 50% of the BW for that class? 
> I am assuming that by "you can't use RED" mean, RED is used with
> controlling the injection rate of high-drop precedence AF 
> traffic to the
> queue. why do we need to control the injection rate to the 
> queue instead
> of scheduling so that we use 50% of the BW?
> 
> Alper K. Demir
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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



From diffserv-admin@ietf.org  Wed Nov 17 22:13:27 1999
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 WAA27598
	for <diffserv-archive@ietf.org>; Wed, 17 Nov 1999 22:13:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA07974;
	Wed, 17 Nov 1999 21:07:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA07949
	for <diffserv@optimus.ietf.org>; Wed, 17 Nov 1999 21:07:31 -0500 (EST)
Received: from usc.edu (root@usc.edu [128.125.253.136])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28499
	for <diffserv@ietf.org>; Wed, 17 Nov 1999 21:07:45 -0500 (EST)
Received: from nunki.usc.edu (demir@nunki.usc.edu [128.125.253.195])
	by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id SAA05751; Wed, 17 Nov 1999 18:07:46 -0800 (PST)
Received: from localhost (demir@localhost)
	by nunki.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
	id SAA20111; Wed, 17 Nov 1999 18:07:43 -0800 (PST)
Date: Wed, 17 Nov 1999 18:07:42 -0800 (PST)
From: demir <demir@usc.edu>
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
cc: diffserv@ietf.org
Subject: RE: [Diffserv] EF with Drop ?
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4135141D@nt-exchange-bby.pmc-sierra.bc.ca>
Message-ID: <Pine.GSO.4.10.9911171754060.17030-100000@nunki.usc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> I think what Juha is proposing is that to reduce the delay, you could for
> example assign 90% of the link BW to an AF class, but you don't want to
> actually use that BW (because if you do other classes will get starved).
> Let's say for example you want to use only 50% of the BW. Due to this
> artificially available BW, there will be no queue buildup, and therefore you
> can't use normal RED (which decides based on queue depth) to control the BW
> usage. So you have to control the injection rate of high drop-precedence
> traffic to the queue.
Hi,
Why do you assing 90% of the link BW to an AF class though you want to use
only 50% of the BW for that class? 
I am assuming that by "you can't use RED" mean, RED is used with
controlling the injection rate of high-drop precedence AF traffic to the
queue. why do we need to control the injection rate to the queue instead
of scheduling so that we use 50% of the BW?

Alper K. Demir



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



From diffserv-admin@ietf.org  Thu Nov 18 02:11:59 1999
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 CAA01635
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 02:11:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22342;
	Thu, 18 Nov 1999 01:32:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22309
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 01:32:31 -0500 (EST)
Received: from rautu.eng.telia.fi (root@tnt-176.pops.easynet.fr [212.180.30.176])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03505
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 01:32:48 -0500 (EST)
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id CAA00376;
	Wed, 17 Nov 1999 02:08:05 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.61925.749789.816139@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 02:08:05 +0200 (EET)
To: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>
Cc: Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org,
        bless@telematik.informatik.uni-karlsruhe.de
Subject: Re: [Diffserv] LBE using RFC 2474
In-Reply-To: <382A9F2F.48A58626@telematik.informatik.uni-karlsruhe.de>
References: <3829C0CB.E18757DC@hursley.ibm.com>
	<382A9F2F.48A58626@telematik.informatik.uni-karlsruhe.de>
X-Mailer: VM 6.74 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Klaus Wehrle writes:

 > nice trick, but if an ISP do not use this mapping, the LBE-traffic would
 > not be treated lower than Best-Effort.

no isp will blindly map code points.  if my isp neighbor tells me that
in the packets that they send to me, prec 1 means background SERVICE,
then i map prec 1 at the boundary to whatever i use for background in my
network.  new phbs should not be defined just in order to standardize
code point for SERVICES.  write a background service spec instead.

-- juha

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



From diffserv-admin@ietf.org  Thu Nov 18 02:14:17 1999
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 CAA02887
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 02:14:17 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22557;
	Thu, 18 Nov 1999 01:43:40 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22526
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 01:43:35 -0500 (EST)
Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09710
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 01:43:52 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA24079;
	Thu, 18 Nov 1999 08:43:46 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14387.40994.769214.100633@lohi.eng.telia.fi>
Date: Thu, 18 Nov 1999 08:43:46 +0200 (EET)
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Cc: "'John Wroclawski'" <jtw@lcs.mit.edu>,
        Joerg Diederich <dieder@ibr.cs.tu-bs.de>, gja@dnrc.bell-labs.com,
        diffserv@ietf.org
Subject: RE: [Diffserv] EF with Drop ?
In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4135141D@nt-exchange-bby.pmc-sierra.bc.ca>
References: <336ECDAFDF7DD311B9E30090277AEE4135141D@nt-exchange-bby.pmc-sierra.bc.ca>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Shahram Davari writes:

 > I think what Juha is proposing is that to reduce the delay, you could for
 > example assign 90% of the link BW to an AF class, but you don't want to
 > actually use that BW (because if you do other classes will get starved).
 > Let's say for example you want to use only 50% of the BW. Due to this
 > artificially available BW, there will be no queue buildup, and therefore you
 > can't use normal RED (which decides based on queue depth) to control the BW
 > usage. So you have to control the injection rate of high drop-precedence
 > traffic to the queue.

thanks shahram, this is what i tried to say.  i would control the total
arrival rate and then start gradually dropping yellows when a given rate
threshold is exceeded.

-- juha

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



From diffserv-admin@ietf.org  Thu Nov 18 02:24:44 1999
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 CAA08179
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 02:24:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22823;
	Thu, 18 Nov 1999 01:56:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22755
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 01:56:33 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17300
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 01:56:50 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id WAA17183
	for <diffserv@external.cisco.com>; Wed, 17 Nov 1999 22:56:40 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy3.cisco.com with SMTP (MailShield v1.5); Wed, 17 Nov 1999 22:51:46 -0800
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id CAA00441;
	Wed, 17 Nov 1999 02:34:46 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.63526.480150.200347@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 02:34:46 +0200 (EET)
To: "nbitar@lucent.com" <nbitar@lucent.com>
Cc: "'Nabil Seddigh'" <nseddigh@nortelnetworks.com>,
        "gja@dnrc.bell-labs.com" <gja@dnrc.bell-labs.com>,
        "jamel@di.ufpe.br"
	 <jamel@di.ufpe.br>,
        "tonyhain@microsoft.com"
	 <tonyhain@microsoft.com>,
        "diffserv@external.cisco.com"
	 <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <01BF2D28.272DD4C0.nbitar@lucent.com>
References: <01BF2D28.272DD4C0.nbitar@lucent.com>
X-Mailer: VM 6.74 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Nabil Bitar writes:

 > Is AF a universal PHB 
 > so that any PHB can be mapped to an appropriately configured instance of 
 > AF? Is it the way that is intended to be?

i don't claim that af is universial, but it fits very well to cases
where cbwfq with a possible ceiling can be used for packet forwarding
and where dropping of packets can be based on red.  background service
definitely fits very well to that.

-- juha


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



From diffserv-admin@ietf.org  Thu Nov 18 02:27:23 1999
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 CAA09268
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 02:27:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22788;
	Thu, 18 Nov 1999 01:56:37 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA22757
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 01:56:33 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17301
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 01:56:50 -0500 (EST)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id WAA17190
	for <diffserv@external.cisco.com>; Wed, 17 Nov 1999 22:56:42 -0800 (PST)
Received: from  (lohi.eng.telia.fi [195.10.149.18]) by proxy3.cisco.com with SMTP (MailShield v1.5); Wed, 17 Nov 1999 22:52:17 -0800
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id CAA00362;
	Wed, 17 Nov 1999 02:01:23 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.61522.995636.382750@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 02:01:22 +0200 (EET)
To: "Albert Manfredi" <albert.e.manfredi@boeing.com>
Cc: <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <NDBBIBKKCLEFDFDGHCNMCEFNCAAA.albert.e.manfredi@boeing.com>
References: <14377.54853.645061.843527@lohi.eng.telia.fi>
	<NDBBIBKKCLEFDFDGHCNMCEFNCAAA.albert.e.manfredi@boeing.com>
X-Mailer: VM 6.74 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Albert Manfredi writes:

 > > it can be
 > > IMPLEMENTED as an af class that has been allocated some buffering
 > > resources, but no scheduling resources, i.e., packets from the
 > > background queue would be served only is all other queues
 > > are empty.
 > 
 > Which is a good description of standard BE traffic handling.

not quite, since traditionally be has had some forwarding resources
allocated to it.

-- juha


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



From diffserv-admin@ietf.org  Thu Nov 18 02:28:36 1999
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 CAA09766
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 02:28:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA23040;
	Thu, 18 Nov 1999 02:01:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA23009
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 02:01:05 -0500 (EST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20976
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 02:01:22 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by kickme.cisco.com (8.9.1a/8.9.1) with SMTP id WAA28678
	for <diffserv@external.cisco.com>; Wed, 17 Nov 1999 22:58:59 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy1.cisco.com with SMTP (MailShield v1.5); Wed, 17 Nov 1999 23:01:52 -0800
Received: (from jh@localhost)
	by rautu.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id CAA00395;
	Wed, 17 Nov 1999 02:15:58 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14385.62398.178833.754124@rautu.eng.telia.fi>
Date: Wed, 17 Nov 1999 02:15:58 +0200 (EET)
To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Cc: gja@dnrc.bell-labs.com, jamel@di.ufpe.br, tonyhain@microsoft.com,
        diffserv@external.cisco.com
Subject: Re: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <199911111804.KAA00380@sj-mailhub-3.cisco.com>
References: <199911111804.KAA00380@sj-mailhub-3.cisco.com>
X-Mailer: VM 6.74 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Nabil Seddigh writes:

 > LBE can certainly be implemented as an AF class. However, I have seen a
 > number of different service proposals for Diffserv. In many of these,
 > the AF classes are already spoken for by services that require better
 > than LBE. So, while in principle, AF can be used, if there are  enough
 > people who want to use all the AF classes for other services, we may
 > want to consider a different solution.

i would suggest that we wait until there is a real diffserv deployment
by some isps that are actually simultaneously offering four af based
services and want to do more.  then we can go ahead and ask new
codepoints for the fifth or sixth af class.  we could possibly be able
to save some code points by defining some af classes to have only two dp
levels.

-- juha


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



From diffserv-admin@ietf.org  Thu Nov 18 06:33:16 1999
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 GAA10501
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 06:33:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA28340;
	Thu, 18 Nov 1999 05:34:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA28309
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 05:33:56 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20596
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 05:34:13 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11oOAO-0002w8-00; Thu, 18 Nov 1999 10:47:48 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA26322;
	Thu, 18 Nov 1999 10:45:06 +0100 (MET)
Message-Id: <199911180945.KAA26322@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: diffserv@ietf.org,
        "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Thu, 11 Nov 1999 17:15:20 EST."
             <199911112224.RAA00516@pzero.sandelman.ottawa.on.ca> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 18 Nov 1999 10:41:19 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

>   Again, I do not understand why the problem expressed by Yoram is not
> solveable by distinguishing between "DSCP == 0" and "BE"

The main idea behind LBE is the following:
1.) currently the main portion of traffic is assigned to the default PHB 
    which corresponds to BE at the moment -> whatever resources are left
    after all other BAs have been served are given to BE packets.
2.) you have one or more traffic sources which are non-responsive
    and which usually would be mapped into the BE aggregate. In order
    to avoid unfairness against existing flows in the BE aggregate
    you want to limit the amount of additional traffic in case of 
    congestion.
    Therefore you push the non-responsive traffic sources in the 
    "background" by limiting their BA (maximum share). However, there is 
    also a no starvation guarantee for LBE packets (minimum share).
3.) if there is no congestion, packets in the LBE BA may also use
    unused bandwidth of any other BA.

>   Why can't Yoram solve his problem by assigning DSCP==0 to be something
> other than the BE queue? As one pointed out, with appropriate AF parameters,
> you can get the behaviour that is wanted.

Because you want to explicitly mark this traffic as background traffic
that is limited in its bandwidth share, so you need a specific codepoint
for LBE. Naturally, you could _implement_ LBE by mapping the DSCP==0 to
an AFx2 PHB mechanism and LBE DSCP to AFx3 PHB if this AF class
particularly fulfills the requirements of the LBE spec. But, simply
mapping the default PHB to a better PHB will not be sufficient, because
the next provider may not treat packets with DSCP == 0 in the same way.
 
> I got silence at diffserv when I asked this. Some people commented
> afterward to me that they didn't know either. Can someone answer me
> this? 
> The DSCP to PHB mapping is programmable by the administrator.

> If BE works for Yoram's network as it is now, then some "better"
> service ought to work as well, right?

If most of the traffic that is BE today will be in this "better" service
class in the future (being not more expensive than BE), one could use 
BE as future background class. But, this is not the situation today, so 
we may use the LBE PHB to protect the current BE traffic from being 
preempted.

Regards,
 Roland
-- 
Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097



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



From diffserv-admin@ietf.org  Thu Nov 18 10:46:43 1999
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 KAA03306
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 10:46:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA05343;
	Thu, 18 Nov 1999 09:52:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA05311
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 09:52:33 -0500 (EST)
Received: from toba.crescentnets.com (toba.crescentnets.com [209.192.235.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08806
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 09:52:48 -0500 (EST)
Received: from crescentnets.com (dhcp41.crescentnets.com [209.192.235.41])
	by toba.crescentnets.com (8.9.2/8.9.2) with ESMTP id JAA12977;
	Thu, 18 Nov 1999 09:52:15 -0500 (EST)
	(envelope-from langille@crescentnets.com)
Message-ID: <38341304.C4F911E1@crescentnets.com>
Date: Thu, 18 Nov 1999 09:53:56 -0500
From: Paul Langille <langille@crescentnets.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
CC: Michael Richardson <mcr@sandelman.ottawa.on.ca>, diffserv@ietf.org,
        "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
Subject: Re: [Diffserv] LBE using RFC 2474
References: <199911180945.KAA26322@blackfoot.telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

See comments below:

Roland Bless wrote:

> >   Again, I do not understand why the problem expressed by Yoram is not
> > solveable by distinguishing between "DSCP == 0" and "BE"
>
> The main idea behind LBE is the following:
> 1.) currently the main portion of traffic is assigned to the default PHB
>     which corresponds to BE at the moment -> whatever resources are left
>     after all other BAs have been served are given to BE packets.
> 2.) you have one or more traffic sources which are non-responsive
>     and which usually would be mapped into the BE aggregate. In order
>     to avoid unfairness against existing flows in the BE aggregate
>     you want to limit the amount of additional traffic in case of
>     congestion.
>     Therefore you push the non-responsive traffic sources in the
>     "background" by limiting their BA (maximum share). However, there is
>     also a no starvation guarantee for LBE packets (minimum share).
> 3.) if there is no congestion, packets in the LBE BA may also use
>     unused bandwidth of any other BA.
>

Roland, when I have talked about this issue I tend to approach it from a 'higher
layer'. I like the statement in your draft "Thus, it constitutes the network
equivalent to a background priority for processes in an operating system." In
broad terms one should not map default 'stuff' to the lowest priority. There may
be something (i.e. batch jobs) that one would like to run at a lower priority than
what everyone is using for the default priority. (This was the basic approach used
in 802.1P.) In my humble opinion, discussing this concept in terms of "BE" is
confusing. (Thinking out loud...I wonder if the current concept of BE needs to be
enhanced/modified to support LBE.)

>
> >   Why can't Yoram solve his problem by assigning DSCP==0 to be something
> > other than the BE queue? As one pointed out, with appropriate AF parameters,
> > you can get the behaviour that is wanted.
>
> Because you want to explicitly mark this traffic as background traffic
> that is limited in its bandwidth share, so you need a specific codepoint
> for LBE. Naturally, you could _implement_ LBE by mapping the DSCP==0 to
> an AFx2 PHB mechanism and LBE DSCP to AFx3 PHB if this AF class
> particularly fulfills the requirements of the LBE spec. But, simply
> mapping the default PHB to a better PHB will not be sufficient, because
> the next provider may not treat packets with DSCP == 0 in the same way.
>

So if I could be so bold as to summarize the issue. It IS possible to create this
behavior by mapping to AF. (Pause - Anyone disagree?) Your point is that it needs
to be standardized so that each provider will offer the same behavior. It might
help to ask if people agree with the basic model you are proposing. (OK, I'm
asking!) If yes, do you like it enough to standardize it? (It may not be easy to
obtain consensus for this question. Brian makes a good point about conserving code
points.) If there is consensus on making this standard then proceed with how to
implement it. (A lot of the discussion (IMHO) on this topic has been about your
implementation.)

            Paul

>
> > I got silence at diffserv when I asked this. Some people commented
> > afterward to me that they didn't know either. Can someone answer me
> > this?
> > The DSCP to PHB mapping is programmable by the administrator.
>
> > If BE works for Yoram's network as it is now, then some "better"
> > service ought to work as well, right?
>
> If most of the traffic that is BE today will be in this "better" service
> class in the future (being not more expensive than BE), one could use
> BE as future background class. But, this is not the situation today, so
> we may use the LBE PHB to protect the current BE traffic from being
> preempted.
>
> Regards,
>  Roland
> --
> Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
> Institute of Telematics, University of Karlsruhe, F.R. of Germany
> Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
> Phone: +49 721 608-6396 Fax: +49 721 388097
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--
Paul Langille                e-mail: langille@crescentnets.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824



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



From diffserv-admin@ietf.org  Thu Nov 18 12:40:37 1999
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 MAA22994
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 12:40:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA09025;
	Thu, 18 Nov 1999 11:43:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA08910
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 11:42:59 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26914
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 11:43:15 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <XB2W2XCC>; Thu, 18 Nov 1999 08:42:40 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A6073D0951@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: Albert Manfredi <albert.e.manfredi@boeing.com>,
        Bob Quinn
	 <rcq@stardust.com>
Cc: rsvp@ISI.EDU, diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Thu, 18 Nov 1999 08:42:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> My description would be that RSVP is thought by some not to "scale
> well" in very large networks,

RSVP is just a signaling protocol. It is traditionally associated with
Intserv and with per-flow trafic handling mechanisms. The scalability
concerns are really with the per-flow trafic handling mechansism more than
with the signaling per-se. 

  and that therefore diffserv is being
> developed to provide QoS within the network core. RSVP is instead
> used at the edges, 

Let's look at this a little further. What do we mean when we say "RSVP is
used at the edges". RSVP is an end-to-end signaling protocol, so - RSVP
travels through every device on the end-to-end path through the network. The
question is - who listens to RSVP? Typically, we would expect devices to
listen to RSVP if they are serving as ingress points to valuable or
congested regions of the network. An example is the ingress router to a
diffserv network (at the edge). Another example might be a router serving a
WAN connection. The fact that certain devices listen to RSVP does not
necessarily mean that they apply per-flow traffic handling. They may listen
to RSVP in order to apply admission control to aggregate trafic handling. In
this case, we can say that:

RSVP is used end-to-end.
Aggregate traffic handling (a.k.a. diffserv) is used in the core.
Per-flow trafic handling may be applied where it benefits us, but for
scalability reasons would not be applied where there are a large number of
flows.
 
which might include interfaces within diffserv
> routers (after all, core routers are likely to be edge routers as
> well).
> 
> 802.1p is a priority scheme for a Layer 2 LAN environment, so it is
> a different issue from IP QoS. But IP QoS could invoke IEEE 802.1p,
> when appropriate.
> 
> Similarly, ATM might be an alternative to diffserv or to intserv
> over datagram LANs, in that ATM could be used either in the core or
> at the edges, instead of datagram nets like Ethernet or FDDI. So ATM
> has proposals for mapping of RSVP and diffserv QoS into ATM QoS,
> when IP is carried over ATM.
> 

One could imagine a very complex world, in which there are N different link
layer QoS mechanisms and we need to define NxN mappings - from each link
layer to each other link layer. On the other hand, one could imagine a high
layer abstraction for expressing QoS requrieemtns (what Intserv started
doing, and still hasn't been proven wrong at - though there may be room for
one or two additional services). This high layer abstraction can then be
mapped to each different link layer QoS mechansim. That's what the ISSLL
group has done (with 802.1p, ATM, ISSLOW) and continues to do with diffserv.
With this approach, you end up with a much more manageable N mappings (as
opposed to NxN).

> Bert
> manfredi@arl.bna.boeing.com
> 

Check out the recent drafts in the ISSLL WG on a framework for using RSVP
and Intserv over diffserv networks. It clarifies many of the points
discussed in this thread.

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



From diffserv-admin@ietf.org  Thu Nov 18 12:44:46 1999
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 MAA25082
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 12:44:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA08666;
	Thu, 18 Nov 1999 11:36:00 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA08633
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 11:35:56 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23699
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 11:36:11 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprtp1.ntcom.nortel.net; Thu, 18 Nov 1999 11:35:42 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2448.0) 
          id <XA994BM5>; Thu, 18 Nov 1999 10:35:41 -0600
Message-ID: <F908F961B7CDD111BC720000F8073E4301934CEF@crchy271.us.nortel.com>
From: "Anurudha Kulatunge" <anurudha@nortelnetworks.com>
To: "'diffserv@ietf.org'" <diffserv@ietf.org>
Date: Thu, 18 Nov 1999 10:35:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF31E2.F324B102"
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.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF31E2.F324B102
Content-Type: text/plain

confirm 663288

------_=_NextPart_001_01BF31E2.F324B102
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.14">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">confirm 663288</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF31E2.F324B102--

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



From diffserv-admin@ietf.org  Thu Nov 18 13:31:19 1999
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 NAA17675
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 13:31:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11247;
	Thu, 18 Nov 1999 12:38:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA11217
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 12:38:04 -0500 (EST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21997
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 12:38:19 -0500 (EST)
Received: from slb-hub-01.boeing.com ([129.172.13.51])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA18593
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 09:38:14 -0800 (PST)
Received: from [199.191.48.134] by slb-hub-01.boeing.com for diffserv@ietf.org; Thu, 18 Nov 1999 09:38:04 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Thu, 18 Nov 1999 12:37:08 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
Cc: <rsvp@ISI.EDU>, <diffserv@ietf.org>
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Thu, 18 Nov 1999 12:38:00 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMIEJECAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <078292D50C98D2118D090008C7E9C6A6073D0951@STAY.platinum.corp.microsoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Yoram Bernet wrote:

> Albert Manfredi wrote:
> > My description would be that RSVP is thought by some
> not to "scale
> > well" in very large networks,
>
> RSVP is just a signaling protocol. It is traditionally
> associated with
> Intserv and with per-flow trafic handling mechanisms. The
> scalability
> concerns are really with the per-flow trafic handling
> mechansism more than
> with the signaling per-se.
>
>   and that therefore diffserv is being
> > developed to provide QoS within the network core. RSVP
> is instead
> > used at the edges,
>
> Let's look at this a little further. What do we mean when
> we say "RSVP is
> used at the edges". RSVP is an end-to-end signaling
> protocol, so - RSVP
> travels through every device on the end-to-end path
> through the network.

Yes, but it doesn't operate to provide QoS knobs within the diffserv
domain. As was proposed in one of the diffserv drafts at the recent
IETF meeting, it's possible to use RSVP as an admission control
protocol at the diffserv edge. Or other means could be used instead.

> The
> question is - who listens to RSVP? Typically, we would
> expect devices to
> listen to RSVP if they are serving as ingress points to
> valuable or
> congested regions of the network. An example is the
> ingress router to a
> diffserv network (at the edge). Another example might be
> a router serving a
> WAN connection. The fact that certain devices listen to
> RSVP does not
> necessarily mean that they apply per-flow traffic
> handling.

But, to summarize, a diffserv core router does not listen to RSVP.
Not unless we really change the diffserv charter.

> RSVP is used end-to-end.
> Aggregate traffic handling (a.k.a. diffserv)

AND per hop behaviors vs per microflow reservations (the latter
being the RSVP and ATM approach to guaranteeing QoS) are used within
the diffserv core.

Next thing you know, this discussion will be moved to
diffserv-interest.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Thu Nov 18 13:48:39 1999
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 NAA26072
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 13:48:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12555;
	Thu, 18 Nov 1999 13:13:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12521
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 13:13:08 -0500 (EST)
Received: from pilgrim.cisco.com (pilgrim.cisco.com [171.69.204.12])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09727
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 13:13:24 -0500 (EST)
Received: from swallow-pc01 (ch-janeiro-p45.cisco.com [171.69.209.249])
	by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA07837;
	Thu, 18 Nov 1999 13:11:46 -0500 (EST)
Message-Id: <4.1.19991118130102.00a02e20@pilgrim.cisco.com>
X-Sender: swallow@pilgrim.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 18 Nov 1999 13:14:20 -0500
To: "Albert Manfredi" <albert.e.manfredi@boeing.com>,
        "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
From: George Swallow <swallow@cisco.com>
Subject: RE: [Diffserv] RSVP vs DiffServ
Cc: <rsvp@ISI.EDU>, <diffserv@ietf.org>
In-Reply-To: <NDBBIBKKCLEFDFDGHCNMIEJECAAA.albert.e.manfredi@boeing.com>
References: <078292D50C98D2118D090008C7E9C6A6073D0951@STAY.platinum.corp.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Albert -

The overall question here is *not* RSVP vs DiffServ.
The question is where do you use IntServ, where do 
you use DiffServ, and how do you glue it all together.

RSVP has defined a tunnel spec.  In this a number of 
RSVP sessions can be aggregated and tunnelled through
another domain.  One such way of doing this is to use DiffServ
on the aggregated stream.

I fully expect to be using RSVP to set up MPLS tunnels across 
DiffServ domains and then aggregating RSVP IntServ requests
into those tunnels.  

As Yoram pointed out RSVP is a signalling protocol.  When it was 
published, all there was to signal was IntServ.  But the two should 
not be so closely associated.  RSVP will certainly be used to signal
the kinds of DiffServ traffic which is flowing on an MPLS tunnel.
See draft-ietf-mpls-diff-ext-02.txt.

...George



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



From diffserv-admin@ietf.org  Thu Nov 18 13:49:43 1999
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 NAA26613
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 13:49:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12305;
	Thu, 18 Nov 1999 13:08:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12269
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 13:07:46 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07086
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 13:07:58 -0500 (EST)
Received: from ascend.com ([152.148.89.11])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id NAA26429;
	Thu, 18 Nov 1999 13:03:48 -0500 (EST)
Message-ID: <38343EB6.DAB09624@ascend.com>
Date: Thu, 18 Nov 1999 13:00:22 -0500
From: Siamack Ayandeh <sayandeh@ascend.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kathleen Nichols <kmn@cisco.com>
CC: "Li, Renwei" <rli@abatis-sys.com>,
        "'Albert Manfredi'" <albert.e.manfredi@boeing.com>,
        Panos GEVROS <P.Gevros@cs.ucl.ac.uk>, diffserv@ietf.org
Subject: Re: [Diffserv] EF RFC and loss
References: <811670B03A7DD211A2730008C709C20959F362@daystrom.abatissys.com> <38308CDD.5CD8D8A7@cisco.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Kathleen Nichols wrote:

> In fact 2598 does not say "zero queueing delay". There should
> be no average or standing queue in any EF buffer (falls out from
> the definition).

Kathie,

If it is not TDM, then the average "or standing" queue length and hence
delay would be greater than zero.

Regards, Siamack


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



From diffserv-admin@ietf.org  Thu Nov 18 14:01:44 1999
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 OAA02702
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 14:01:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12900;
	Thu, 18 Nov 1999 13:21:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA12867
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 13:21:10 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13482
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 13:21:24 -0500 (EST)
Received: from ascend.com ([152.148.89.11])
	by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id NAA02730;
	Thu, 18 Nov 1999 13:19:59 -0500 (EST)
Message-ID: <38344280.59D32139@ascend.com>
Date: Thu, 18 Nov 1999 13:16:32 -0500
From: Siamack Ayandeh <sayandeh@ascend.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Omar Elloumi <Omar.Elloumi@alcatel.be>
CC: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: Re: [Diffserv] EF RFC and loss
References: <38301BAB.8051BA38@alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Omar Elloumi wrote:

> Hello,
>
> I went through the emails on EF and losses but I'm still
> confused. The original question was do we need absolute zero
> loss in EF or not?
> Some of you responded no (few losses are tolerated),
> in that case how can we distinguish packet losses due
> to possible attacks from tolerated losses??? do we
> need to have a threshold above it we trigger an alarm
> to check a possible attack?
>
> My intention is NOT to trigger a new discussion but just
> to have in few lines a definitive (formal if possible) answer to this.
>

Omar,

There can be no formal answer to a rather informal notion.
Let's put loss in perspective.  What do you mean by zero loss?

1. Bit error rate on an OC-48 fiber interface gives you 1-bit error
every 6 minutes or so.

2. With a probability between 10E-17 & 10E-18 the same
fiber may be cut with a back hoe.

If you do some back of envelope calculations the probability
of buffer overflow, for reasonable size buffers, and independent
sources is smaller than 1 & 2.

Since reasonable size buffers, as of rfc 2598, seem to work, the
question of delay is also a non issue.

Regards, Siamack



> kind regards.
>
> --
> ____________________________________________________________
> Omar Elloumi
>
> Alcatel Research - Network Architecture - Traffic Technology
>
> Francis Wellesplein 1, 2018 Antwerp, Belgium
>
> Phone: + 32 3 240 78 33
> Fax:   + 32 3 240 99 32
> http://www.alcatel.com/crc/
> ____________________________________________________________
>
> Opinions expressed are those of the sender and do not reflect Alcatel
> policy or agreement
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Thu Nov 18 16:45:15 1999
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 QAA21468
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 16:45:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA19712;
	Thu, 18 Nov 1999 15:46:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA19682
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 15:45:59 -0500 (EST)
Received: from cnri.reston.va.us (cnri.reston.va.us [132.151.1.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23514
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 15:46:18 -0500 (EST)
Received: from action-nt.cnri.reston.va.us (action-nt [132.151.1.91])
	by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id PAA10775
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 15:45:59 -0500 (EST)
Date: Thu, 18 Nov 1999 15:48:43 -0500 (Eastern Standard Time)
From: Stanley Weilnau <sweilnau@cnri.reston.va.us>
To: diffserv@ietf.org
Message-ID: <Pine.WNT.4.05.9911181539420.445-100000@action-nt.cnri.reston.va.us>
X-X-Sender: sweilnau@kaluha.cnri.reston.va.us
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Diffserv] Diffserv subscriber information
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org


Diffserv is a mailing list that is supported by 
mailman (http://www.list.org).  

All of the user interaction with the list can be done with a web browser.

Visit http://www.ietf.org/mailman/listinfo/diffserv and go to the bottom
of the page.  Enter your email address in the last box under the sentence
that states "To change your subscribtion..." and click on "Edit Options".
On this page, you can unsubscribe or change options for your subscription
to the list.  You will need your password to make changes.   If you do not
have your list password, then under "Your diffserv Password", click "Email
my Password to Me".  

You can also send a message to diffserv-request@ietf.org.  Put help in the
body of the message to get the commands available via email.



Stanley Weilnau




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



From diffserv-admin@ietf.org  Thu Nov 18 17:38:34 1999
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 RAA17077
	for <diffserv-archive@ietf.org>; Thu, 18 Nov 1999 17:38:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA23092;
	Thu, 18 Nov 1999 16:56:06 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA23063
	for <diffserv@optimus.ietf.org>; Thu, 18 Nov 1999 16:56:02 -0500 (EST)
Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26983
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 16:56:20 -0500 (EST)
Received: from shultz.argon.com by wodc7mr0.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: shultz.argon.com [208.234.161.2])
	id QQhpxn20927
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 21:56:44 GMT
Received: from hochstetter (hochstetter.argon.com [208.234.161.53])
	by shultz.argon.com (8.8.6/8.8.6) with SMTP id QAA14081
	for <diffserv@ietf.org>; Thu, 18 Nov 1999 16:56:15 -0500 (EST)
Message-Id: <3.0.3.32.19991118165823.009bb430@shultz.argon.com>
X-Sender: kasten@shultz.argon.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Thu, 18 Nov 1999 16:58:23 -0500
To: diffserv@ietf.org
From: Frank Kastenholz <kasten@argon.com>
Subject: Re: [Diffserv] LBE using RFC 2474 
In-Reply-To: <199911180945.KAA26322@blackfoot.telematik.informatik.uni-k
 arlsruhe.de>
References: <Your message of "Thu, 11 Nov 1999 17:15:20 EST."             <199911112224.RAA00516@pzero.sandelman.ottawa.on.ca>
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.ietf.org>
X-BeenThere: diffserv@ietf.org




Isn't this just "RED with Penalty Box"?




>>   Again, I do not understand why the problem expressed by Yoram is not
>> solveable by distinguishing between "DSCP == 0" and "BE"
>
>The main idea behind LBE is the following:
>1.) currently the main portion of traffic is assigned to the default PHB 
>    which corresponds to BE at the moment -> whatever resources are left
>    after all other BAs have been served are given to BE packets.
>2.) you have one or more traffic sources which are non-responsive
>    and which usually would be mapped into the BE aggregate. In order
>    to avoid unfairness against existing flows in the BE aggregate
>    you want to limit the amount of additional traffic in case of 
>    congestion.
>    Therefore you push the non-responsive traffic sources in the 
>    "background" by limiting their BA (maximum share). However, there is 
>    also a no starvation guarantee for LBE packets (minimum share).
>3.) if there is no congestion, packets in the LBE BA may also use
>    unused bandwidth of any other BA.


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



From diffserv-admin@ietf.org  Fri Nov 19 05:40:38 1999
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 FAA09171
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 05:40:33 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA21809;
	Fri, 19 Nov 1999 04:45:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA21781
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 04:45:46 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14479
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 04:46:01 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11okcB-0003R9-00; Fri, 19 Nov 1999 10:45:59 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id KAA07640;
	Fri, 19 Nov 1999 10:45:58 +0100 (MET)
Message-Id: <199911190945.KAA07640@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Juha Heinanen <jh@lohi.eng.telia.fi>
cc: Klaus Wehrle <wehrle@telematik.informatik.uni-karlsruhe.de>,
        Brian E Carpenter <brian@hursley.ibm.com>, diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Wed, 17 Nov 1999 02:08:05 +0200."
             <14385.61925.749789.816139@rautu.eng.telia.fi> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Fri, 19 Nov 1999 10:43:25 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

> no isp will blindly map code points.  if my isp neighbor tells me that
> in the packets that they send to me, prec 1 means background SERVICE,
> then i map prec 1 at the boundary to whatever i use for background in my
> network.  new phbs should not be defined just in order to standardize
> code point for SERVICES.  write a background service spec instead.

A service is something with "end-to-end" semantics whereas a PHB
describes a forwarding treatment applied at a differentiated
services-compliant node to a behavior aggregate. The latter applies
exactly to our LBE motivation and definition and we do not specify a
particular behavior for more than one hop. It is clear that a background
service may be constructed by using the defined LBE behavior which may
be realized by using other PHBs as a basis, but this is also true for EF
or AF with respect to class selector compliant PHBs. I suppose that most
confusion about the LBE PHB is caused by its name and everybody using
another interpretation of its supposed meaning. However, its name also
expresses its relation to the BE aggregate and that was the main
intention behind the name.

Roland



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



From diffserv-admin@ietf.org  Fri Nov 19 05:41:12 1999
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 FAA09468
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 05:41:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA21605;
	Fri, 19 Nov 1999 04:38:53 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA21576
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 04:38:41 -0500 (EST)
Received: from condor.uom.ac.mu (condor.uom.ac.mu [202.60.7.52])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11249
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 04:38:43 -0500 (EST)
Received: from sgoorahpc01 ([202.60.7.159]) by condor.uom.ac.mu
          (Post.Office MTA v3.5.3 release 223 ID# 0-60726U1000L100S0V35)
          with SMTP id mu; Fri, 19 Nov 1999 13:42:07 +0400
Message-ID: <38351FB9.AC3@uom.ac.mu>
Date: Fri, 19 Nov 1999 14:00:25 +0400
From: sgoorah@uom.ac.mu (Goorah Shravan)
Reply-To: sgoorah@uom.ac.mu
Organization: University of Mauritius
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: Albert Manfredi <albert.e.manfredi@boeing.com>
CC: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>, rsvp@ISI.EDU,
        diffserv@ietf.org
Subject: Re: [Diffserv] RSVP vs DiffServ
References: <NDBBIBKKCLEFDFDGHCNMIEJECAAA.albert.e.manfredi@boeing.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

	at least this is a topic of discussion which I am interested in

> > > My description would be that RSVP is thought by some
> > not to "scale
> > > well" in very large networks,

	It would clarify things if you could explain "scalability with respect
to what?"

> > Let's look at this a little further. What do we mean when
> > we say "RSVP is
> > used at the edges". RSVP is an end-to-end signaling
> > protocol, so - RSVP
> > travels through every device on the end-to-end path
> > through the network.
> 
> Yes, but it doesn't operate to provide QoS knobs within the diffserv
> domain. As was proposed in one of the diffserv drafts at the recent
> IETF meeting, it's possible to use RSVP as an admission control
> protocol at the diffserv edge. Or other means could be used instead.

RSVP can be used to provide end-to-end admission control.

With reference to 

	Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., Speer M., Braden
R., Davie B., "Integrated Services Operation Over Diffserv Networks",
Internet Draft, June 1999

Diffserv is being considered as a NETWORK ELEMENT along the end-to-end
path. So at  least the ingress/egress points should be RSVP-aware -
isn't?


> But, to summarize, a diffserv core router does not listen to RSVP.
> Not unless we really change the diffserv charter.
> 

This is interesting but I tend to agree with Yoram on that it depends on
what RSVP signaling does to "network elements" or RSVP-aware devices and
whether Diffserv should be RSVP-aware or not. 
	Do you have some proposals on how to change it?

		Per-Flow set-up of Path/Resv state is one task that can be done using
RSVP. RSVP could be modified in such a way so as NOT to install per-flow
state or to have no state at all in Diffserv

	Your views?

Best Regards,
Shravan Goorah
-- 
Shravan Goorah
Lecturer, Department of Computer Science,
Faculty of Engineering, University of Mauritius
Tel. 454 1041 		Fax.  465 71 44

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



From diffserv-admin@ietf.org  Fri Nov 19 06:34:32 1999
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 GAA06090
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 06:34:32 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA23064;
	Fri, 19 Nov 1999 05:44:19 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA23034
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 05:44:14 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11179
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 05:44:31 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11olWo-00062c-00; Fri, 19 Nov 1999 11:44:30 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id LAA08365;
	Fri, 19 Nov 1999 11:44:29 +0100 (MET)
Message-Id: <199911191044.LAA08365@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Paul Langille <langille@crescentnets.com>
cc: Michael Richardson <mcr@sandelman.ottawa.on.ca>, diffserv@ietf.org,
        "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Thu, 18 Nov 1999 09:53:56 EST."
             <38341304.C4F911E1@crescentnets.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Date: Fri, 19 Nov 1999 11:42:00 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

> Roland, when I have talked about this issue I tend to approach it from a 'higher
> layer'. I like the statement in your draft "Thus, it constitutes the network
> equivalent to a background priority for processes in an operating system." In
> broad terms one should not map default 'stuff' to the lowest priority. There may
> be something (i.e. batch jobs) that one would like to run at a lower priority than
> what everyone is using for the default priority. (This was the basic approach used
> in 802.1P.) In my humble opinion, discussing this concept in terms of "BE" is

Good point.

> confusing. (Thinking out loud...I wonder if the current concept of BE needs to be
> enhanced/modified to support LBE.)

I suppose that LBE PHB and default PHB maybe form a PHB group together,
because they share a common constraint. 

> So if I could be so bold as to summarize the issue. It IS possible to create this
> behavior by mapping to AF. (Pause - Anyone disagree?) Your point is that it needs

Not only mapping, but also using appropriate parameters for AF 
derived from the LBE spec. Note that realization of the EF PHB is also
possible by using a CSC PHB if the constraints imposed by the EF spec
are met by this particular CSC PHB implementation.

> to be standardized so that each provider will offer the same behavior. It might

Right.

> help to ask if people agree with the basic model you are proposing. (OK, I'm
> asking!) If yes, do you like it enough to standardize it? (It may not be easy to
> obtain consensus for this question. Brian makes a good point about conserving code
> points.) If there is consensus on making this standard then proceed with how to
> implement it. (A lot of the discussion (IMHO) on this topic has been about your
> implementation.)

This draft was a first attempt to specify the requirements we had for
our particular problem with re-marking multicast flows (see also
draft-bless-diffserv-multicast-00), but as mentioned by the examples in
the draft, there are more useful applications of it, which were also
confirmed at the meeting. Naturally, a future version will highly benefit 
from additional input or requirements.

We do not want an LBE PHB specification with unnecessary restriction for
its implementation. Therefore, as long as the requirements of the LBE spec
are met you can use various mechanisms to realize the LBE PHB (one was
using an AF PHB as basis).

Regards,
 Roland

-- 
Roland Bless -- e-Mail: bless@telematik.informatik.uni-karlsruhe.de
Institute of Telematics, University of Karlsruhe, F.R. of Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Engesserstr.2 (Bld. 20.50), 1st floor
Phone: +49 721 608-6396 Fax: +49 721 388097



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



From diffserv-admin@ietf.org  Fri Nov 19 06:41:20 1999
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 GAA09391
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 06:41:20 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA23302;
	Fri, 19 Nov 1999 05:54:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA23267
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 05:54:33 -0500 (EST)
Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16245
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 05:54:48 -0500 (EST)
Received: from blackfoot.telematik.informatik.uni-karlsruhe.de (blackfoot.telematik.informatik.uni-karlsruhe.de [129.13.35.14])
	by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.02 #2)
	id 11olgn-0006Qz-00; Fri, 19 Nov 1999 11:54:49 +0100
Received: from i70pop0 (bless@tpce10.telematik.informatik.uni-karlsruhe.de [129.13.41.110])
	by blackfoot.telematik.informatik.uni-karlsruhe.de (8.9.3/8.9.3) with ESMTP id LAA08493;
	Fri, 19 Nov 1999 11:54:49 +0100 (MET)
Message-Id: <199911191054.LAA08493@blackfoot.telematik.informatik.uni-karlsruhe.de>
X-Mailer: exmh version 2.0.2 2/24/98
To: Frank Kastenholz <kasten@argon.com>
cc: diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474 
In-reply-to: Your message of "Thu, 18 Nov 1999 16:58:23 EST."
             <3.0.3.32.19991118165823.009bb430@shultz.argon.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Nov 1999 11:52:20 +0100
From: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> Isn't this just "RED with Penalty Box"?

Whatever you mean by "RED with Penalty Box", RED could be used very well
for implementing the LBE PHB as already mentioned in the draft in
section 2.3.

> >>   Again, I do not understand why the problem expressed by Yoram is not
> >> solveable by distinguishing between "DSCP == 0" and "BE"
> >
> >The main idea behind LBE is the following:
> >1.) currently the main portion of traffic is assigned to the default PHB 
> >    which corresponds to BE at the moment -> whatever resources are left
> >    after all other BAs have been served are given to BE packets.
> >2.) you have one or more traffic sources which are non-responsive
> >    and which usually would be mapped into the BE aggregate. In order
> >    to avoid unfairness against existing flows in the BE aggregate
> >    you want to limit the amount of additional traffic in case of 
> >    congestion.
> >    Therefore you push the non-responsive traffic sources in the 
> >    "background" by limiting their BA (maximum share). However, there is 
> >    also a no starvation guarantee for LBE packets (minimum share).
> >3.) if there is no congestion, packets in the LBE BA may also use
> >    unused bandwidth of any other BA.

Roland




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



From diffserv-admin@ietf.org  Fri Nov 19 09:59:30 1999
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 JAA12180
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 09:59:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA26080;
	Fri, 19 Nov 1999 08:23:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA26050
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 08:23:13 -0500 (EST)
Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27818
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 08:22:53 -0500 (EST)
Received: from kelts.ibr.cs.tu-bs.de (IDENT:root@kelts [134.169.34.131])
	by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA28305
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 14:22:53 +0100 (MET)
Received: (from dieder@localhost)
	by kelts.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA12251;
	Fri, 19 Nov 1999 14:22:53 +0100
Date: Fri, 19 Nov 1999 14:22:53 +0100
Message-Id: <199911191322.OAA12251@kelts.ibr.cs.tu-bs.de>
X-Authentication-Warning: kelts.ibr.cs.tu-bs.de: dieder set sender to dieder@kelts.ibr.cs.tu-bs.de using -f
From: Joerg Diederich <dieder@ibr.cs.tu-bs.de>
To: diffserv@ietf.org
In-reply-to: <14385.45472.997856.781792@rautu.eng.telia.fi> (message from Juha
	Heinanen on Tue, 16 Nov 1999 21:33:52 +0200 (EET))
Subject: Re: [Diffserv] EF with Drop ?
References: <3828F51F.25484DF8.diff-serv@dnrc.bell-labs.com>
	<yj84seurs7n.fsf@kelts.ibr.cs.tu-bs.de> <14385.45472.997856.781792@rautu.eng.telia.fi>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Juha Heinanen writes:

Juha> Joerg Diederich writes:
>> In my eyes, you _can_ apply the same traffic conditioning actions
>> to packets marked for an AF class as to packets marked for EF so
>> that you model EF using AF. In this way, you simply do not need the
>> buffer management from AF since almost no queues arise. And if you
>> do so, you get 'EF with two drop precedences' so that you do not
>> need EFD anymore.

Juha> you can implement a behavior that is atleast close to ef by
Juha> using an af queue with a large weight (in order to guarantee low

I agree. As you said, you are _implementing_ the externally observable
forwarding treatment, the EF RFC describes, with the same _mechanisms_
you implement the AF PHB by tuning the parameter of the concrete AF
implementation (e.g., WFQ).

Thus, IMO the distinction between the AF PHB and the EF PHB in
separate RFCs is necessary as it is done now, no matter how you
_implement_ both.

Juha> delay) and by policing traffic at the ingress so that only green
Juha> packets are allowed to the network.

I thought that using traffic policing at the ingress does not belong
to a per-hop behavior but to the construction of a service? Is it
possible that here services and PHBs got confused (your sentence
sounds to me more like 'you can construct a service that is at least
close to Premium service by using the AF PHB, implemented with WFQ
with a large weight, and by policing traffic...')?  (I really don't
like to be so 'stubborn' on terminology issues and wording, but I
think this is the main point why we do not agree whether there is a
need for an EFD PHB or not. See my comments below.)

Juha> implementing an ef like behavior with drop is a bit more
Juha> complicated though, since i don't want the yellow packets to get
Juha> all the bandwidth that would be granted to them because of the
Juha> large weight of the af queue.  so what is needed in this case is
Juha> red that starts to kick in not when the queue size exceeds a
Juha> threshold (which it never does), but when the arrival rate of
Juha> packets to that queue exceed a threshold.  for example, if i
Juha> want the "low delay with drop" packets not to consume more than
Juha> 20 mbps of a link's capacity, i would start dropping yellow
Juha> packets when the arrival rate of the packets exceeds 10 mbps.

Following my comments above, I agree that it may be possible to
_implement_ the EFD PHB using the same means of implementing AF
classes with special set of parameters, such as you propose. However,
the externally observable forwarding treatment is in my opinion
substantially different from the one described in the AF
RFC. Therefore, I think it is valueable to have the EFD PHB described
in a separate document.

Furthermore, as you said, it may be complicated to implement the EFD
PHB using AF queues (I cannot jugde this since I do not have that much
implementation experience with AF as you have). I have not implemented
the EFD PHB yet, but I think that there is a good chance that the
implementation I have in mind is less complicated. However, this is
speculation and a discussion about it must be delayed until I have
first results to present on simulation / implementation experience.
Also, a discussion of how to implement certain PHBs may be outside the
scope of this working group(?).

>> I assume that there already was some discussion on this point but I
>> don't know, since I haven't been in the DiffServ working group from
>> the beginning.

Juha> there was discussion about this, but to me it was more important
Juha> to get af done than to spend my time fighting against ef.

I guess, most of us suffer from having too many problems to solve and
too less time to spend :-) Thanks for the information.

>> Thus, the EFD draft assumes that EF should be used to build a
>> low-delay service such as Premium service and we want to build a
>> service with _exactly_ the same delay characteristics as Premium
>> service using EF but allowing dropping. I do not think that you can
>> achieve the delay requirement by using AF for BELD traffic and EF
>> for Premium service simultaneously.

Juha> the customers don't care about af or ef.  they care about
Juha> services and it is my business which phbs i use to implement
Juha> them.  the phbs used in my network to implement a service don't
Juha> need to be the same that the next network is using.

Jep. The customers do not care about DS at all, they would be
perfectly satisfied with IntServ, DiffServ or whatsoever, if it
provides the service they want. 

But, ISPs using DS may care about PHBs. They are in my view the ones
for which the PHB standardization is targeted. For the development of
DiffServ, it is very useful to have several DS nodes from different
vendors which can interoperate within an ISP's domain using the
standardized PHBs (not necessarily the same DSCPs, since the mapping
DSCP - PHB will be configurable on each DS node). Each vendor may use
different implementations of the standardized PHBs and the market will
decide which vendor did the implementation job best.

Otherwise, (if you look at a DS domain with nodes from a single vendor
only), you do not need to standardize PHBs at all since the
construction of domain-wide services from PHBs and TC is a purely DS
domain local matter and the concatenation of DS domains is done on the
service level (although standardized PHBs (and DSCPs) avoid re-marking
at domain boundaries and may be useful in this case as well since they
make the implementation of DS boundary nodes easier).

>>  I agree with you, but since we assume that EF is used (or should
>> be used) to built low-delay services which rely on avoidance of
>> congestion by traffic conditioning (see above), AF seems to be not
>> the right way to implement a low-delay service which allows
>> dropping but does not allow congestion.

Juha> see above for an implementation that uses an af class with red
Juha> and results in a low delay service with drop.  is there
Juha> something wrong with it?  what else you would need?

As I said, your proposal for the mechanisms to _implement_ the EFD PHB
may be ok for constructing BELD service. However, there may be other
implementations but I cannot judge if they are better, easier to
maintain, better to implement, faster etc. 


To summarize my argumentation: my main point is that I do not think
that the description of the externally observable forwarding
treatment, as described in the EFD draft, is covered by the AF RFC (as
I said in my last email, they differ fundamentally in their concepts:
EF/EFD tries to avoid congestion using traffic conditioning means
while AF tries to deal gracefully with congestion using active buffer
management). Therefore, I think there is a need to describe EFD
separately.


/J"org
----
J"org Diederich
Institute of Operating Systems and Computer Networks, 
Technical University Braunschweig, Germany
Email: dieder@ibr.cs.tu-bs.de

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



From diffserv-admin@ietf.org  Fri Nov 19 13:01:24 1999
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 NAA28607
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 13:01:24 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA03956;
	Fri, 19 Nov 1999 11:57:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA03927
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 11:57:21 -0500 (EST)
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01078
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 11:57:36 -0500 (EST)
Received: from localhost (vjosyula@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with SMTP id LAA18777;
	Fri, 19 Nov 1999 11:57:06 -0500 (EST)
Date: Fri, 19 Nov 1999 11:57:05 -0500 (EST)
From: Venumadhav Josyula <vjosyula@osf1.gmu.edu>
To: Goorah Shravan <sgoorah@uom.ac.mu>
cc: Albert Manfredi <albert.e.manfredi@boeing.com>,
        "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>,
        rsvp@ISI.EDU, diffserv@ietf.org
Subject: Re: [Diffserv] RSVP vs DiffServ
In-Reply-To: <38351FB9.AC3@uom.ac.mu>
Message-ID: <Pine.OSF.3.96.991119115433.14274A-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hello shravan,

how can rsvp modified to have no state at all. Secondly is'nt the
extensions to RSVP useful in diffserv. But extension to rsvp does deal
with per flow but it deals with per aggregate flow is it not

thanks 
bye
venu

On Fri, 19 Nov
1999, Goorah Shravan wrote:

> Hi,
> 
> 	at least this is a topic of discussion which I am interested in
> 
> > > > My description would be that RSVP is thought by some
> > > not to "scale
> > > > well" in very large networks,
> 
> 	It would clarify things if you could explain "scalability with respect
> to what?"
> 
> > > Let's look at this a little further. What do we mean when
> > > we say "RSVP is
> > > used at the edges". RSVP is an end-to-end signaling
> > > protocol, so - RSVP
> > > travels through every device on the end-to-end path
> > > through the network.
> > 
> > Yes, but it doesn't operate to provide QoS knobs within the diffserv
> > domain. As was proposed in one of the diffserv drafts at the recent
> > IETF meeting, it's possible to use RSVP as an admission control
> > protocol at the diffserv edge. Or other means could be used instead.
> 
> RSVP can be used to provide end-to-end admission control.
> 
> With reference to 
> 
> 	Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., Speer M., Braden
> R., Davie B., "Integrated Services Operation Over Diffserv Networks",
> Internet Draft, June 1999
> 
> Diffserv is being considered as a NETWORK ELEMENT along the end-to-end
> path. So at  least the ingress/egress points should be RSVP-aware -
> isn't?
> 
> 
> > But, to summarize, a diffserv core router does not listen to RSVP.
> > Not unless we really change the diffserv charter.
> > 
> 
> This is interesting but I tend to agree with Yoram on that it depends on
> what RSVP signaling does to "network elements" or RSVP-aware devices and
> whether Diffserv should be RSVP-aware or not. 
> 	Do you have some proposals on how to change it?
> 
> 		Per-Flow set-up of Path/Resv state is one task that can be done using
> RSVP. RSVP could be modified in such a way so as NOT to install per-flow
> state or to have no state at all in Diffserv
> 
> 	Your views?
> 
> Best Regards,
> Shravan Goorah
> -- 
> Shravan Goorah
> Lecturer, Department of Computer Science,
> Faculty of Engineering, University of Mauritius
> Tel. 454 1041 		Fax.  465 71 44
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 








!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Josyula Venumadhav

Residnce:					Office:
4303 Apt#L, Ramona Drive			Department of Electrical
Fairfax, Virginia-22030				Engg
						
Phone:
Residence: (703)-359-5419			Office:    (703)-993-1566
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 


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



From diffserv-admin@ietf.org  Fri Nov 19 14:26:08 1999
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 OAA07009
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 14:26:08 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07282;
	Fri, 19 Nov 1999 13:36:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07245
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 13:36:04 -0500 (EST)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15039
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 13:36:20 -0500 (EST)
Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id TAA08973; Fri, 19 Nov 1999 19:35:55 +0100 (MET)
Message-Id: <199911191835.TAA08973@malmo.trab.se>
From: "Istvan Cselenyi" <Istvan.I.Cselenyi@telia.se>
To: sgoorah@uom.ac.mu (Goorah Shravan)
Date: Fri, 19 Nov 1999 19:36:02 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [Diffserv] RSVP vs DiffServ
Reply-to: Istvan.I.Cselenyi@telia.se
CC: Yoram Bernet <yoramb@exchange.microsoft.com>,
        Albert Manfredi <albert.e.manfredi@boeing.com>, rsvp@ISI.EDU,
        diffserv@ietf.org
Priority: normal
In-reply-to: <38351FB9.AC3@uom.ac.mu>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Content-Transfer-Encoding: 7BIT
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7BIT

Goorah,

> 	at least this is a topic of discussion which I am interested in

me too - just before we are moved to diffserv-interest...

> > > > My description would be that RSVP is thought by some
> > > not to "scale
> > > > well" in very large networks,
> 
> 	It would clarify things if you could explain "scalability with respect
> to what?"

I hope you can find an answer to this in our study about scalability of 
QoS signaling as of today:

http://soha.ttt.bme.hu/boomerang/public/decides.zip

BR
Istvan Cselenyi




--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: Istvan.I.Cselenyi@telia.se
--------------------------------------------------

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



From diffserv-admin@ietf.org  Fri Nov 19 14:30:23 1999
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 OAA09131
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 14:30:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07835;
	Fri, 19 Nov 1999 13:51:49 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA07803
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 13:51:45 -0500 (EST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21765
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 13:52:02 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Nov 19 13:51:57 EST 1999
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13291;
	Fri, 19 Nov 1999 13:51:53 -0500 (EST)
Message-ID: <38359CBF.40B123B1@dnrc.bell-labs.com>
Date: Fri, 19 Nov 1999 10:53:51 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474
References: <199911121414.JAA00543@pzero.sandelman.ottawa.on.ca>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Michael Richardson wrote:
> 
> >>>>> "Grenville" == Grenville Armitage <gja@dnrc.bell-labs.com> writes:
>     Grenville> I also dont believe LBE is necessary. What is necessary is to
>     Grenville> have those apps and customers who really desire an APG service
>     Grenville> be remarked to a DSCP that will given it to them (whether a Class
>     Grenville> Selector or AF codepoint). Leave BE as it has always been. Voila,
>     Grenville> we have two levels of service as desired.
> 
>   The problem is that this requires coordination for all user's of service
> "X" that wanted APG, and with 200-300 distinct applications, it may not be
> clear which services are most important. So, to do this right, you need
> flag-days (maybe flag-months).

Since we're talking about a transition plan here, how about an
MF classification that wild-cards almost everything to APG, except
for the few 'new' apps that require 'background' service?

cheers,
gja

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



From diffserv-admin@ietf.org  Fri Nov 19 14:36:44 1999
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 OAA12032
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 14:36:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA08472;
	Fri, 19 Nov 1999 14:03:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA08439
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 14:03:31 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26727
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 14:03:49 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <XB2WJDXV>; Fri, 19 Nov 1999 11:03:19 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A6073D0E06@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: sgoorah@uom.ac.mu, Albert Manfredi <albert.e.manfredi@boeing.com>
Cc: rsvp@ISI.EDU, diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Fri, 19 Nov 1999 11:03:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

comments below...

> -----Original Message-----
> From: sgoorah@uom.ac.mu [mailto:sgoorah@uom.ac.mu]
> Sent: Friday, November 19, 1999 2:00 AM
> To: Albert Manfredi
> Cc: Yoram Bernet (Exchange); rsvp@ISI.EDU; diffserv@ietf.org
> Subject: Re: [Diffserv] RSVP vs DiffServ
> 
> RSVP can be used to provide end-to-end admission control.
> 
> With reference to 
> 
> 	Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., 
> Speer M., Braden
> R., Davie B., "Integrated Services Operation Over Diffserv Networks",
> Internet Draft, June 1999
> 
> Diffserv is being considered as a NETWORK ELEMENT along the end-to-end
> path. So at  least the ingress/egress points should be RSVP-aware -
> isn't?
> 

Indeed. A diffserv network, through provisioning of some sort, is presumed
to be able to offer an SLA at its ingress points. The provider's ingress
router and the customer's egress router both know this SLA. Thus either (or
both) could use RSVP to admit or deny requests for admission to one of the
service classes offered by the SLA.

> 
> > But, to summarize, a diffserv core router does not listen to RSVP.
> > Not unless we really change the diffserv charter.
> > 
> 

The diffserv charter says nothing about precluding routers in the diffserv
network from listening to signaling. There are many ideas about how to
configure the routers in the diffserv core to be able to offer the SLAs at
the edges. Different provisioning options will enable the core of the
diffserv network to be more or less efficient in its use of resources (or to
br able to offer higher or lower quality services). If the core of the
diffserv network is going to offer high quality (e.g. telephony) service
*and* is not going to be highly over-provisioned, then - chances are that
some kind of signaling will have to be applied to provisioning the core. One
option is the magical and mystical bandwidth broker. Another is aggregate
RSVP, of the form defined by Fred Baker and Carol Ituralde in thir draft in
the ISSLL WG. Yet another is per-flow RSVP. I expect that certain diffserv
providers will configure certain key nodes in the core of the network to
listen to some kind of signaling. That signaling is going to talk about
resource requirements. It's probably gonna look an awful lot like RSVP. 

> This is interesting but I tend to agree with Yoram on that it 
> depends on
> what RSVP signaling does to "network elements" or RSVP-aware 
> devices and
> whether Diffserv should be RSVP-aware or not. 
> 	Do you have some proposals on how to change it?
> 
> 		Per-Flow set-up of Path/Resv state is one task 
> that can be done using
> RSVP. RSVP could be modified in such a way so as NOT to 
> install per-flow
> state or to have no state at all in Diffserv

RSVP per-flow signaling state is not the scalability problem. The
scalability problem is relaed to the per-flow *traffic handling* state that
is typically asociated with RSVP. RSVP, per-se does not mandate any
particular form of traffic handling. Difserv, being an aggregate form of
traffic handling works nicely *with* RSVP to support scalable QoS in large
networks.
> 
> 	Your views?
> 
> Best Regards,
> Shravan Goorah
> -- 
> Shravan Goorah
> Lecturer, Department of Computer Science,
> Faculty of Engineering, University of Mauritius
> Tel. 454 1041 		Fax.  465 71 44
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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



From diffserv-admin@ietf.org  Fri Nov 19 14:51:50 1999
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 OAA19265
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 14:51:49 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA08939;
	Fri, 19 Nov 1999 14:16:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA08905
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 14:16:46 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02475
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 14:17:03 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <XB2WJD98>; Fri, 19 Nov 1999 11:16:35 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A6073D0E1B@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: Istvan.I.Cselenyi@telia.se, sgoorah@uom.ac.mu
Cc: Albert Manfredi <albert.e.manfredi@boeing.com>, rsvp@ISI.EDU,
        diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Fri, 19 Nov 1999 11:16:30 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Hmmm. Istvan - from our discussions at the IETF, it is not clear to me what
fraction of processing overhead you atrribute to *signaling* vs. to
*traffic-handling*. In fact, it seemed to me that the traffic handling
burden is far heavier than the signaling burden. Traditionally, RSVP
triggers per-flow traffic handling. WFQ is commonly used for this. From my
experience, the policing and queuing that ar required for per-flow traffic
handling render the signaling overhead negligible. 

Thus, I would claim that your study is about the scalability of "RSVP
signaling *with* per-flow traffic handling", as opposed to "RSVP signaling".
The distinction is important because, diffserv, as an aggregate form of
traffic handling can be used with per-flow signaling to yield a very
scalable QoS architecture.

I would be interested in seeing the following stats:

Assume a 1 Mbps flow, signaled by RSVP (one signaling message very 30
seconds):
How much processing power per-second is expended on handling RSVP signaling
in the router?
How much processing power per-second is expended on trafic handling the 1
Mbps data flow?

Of course, processing power can be expressed in some normalized, unitless
sense. It's the ratio that is interesting.

Yoram 

> -----Original Message-----
> From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se]
> Sent: Friday, November 19, 1999 10:36 AM
> To: sgoorah@uom.ac.mu
> Cc: Yoram Bernet (Exchange); Albert Manfredi; rsvp@ISI.EDU;
> diffserv@ietf.org
> Subject: Re: [Diffserv] RSVP vs DiffServ
> 
> 
> Goorah,
> 
> > 	at least this is a topic of discussion which I am interested in
> 
> me too - just before we are moved to diffserv-interest...
> 
> > > > > My description would be that RSVP is thought by some
> > > > not to "scale
> > > > > well" in very large networks,
> > 
> > 	It would clarify things if you could explain 
> "scalability with respect
> > to what?"
> 
> I hope you can find an answer to this in our study about 
> scalability of 
> QoS signaling as of today:
> 
http://soha.ttt.bme.hu/boomerang/public/decides.zip

BR
Istvan Cselenyi




--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: Istvan.I.Cselenyi@telia.se
--------------------------------------------------

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



From diffserv-admin@ietf.org  Fri Nov 19 15:35:19 1999
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 PAA08096
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 15:35:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA10719;
	Fri, 19 Nov 1999 15:00:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA10688
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 15:00:51 -0500 (EST)
Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23546
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 15:01:08 -0500 (EST)
Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2650.21)
	id <WRNX5WKH>; Fri, 19 Nov 1999 12:00:37 -0800
Message-ID: <D0805D3B448BD211A7990008C7B181300257B916@ftp.extremenetworks.com>
From: Andrew Smith <andrew@extremenetworks.com>
To: "'Yoram Bernet (Exchange)'" <yoramb@Exchange.Microsoft.com>
Cc: rsvp@ISI.EDU, diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Fri, 19 Nov 1999 12:00:29 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

And of course another interesting question is: 

"How much electrical power (as in how many transitions of how many
flip-flops in router ASIC silicon) is expended on traffic handling the 1
Mbps data flow?"

:-)

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
****************************************************************


> -----Original Message-----
> From: Yoram Bernet (Exchange) [mailto:yoramb@Exchange.Microsoft.com]
> Sent: Friday, November 19, 1999 11:17 AM
> To: Istvan.I.Cselenyi@telia.se; sgoorah@uom.ac.mu
> Cc: Albert Manfredi; rsvp@ISI.EDU; diffserv@ietf.org
> Subject: RE: [Diffserv] RSVP vs DiffServ
> 
> 
> Hmmm. Istvan - from our discussions at the IETF, it is not 
> clear to me what
> fraction of processing overhead you atrribute to *signaling* vs. to
> *traffic-handling*. In fact, it seemed to me that the traffic handling
> burden is far heavier than the signaling burden. Traditionally, RSVP
> triggers per-flow traffic handling. WFQ is commonly used for 
> this. From my
> experience, the policing and queuing that ar required for 
> per-flow traffic
> handling render the signaling overhead negligible. 
> 
> Thus, I would claim that your study is about the scalability of "RSVP
> signaling *with* per-flow traffic handling", as opposed to 
> "RSVP signaling".
> The distinction is important because, diffserv, as an 
> aggregate form of
> traffic handling can be used with per-flow signaling to yield a very
> scalable QoS architecture.
> 
> I would be interested in seeing the following stats:
> 
> Assume a 1 Mbps flow, signaled by RSVP (one signaling message very 30
> seconds):
> How much processing power per-second is expended on handling 
> RSVP signaling
> in the router?
> How much processing power per-second is expended on trafic 
> handling the 1
> Mbps data flow?
> 
> Of course, processing power can be expressed in some 
> normalized, unitless
> sense. It's the ratio that is interesting.
> 
> Yoram 
> 
> > -----Original Message-----
> > From: Istvan Cselenyi [mailto:Istvan.I.Cselenyi@telia.se]
> > Sent: Friday, November 19, 1999 10:36 AM
> > To: sgoorah@uom.ac.mu
> > Cc: Yoram Bernet (Exchange); Albert Manfredi; rsvp@ISI.EDU;
> > diffserv@ietf.org
> > Subject: Re: [Diffserv] RSVP vs DiffServ
> > 
> > 
> > Goorah,
> > 
> > > 	at least this is a topic of discussion which I am interested in
> > 
> > me too - just before we are moved to diffserv-interest...
> > 
> > > > > > My description would be that RSVP is thought by some
> > > > > not to "scale
> > > > > > well" in very large networks,
> > > 
> > > 	It would clarify things if you could explain 
> > "scalability with respect
> > > to what?"
> > 
> > I hope you can find an answer to this in our study about 
> > scalability of 
> > QoS signaling as of today:
> > 
> http://soha.ttt.bme.hu/boomerang/public/decides.zip
> 
> BR
> Istvan Cselenyi
> 
> 
> 
> 
> --------------------------------------------------
>                 Istvan Cselenyi                      
>  Telia Research AB           Phone: +46-8-7138173
>  Vitsandsgatan 9 B431          Fax: +46-8-7138199          
>  S-12386 Farsta            Mobile: +46-70-3228801  
>  Sweden        E-mail: Istvan.I.Cselenyi@telia.se
> --------------------------------------------------
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

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



From diffserv-admin@ietf.org  Fri Nov 19 15:35:32 1999
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 PAA08194
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 15:35:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA08115;
	Fri, 19 Nov 1999 13:57:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id NAA08088
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 13:57:46 -0500 (EST)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24240
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 13:58:03 -0500 (EST)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Nov 19 13:56:46 EST 1999
Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168])
	by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13489;
	Fri, 19 Nov 1999 13:56:42 -0500 (EST)
Message-ID: <38359DE0.DD5EE874@dnrc.bell-labs.com>
Date: Fri, 19 Nov 1999 10:58:40 -0800
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Roland Bless <bless@telematik.informatik.uni-karlsruhe.de>
CC: Juha Heinanen <jh@lohi.eng.telia.fi>, diffserv@ietf.org
Subject: Re: [Diffserv] LBE using RFC 2474
References: <199911190945.KAA07640@blackfoot.telematik.informatik.uni-karlsruhe.de>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Roland Bless wrote:
> 
> > no isp will blindly map code points.  if my isp neighbor tells me that
> > in the packets that they send to me, prec 1 means background SERVICE,
> > then i map prec 1 at the boundary to whatever i use for background in my
> > network.  new phbs should not be defined just in order to standardize
> > code point for SERVICES.  write a background service spec instead.
> 
> A service is something with "end-to-end" semantics whereas a PHB
> describes a forwarding treatment applied at a differentiated
> services-compliant node to a behavior aggregate. The latter applies
> exactly to our LBE motivation and definition and we do not specify a
> particular behavior for more than one hop.

So that was Juha's point - you appear to be defining a new PHB when in
fact you are really looking for a new service. And some of the feedback
you are being given is that your desire for 2 levels of BE service
can be achieved with suitable use of existing PHBs.

> It is clear that a background
> service may be constructed by using the defined LBE behavior which may
> be realized by using other PHBs as a basis,

Cool. Are we finished now?

cheers,
gja

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



From diffserv-admin@ietf.org  Fri Nov 19 15:36:06 1999
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 PAA08441
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 15:36:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA10309;
	Fri, 19 Nov 1999 14:52:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id OAA10277
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 14:52:01 -0500 (EST)
Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19507
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 14:52:17 -0500 (EST)
Received: by ftp.extremenetworks.com with Internet Mail Service (5.5.2650.21)
	id <WRNX5WH0>; Fri, 19 Nov 1999 11:51:46 -0800
Message-ID: <D0805D3B448BD211A7990008C7B181300257B914@ftp.extremenetworks.com>
From: Andrew Smith <andrew@extremenetworks.com>
To: "'Yoram Bernet (Exchange)'" <yoramb@Exchange.Microsoft.com>
Cc: rsvp@ISI.EDU, diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Fri, 19 Nov 1999 11:51:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

I think the jury is still out on the scalability of RSVP control-plane
signaling state - but I think that is just a measure of the early state of
implementations right now. Using ATM as an example, early implementations of
Q.2931 and PNNI were pathetically inefficient and, IMHO, were a major
barrier to deployment of ATM; these days they are much more useful. Whilst
RSVP is a lot simpler (no routing, no hierarchy, much simpler parameter
set), I think the same sort of maturity-process will occur.

Just to expand on Yoram's point regarding the data-plane: we have found that
it is what I call the "per-flowspec" state rather than the "per-filterspec"
state that is expensive i.e. packet filters are quite cheap but queues and
rate-meters/markers are expensive. So any scheme that can aggregate
microflows into a smaller number of scheduling classes seems worth pursuing,
even if it still relies on microflow classification. This leads to the
heretical observation that you don't really need upstream marking with "QoS
labels" (modulo the IPSEC scenario) but you do need to be able to aggregate
scheduling classes ... but we digress.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
****************************************************************

> -----Original Message-----
> From: Yoram Bernet (Exchange) [mailto:yoramb@Exchange.Microsoft.com]
> Sent: Friday, November 19, 1999 11:03 AM
> To: sgoorah@uom.ac.mu; Albert Manfredi
> Cc: rsvp@ISI.EDU; diffserv@ietf.org
> Subject: RE: [Diffserv] RSVP vs DiffServ
...
> RSVP per-flow signaling state is not the scalability problem. The
> scalability problem is relaed to the per-flow *traffic 
> handling* state that
> is typically asociated with RSVP. RSVP, per-se does not mandate any
> particular form of traffic handling. Difserv, being an 
> aggregate form of
> traffic handling works nicely *with* RSVP to support scalable 
> QoS in large
> networks.

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



From diffserv-admin@ietf.org  Fri Nov 19 17:34:20 1999
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 RAA00702
	for <diffserv-archive@ietf.org>; Fri, 19 Nov 1999 17:34:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA13317;
	Fri, 19 Nov 1999 16:46:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA13295
	for <diffserv@optimus.ietf.org>; Fri, 19 Nov 1999 16:46:00 -0500 (EST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08525
	for <diffserv@ietf.org>; Fri, 19 Nov 1999 16:46:16 -0500 (EST)
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <XF7PHANY>; Fri, 19 Nov 1999 13:45:38 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A6073D0EF1@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: Andrew Smith <andrew@extremenetworks.com>
Cc: rsvp@ISI.EDU, diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Fri, 19 Nov 1999 13:45:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF32D7.6B35003A"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF32D7.6B35003A
Content-Type: text/plain;
	charset="iso-8859-1"

I agree.

> -----Original Message-----
> From: Andrew Smith [mailto:andrew@extremenetworks.com]
> Sent: Friday, November 19, 1999 11:52 AM
> To: Yoram Bernet (Exchange)
> Cc: rsvp@ISI.EDU; diffserv@ietf.org
> Subject: RE: [Diffserv] RSVP vs DiffServ
> 
> 
> I think the jury is still out on the scalability of RSVP control-plane
> signaling state - but I think that is just a measure of the 
> early state of
> implementations right now. Using ATM as an example, early 
> implementations of
> Q.2931 and PNNI were pathetically inefficient and, IMHO, were a major
> barrier to deployment of ATM; these days they are much more 
> useful. Whilst
> RSVP is a lot simpler (no routing, no hierarchy, much simpler 
> parameter
> set), I think the same sort of maturity-process will occur.
> 
> Just to expand on Yoram's point regarding the data-plane: we 
> have found that
> it is what I call the "per-flowspec" state rather than the 
> "per-filterspec"
> state that is expensive i.e. packet filters are quite cheap 
> but queues and
> rate-meters/markers are expensive. So any scheme that can aggregate
> microflows into a smaller number of scheduling classes seems 
> worth pursuing,
> even if it still relies on microflow classification. This leads to the
> heretical observation that you don't really need upstream 
> marking with "QoS
> labels" (modulo the IPSEC scenario) but you do need to be 
> able to aggregate
> scheduling classes ... but we digress.
> 
> Andrew
> 
> ****************************************************************
> Andrew Smith                              tel: +1 (408) 579-2821
> Extreme Networks                          fax: +1 (408) 579-3000
> 3585 Monroe St.                   http://www.extremenetworks.com
> Santa Clara CA 95051-1450        em:  andrew@extremenetworks.com
> ****************************************************************
> 
> > -----Original Message-----
> > From: Yoram Bernet (Exchange) [mailto:yoramb@Exchange.Microsoft.com]
> > Sent: Friday, November 19, 1999 11:03 AM
> > To: sgoorah@uom.ac.mu; Albert Manfredi
> > Cc: rsvp@ISI.EDU; diffserv@ietf.org
> > Subject: RE: [Diffserv] RSVP vs DiffServ
> ...
> > RSVP per-flow signaling state is not the scalability problem. The
> > scalability problem is relaed to the per-flow *traffic 
> > handling* state that
> > is typically asociated with RSVP. RSVP, per-se does not mandate any
> > particular form of traffic handling. Difserv, being an 
> > aggregate form of
> > traffic handling works nicely *with* RSVP to support scalable 
> > QoS in large
> > networks.
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

------_=_NextPart_001_01BF32D7.6B35003A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: [Diffserv] RSVP vs DiffServ</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Andrew Smith [<A =
HREF=3D"mailto:andrew@extremenetworks.com">mailto:andrew@extremenetworks=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, November 19, 1999 11:52 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Yoram Bernet (Exchange)</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: rsvp@ISI.EDU; diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Diffserv] RSVP vs DiffServ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think the jury is still out on the =
scalability of RSVP control-plane</FONT>
<BR><FONT SIZE=3D2>&gt; signaling state - but I think that is just a =
measure of the </FONT>
<BR><FONT SIZE=3D2>&gt; early state of</FONT>
<BR><FONT SIZE=3D2>&gt; implementations right now. Using ATM as an =
example, early </FONT>
<BR><FONT SIZE=3D2>&gt; implementations of</FONT>
<BR><FONT SIZE=3D2>&gt; Q.2931 and PNNI were pathetically inefficient =
and, IMHO, were a major</FONT>
<BR><FONT SIZE=3D2>&gt; barrier to deployment of ATM; these days they =
are much more </FONT>
<BR><FONT SIZE=3D2>&gt; useful. Whilst</FONT>
<BR><FONT SIZE=3D2>&gt; RSVP is a lot simpler (no routing, no =
hierarchy, much simpler </FONT>
<BR><FONT SIZE=3D2>&gt; parameter</FONT>
<BR><FONT SIZE=3D2>&gt; set), I think the same sort of maturity-process =
will occur.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Just to expand on Yoram's point regarding the =
data-plane: we </FONT>
<BR><FONT SIZE=3D2>&gt; have found that</FONT>
<BR><FONT SIZE=3D2>&gt; it is what I call the &quot;per-flowspec&quot; =
state rather than the </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;per-filterspec&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; state that is expensive i.e. packet filters are =
quite cheap </FONT>
<BR><FONT SIZE=3D2>&gt; but queues and</FONT>
<BR><FONT SIZE=3D2>&gt; rate-meters/markers are expensive. So any =
scheme that can aggregate</FONT>
<BR><FONT SIZE=3D2>&gt; microflows into a smaller number of scheduling =
classes seems </FONT>
<BR><FONT SIZE=3D2>&gt; worth pursuing,</FONT>
<BR><FONT SIZE=3D2>&gt; even if it still relies on microflow =
classification. This leads to the</FONT>
<BR><FONT SIZE=3D2>&gt; heretical observation that you don't really =
need upstream </FONT>
<BR><FONT SIZE=3D2>&gt; marking with &quot;QoS</FONT>
<BR><FONT SIZE=3D2>&gt; labels&quot; (modulo the IPSEC scenario) but =
you do need to be </FONT>
<BR><FONT SIZE=3D2>&gt; able to aggregate</FONT>
<BR><FONT SIZE=3D2>&gt; scheduling classes ... but we digress.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
****************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; Andrew =
Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tel: +1 (408) 579-2821</FONT>
<BR><FONT SIZE=3D2>&gt; Extreme =
Networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; fax: +1 (408) 579-3000</FONT>
<BR><FONT SIZE=3D2>&gt; 3585 Monroe =
St.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.extremenetworks.com" =
TARGET=3D"_blank">http://www.extremenetworks.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Santa Clara CA =
95051-1450&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; em:&nbsp; =
andrew@extremenetworks.com</FONT>
<BR><FONT SIZE=3D2>&gt; =
****************************************************************</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Yoram Bernet (Exchange) [<A =
HREF=3D"mailto:yoramb@Exchange.Microsoft.com">mailto:yoramb@Exchange.Mic=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Friday, November 19, 1999 11:03 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: sgoorah@uom.ac.mu; Albert =
Manfredi</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: rsvp@ISI.EDU; diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [Diffserv] RSVP vs =
DiffServ</FONT>
<BR><FONT SIZE=3D2>&gt; ...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; RSVP per-flow signaling state is not the =
scalability problem. The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; scalability problem is relaed to the =
per-flow *traffic </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; handling* state that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; is typically asociated with RSVP. RSVP, =
per-se does not mandate any</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; particular form of traffic handling. =
Difserv, being an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aggregate form of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; traffic handling works nicely *with* RSVP =
to support scalable </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; QoS in large</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; networks.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; diffserv mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; diffserv@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/mailman/listinfo/diffserv" =
TARGET=3D"_blank">http://www.ietf.org/mailman/listinfo/diffserv</A></FON=
T>
<BR><FONT SIZE=3D2>&gt; Archive: <A =
HREF=3D"http://www-nrg.ee.lbl.gov/diff-serv-arch/" =
TARGET=3D"_blank">http://www-nrg.ee.lbl.gov/diff-serv-arch/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF32D7.6B35003A--

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



From diffserv-admin@ietf.org  Sat Nov 20 09:49:14 1999
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 JAA08967
	for <diffserv-archive@ietf.org>; Sat, 20 Nov 1999 09:49:14 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA08021;
	Sat, 20 Nov 1999 09:22:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA07989
	for <diffserv@optimus.ietf.org>; Sat, 20 Nov 1999 09:22:14 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27595
	for <diffserv@ietf.org>; Sat, 20 Nov 1999 09:22:31 -0500 (EST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199911201420.XAA01837@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id XAA01837; Sat, 20 Nov 1999 23:19:45 +0859
Subject: Re: [Diffserv] RSVP vs DiffServ
To: Istvan.I.Cselenyi@telia.se (Istvan Cselenyi)
Date: Sat, 20 Nov 99 23:19:44 JST
Cc: sgoorah@uom.ac.mu, yoramb@exchange.microsoft.com,
        albert.e.manfredi@boeing.com, rsvp@ISI.EDU, diffserv@ietf.org
In-Reply-To: <199911191835.TAA08973@malmo.trab.se>; from "Istvan Cselenyi" at Nov 19, 99 7:36 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> 
> Goorah,
> 
> > 	at least this is a topic of discussion which I am interested in
> 
> me too - just before we are moved to diffserv-interest...
> 
> > > > > My description would be that RSVP is thought by some
> > > > not to "scale
> > > > > well" in very large networks,
> > 
> > 	It would clarify things if you could explain "scalability with respect
> > to what?"
> 
> I hope you can find an answer to this in our study about scalability of 
> QoS signaling as of today:
> 
> http://soha.ttt.bme.hu/boomerang/public/decides.zip

FYI, we have proven in our INET '98 paper that multicast
routing table entries can not be aggregated.

It is easy to prove routing table entries with QoS routing can
not either be aggregated.

There also is an easy proof that RSVP scales at the backbone.

							Masataka Ohta

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



From diffserv-admin@ietf.org  Sat Nov 20 22:31:16 1999
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 WAA05495
	for <diffserv-archive@ietf.org>; Sat, 20 Nov 1999 22:31:15 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA18064;
	Sat, 20 Nov 1999 21:51:24 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id VAA18033
	for <diffserv@optimus.ietf.org>; Sat, 20 Nov 1999 21:51:15 -0500 (EST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16259
	for <diffserv@ietf.org>; Sat, 20 Nov 1999 21:51:31 -0500 (EST)
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199911210248.LAA04311@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id LAA04311; Sun, 21 Nov 1999 11:48:26 +0900
Subject: Re: [Diffserv] RSVP vs DiffServ
To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 21 Nov 99 11:48:25 JST
Cc: Istvan.I.Cselenyi@telia.se, sgoorah@uom.ac.mu,
        yoramb@exchange.microsoft.com, albert.e.manfredi@boeing.com,
        rsvp@ISI.EDU, diffserv@ietf.org
In-Reply-To: <199911201420.XAA01837@necom830.hpcl.titech.ac.jp>; from "Masataka Ohta" at Nov 20, 99 11:19 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

> > > 	It would clarify things if you could explain "scalability with respect
> > > to what?"
> > 
> > I hope you can find an answer to this in our study about scalability of 
> > QoS signaling as of today:
> > 
> > http://soha.ttt.bme.hu/boomerang/public/decides.zip
> 
> FYI, we have proven in our INET '98 paper that multicast
> routing table entries can not be aggregated.

To my surprise, I have got a few questions on the location of the paper,
even though INET, the Internet Summit, is an annual conference of ISOC,
which is a legal umbrella of IETF.

The referece information is:

	Manolo Sola, Masataka Ohta, Toshinori Maeno,
	"Scalability of Internet Multicast Protocols",
	Proceedings of INET'98,
	http://www.isoc.org/inet98/proceedings/6d/6d_3.htm,
	July 1998.

> There also is an easy proof that RSVP scales at the backbone.

A brief discription of the easy proof is that a high speed backbone needs
parallel hardware (including parallel routing tables, parallel policers
and parallel schedulers) amount of which is proportional to the speed
of the backbone or the expected number of flows at the backbone.

FYI, I have pointed it out several times in RSVP ML before the silly
attempt of diffserve was proposed.

							Masataka Ohta

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



From diffserv-admin@ietf.org  Mon Nov 22 01:29:07 1999
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 BAA12592
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 01:29:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA21823;
	Mon, 22 Nov 1999 00:47:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA21791
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 00:46:53 -0500 (EST)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19896
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 00:47:12 -0500 (EST)
Received: from tu660 (udn100.ringin.udn.telia.se [131.115.97.100]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id GAA26179; Mon, 22 Nov 1999 06:45:38 +0100 (MET)
Message-Id: <199911220545.GAA26179@malmo.trab.se>
From: "Istvan Cselenyi" <Istvan.I.Cselenyi@telia.se>
To: "Yoram Bernet (Exchange)" <yoramb@exchange.microsoft.com>
Date: Mon, 22 Nov 1999 06:40:33 +1
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: [Diffserv] RSVP vs DiffServ
Reply-to: Istvan.I.Cselenyi@telia.se
CC: Albert Manfredi <albert.e.manfredi@boeing.com>, sgoorah@uom.ac.mu,
        boomerang@soha.ttt.bme.hu, rsvp@ISI.EDU, diffserv@ietf.org
Priority: normal
In-reply-to: <078292D50C98D2118D090008C7E9C6A6073D0E1B@STAY.platinum.corp.microsoft.com>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Content-Transfer-Encoding: 7BIT
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7BIT

Hi Yoram,

> Hmmm. Istvan - from our discussions at the IETF, it is not clear to me what
> fraction of processing overhead you atrribute to *signaling* vs. to
> *traffic-handling*. 

Our goal was to quantify the scalability of processing _signaling_ 
messages (i.e. load on control plane) as a function of 
* total number of concurrent reservation sessions in the router
* intensity of new reservation attempts (hits per sec).

The control plane performance of QoS signaling is important, since 
(1) that is what end-user applications and network designers are 
facing with (e.g. reservation setup time, maximum # of reservations 
and max. intensity of setups) and
(2) heavy signaling can have a serious impact on handling other 
protocols (e.g. routing, management - if they are not isolated).

As you wrote earlier on this thread, the selection of traffic-
handling approach (per-flow or per-BA) is not directly coupled to 
signaling. Thus the (data plane) processing overhead due to 
conditioning the traffic of reserved flows is also independent from 
the performance of signaling protocol.

> In fact, it seemed to me that the traffic handling
> burden is far heavier than the signaling burden. Traditionally, RSVP
> triggers per-flow traffic handling. WFQ is commonly used for this. From my
> experience, the policing and queuing that ar required for per-flow traffic
> handling render the signaling overhead negligible. 

This is true (see below), but another story.

> Thus, I would claim that your study is about the scalability of "RSVP
> signaling *with* per-flow traffic handling", as opposed to "RSVP signaling".

Yes, we had to use the per-flow RSVP version, the only one which was 
available. Moreover, we disabled the TC setup in the source code and 
found that it takes only 2-3 msec from the  8 ms processing time of 
Resv. Thus setting up per-BA TC instead of per-flow TC probably does 
not speeds up RSVP handling. We submitted a paper on this: 
http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html

> The distinction is important because, diffserv, as an aggregate form of
> traffic handling can be used with per-flow signaling to yield a very
> scalable QoS architecture.

I agree. For the same reason, we have two Boomerang prototypes, one 
with per-flow and another with per-BA traffic conditioning: 
http://soha.ttt.bme.hu/boomerang/public/boom_sw/boomerang-net.tgz

> I would be interested in seeing the following stats:
> 
> Assume a 1 Mbps flow, signaled by RSVP (one signaling message very 30
> seconds):
> How much processing power per-second is expended on handling RSVP signaling
> in the router?
> How much processing power per-second is expended on trafic handling the 1
> Mbps data flow?
> 
> Of course, processing power can be expressed in some normalized, unitless
> sense. It's the ratio that is interesting.

I was also curious, thus searched our measurements and found 
something similar for the per-flow TC Boomerang prototype:

Processing power of traffic handling / signaling

				Signaling Intensity [1/sec]	
Backgr. rate	1000	2000	3000
1 Kbps			4886	14657	41331
1 Mbps			7321	19803	43578

Foreground (reserved) traffic rate 1 Mbps
Boomerang refresh rate 30 sec
Size of data packets 1500 bytes

That is traffic handling of a 1 Mbps flow consumes about 5000 - 45000 
times more CPU than the related signaling, depending on the load of 
control and data planes. Since our Linux box needs more than 100 
times more time for handling RSVP than Boomerang, these figures are 
probably between 50 - 450 for the Linux/RSVP. Moreover, this ratio is 
less for tiny flows (e.g. 64K or 8K VoIP). 

But anyway, I accept that traffic handling is also worth to look at 
and we will measure this for RSVP a.s.a.p.

Istvan


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



From diffserv-admin@ietf.org  Mon Nov 22 03:01:53 1999
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 DAA08971
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 03:01:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA29659;
	Mon, 22 Nov 1999 01:57:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA29631
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 01:57:34 -0500 (EST)
Received: from condor.uom.ac.mu (condor.uom.ac.mu [202.60.7.52])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29361
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 01:57:43 -0500 (EST)
Received: from sgoorahpc01 ([202.60.7.159]) by condor.uom.ac.mu
          (Post.Office MTA v3.5.3 release 223 ID# 0-60726U1000L100S0V35)
          with SMTP id mu; Thu, 3 Jun 1999 11:27:37 +0400
Message-ID: <3838EE8C.45F@uom.ac.mu>
Date: Mon, 22 Nov 1999 11:19:40 +0400
From: sgoorah@uom.ac.mu (Goorah Shravan)
Reply-To: sgoorah@uom.ac.mu
Organization: University of Mauritius
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: Venumadhav Josyula <vjosyula@osf1.gmu.edu>
CC: Albert Manfredi <albert.e.manfredi@boeing.com>,
        "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>,
        rsvp@ISI.EDU, diffserv@ietf.org
Subject: Re: [Diffserv] RSVP vs DiffServ
References: <Pine.OSF.3.96.991119115433.14274A-100000@osf1.gmu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hello Venumadhav,

> 
> how can rsvp modified to have no state at all. Secondly is'nt the

I do hesitate to give you a reference about Intserv in Diffserv/RSVP
mailing list(s)  BUT this paper is of good quality according to me,

Berson S., Vincent S., "Aggregation of Internet Integrated Services
State", IWQoS 98

You will get it somewhere beneath the "RSVP Working Group HomePage"
(Additional RSVP Page -> see Publications)

> extensions to RSVP useful in diffserv. But extension to rsvp does deal
> with per flow but it deals with per aggregate flow is it not
> 

	I think this question has been clarified/answered to some extent by
others - BUT the draft which I mentioned in my previous mail and which I
quote again, mentions "RSVP state aggregation" and this draft can be
useful as well

	Bernet Y., Yavatkar R., Ford P., Baker F., Zhang L., Speer M., Braden
R., Davie B., "Integrated Services Operation Over Diffserv Networks",
Internet Draft, June 1999

Best Regards,
Shravan
-- 
Shravan Goorah
Lecturer, Department of Computer Science,
Faculty of Engineering, University of Mauritius
Tel. 454 1041 		Fax.  465 71 44

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



From diffserv-admin@ietf.org  Mon Nov 22 05:57:06 1999
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 FAA00833
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 05:57:06 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA04078;
	Mon, 22 Nov 1999 05:03:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id FAA04048
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 05:03:18 -0500 (EST)
Received: from post.netchina.com.cn ([202.94.1.48])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04801
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 05:03:29 -0500 (EST)
Received: (qmail 17096 invoked from network); 22 Nov 1999 10:04:57 -0000
Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227)
  by 202.94.1.48 with SMTP; 22 Nov 1999 10:04:57 -0000
Message-ID: <38391476.4BB3AF6@netchina.com.cn>
Date: Mon, 22 Nov 1999 18:01:29 +0800
From: Robert Tan <tjsh@netchina.com.cn>
Reply-To: tjsh@netchina.com.cn
Organization: Tan Junsheng
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Dear Sir: This is my discussion article.
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Dear Sir: This is my discussion article.
The title:
                   Flash Bandwidth 1KHz to 100MHz
                         Digital Controlled Broadband
                     Anti-alias & Reconstruction Filter
The details:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc

Sincerely,

Robert Tan
11.22



Flash Bandwidth 1KHz to 100MHz
Digital Controlled Broadband
Anti-alias & Reconstruction Filter
The Next Era Web of Multimedia Data-stream
Transmission Solution of the Internet!

By Robert Tan
Update: 1999. 11. 22

For the many more format and definite of standard of digital film and
video, digital audio
and the other multimedia data stream of tomorrow, the existing network
technology including
the modern internet webs will be fabulous and difficult to transmit it
for us. The Endpoint
Congestion almost resistant our viewer area full of the entire world, We
would need the
straightway link of the multi-media data-stream in real-time for us.
Would you like to get a lower cost & more effective digital signal
channel in a wide-bandwidth
or broadband hybrid coax cable system? For the FTTX, HFC networks,
especially in the HFC
networks with the 256QAM or 64VSB digital modulation technology systems,
the SSB-ASK or the
VSB-ASK technology transmission systems would be used normally. The
Flash Bandwidth 1KHZ to
100MHz digital control a variable frequency bandwidth, it is
high-performance anti-alias &
reconstruction (FBW) filter, it will be able to provide a variable
multiplex sub-frequency
band in any broadband HFC system. With the FDM assistant digital carry
system and SSB or VSB
signal channel, a group of FBW filters will provide separate
multi-frequency bands in spectrum
without any cross talking and distortion by a large frequency range in a
high-speed high-
effective transmission system. In a FTTX or HFC web, this digital
controlled signal channel
would have a very large frequency spectrum changed dynamic range. For a
large client group,
such as the Broadband Cable Internet Access or HFC users, one of them
would like to get a
variable data speed according to the applications of his needed. It will
provide a lot of
digital control frequency bandwidth which is separated one another in
HFC transmission system,
and it will more effective for the "hot clients", such as the VOD video
clients or the other
high-code rate users and high-speed data stream user's applications. The
FBW will improve the
speed of the data stream, diminish the amount of the spare resource
seizing of "Cool Clients",
reduce the calculations of the DSP processor of the center web main
switching system and the
branch switching system. Reduce the CPU utilities of the applications in
all of client
communication adapter and its cost of produce is very important. The
"Cool Clients" mains
the IP telephone users or the other lower speed code rate audio
applications. Anyway, the
speed of the up-stream data and down-stream data speed could be changed
to any value you
needed, and the changing degree will be very smoothly and very simply in
writing one or
two bytes in the command system of communication web switcher. By the
high-speed frequency
variable characteristic, if the FBW filter were used in your FTTX or HFC
switching system,
the upward and downward data stream speed could be managed and attempted
by your command
system. So that, the transmission bandwidth will be able to adjusted to
your needed in any
time within one millionth second. The real-time will be very more
improved and more effective
on the communication main roads such as FTTX and HFC system,
transmission controlling system
will completely control the data stream in real-time.



Dear Technology Research and Development Administrator:
   I am an electronic engineer in the field of Analog and Digital
filters researching and
designing. I had been a DSP engineer for ten years. My development field
is electronic circuits
-- digital and analog hardware designing and researching in applications
of Digital Signal
Processing. My works contains the frequency spectrum analysis, digital
audio and digital video
systems, noise spectrum controlling and processing, and the other
military applications. I have
researched and designed several kind of analog and digital anti-alias &
reconstruction filters.
A few years before, in my R&D works, I find the special frequency of the
filters is usually
fixed, it could be very difficult to change the cutoff frequency of the
low-pass anti-alias
& reconstruction filter. But the fixed filter could not suit the target
of my technical
applications. If we want to get several special frequency of the
filters, we must to use
several different fixed filters or instead of fixed filter with
switching capacity filter
or digital filter, such as IIR or FIR filter, and their frequency must
be variable in order
to change the analysis frequency. It is very important for the spectrum
analysis system and
the digital random real time vibrated controlling system. But, in this
way, we must pay for
digital IIR or FIR filter, it is very expensive in the price, take a
large space for the DSP
chips and its outside memory banks to install it. So, we would get into
much troubles and
complex questions from a simple problem.
However, we have the switching capacity technologies, and the product of
up to 8th order
filters is a very normally used. But the switching capacity filter will
have a high noise
and low frequency range, and it has a non-exactly special frequency,
generally. The special
frequency of most of the switching capacity filters is from 1/95 to
1/105 times of its main
switching clock and it is difficult to improve its accuracy. Actually,
the switching capacity
filter circuit is very difficult to adjust and use in applications.
Anywise, its order is
normally below 8th order, and the special frequency and bandwidth of the
switching capacity
filters is below to 50KHz, and the amplitude response is not exactly
yet, the dynamic range
of the amplitude is very low, normally, it is below the 48dB. Except of
frequency range from
0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not
usefully, it is
normally being used in the speech processing circuit and the other lower
frequency band
processing systems. Attention, all of this analysis is not including the
phase noise of the
main switching clock and the noise of clock feed through yet. The
others, it is difficult to
get much more analysis frequency bands or special frequency points for
the switching capacity
filters, it is especially for the higher frequency band which is
approached to the top
frequency point. All of these characteristics of the switching capacity
filters will restrict
its applications in the area of modern digital communications.
The others method of the filters designing is the contact-time analog
filter .I have found
some method. It could make many transfer functions. Such as the
elliptical function,
Chebyshev function and Butterworth function, but there is some
interesting things here,
it is that the same circuit frame could be built into many transfer
functions, and it
would have programmable (digital controlled) special frequency. Changing
special frequency
on line is available. It could get the very wide frequency range, very
quickly to change
the used band, and the digital controlled circuit is very directly and
simply, the special
frequency step is very smoothly (because the Frequency is controlled by
long bit Digital
multiplier). In that points, integrate the FBW filter circuit technology
is very useful
for the digital controlling and processing systems. Because of the
Digital Controlling
Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8
or 12 bits long
Digital Multiplier and a few chips of high-speed amplifiers. The other,
this filter
technology is used with a few exactitude resistors and exactitude
capacitors also. For
example, an 8th order elliptical filter need 8chips of dual Digital
Multiplier and several
chips high bandwidth amplifiers, 8chips exactitude capacitors and
several chips exactitude
resisters. If it is possible, integrating all the Digital Multiplier and
amplifiers into
one chip or one plastic package (mixed circuit), place all the
exactitude resistors and
capacitors out of the package. It will be finest filter and very easy to
used and could
be re-designed agilely by the customers and the OEMs. The parameter of
the filters is
depending on the value of the resistors and the capacitors. Its value
could be designed
by the customs freely and calculated by constant functions directly, and
that is very
simply.
And then, the FBW filters would be very usefully in the FTTX or HFC
networks. For working
with the 256QAM or 64VSB modulation technology and any narrow-band
transmission technology
systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV
and VOD systems, it
would compress the used frequency bandwidth in mostly extent. Because of
the WAN systems in
any nations will be depending on the "Tree structures" as the main road
in the webs in the
future. The frequency source is very expensive in this web, It would be
welcomed in the
Internet web digital information transmission, exchanging and switching
technology area,
DSP area and digital communications area, such as MAN and WAN coax cable
webs or the FTTX
system applications. Any way, the most of modern networking transmission
mode is TDM. It
is very suitable for the text material or media, because of it is a
fixed media in size,
and it is the fixed continue time in length and generation procedure.
But the most of
multimedia is not to be suitable with that. The data stream of voice and
video will have
no constant size to be forecasted has no constant procedure time. It is
only have a constant
and fixed bandwidth of media data stream. Because of your interesting
points is onto the
generations and the procedures of the video or audio information of thus
material or the
news, such as the high quality digital cinema, digital musicale and so
on. Certainly, you
could take the any multimedia information and any moving picture on you
desktop through the
Internet Web. It will be appeared the true alive world with you in any
site you can go! So
that, the only one of best way of the media data streams transmission
and exchanging is the
FDM mode with the SSB-ASK or VSB-ASK technology, it should be working
with the QAM or
VSB- ASK digital modulation technology in the future Internet webs.
FBW filter would be used in most of switchers and routers, which is
depending on the FDM
technologies. For the cable TV systems STB (set top box), video & audio
servers in Broadband
Cable Internet Access, cable modems or the client-end adapters in the
most of family users
and the most of business cable users in the world will need a very great
deal of broadband
web transmission bandwidth. Because of that, in any modern
home-electronic equipment, such
as the Internet officers, shopping's and the VOD or the other broadband
information
electronics, its using method would be depending on the FDM switching
technologies. So that,
the "Online Home-Electronics" or the other Internet accessing products
which is used in
people's homes would be simply to operate and easy to use. And it must
be depend on the
simply low-layer hardware equipment and protocols of the webs, such as
the VOD systems
and the STB terminals in the Broadband Cable Internet Access or HFC
networks. The FBW
technology would provide us more applicable and useable method in the
physics layer of
the public HFC networks, its FDM applications in a broadband web get us
in a lower building
price, more effective than the other technology. Such as the Broadband
Cable Internet Access
webs, HFC networks, FTTX networks, and the other and the other WAN
public broadband networks
would have a very great applications of the FBW filters.
The others, using a Flash-Band-width filter will help you get in to a
fully data stream
bandwidth management of any expensive data-link channels and the very
expensive communication
data stream bandwidth, such as the communication data-link of the
satellite communication
systems, and the ocean bottom communication systems. FBW filter will
control the any leased
data-stream bandwidth in dynamic mode within a very large frequency
range, a large range of
signal frequency bandwidth and data-stream speed in any time for a
communication administration
and operation system. It will change the bandwidth with you leased data
stream very imminently
within several microsecond, improve your expensive bandwidth of
data-stream transmission channel,
save your leased payment and money cost for any customers of digital
communications and any
Tele-communication operating and service company. It will hold any
important transmission of
data-stream in smoothly and take it freely. So, in this system, any
interrupt of your
communication data stream will be never.



The Digital Control Flash Bandwidth Filter specifications:
(1) General details:
Frequency range:   0.1Hz--100MHz
Useable frequency range:  0.1Hz--100MHz(at least)
Special frequency step:  0.001Hz-1000KHz
Transfer functions:   Elliptical, Butterworth, Chebyshev, and Bassel
function.
       And the others contacted-time filters.
Available filter type:  Low-pass filter, High-pass filter, Notch filter,

       Band-pass filter and All-pass filter.
Noise Level:  -160dB(max) (Only depend on the number of the used
amplifiers.)
Order range: 2nd--12th(Depend on the sensitivity of the transfer
functions.)
Filter switching time:  Less than 300nS (Filter Setting time is 200nS)
Useful Range:    Anti-alias filters, Reconstruction filters.

(2) Pass Band Specifications:
Frequency selectable range:  100Hz--100MHz
(Depend on the performance of the selected amplifiers)
Special Frequency steps:  1Hz-1000KHz
Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of
the filter.)
Ripple:  0.01--1.0dB (Only depend on the filter function and the
passband ripple designed.)

(3) Pass to Stop Band:
Drop speed of Interim-band Cut-off:
180db/oct (8th order elliptical function with 0.05dB pass-band ripple)

(4) Stop Band:
Amplitude min drop:  120db(8th elliptical filter for example)
Frequency range:   0.1Hz--100MHz
(Depend on the amplifiers and the Digital Multiplier specifications)

(5) Digital Control specifications:
Digital component is used (8 bit, 10bit, 12bit, and 16bit is available).

The special frequency is (N1/N2) * Frequency (ref).
(The N1, N2 is the Digital component input byte, from 8bit to 16 bit.)
The Frequency (ref) is form 10Hz to 10MHz.
(This parameter is depends on one RC time constant.)
High speed and voltage feedback high-bandwidth operation amplifiers are
required.

(6) Requirement: (The filter section of 8th order)
Digital component:    8 chips (Selections depend on the frequency range)

High-performance Amplifiers: 12 to 24 chips (Selections depend on the
frequency)
Capacitors or inductors:   8 chips (exactitude degree value is 1% to
0.1%)
Resistors:          16-36 chips (exactitude degree value is 1% to 0.1%)

(7) Group delay:                Depend on the function of the filter
designed, filter
                                phase response designed, and the filter
order.

(8) Filter switching time:  Less than 300nS (Filter Setting time is
200nS)




   The Comparisons of the 4 kinds active Filters

For example:
8th order filter
Switching Capacity Filter
Digital Filter
(FIR or IIR Filter)
Traditional
Fixed Analog Frequency Filter
Digital controlling FBW filter

Noise Level or  (THD+N) Value:

Highest

-48db
Lower

-70db
Very Low

-160db
Very Low

-120db
Filter Dynamic Range
The Value:
Little

50db
Middle

70db
Very Large

160db
Large

100db
Real-time          active frequency
The range of the value:
Narrow

200Hz to 300KHz
Wide

0.001Hz to  50KHz
Very Wide

0.1Hz   to 1MHz
Very wide

0.001Hz    to 100MHz
The Outside in advance  Anti-alias & Reconstruction assistant filter
requirement

The degree of assistant filter Quality
Required





2nd to 4th order  anti-alias & reconstruction assistant outside filter
Required





4th to 6th order anti-alias & reconstruction   assistant outside filter
Not required.





----------
Not required





----------
The Precision of the special  frequency:
The ability of on-line changing the filter special frequency
&Method
Low.

+/-3%

Very easy
(Changing the switching clock)
High

+/-3%

Very difficult
(Change a new programs and
parameters )
Very high

0.1%

Very difficult.
(Changing the system time
constant)
Very high

0.1%

Easy(Writing  digital word to the filter control port)
The complex degree of the filter system designing
&The used space
Simple



Small
Very complex



Very large
Simple



Middle
Middle



Middle
The price for  produce a filter
&The difficult degree of the applications
Very low

$10~50

Easy
Very high

$300~600

Difficult
Low

$30~90

Easy
Middle

$50~100

Middle
Anti-alias &  Reconstruction filter Performance: (1)Pass Band
Ripple &Dynamic Range:
(2)Stop Band
Rejection
(3)Interim Band Dropping Slope:
Low Quality & Low Price.


+/-0.2db

50db

55db

50db/oct
Normal or High Quality & High price

+/-0.01db

70db

70db

130db/oct
Normal Quality  & Low Price


+/-0.01db

120db

120db

180db/oct
High Quality  & & Middle Price.


+/-0.01db

110db

120db

180db/oct
Online/offline Changing of highest/lowest special frequency rate &
Range:
&changing time:
All available
1000 times
300Hz to 300KHz

10mS(Time of PLL tracking & locked)
Offline available
Not available

Not available

Not available
(Reboot DSP & A/D system)
Offline available
1000 times

Not available

Not available

All available
100000 times
1KHz to 100MHz

160nS (TTL 2 bytes writing time)
Filter online reconstruction setting time (The total time  of
filter frequency switched)


10mS


Not available


Not available


300nS
Group delay and the phase response:
Producer design only.
Linear or Producer design only.
Producer design only.
Producer & User design is available.
Equality data stream speed or comported speed of its TxDAC :
&Butterworth 8th filter
(Broadband  channel HFC usable signal dynamic range is  about 50dB):
4.8Kbps to 4.8Mbps
(600SPS to 600KSPS)


8bit TxDAC
Constant 400Kbps
(50KSPS)



8bit TxDAC
Constant 800Mbps
(100MSPS)



8bit TxDAC
16Kbps to 1600Mbps
(2KSPS to 200MSPS)


8bit TxDAC
Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in  SSB/VSB mode
of technology
(Data speed of Base Band):

Carrier signal RF full-band tie up:
Difficult to be used with the 256QAM and 64VSB.
(High Level Phase Noise)
4.8Kbps(Min)
4.8Mbps(Max)

384Hz to 384KHz
Difficult to be used in variable data-speed transmission or receiving
system



Difficult to be used in variable data-speed transmission or receiving
system
With 256QAM:
8Kbps(Min)
800Mbps
(Max)
With 64VSB:
12Kbps(Min)
1200Mbps (Max).

1.28KHz to 128MHz
For the HFC Specialty signal TV Channel:
40dB Eb/N
6MHz Full-band 64VSB model
@1KHz-6MHz
Data-rate:



With 64VSB:

9.375Kbps
(Min)
56.25Mbps
(Max)

Contact Address:
No.2 Buliding Room1007,
Mudanyuan Beili, Haidian District
Beijing P. R. China,
Post Code: 100083
Name: Tan Junsheng (Robert Tan)
Tele: 8610-82076834, 86-13701070213(Mobile)
E-mail:  Tjsh@netchina.com.cn or tanjun@hotmail.com
Homepage: http://www.cnindex.net/~tjsh
Details Remind:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html




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



From diffserv-admin@ietf.org  Mon Nov 22 08:09:28 1999
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 IAA05779
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 08:09:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA06879;
	Mon, 22 Nov 1999 07:02:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA06847
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 07:02:30 -0500 (EST)
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29386
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 07:02:48 -0500 (EST)
Received: from m1.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX9911-Fujitsu Gateway)
	id VAA09951; Mon, 22 Nov 1999 21:01:14 +0900 (JST)
Received: from flabmail.flab.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-9911-Fujitsu Domain Master)
	id VAA25142; Mon, 22 Nov 1999 21:01:14 +0900 (JST)
Received: from silver by flabmail.flab.fujitsu.co.jp (8.6.12+2.5Wb7/3.3W9-MX970225-Fujitsu Labs. Domain Mail Master)
	id VAA13618; Mon, 22 Nov 1999 21:01:13 +0900
Received: from localhost (localhost [127.0.0.1])
	by silver (8.8.7/3.6Wbeta7-98082009) with ESMTP id UAA18467;
	Mon, 22 Nov 1999 20:58:53 +0900 (JST)
To: Istvan.I.Cselenyi@telia.se
Cc: yoramb@exchange.microsoft.com, albert.e.manfredi@boeing.com,
        sgoorah@uom.ac.mu, boomerang@soha.ttt.bme.hu, rsvp@ISI.EDU,
        diffserv@ietf.org
Subject: RE: [Diffserv] RSVP vs DiffServ
From: Masanobu Yuhara <yuhara@flab.fujitsu.co.jp>
In-Reply-To: <199911220545.GAA26179@malmo.trab.se>
References: <078292D50C98D2118D090008C7E9C6A6073D0E1B@STAY.platinum.corp.microsoft.com>
	<199911220545.GAA26179@malmo.trab.se>
X-Mailer: Mew version 1.94b28 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991122205853Y.yuhara@atom.flab.fujitsu.co.jp>
Date: Mon, 22 Nov 1999 20:58:53 +0900
X-Dispatcher: imput version 990425(IM115)
Lines: 10
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

There's a paper on RSVP performace:

A. Neogi, et. al, "Performance Analysis of an RSVP-Capable Router",
IEEE Network, Vol.14, No. 5, Sep./Oct. 1999.

------
Masanobu Yuhara		yuhara@flab.fujitsu.co.jp
Fujitsu Laboratories Ltd.



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



From diffserv-admin@ietf.org  Mon Nov 22 11:31:53 1999
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 LAA12885
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 11:31:53 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA14031;
	Mon, 22 Nov 1999 10:44:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA13930
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 10:44:02 -0500 (EST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21295
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 10:44:10 -0500 (EST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <XKVD7C99>; Mon, 22 Nov 1999 07:43:23 -0800
Message-ID: <078292D50C98D2118D090008C7E9C6A6073D10E7@STAY.platinum.corp.microsoft.com>
From: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
To: Istvan.I.Cselenyi@telia.se
Cc: Albert Manfredi <albert.e.manfredi@boeing.com>, sgoorah@uom.ac.mu,
        boomerang@soha.ttt.bme.hu, rsvp@ISI.EDU, diffserv@ietf.org,
        Matthias_Kraner@credo.dcs.shef.ac.uk
Subject: RE: [Diffserv] RSVP vs DiffServ
Date: Mon, 22 Nov 1999 07:43:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

Istvan:

Thank you for your in-depth response. Comments below...

> Yes, we had to use the per-flow RSVP version, the only one which was 
> available. Moreover, we disabled the TC setup in the source code and 
> found that it takes only 2-3 msec from the  8 ms processing time of 
> Resv. Thus setting up per-BA TC instead of per-flow TC probably does 
> not speeds up RSVP handling. We submitted a paper on this: 
> http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html
> 

I don't quite understand the numbers here. When you say that "TC takes 2-3
msec from the 8 msec processing time of RESV", what exactly do you mean?
Let's normalize the measurements to per-flow measurements. In that case -
RESV messages come in at a certain rate (typically one per 30 seconds per
flow), and each message needs some processor time. Data packets on the flow
come in at a certain rate (usually a couple of orders of magnitude higher
than the signaling messages)and they incurr some processor time. So - is the
2-3 msec the time required per packet or for all the packets that come in
every 30 seconds (for each signaling message)? What rate is the data flow?
You provide numbers below that do seem to normalize signaling burden vs.
trafic handling burden, but - it's not clear from this statement per-se. Of
course - I haven't yer read the source you pointed out - so - it may be
clear in there...

> I was also curious, thus searched our measurements and found 
> something similar for the per-flow TC Boomerang prototype:
> 
> Processing power of traffic handling / signaling
> 
> 				Signaling Intensity [1/sec]	
> Backgr. rate	1000	2000	3000
> 1 Kbps			4886	14657	41331
> 1 Mbps			7321	19803	43578
> 
> Foreground (reserved) traffic rate 1 Mbps
> Boomerang refresh rate 30 sec
> Size of data packets 1500 bytes

I'm not sure how to read this table, though it seems to hold the answers i'm
looking for... I assume that the second row holds the numbers for a traffic
flow of 1 Kbps and the third row for a traffic flow of 1 Mbps. I gather that
the packet size (in both cases is 1500 bytes, though for the 1 Kbps flow,
it's likely that smaller packet sizes would be used). I'm not sure what the
1000/2000/3000 numbers across the top row mean - background something or
other... Also - what does the 'signaling intensity [1/sec]' mean? Is that
the assumed signaling rate for the flow? or is that all the signaling from
background flows?
> 
> That is traffic handling of a 1 Mbps flow consumes about 5000 - 45000 
> times more CPU than the related signaling, depending on the load of 
> control and data planes. Since our Linux box needs more than 100 
> times more time for handling RSVP than Boomerang, these figures are 
> probably between 50 - 450 for the Linux/RSVP. Moreover, this ratio is 
> less for tiny flows (e.g. 64K or 8K VoIP). 
> 

Interesting - these numbers do confirm that the burden due to traffic
handling is substantially greater than that due to signaling. You note that
the ratio won't be as bad for tiny flows. With smaller flows, there is less
data to move, but - the packet sizes tend to be smaller, because these tend
to be audio flows requiring less latency. So - the per-packet burden of
traffic handling would not go down quite as quickly as one might consider.
Since policing and scheduling are per-packet, this is an important
consideration.

> But anyway, I accept that traffic handling is also worth to look at 
> and we will measure this for RSVP a.s.a.p.
> 

Great - i'm very interested in hearing more. Thanks for the insight.

> Istvan
> 

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



From diffserv-admin@ietf.org  Mon Nov 22 23:27:44 1999
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 XAA04900
	for <diffserv-archive@ietf.org>; Mon, 22 Nov 1999 23:27:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA06126;
	Mon, 22 Nov 1999 22:37:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA06094
	for <diffserv@optimus.ietf.org>; Mon, 22 Nov 1999 22:37:50 -0500 (EST)
Received: from CS.Princeton.EDU (root@CS.Princeton.EDU [128.112.136.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09520
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 22:38:09 -0500 (EST)
Received: from vectra24 (vectra09 [128.112.4.69])
	by CS.Princeton.EDU (8.9.3/8.9.3) with SMTP id WAA02217
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 22:36:11 -0500 (EST)
From: "Wenjia Fang" <wfang@cs.princeton.edu>
To: <diffserv@ietf.org>
Date: Mon, 22 Nov 1999 22:36:13 -0500
Message-ID: <NDBBLGEHIMOEIEHCLNNEGEBJCBAA.wfang@cs.princeton.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Diff-Serv Router Policies on ACK packets
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I wonder what DiffServ WG has decided on router's policy
w.r.t to Acknowledgement packets, if any.   Will either 
PHBs treat ACK packets any different from data packets?
for example, never drop an ACK packet in the case of AF?

thanks,

Wenjia


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



From diffserv-admin@ietf.org  Tue Nov 23 01:22:38 1999
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 BAA04984
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 01:22:37 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA07886;
	Tue, 23 Nov 1999 00:30:02 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id AAA07844
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 00:29:58 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06876
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 00:30:18 -0500 (EST)
Received: from cisco.com (kmn-isdn1.cisco.com [171.70.228.26])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA19668
	for <diffserv@ietf.org>; Mon, 22 Nov 1999 21:29:41 -0800 (PST)
Message-ID: <383A2707.6EB172CB@cisco.com>
Date: Mon, 22 Nov 1999 21:32:55 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: diffserv@ietf.org
Subject: Re: [Diffserv] Diff-Serv Router Policies on ACK packets
References: <NDBBLGEHIMOEIEHCLNNEGEBJCBAA.wfang@cs.princeton.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Wenjia Fang wrote:
...
> I wonder what DiffServ WG has decided on router's policy
> w.r.t to Acknowledgement packets, if any.   Will either
> PHBs treat ACK packets any different from data packets?
> for example, never drop an ACK packet in the case of AF?
> 

Wenjia,

PHBs are normally applied to behavior aggregates as indicated
by the DSCP in the DS field. It is a matter of local policy which
packets get put into what behavior aggregate. In the diffserv
context, it doesn't make sense to have individual routers each
looking inside an IP packet to see if the ACK flag is set. Certainly,
it doesn't seem possible to decide to never drop an ACK packet that
is marked for the AF PHB without knowing something about the
rules that are governing that particular AF class in order that
its queue is never full. 

Although the WG will discuss characteristics of behavior aggregates
that are formed subject to certain rules enforced by edge behaviors
and handled by certain configurations of particular PHBs, it
seems more a topic of research whether ACKs *should* be of the
same behavior aggregate. It would seem best to attempt to use
the same behavior aggregate for ACKs as for the DATA they are
ACK'ing in the absence of clear indicators to the contrary, but
this doesn't seem to me like a topic for standardization.

        Kathie

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



From diffserv-admin@ietf.org  Tue Nov 23 03:49:27 1999
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 DAA29125
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 03:49:27 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA16556;
	Tue, 23 Nov 1999 02:40:15 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id CAA16514
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 02:40:03 -0500 (EST)
Received: from malmo.trab.se (malmo.trab.se [131.115.48.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24454
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 02:40:22 -0500 (EST)
Received: from trab1645 (dhcp4088.haninge.trab.se [131.115.157.88]) by malmo.trab.se (8.9.1/TRAB-primary-2) with SMTP id IAA06103; Tue, 23 Nov 1999 08:40:00 +0100 (MET)
Message-Id: <199911230740.IAA06103@malmo.trab.se>
From: "Istvan Cselenyi" <Istvan.I.Cselenyi@telia.se>
To: "Yoram Bernet (Exchange)" <yoramb@Exchange.Microsoft.com>
Date: Tue, 23 Nov 1999 08:39:59 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: [Diffserv] RSVP vs DiffServ
Reply-to: Istvan.I.Cselenyi@telia.se
CC: boomerang@soha.ttt.bme.hu, rsvp@ISI.EDU, diffserv@ietf.org,
        Albert Manfredi <albert.e.manfredi@boeing.com>, sgoorah@uom.ac.mu,
        Matthias_Kraner@credo.dcs.shef.ac.uk
Priority: normal
In-reply-to: <078292D50C98D2118D090008C7E9C6A6073D10E7@STAY.platinum.corp.microsoft.com>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Content-Transfer-Encoding: 7BIT
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7BIT

Yoram,

> > Moreover, we disabled the TC setup in the source code and 
> > found that it takes only 2-3 msec from the  8 ms processing time of 
> > Resv. Thus setting up per-BA TC instead of per-flow TC probably does 
> > not speeds up RSVP handling. We submitted a paper on this: 
> > http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html
> > 
> 
> I don't quite understand the numbers here. When you say that "TC takes 2-3
> msec from the 8 msec processing time of RESV", what exactly do you mean?

I mean that the Linux-RSVP router needs about 8 ms to process *one* 
Resv message, but if you switch off the setup of TC in the RSVP 
daemon, it takes 2-3 ms less to process one Resv message.

> You provide numbers below that do seem to normalize signaling burden vs.
> trafic handling burden, but - it's not clear from this statement per-se. Of
> course - I haven't yer read the source you pointed out - so - it may be
> clear in there...

Yes, I hope so.
 
> I'm not sure how to read this table, though it seems to hold the answers i'm
> looking for... 

That 2 dimensional table might be tricky for the first glance. The idea 
was to test the Boomerang router's performance in different load 
conditions. Thus we measured the forwarding latency of packets of a 
reserved flow in case of different load on data and control planes (i.e. 
different background load and signaling intensity).

> I assume that the second row holds the numbers for a traffic
> flow of 1 Kbps and the third row for a traffic flow of 1 Mbps. I gather that
> the packet size (in both cases is 1500 bytes, though for the 1 Kbps flow,
> it's likely that smaller packet sizes would be used). 

Here we fed two UDP flows into the Boomerang router - one 1 Mbps 
"foreground" flow and a "background" flow with changing bitrate (1 Kbps 
and 1 Mbps). Reservation was made for the foreground flow, which had 
a fix packet size of 1500 bytes. What about these tables:

Background data load 1 Kbps
Signaling Intensity [1/sec]	1000	2000	3000
Ratio of TC / signaling        4886	14657	41331

Background data load 1 Mbps
Signaling Intensity [1/sec]	1000	2000	3000
Ratio of TC / signaling        7321	19803	43578

> I'm not sure what the
> 1000/2000/3000 numbers across the top row mean - background something or
> other... Also - what does the 'signaling intensity [1/sec]' mean? Is that
> the assumed signaling rate for the flow? or is that all the signaling from
> background flows?

Besides the data flows, we also generated extra Boomerang messages 
(without corresponding data flows) in order to load the control plane. 
Signaling intensity expresses how many Boomerang messages are 
received by the router within one second (not the assumed signaling 
rate).

I hope this helps.

Istvan


--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: Istvan.I.Cselenyi@telia.se
--------------------------------------------------

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



From diffserv-admin@ietf.org  Tue Nov 23 10:17:46 1999
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 KAA14726
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 10:17:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA25801;
	Tue, 23 Nov 1999 09:26:35 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA25766
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 09:26:26 -0500 (EST)
Received: from samar.sasi.com (sasi.com [164.164.56.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17374
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 09:26:31 -0500 (EST)
Received: from sunc6.sasi.com (sunc6.sasi.com [10.0.32.6])
	by samar.sasi.com (8.9.3/8.9.3) with ESMTP id TAA11639;
	Tue, 23 Nov 1999 19:56:42 +0530 (IST)
Received: from rajivc (pcc88.sasi.com [10.0.32.88])
	by sunc6.sasi.com (8.9.3/8.9.3) with SMTP id TAA21111;
	Tue, 23 Nov 1999 19:56:39 +0530 (IST)
Message-ID: <005001bf35be$bfe8b2e0$5820000a@rajivc.sasi.com>
From: "Rajiv Chakravorty" <rajivc@sasi.com>
To: <Istvan.I.Cselenyi@telia.se>,
        "Masanobu Yuhara" <yuhara@flab.fujitsu.co.jp>
Cc: <yoramb@exchange.microsoft.com>, <albert.e.manfredi@boeing.com>,
        <sgoorah@uom.ac.mu>, <boomerang@soha.ttt.bme.hu>, <rsvp@isi.edu>,
        <diffserv@ietf.org>
Subject: Re: [Diffserv] RSVP vs DiffServ
Date: Tue, 23 Nov 1999 19:56:36 +0530
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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Right. The paper can downloaded from the authors Web-site
http://www.cs.sunysb.edu/~neogi/

Regards,
Rajiv Chakravorty
----------------------------------------------------------------------------
---
Silicon Automation Systems(SAS), Bangalore, India
Email: rajivc@sasi.com            http://www.sasi.com




>There's a paper on RSVP performace:
>
>A. Neogi, et. al, "Performance Analysis of an RSVP-Capable Router",
>IEEE Network, Vol.14, No. 5, Sep./Oct. 1999.
>
>------
>Masanobu Yuhara yuhara@flab.fujitsu.co.jp
>Fujitsu Laboratories Ltd.
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Tue Nov 23 10:39:03 1999
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 KAA25749
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 10:39:03 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA26553;
	Tue, 23 Nov 1999 09:58:54 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA26527
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 09:58:50 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05121
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 09:59:07 -0500 (EST)
Received: from nbitar1 ([152.148.89.22])
	by alpo.casc.com (8.9.1a/8.9.1) with SMTP id JAA06201;
	Tue, 23 Nov 1999 09:57:59 -0500 (EST)
Received: by localhost with Microsoft MAPI; Tue, 23 Nov 1999 09:54:33 -0500
Message-ID: <01BF3598.BE9D6370.nbitar@lucent.com>
From: Nabil Bitar <nbitar@lucent.com>
Reply-To: "nbitar@lucent.com" <nbitar@lucent.com>
To: "'Kathleen Nichols'" <kmn@cisco.com>
Cc: "diffserv@ietf.org" <diffserv@ietf.org>
Subject: RE: [Diffserv] Diff-Serv Router Policies on ACK packets
Date: Tue, 23 Nov 1999 09:54:32 -0500
Organization: INS Lucent Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



On Tuesday, November 23, 1999 12:33 AM, Kathleen Nichols 
[SMTP:kmn@cisco.com] wrote:
>
>
>> Although the WG will discuss characteristics of behavior aggregates
> that are formed subject to certain rules enforced by edge behaviors
> and handled by certain configurations of particular PHBs, it
> seems more a topic of research whether ACKs *should* be of the
> same behavior aggregate. It would seem best to attempt to use
> the same behavior aggregate for ACKs as for the DATA they are
> ACK'ing in the absence of clear indicators to the contrary, but
> this doesn't seem to me like a topic for standardization.
>
>         Kathie
>

Hi Kathie,

I don't see whether currently there is a capability to mark the ack packets 
with the same BA as the data at the ingress router for the acks. This goes 
back to the fact that diffserv is focused now on unidirectional traffic 
where marking and policing is sender based. That is, DATA sent will be 
marked and policed according to the sender's profile. The same for the 
ACKs, they will be marked and policed according to the ack sender's 
profile. There are variations on this where a mutli-field classifier at the 
ingress router that includes destination ip address and destination port 
number will make it easier, although this requires apriori knowledge of 
this information. the generic problem where dynamic coordination is made 
between the two ends of a tcp sessions based on either end's BA is not 
addressed yet.  Additionally, this problem is beyond acks. I see it 
effecting any two-way sessions by which the session quality is effected by 
both directions of the traffic. An example that I stated some time back is 
a VoIP service when one end of the session has golden service (built using 
EF or some AF class) and the other has best-effort service. Can one make 
both directions have golden services in that case for the duration of the 
session? If not, the person with the golden service will get the quality of 
that service when he/she talks to another person with the same service 
level or better. Are mechanisms that allow this sort of things still out of 
the scope of the WG?

Nabil.

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


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



From diffserv-admin@ietf.org  Tue Nov 23 10:50:06 1999
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 KAA01594
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 10:50:05 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27074;
	Tue, 23 Nov 1999 10:17:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27043
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 10:17:39 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14866
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 10:18:00 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA27808 for <diffserv@ietf.org>; Tue, 23 Nov 1999 15:17:27 GMT
Received: from hursley.ibm.com (lig32-239-215-243.emea.lig-dial.ibm.com [32.239.215.243]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA27518 for <diffserv@ietf.org>; Tue, 23 Nov 1999 15:17:23 GMT
Message-ID: <383AA68E.260D612A@hursley.ibm.com>
Date: Tue, 23 Nov 1999 08:37:02 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Diff Serv <diffserv@ietf.org>
Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
References: <6342F12F9359D311990B009027A1B9B603E747@monterey.pluris.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

The way charters get updated is by a combination of direction from
the Area Directors, agreement of the WG chairs, and consensus of the WG.

One of the things ADs and chairs insist on are deliverables and milestones
that can be delivered and reached. That's why the diffserv charter has always
explicitly excluded end to end services: nobody has the recipe for turning
that topic into deliverables. The ADs and chairs believe that we do now
know how to approach the topic of defining behavior aggregates 
(i.e. the edge to edge behavior of a diffserv network). We *will* propose 
a charter update to reflect this - just a little patience please.

   Brian

Bora Akyol wrote:
> 
> I completely agree with Juha on this.
> One of the most frustrating things about the Diffserv WG is that it is
> trying to define mechanisms without considering the services that may use
> them. Should we have a vote for charter amendment?
> 
> Bora Akyol, Pluris
> http://www.pluris.com/
> 
> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi]
> Sent: Tuesday, November 16, 1999 4:19 PM
> To: Brian E Carpenter
> Cc: Roland Bless; DiffServ
> Subject: Re: Services or PHBs? (was Re: [Diffserv] EF with Drop ?)
> 
> Brian E Carpenter writes:
> 
>  > Need I say again that services are outside the diffserv WG charter?
> 
> is there another wg to which they belong or can diffserv change its
> charter?  the current situation is simply unbearable and will result in
> countless new phb proposal when in fact they are proposing services.
> 
> -- juha
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/



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



From diffserv-admin@ietf.org  Tue Nov 23 11:11:14 1999
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 LAA11678
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 11:11:13 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27118;
	Tue, 23 Nov 1999 10:18:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27081
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 10:17:51 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15000
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 10:18:11 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA37314; Tue, 23 Nov 1999 15:17:41 GMT
Received: from hursley.ibm.com (lig32-239-215-243.emea.lig-dial.ibm.com [32.239.215.243]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA34446; Tue, 23 Nov 1999 15:17:36 GMT
Message-ID: <383AA8E8.1F0B3EA@hursley.ibm.com>
Date: Tue, 23 Nov 1999 08:47:04 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] RSVP vs DiffServ
References: <199911210248.LAA04311@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Masataka,

As was clear in your presentation at IWS99 in Osaka, the main problem
you have with diffserv is that your own router design has serious
problems dealing with diffserv, due to its specific approach to parallelism
in the routing core. Please don't extrapolate from this to a general
attack on diffserv; or if you do, please don't do it on this mailing
list which is dedicated to the milestones and deliverables of the diffserv
WG. The scaling issue with Integrated Services (not with RSVP itself) is
also out of scope here.

Thanks

   Brian

Masataka Ohta wrote:
> 
> > > >   It would clarify things if you could explain "scalability with respect
> > > > to what?"
> > >
> > > I hope you can find an answer to this in our study about scalability of
> > > QoS signaling as of today:
> > >
> > > http://soha.ttt.bme.hu/boomerang/public/decides.zip
> >
> > FYI, we have proven in our INET '98 paper that multicast
> > routing table entries can not be aggregated.
> 
> To my surprise, I have got a few questions on the location of the paper,
> even though INET, the Internet Summit, is an annual conference of ISOC,
> which is a legal umbrella of IETF.
> 
> The referece information is:
> 
>         Manolo Sola, Masataka Ohta, Toshinori Maeno,
>         "Scalability of Internet Multicast Protocols",
>         Proceedings of INET'98,
>         http://www.isoc.org/inet98/proceedings/6d/6d_3.htm,
>         July 1998.
> 
> > There also is an easy proof that RSVP scales at the backbone.
> 
> A brief discription of the easy proof is that a high speed backbone needs
> parallel hardware (including parallel routing tables, parallel policers
> and parallel schedulers) amount of which is proportional to the speed
> of the backbone or the expected number of flows at the backbone.
> 
> FYI, I have pointed it out several times in RSVP ML before the silly
> attempt of diffserve was proposed.
> 
>                                                         Masataka Ohta
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


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



From diffserv-admin@ietf.org  Tue Nov 23 11:42:04 1999
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 LAA26948
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 11:42:04 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27809;
	Tue, 23 Nov 1999 10:41:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA27779
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 10:41:54 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27382
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 10:42:14 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id HAA08136
	for <diffserv@external.cisco.com>; Tue, 23 Nov 1999 07:51:22 -0800 (PST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by proxy2.cisco.com with SMTP (MailShield v1.5); Tue, 23 Nov 1999 07:44:11 -0800
Received: from nbitar1 ([152.148.89.22])
	by alpo.casc.com (8.9.1a/8.9.1) with SMTP id KAA16343;
	Tue, 23 Nov 1999 10:21:01 -0500 (EST)
Received: by localhost with Microsoft MAPI; Tue, 23 Nov 1999 10:17:35 -0500
Message-ID: <01BF359B.F6024490.nbitar@lucent.com>
From: Nabil Bitar <nbitar@lucent.com>
Reply-To: "nbitar@lucent.com" <nbitar@lucent.com>
To: "'Juha Heinanen'" <jh@lohi.eng.telia.fi>
Cc: "'Nabil Seddigh'" <nseddigh@nortelnetworks.com>,
        "gja@dnrc.bell-labs.com"
	 <gja@dnrc.bell-labs.com>,
        "jamel@di.ufpe.br" <jamel@di.ufpe.br>,
        "tonyhain@microsoft.com" <tonyhain@microsoft.com>,
        "diffserv@external.cisco.com" <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
Date: Tue, 23 Nov 1999 10:17:34 -0500
Organization: INS Lucent Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-SMTP-HELO: alpo.casc.com
X-SMTP-MAIL-FROM: nbitar@lucent.com
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: alpo.casc.com [152.148.10.6]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Juha,
I mainly agree with what you said below about the af and its knobs. 
However, in the case of background service that you talk about below, do 
you have one drop-level? That is, are all packets that belong to an LBE 
service by default marked red when you use af to provide an LBE service? if 
it is, then my question is and was do you still call the resulting PHB, 
i.e. providing one drop-level, af? There is nothing that prevents you from 
doing so. It is a matter of what really defines an AF class. The impression 
that I had all along is that what defines an af class are the three drop 
preference levels. Is this condition relaxed so that you can have up to 
three drop preference levels rather than three (I believe that the RFC says 
that two are allowed and should be used only in particular situations but 
that three are preferred). Is it this the case.? or not?

Nabil.


On Tuesday, November 16, 1999 7:35 PM, Juha Heinanen 
[SMTP:jh@lohi.eng.telia.fi] wrote:
> Nabil Bitar writes:
>
>  > Is AF a universal PHB
>  > so that any PHB can be mapped to an appropriately configured instance 
of
>  > AF? Is it the way that is intended to be?
>
> i don't claim that af is universial, but it fits very well to cases
> where cbwfq with a possible ceiling can be used for packet forwarding
> and where dropping of packets can be based on red.  background service
> definitely fits very well to that.
>
> -- juha
>
>
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


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



From diffserv-admin@ietf.org  Tue Nov 23 13:23:21 1999
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 NAA17394
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 13:23:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA01472;
	Tue, 23 Nov 1999 12:38:07 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA01438
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 12:38:03 -0500 (EST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24366
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 12:38:24 -0500 (EST)
Message-Id: <199911231738.MAA24366@ietf.org>
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprtp1.ntcom.nortel.net; Tue, 23 Nov 1999 12:33:31 -0500
Received: from zcard00f.ca.nortel.com ([47.208.128.127]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id XHB44AN6; Tue, 23 Nov 1999 12:33:29 -0500
Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id VA6MKCV2; Tue, 23 Nov 1999 12:33:30 -0500
Date: Tue, 23 Nov 1999 12:32:53 -0500 (EST)
From: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Reply-To: "Nabil Seddigh" <nseddigh@nortelnetworks.com>
Subject: RE: [Diffserv] Diff-Serv Router Policies on ACK packets
To: nbitar@lucent.com
cc: kmn@cisco.com, diffserv@ietf.org, wfang@cs.princeton.edu
X-Mailer: Rosa 2.1.1 HP-UXB.10.20
X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-ID: <Rosa.HP-UXB.10..2.1.1.991123123253.26991o@zcarh014>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA01439
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

Nabil Bitar wrote:

>I don't see whether currently there is a capability to mark the 
> ack packets with the same BA as the data at the ingress 
> router for the acks. This goes back to the fact that diffserv
> is focused now on unidirectional traffic...
>
> [..............stuff deleted.....]
>
> Additionally, this problem is beyond acks. I see it 
>effecting any two-way sessions by which the session quality 
> is effected by both directions of the traffic. An example that 
> I stated some time back is a VoIP service when one end of 
> the session has golden service (built using EF or some AF 
> class) and the other has best-effort service. Can one make
>both directions have golden services in that case for the 
>duration of the session? If not, the person with the golden 
> service will get the quality of that service when he/she talks 
> to another person with the same service level or better. 
> Are mechanisms that allow this sort of things still out
>of the scope of the WG?Nabil.Plan
>

Hi Nabil :)

I agree with your statement that the problem is beyond ACKs
and also extends to VoIP services etc. In general, in SOME 
cases, there are requirements for utilities and schemes to install
"correlated" filters/classifiers at ingress routers of both
communicating parties. To some extent, this is already possible
today.

Today, it is actually possible to have pre-installed (relatively static)
filters that allow:

  - One-to-one services (source & destination are fixed)
  - One-to-few services ( source and few destinations are fixed)

With the above, one can clearly construct a number of services
where both ingress routers have the same rules for the two
communicating parties. This can be done using standard policy 
management tools. Neither of the above two types of services
would NECESSARILY require Layer 4 information. Filters can 
be based on Layer 3 information alone.

There are 2 other cases for which additional mechanisms
are required to enable installation of "duplicate" filters
at 2 ingress routers.

a.) In the case where a one-to-anywhere service is offered
  (as in today's Internet), and there is a need to have
  "duplicate" filters, the filter on the sender side can
  be static and pre-installed. However, the filter on the
  receiver side ingress router would have to be dynamically
  installed via  a tool (BB?) that is prompted based on 
  some trigger. 

b.) The case where both filters are dynamically installed 
     via a tool that is prompted based on a trigger.

BTW, the above discussion  acknowledges the need for both static and
dynamic setting of filters. This is independent of the approach to
provisioning.  It is possible to have static/dynamic filters in
combination with static  provisioning. 

If as Brian's note indicates, the WG is thinking of standardizing
services, I suggest we clearly delineate and separate the discussion
between provisioning of core router resources and co-ordinated
configuration of edge devices rules.

Regards
Nabil Seddigh
nseddigh@nortelnetworks.com


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



From diffserv-admin@ietf.org  Tue Nov 23 23:07:34 1999
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 XAA12021
	for <diffserv-archive@ietf.org>; Tue, 23 Nov 1999 23:07:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA18555;
	Tue, 23 Nov 1999 22:33:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id WAA18525
	for <diffserv@optimus.ietf.org>; Tue, 23 Nov 1999 22:32:59 -0500 (EST)
Received: from duettech.com (snt.snt.com [209.24.228.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25967
	for <diffserv@ietf.org>; Tue, 23 Nov 1999 22:33:16 -0500 (EST)
Received: (from root@localhost)
	by duettech.com (8.8.8/8.8.8) id TAA18980;
	Tue, 23 Nov 1999 19:33:12 -0800 (PST)
Received: from snt002(199.172.181.2) by duet.duettech.com via smap (V2.1)
	id xma018965; Tue, 23 Nov 99 19:32:53 -0800
Received: from duettech.com ([199.172.183.52])
	by casnt.ca.duettech.com (8.9.0/8.9.0) with SMTP id TAA07873;
	Tue, 23 Nov 1999 19:28:48 -0800 (PST)
Received: from surat.snt.com by  duettech.com  (4.1/SMI-4.1-S&T)
	id AA24515; Wed, 24 Nov 99 08:59:53 IST
Received: from duettech.com (greenland) by surat.snt.com (4.1/SMI-4.1-iS&T)
        id AA03039; Wed, 24 Nov 99 08:59:52 IST
Message-Id: <383B5C75.E754E9B2@duettech.com>
Date: Wed, 24 Nov 1999 09:03:09 +0530
From: Sarraju Narasinga Rao <snrao@duettech.com>
Organization: Duet Technologies
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
Mime-Version: 1.0
Cc: rsvp@ISI.EDU, diffserv@ietf.org, Bob Braden <braden@ISI.EDU>
Subject: Re: [Diffserv] RSVP vs DiffServ
References: <078292D50C98D2118D090008C7E9C6A6073D10E7@STAY.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi

I have been following this thread with keen interest. Thank you all for
bringing up and discussing a topic that helps clarify the direction that
deployment of signaled QoS will take.

That said, IMHO, this discussion would probably benefit from being moved
to a separate mailing list. I recollect that Bob Braden had pointed out
in one of the early mails in this thread that neither the RSVP nor the
DiffServ list is the "appropriate" list for this discussion.

Apart from the "appropriateness" criteria, this will also help conserve
bandwidth (this thread is currently duplicated on both lists). Also, it
leads to less clutter in the mailboxes (for those of us that are
subscribed to both lists).

Bob, is your offer of a separate list (end2end-interest@isi.edu) still
open? 

I apologise for the routine, administrative nature of this posting. I
hope to make useful technical contributions soon. 

Regards
-Sarraju

*******************************
* Sarraju Narasinga Rao       *
* Duet Technologies Pvt. Ltd  *
* SDF # B-1, NEPZ             *
* Noida, UP 201305            *
* INDIA                       *
*-----------------------------*
* Phone: +91(1191)568302-9    *
*        +91(1191)567002-5    *
*         x136                *
* eFax : +1(603)843-3302      *
* Fax  : +91(1191)562970      *
* email: snrao@duettech.com   *
*******************************

"Yoram Bernet (Exchange)" wrote:
> 
> Istvan:
> 
> Thank you for your in-depth response. Comments below...
> 
> > Yes, we had to use the per-flow RSVP version, the only one which was
> > available. Moreover, we disabled the TC setup in the source code and
> > found that it takes only 2-3 msec from the  8 ms processing time of
> > Resv. Thus setting up per-BA TC instead of per-flow TC probably does
> > not speeds up RSVP handling. We submitted a paper on this:
> > http://soha.ttt.bme.hu/boomerang/public/net2k_abs.html
> >
> 
> I don't quite understand the numbers here. When you say that "TC takes 2-3
> msec from the 8 msec processing time of RESV", what exactly do you mean?
> Let's normalize the measurements to per-flow measurements. In that case -
> RESV messages come in at a certain rate (typically one per 30 seconds per
> flow), and each message needs some processor time. Data packets on the flow
> come in at a certain rate (usually a couple of orders of magnitude higher
> than the signaling messages)and they incurr some processor time. So - is the
> 2-3 msec the time required per packet or for all the packets that come in
> every 30 seconds (for each signaling message)? What rate is the data flow?
> You provide numbers below that do seem to normalize signaling burden vs.
> trafic handling burden, but - it's not clear from this statement per-se. Of
> course - I haven't yer read the source you pointed out - so - it may be
> clear in there...
> 
> > I was also curious, thus searched our measurements and found
> > something similar for the per-flow TC Boomerang prototype:
> >
> > Processing power of traffic handling / signaling
> >
> >                               Signaling Intensity [1/sec]
> > Backgr. rate  1000    2000    3000
> > 1 Kbps                        4886    14657   41331
> > 1 Mbps                        7321    19803   43578
> >
> > Foreground (reserved) traffic rate 1 Mbps
> > Boomerang refresh rate 30 sec
> > Size of data packets 1500 bytes
> 
> I'm not sure how to read this table, though it seems to hold the answers i'm
> looking for... I assume that the second row holds the numbers for a traffic
> flow of 1 Kbps and the third row for a traffic flow of 1 Mbps. I gather that
> the packet size (in both cases is 1500 bytes, though for the 1 Kbps flow,
> it's likely that smaller packet sizes would be used). I'm not sure what the
> 1000/2000/3000 numbers across the top row mean - background something or
> other... Also - what does the 'signaling intensity [1/sec]' mean? Is that
> the assumed signaling rate for the flow? or is that all the signaling from
> background flows?
> >
> > That is traffic handling of a 1 Mbps flow consumes about 5000 - 45000
> > times more CPU than the related signaling, depending on the load of
> > control and data planes. Since our Linux box needs more than 100
> > times more time for handling RSVP than Boomerang, these figures are
> > probably between 50 - 450 for the Linux/RSVP. Moreover, this ratio is
> > less for tiny flows (e.g. 64K or 8K VoIP).
> >
> 
> Interesting - these numbers do confirm that the burden due to traffic
> handling is substantially greater than that due to signaling. You note that
> the ratio won't be as bad for tiny flows. With smaller flows, there is less
> data to move, but - the packet sizes tend to be smaller, because these tend
> to be audio flows requiring less latency. So - the per-packet burden of
> traffic handling would not go down quite as quickly as one might consider.
> Since policing and scheduling are per-packet, this is an important
> consideration.
> 
> > But anyway, I accept that traffic handling is also worth to look at
> > and we will measure this for RSVP a.s.a.p.
> >
> 
> Great - i'm very interested in hearing more. Thanks for the insight.
> 
> > Istvan
> >
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

--

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



From diffserv-admin@ietf.org  Wed Nov 24 02:03:20 1999
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 CAA15223
	for <diffserv-archive@ietf.org>; Wed, 24 Nov 1999 02:03:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA28694;
	Wed, 24 Nov 1999 01:33:34 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id BAA28662
	for <diffserv@optimus.ietf.org>; Wed, 24 Nov 1999 01:33:29 -0500 (EST)
Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26106
	for <diffserv@ietf.org>; Wed, 24 Nov 1999 01:33:49 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with SMTP id WAA02315
	for <diffserv@external.cisco.com>; Tue, 23 Nov 1999 22:43:01 -0800 (PST)
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by proxy1.cisco.com with SMTP (MailShield v1.5); Tue, 23 Nov 1999 22:34:06 -0800
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id IAA13219;
	Wed, 24 Nov 1999 08:28:37 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14395.34197.730358.605475@lohi.eng.telia.fi>
Date: Wed, 24 Nov 1999 08:28:37 +0200 (EET)
To: "nbitar@lucent.com" <nbitar@lucent.com>
Cc: "'Nabil Seddigh'" <nseddigh@nortelnetworks.com>,
        "gja@dnrc.bell-labs.com"
	 <gja@dnrc.bell-labs.com>,
        "jamel@di.ufpe.br" <jamel@di.ufpe.br>,
        "tonyhain@microsoft.com" <tonyhain@microsoft.com>,
        "diffserv@external.cisco.com" <diffserv@external.cisco.com>
Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
In-Reply-To: <01BF359B.F6024490.nbitar@lucent.com>
References: <01BF359B.F6024490.nbitar@lucent.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
X-SMTP-HELO: lohi.eng.telia.fi
X-SMTP-MAIL-FROM: jh@lohi.eng.telia.fi
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: lohi.eng.telia.fi [195.10.149.18]
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Nabil Bitar writes:

 > I mainly agree with what you said below about the af and its knobs. 
 > However, in the case of background service that you talk about below, do 
 > you have one drop-level? That is, are all packets that belong to an LBE 
 > service by default marked red when you use af to provide an LBE
 > service? 

there can be one or two dp levels depending on how the service is
defined.  as i defined background service in an earlier message, only
one dp level makes sense, but lbe could have one or two dp levels.

 > if it is, then my question is and was do you still call the resulting PHB, 
 > i.e. providing one drop-level, af?

sure since one dp level clearly is a subset of three dp levels.  you
simply send packets of only one color to the network.

 > There is nothing that prevents you from 
 > doing so. It is a matter of what really defines an AF class. The impression 
 > that I had all along is that what defines an af class are the three drop 
 > preference levels. Is this condition relaxed so that you can have up to 
 > three drop preference levels rather than three (I believe that the RFC says 
 > that two are allowed and should be used only in particular situations but 
 > that three are preferred). Is it this the case.? or not?

an af IMPLEMENTATION should support at least two dp levels, but as i
said in above, a SERVICE doesn't need to use all of them.

-- juha


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



From diffserv-admin@ietf.org  Wed Nov 24 13:18:57 1999
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 NAA16785
	for <diffserv-archive@ietf.org>; Wed, 24 Nov 1999 13:18:57 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA16391;
	Wed, 24 Nov 1999 12:17:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA16362
	for <diffserv@optimus.ietf.org>; Wed, 24 Nov 1999 12:17:38 -0500 (EST)
Received: from alpo.casc.com (alpo.casc.com [152.148.10.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17227
	for <diffserv@ietf.org>; Wed, 24 Nov 1999 12:17:47 -0500 (EST)
Received: from nbitar1 ([152.148.89.22])
	by alpo.casc.com (8.9.1a/8.9.1) with SMTP id MAA17770;
	Wed, 24 Nov 1999 12:15:44 -0500 (EST)
Received: by localhost with Microsoft MAPI; Wed, 24 Nov 1999 12:12:11 -0500
Message-ID: <01BF3675.22C347C0.nbitar@lucent.com>
From: Nabil Bitar <nbitar@lucent.com>
Reply-To: "nbitar@lucent.com" <nbitar@lucent.com>
To: "'Nabil Seddigh'" <nseddigh@nortelnetworks.com>
Cc: "kmn@cisco.com" <kmn@cisco.com>, "diffserv@ietf.org"
	 <diffserv@ietf.org>,
        "wfang@cs.princeton.edu"
	 <wfang@cs.princeton.edu>
Subject: RE: [Diffserv] Diff-Serv Router Policies on ACK packets
Date: Wed, 24 Nov 1999 12:12:10 -0500
Organization: INS Lucent Technologies
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Hi Nabil (Seddigh)
> Nabil Bitar wrote:
>
> >I don't see whether currently there is a capability to mark the
> > ack packets with the same BA as the data at the ingress
> > router for the acks. This goes back to the fact that diffserv
> > is focused now on unidirectional traffic...
> >
> > [..............stuff deleted.....]
> >
> > Additionally, this problem is beyond acks. I see it
> >effecting any two-way sessions by which the session quality
> > is effected by both directions of the traffic. An example that
> > I stated some time back is a VoIP service when one end of
> > the session has golden service (built using EF or some AF
> > class) and the other has best-effort service. Can one make
> >both directions have golden services in that case for the
> >duration of the session? If not, the person with the golden
> > service will get the quality of that service when he/she talks
> > to another person with the same service level or better.
> > Are mechanisms that allow this sort of things still out
> >of the scope of the WG?
> >
>
> Hi Nabil :)
>
> I agree with your statement that the problem is beyond ACKs
> and also extends to VoIP services etc. In general, in SOME
> cases, there are requirements for utilities and schemes to install
> "correlated" filters/classifiers at ingress routers of both
> communicating parties. To some extent, this is already possible
> today.
>
> Today, it is actually possible to have pre-installed (relatively static)
> filters that allow:
>
>   - One-to-one services (source & destination are fixed)
>   - One-to-few services ( source and few destinations are fixed)
>
> With the above, one can clearly construct a number of services
> where both ingress routers have the same rules for the two
> communicating parties. This can be done using standard policy
> management tools. Neither of the above two types of services
> would NECESSARILY require Layer 4 information. Filters can
> be based on Layer 3 information alone.
>
This is clearly doable. However, how well does it scale (e.g. effected by a 
combination of static configuration and service scope) ?  Furthermore, it 
limits you to a static apriori knowledge. While there is use for such 
configuration, it is practically limiting from a  deployment scope and the 
type of services that you can practically offer. The question of whether 
you need to do the filtering at layer 3 or layer 4 depends on your traffic 
conditioning and what you to do offer.

> There are 2 other cases for which additional mechanisms
> are required to enable installation of "duplicate" filters
> at 2 ingress routers.
>
> a.) In the case where a one-to-anywhere service is offered
>   (as in today's Internet), and there is a need to have
>   "duplicate" filters, the filter on the sender side can
>   be static and pre-installed.
In my email, I was implicitly referring to "from one to anywhere" service.
>   receiver side ingress router would have to be dynamically
>   installed via  a tool (BB?) that is prompted based on
>   some trigger.
>
that is more like what I referred to in mechanisms needed to dynamically 
install filters. I am not sure if this in the realm of the BB now or 
whether it should be!

> b.) The case where both filters are dynamically installed
>      via a tool that is prompted based on a trigger.
>
> BTW, the above discussion  acknowledges the need for both static and
> dynamic setting of filters. This is independent of the approach to
> provisioning.  It is possible to have static/dynamic filters in
> combination with static  provisioning.
>
The dynamic case is the more challenging and more generic.
> If as Brian's note indicates, the WG is thinking of standardizing
> services,
Mechanisms that enable the installation of dynamic filters in the way 
referred to above are service building blocks as much as PHBs are. Thus, 
such mechanisms do not imply specific services and do not require service 
standardization. In addition, I do not think that Brian is talking about 
standardizing services but rather probably working on services from 
informational perspective to see how the PHBs defined so far will be used 
and whether there is need for more.


> I suggest we clearly delineate and separate the discussion
> between provisioning of core router resources and co-ordinated
> configuration of edge devices rules.
>
What we are talking about is clearly an edge router issue. The above 
discussion is about how to instantiate traffic conditioning rules. I think 
such instantiation mechanisms are explicitly stated as part of the diffserv 
router conceptual model. Aren't they?

> Regards
> Nabil Seddigh
> nseddigh@nortelnetworks.com
>

Regards,
Nabil Bitar. 

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



From diffserv-admin@ietf.org  Thu Nov 25 11:30:58 1999
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 LAA03330
	for <diffserv-archive@ietf.org>; Thu, 25 Nov 1999 11:30:58 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA21301;
	Thu, 25 Nov 1999 10:52:58 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id KAA21275
	for <diffserv@optimus.ietf.org>; Thu, 25 Nov 1999 10:52:54 -0500 (EST)
Received: from nwcst294.netaddress.usa.net (nwcst294.netaddress.usa.net [204.68.23.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14999
	for <diffserv@ietf.org>; Thu, 25 Nov 1999 10:53:15 -0500 (EST)
Received: (qmail 18778 invoked by uid 60001); 25 Nov 1999 15:53:02 -0000
Message-ID: <19991125155302.18777.qmail@nwcst294.netaddress.usa.net>
Received: from 204.68.23.39 by nwcst294 for [202.112.137.10] via web-mailer(M3.4.0.33) on Thu Nov 25 15:53:02 GMT 1999
Date: 25 Nov 99 08:53:02 MST
From: zhang guangming <zhangguangming@usa.net>
To: diffserv@ietf.org
X-Mailer: USANET web-mailer (M3.4.0.33)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21276
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 8bit

   As i known,The service mappings are useful for providing
   effective interoperation and end-to-end Quality of Service for IP
   Integrated Services networks containing ATM subnetworks.
   
   But why it is only natural that RSVP and the Internet Integrated
   Services (IIS) model would like to utilize the QoS properties of any
   underlying link layer including ATM, and the Diff-Serv is not ?
 
   If i want to model a Diff-Serv Over ATM,what should i pay attention?

   Thank u.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

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



From diffserv-admin@ietf.org  Thu Nov 25 11:35:36 1999
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 LAA05712
	for <diffserv-archive@ietf.org>; Thu, 25 Nov 1999 11:35:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA21679;
	Thu, 25 Nov 1999 11:08:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id LAA21648
	for <diffserv@optimus.ietf.org>; Thu, 25 Nov 1999 11:08:42 -0500 (EST)
Received: from nwcst267.netaddress.usa.net (nwcst267.netaddress.usa.net [204.68.23.12])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22519
	for <diffserv@ietf.org>; Thu, 25 Nov 1999 11:09:02 -0500 (EST)
Received: (qmail 19026 invoked by uid 60001); 25 Nov 1999 16:08:17 -0000
Message-ID: <19991125160817.19025.qmail@nwcst267.netaddress.usa.net>
Received: from 204.68.23.12 by nwcst267 for [202.112.137.10] via web-mailer(M3.4.0.33) on Thu Nov 25 16:08:17 GMT 1999
Date: 25 Nov 99 09:08:17 MST
From: zhang guangming <zhangguangming@usa.net>
To: diffserv@ietf.org
CC: brian@icair.org
X-Mailer: USANET web-mailer (M3.4.0.33)
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----NetAddressPart-01--=_yqiR0096S673715fc32"
Subject: [Diffserv] If the Diff-Serv would like to utilize the QoS properties of ATM
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This is a multi-part message in MIME format.

------NetAddressPart-01--=_yqiR0096S673715fc32
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Why it is only natural that RSVP and the Internet Integrated
Services (IIS) model would like to utilize the QoS properties =

of any underlying link layer including ATM?
Could the Diff-Serv Model use utilize the QoS properties of any
underlying link layer including ATM? How to frame it?

Thank u.


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=3D=
1

------NetAddressPart-01--=_yqiR0096S673715fc32
Content-Type: multipart/related;
	boundary="----NetAddressPart-02--=_yqiR0096S67295d5ba3"

------NetAddressPart-02--=_yqiR0096S67295d5ba3
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<STYLE TYPE=3D"text/css" TITLE=3D"Bright Colours">
	<!--
		BODY { margin-left: 115px; }
		A    { color:       blue; }
	-->
	</STYLE>
</HEAD><BODY background=3D"cid:03=3D_$yqiR0096S67$-2533058e" bgColor=3D"white">
<font face=3D"script, arial, helvetica" color=3D"blue" size=3D"4">

<pre>Why it is only natural that RSVP and the Internet Integrated
Services (IIS) model would like to utilize the QoS properties =

of any underlying link layer including ATM?
Could the Diff-Serv Model use utilize the QoS properties of any
underlying link layer including ATM? How to frame it?

Thank u.
</pre>

<BR>
<HR noshade width=3D"90%">
Get free email and a permanent address at <a href=3Dhttp://www.netaddress=
=2Ecom/?N=3D1>http://www.netaddress.com</a>
</font>
</BODY></HTML>

------NetAddressPart-02--=_yqiR0096S67295d5ba3
Content-Type: image/gif
Content-ID: <03=_$yqiR0096S67$-2533058e>
Content-Transfer-Encoding: base64

R0lGODlhGgRPAPf/AP///+f//97//9b//87//73//6X//5z//4z//3v//2v//2P//0r//2v3
/wBKUlLn/wAxOZzGzine/wBaa6Xv/4ze70re/wBSYwBKWjGtzimUrRjG7xCcvRCt1giUtQCM
rQCEpQBrhABjewBCUnPO50qElGO91kq93kLO9zHG7ym13im95yGt1hCcxgCl1gCcxgCUvQCM
tQB7nABacwA5Ss7n773W3jnO/xCl1giErQCczgCErQBrjAAxQkLO/yGl1hiczghKYwApOVK9
5xiMvb3e77XW56XW7zGUxhBjjBBrnBBzpQg5UiGEvXOMnHutzggxSjF7rRhSexhajFKU1hhC
azlrpSlShDFalBgxUjlrvXuMrSlCc4yl3pSl50palCEpUmtzpSkxY2NrpXuE1kJKjFpalEJC
hCkpUoyErXtrtZyMxqWMzlpChDkhUoxzpWNChHNSjFoxc9al7zkYSmMxe2sphN6t71IhY4RK
lNaM55xSrWspe4xalEoYUnsxhJRCnP/3///n///W///O//+9//+t//el9/+U/4RKhP+M/9Zr
1nM5c1oYWlIQUv+E985axr1StXMha/9z74RCe85avf9j50oQQtatzv9r3nMpY+dSxmsYWloQ
Sv9a1qUhhN5Ktf9Szs45pb0plJwQc6UQe2MISpQIa/fe7/9CxnMIUt6UxrVrnN57vaVajJxS
hM4IjN6Evb1jnKVKhJQ5c4QpY/9Kvf9CvecppdYhlO8hpfchrc4YjOcYnLUQe8YQhN4QlK0I
c+cAlNYAjL0Ae7UAc5wAY4wAWnMASloAOd61zr05jM45lOc5pf85tdYplIQYWuchnN4YlL0Q
e6UIa7UIc94IjM4IhN4AjNYAhMYAe60Aa4QAUmsAQt5jrbU5hP8xrfcppb0Ye7UQc4QIUr0A
c7UAa6UAY3sASs6lvfe93u+11pw5c5wAWnMAQmMAOYQASloAMYwASnsAQvfn77UAWoQAQmMA
MVIAKe/O3ufG1msAMUoAIWMAKUIAGAAAACwAAAAAGgRPAEAI/wBv2QoVShe2gwgTKhSmsKHD
hxAjSpxI8SAxdO/u3UMFoKPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP
n0CDCh1KtCjQWwJt9Wq4rVu3ZPcc0aDRo8fUESMwaJ0w4dQ5asGC/apItqxZhNmyHXsXD5nR
t3Djyp1Lt67du3jz6t3Lt6/fvyuR2lKq8ByyefNUWd0qgscOGDBe6NDhwoWOF5MyZ9KV7axn
h+aQvYN6zxQaqlWtYsU6lUYJwLBjy55Nu7bt27hz697NG4Bgwg+JUaO2bVs5a9GcpUplSZEh
QoQKKdqVdmI2bdiJlStHjJi2a53NXv9b++6do6o0sGKY0JiHjB0xIL+YP/nyfMggivTez7+/
//8ABijggAT69dtSn0GkDTfJxBMPP4kIQMABByCQgAILLPCADzhwwAEMOYAgw4gygMBHO+0c
Y8w211yjUDHouIMOOlOtJ0Jjj9FX2Y489lhZBwUGKeSQRBZp5JFIJtnTgQm+KNo7/KRRIQII
GFAAAQIIEEAAAxRQAAIPqOBhDjLwYGYIN87A1QQztJHWL7wMk5A2xhjDDTfGVMGVCO/JR5mP
O+qggpKEFmrooYgmquiiRjHZ5EHjdbPPPnB0AIOHLWTqoYcekFmmCBNcIKqoWmnFWms07LGH
JwUNI6dErrr/Kk00wGyHTjyqMKrrrrz26uuvwALo6KMHaXPMMdzIUwcIIJjJQwjQprnmBaWe
iloPQmRLwx2DFFLII72E95A255yDTjejJYOPP/Eoo0yw8MYr77z01mvvS8MS+9A1xFQTTDXV
XGPNrNE0Iwoom2zSHCKGNGwIIp70Em5Z1xhz7DnlaPPLL8zEks+9IIcs8sgkl1xgvvqmrDJF
1xRTDLLzyGLyzDTXbPPNONeE8pzcPJVMMuUhhtiMdx6zjbgrJx1RNj3jQwstOUct9dRUVy1v
vsMYg+47naCX3gUzhGBmifDFEMMHzIQTTjPRKH1WNi4f41R5TtXt1IP84IOJ1Xz3/+3334AP
iHI21NzJTTtiOOAAe475aZkOXQxCSMOhIO22Q009tY9UqaWn1QXsQevs6CHMYIMNgaeu+uqs
t/7WzhVVF5HLPTfIDz/vMLLFE0+QMAQSUURhxReSyCOPPUWX6+JD2yDjs2rrTRBCn5H9CWiP
k7mu/fbcd+99SLB/tiA3UGoywAAEeEnA+l4akMCFPqiQqQc7lOksmjcmEcw2Yfny6kHb4AY8
4HEMJozgAjdqnI6u5yMcfO+BEIygBHMWPvH0rB/9CAMDbmCBDj7gAQtQgAgTgAAKHQAFMTiT
CNQ0LWqVCgN5yANScPGQ62xjOMbJhjUGJopIVKISoOCFOf8EIYgJGvGISEzivCpolmJwY0b2
+EIMmCWiEZFOWqMylbVS0wMIjAERYJwEMGRXkWtQwx0/40ctlMjGNrrxjUliYoKIYbFjtKMe
duDBDNREKlOhqioQgIAQRsAGIgpiEIigjuUaMh53OIgVcIykJCdJSWElBUGXe4irgAEMaUjs
k8CwRloWmSBXtYgXqETlL6pxDhQto5KwjKUsZ0kUOWbylp/JhjFiNKNA0PKXwAymMEvCRDMO
0G51QwaejEEMUuJSaXKLBzSgMcxqWvOaldyZLo3Blnt0ohNuQE1rRiAGcpAjRcbYzv+eubJi
PAUf+tAHNudJz3pKEGXFcEd53gH/hs5lBWwzEIHozASHckxjGr9YJzut0yJtaGc75XjZ3PDR
DV/a86IYzWjq8pWNdnTDHe64hGqywjhmPQYykYFBJJzhDFvgwpkLNdbcgAbSmoIUGe4gxyxm
8TGN+vSnQKXgJRViLMPhgQaMaVz1AjWHQjRMjDC9nFrWAjQ/TAU9q8EA6Nh0o67O4AIRCKpY
x0rWJQ61Idix2DnMYY5StGEKJQJBE8hwiEEM4pCK0AVnFpoQavisG1mAgFW+xp7GkA0+KEWp
2UakgbI69rGQLZQcs7GxX+SiGYMZSCYywVJsRJVOM6ob3d5RN3cgAx1FYxFFiiEap0ABeuuZ
3g7gQx/r/2FvMi/IQGR3y9veWnIwmExa85CRxni84Q0UsFCGFnCDDtT2BUtYQh2SxY1jUWN5
TMHpz1QDUB6AIAYLZCD2fEve8pp3NrYsS1rWgrc+cKkABjBAhS6kgA2xIFMgqqKzZMAHPtSj
TgBbJzG4gYwBZgGphW1cfcTroxOc98EQjjBd0ssy8r0DH5IoAIWsVIABZClL8HWfBVaQqRDd
D397lN4ntoPQhGQjgHdCHAb26N34wGAyDNbBEIYg4R77+Mc+obBE1NINjXAiActVAAk5TAAP
n88AD2BBDsj0LK9yZVSgG8UopPGMXCgkLcGwWDvYKofpMSs+krEejisA5Da7+f/NMhFyRK5x
wX6MQQIryHMKUIACH/i5gxb4IApc8AJopfjKfcQAVhwQw1S4dM7d8QVCURkNcCDlFtEwFyo4
AudOe/rTI5EzRNRymHlIogMeSLWqpxwi+z2Lj31czRatsohFTGIzrnrbsaD0ClD7+teeFjVE
hlE4AXJjCVY8MYphrcU/djFbQjiDUx92i6gihE49c4q6bpcOYHv72z8W9pyvcQ5koagMPEjT
obO4mqumBtphCAMRC2EJS4hy1Fr7GT7ewQp60APcAA+4hMW92jrVqR6kuMIVQOVCRbcGkFgZ
gyHsatdEWvsgunwSOwTO8Y6bl+BlGcY1piEOccApF9H/SM4tUkGQ5igCjI/wRDhGeRZthEUc
qOxOMTKGSm+sw+NAD3pGQc7XTFI2zBazxyuFzvSm05LoRX9mUd2xU6db/epv/I00VjbKbHDy
62AP+9dhQfaym93sClXIMEYp8rO7/e3A8IUqTPEzeWL97niP4IGs3aJyUMNiBt9GMy8e9QSd
oxttcUveF8947RWTGsdEZjeUWadmFh6aiJ9m4zfPecDBrkVU1cg7kOEHOpi+EYar7jGCQcbL
N0kb5+IHKyDZ+drbPmo7yxxUpCLO9GRlK135SljG4vpcqoUtir+98pdvMpTRuTyluZbnRsWm
PUrBHNsA2DTSXnzrlOspsme+//jHfy+U+bU8pvDa18ImNveQSAnZQOUzgNF9hbTMTk+ckf6d
Vx584ONd5BeAAggsWKM15dE1g3VAYTM2IFA2Z5M2a9M29Qc3ErU1kod4t6M3A7iBHMgoBVhT
XeN7YFNjaFYflwEJBFEQhHc5zZMu8fAOpuAGbgAGTNAaTJAFTtCBOriDh4JP+ccNNZhUJyUZ
gUIFYIQIj7BXUdcdovGCjuAIrzVYnvM5oCMqIzABqMODWriFBIIyRXUnRyWEjlMZOtBUTzVG
UTdVo/EOViVOWbVVAdVVKwRWXFiHdrgfO1MxdXQOeIAHbEKCkfECXuAFd0UImSEMK6gyC/Iz
3kQV4/+0VQLlfg04W5QoImZSA3eYiZooGxUkHMRhHMihHMzhHNAhHYpkHdjhUNvRHd+RiAgx
Hvt0HiNlI2ODWIGYZvbxAvihH5vYi76IF0ykDdUwDuMwDbyAC6LYHA5jCUqoSdixDciif9JY
XcbgMtg1EbD3DiCFBgl4QIb1HmiGiyaIWy8QAybwi+iYjnBBYbKSctHQC9IgSlFlRudSHvGA
DxjUD/ugjSA1D/YwD0RTXcXQetkFg+m3GKLSGN9VggxGhkCgjhAZkT9BcATZELTzFHiTO7vT
O78TPMNTPMeTPOdwjQrRPM/jOVwhW2PYkNkjkS75kjpzVklTDsRlO5xgBF7/cgBI9kEPcANA
ABmptgMfMJRKcAopYl0kCUA4pQqK8TUJlCNE2JA8ApNUWZUtAXVfdnzt9V7xNV8iZF/41Wqu
xl/+BWDVIGAEZmAI9pQ3hmNSWRkOZpVyOZehJpP6UhzgRwmU8F5eEmIWgmQ+cF8tkF/J9ixm
4hWfSHyQcgzoYDxWZSM40pa2lWNsRpeWaZlYiRCHh3jxgJPwdSUeJgDoo2EHoAAWID8t4AGW
eCZoskcicAblADC+cI1fyA2N4AAIpJCBOJnXMxlHcJnAOZeZiQ2sVR5RMiVVciVZsiVd8iVh
MiauhmJr0iZvEidzUid3kid7Qj1R2ZuDEpzgaZXD/3l4jFgB70NCB2Al56MlEjIhYZJqzfIs
y4ZoUmBK1pkQcWNHxsAFXDADgNid2BOX4TmgL5mZdNYNGBQHCxBoIDRCVJKeV5I+DdACVtSa
69ZHFwAIgBCBDjEMxVAn5WIO1fAHWIAFIPABu6kDWnAEv0mgLlqgdpkgB4pBGsRBHtSgDmpC
KKRCLIRoLwRDMnQLNOQQNoRD5aBDPORDQCRERPSiThqRBlpnZrABLQAEVsoCWJqlPwAEYxID
MtBCidZuU9FotmAQEWFKJ5cLyOgMuZALxuAOFWVRTzqnvpiZpIYYp6ZqqzZlq/lqoRJrsvZw
tGZruMZ9Q7Zr/NBrdLqovf84nNSADogBD0QQA5XILIUZLV8FqLNWFUGgCJ46CdFQkRNxDvbI
D3bHqKhqh8M5HndiD3LgpSQyOlWGRdUyAs4GSD2gBw7jCStoQwH0Tv7XU6k6rFs4nMR2J/Bw
bIUpn/MJqM4mSNkibQ2DCNVGEdhWN9vGD91GrNzKg8OJDcNQHDFWBmVQJtEiLT4qplwEbUKw
BofUMKnwWXKDkfzgIKrgCpzWrfqqg996bWJ2R2eQbhfqQrb6cIEErfJGRIOQV81IpNEUD1Cz
rxJbrDGaMnR0LHeURykWps8qSIRkSIh0inN2DI4UD7Q3sSjbgf2aEMOwHcNBDeawHZ/QBlJw
ZYrFph5SoAZgVAilCEbUQRYBNCPH0ArqkLJGK4Ar26EjV3Inl3LOsHIt56kwJ3M0ZxY2Fww4
xws6x3O84HNH+7Wbl7Sa1CKwwAvPgAvIOBgpmAmewFJL4YoNkRZlywuVBScbUw7m4AursApg
27dYJ7b1d6auokq+EAzlIg/f4LeKK3SAG7gUcXR1cgxKt7iUy3GN67ixQzgCNA/5IKyV+7mg
drmYGzu7JCPoIKegm7pvBrhd17quC7e3ZA7w4A6Tcqqqe7s/FhAAO7mg27u0FRAAOw==

------NetAddressPart-02--=_yqiR0096S67295d5ba3--

------NetAddressPart-01--=_yqiR0096S673715fc32--

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



From diffserv-admin@ietf.org  Thu Nov 25 13:14:09 1999
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 NAA24972
	for <diffserv-archive@ietf.org>; Thu, 25 Nov 1999 13:14:09 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA23838;
	Thu, 25 Nov 1999 12:36:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id MAA23806
	for <diffserv@optimus.ietf.org>; Thu, 25 Nov 1999 12:36:36 -0500 (EST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06171
	for <diffserv@ietf.org>; Thu, 25 Nov 1999 12:36:56 -0500 (EST)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88])
	by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with SMTP id JAA03803
	for <diffserv@external.cisco.com>; Thu, 25 Nov 1999 09:36:32 -0800 (PST)
Received: from sdns.nudt.edu.cn (sdns.nudt.edu.cn [202.197.0.181]) by proxy1.cisco.com with SMTP (MailShield v1.5); Thu, 25 Nov 1999 09:37:01 -0800
Received: from netzzy ([172.26.12.10]) by sdns.nudt.edu.cn
          (Netscape Messaging Server 3.6)  with SMTP id AAA1CC0
          for <diffserv@external.cisco.com>;
          Thu, 25 Nov 1999 15:24:45 +0800
Message-ID: <000801bf3716$72080680$0a0c1aac@nudt.edu.cn>
From: "yjliu" <yjliu@nudt.edu.cn>
To: <diffserv@external.cisco.com>
Date: Thu, 25 Nov 1999 15:26:50 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01BF3759.7E987180"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-SMTP-HELO: sdns.nudt.edu.cn
X-SMTP-MAIL-FROM: yjliu@nudt.edu.cn
X-SMAP-Received-From: outside
X-SMTP-PEER-INFO: sdns.nudt.edu.cn [202.197.0.181]
Subject: [Diffserv] subscribe diffserv <yjliu@nudt.edu.cn>
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF3759.7E987180
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

DQo=

------=_NextPart_000_0005_01BF3759.7E987180
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yMzE0LjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_0005_01BF3759.7E987180--



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



From diffserv-admin@ietf.org  Fri Nov 26 16:42:29 1999
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 QAA12872
	for <diffserv-archive@ietf.org>; Fri, 26 Nov 1999 16:42:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA00022;
	Fri, 26 Nov 1999 15:59:38 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id PAA29990
	for <diffserv@optimus.ietf.org>; Fri, 26 Nov 1999 15:59:34 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23996
	for <diffserv@ietf.org>; Fri, 26 Nov 1999 15:59:58 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA72074; Fri, 26 Nov 1999 20:59:28 GMT
Received: from hursley.ibm.com (ss7.bld.socks.ibm.com [9.14.4.72]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA31348; Fri, 26 Nov 1999 20:59:26 GMT
Message-ID: <383EF464.BCD6A0CD@hursley.ibm.com>
Date: Fri, 26 Nov 1999 14:58:12 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: zhang guangming <zhangguangming@usa.net>
CC: diffserv@ietf.org
Subject: Re: [Diffserv] If the Diff-Serv would like to utilize the QoS properties 
 of ATM
References: <19991125160817.19025.qmail@nwcst267.netaddress.usa.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Zhang,

Please set your mail system to send plain text, not fancy formats which
waste bandwidth.

Diffserv mappings to ATM are being specified by the ATM Forum and are
not the job of this working group.

Regards

  Brian Carpenter
  diffserv co-chair

zhang guangming wrote:
> 
> Why it is only natural that RSVP and the Internet Integrated
> Services (IIS) model would like to utilize the QoS properties
> of any underlying link layer including ATM?
> Could the Diff-Serv Model use utilize the QoS properties of any
> underlying link layer including ATM? How to frame it?
> 
> Thank u.

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



From diffserv-admin@ietf.org  Fri Nov 26 16:42:39 1999
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 QAA12929
	for <diffserv-archive@ietf.org>; Fri, 26 Nov 1999 16:42:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA00219;
	Fri, 26 Nov 1999 16:06:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA00186
	for <diffserv@optimus.ietf.org>; Fri, 26 Nov 1999 16:06:41 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27119
	for <diffserv@ietf.org>; Fri, 26 Nov 1999 16:07:05 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA80366 for <diffserv@ietf.org>; Fri, 26 Nov 1999 21:06:35 GMT
Received: from hursley.ibm.com (ss3.bld.socks.ibm.com [9.14.4.68]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA19702 for <diffserv@ietf.org>; Fri, 26 Nov 1999 21:06:33 GMT
Message-ID: <383EF60D.A5F9EE85@hursley.ibm.com>
Date: Fri, 26 Nov 1999 15:05:17 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Diff Serv <diffserv@ietf.org>
Subject: Re: [Diffserv] Diff-Serv Router Policies on ACK packets
References: <01BF3675.22C347C0.nbitar@lucent.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

People,

Diffserv (the topic of this WG) is clearly a stateless one-way hop-by-hop
mechanism. So this discussion - however important it is - is simply
out of scope for this mailing list. 

As has been said from the beginning, if you want symmetric behavior you need
symmetric service level specifications, and nothing in diffserv prevents this.
But it isn't this WG's job to worry about this.

   Brian Carpenter
   diffserv co-chair

Nabil Bitar wrote:
> 
> Hi Nabil (Seddigh)
> > Nabil Bitar wrote:
> >
> > >I don't see whether currently there is a capability to mark the
> > > ack packets with the same BA as the data at the ingress
> > > router for the acks. This goes back to the fact that diffserv
> > > is focused now on unidirectional traffic...
> > >
> > > [..............stuff deleted.....]
> > >
> > > Additionally, this problem is beyond acks. I see it
> > >effecting any two-way sessions by which the session quality
> > > is effected by both directions of the traffic. An example that
> > > I stated some time back is a VoIP service when one end of
> > > the session has golden service (built using EF or some AF
> > > class) and the other has best-effort service. Can one make
> > >both directions have golden services in that case for the
> > >duration of the session? If not, the person with the golden
> > > service will get the quality of that service when he/she talks
> > > to another person with the same service level or better.
> > > Are mechanisms that allow this sort of things still out
> > >of the scope of the WG?
> > >
> >
> > Hi Nabil :)
> >
> > I agree with your statement that the problem is beyond ACKs
> > and also extends to VoIP services etc. In general, in SOME
> > cases, there are requirements for utilities and schemes to install
> > "correlated" filters/classifiers at ingress routers of both
> > communicating parties. To some extent, this is already possible
> > today.
> >
> > Today, it is actually possible to have pre-installed (relatively static)
> > filters that allow:
> >
> >   - One-to-one services (source & destination are fixed)
> >   - One-to-few services ( source and few destinations are fixed)
> >
> > With the above, one can clearly construct a number of services
> > where both ingress routers have the same rules for the two
> > communicating parties. This can be done using standard policy
> > management tools. Neither of the above two types of services
> > would NECESSARILY require Layer 4 information. Filters can
> > be based on Layer 3 information alone.
> >
> This is clearly doable. However, how well does it scale (e.g. effected by a
> combination of static configuration and service scope) ?  Furthermore, it
> limits you to a static apriori knowledge. While there is use for such
> configuration, it is practically limiting from a  deployment scope and the
> type of services that you can practically offer. The question of whether
> you need to do the filtering at layer 3 or layer 4 depends on your traffic
> conditioning and what you to do offer.
> 
> > There are 2 other cases for which additional mechanisms
> > are required to enable installation of "duplicate" filters
> > at 2 ingress routers.
> >
> > a.) In the case where a one-to-anywhere service is offered
> >   (as in today's Internet), and there is a need to have
> >   "duplicate" filters, the filter on the sender side can
> >   be static and pre-installed.
> In my email, I was implicitly referring to "from one to anywhere" service.
> >   receiver side ingress router would have to be dynamically
> >   installed via  a tool (BB?) that is prompted based on
> >   some trigger.
> >
> that is more like what I referred to in mechanisms needed to dynamically
> install filters. I am not sure if this in the realm of the BB now or
> whether it should be!
> 
> > b.) The case where both filters are dynamically installed
> >      via a tool that is prompted based on a trigger.
> >
> > BTW, the above discussion  acknowledges the need for both static and
> > dynamic setting of filters. This is independent of the approach to
> > provisioning.  It is possible to have static/dynamic filters in
> > combination with static  provisioning.
> >
> The dynamic case is the more challenging and more generic.
> > If as Brian's note indicates, the WG is thinking of standardizing
> > services,
> Mechanisms that enable the installation of dynamic filters in the way
> referred to above are service building blocks as much as PHBs are. Thus,
> such mechanisms do not imply specific services and do not require service
> standardization. In addition, I do not think that Brian is talking about
> standardizing services but rather probably working on services from
> informational perspective to see how the PHBs defined so far will be used
> and whether there is need for more.
> 
> > I suggest we clearly delineate and separate the discussion
> > between provisioning of core router resources and co-ordinated
> > configuration of edge devices rules.
> >
> What we are talking about is clearly an edge router issue. The above
> discussion is about how to instantiate traffic conditioning rules. I think
> such instantiation mechanisms are explicitly stated as part of the diffserv
> router conceptual model. Aren't they?
> 
> > Regards
> > Nabil Seddigh
> > nseddigh@nortelnetworks.com
> >
> 
> Regards,
> Nabil Bitar.
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: brian@icair.org
Ethernet address: 00-00-AC-CF-5B-82

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



From diffserv-admin@ietf.org  Sat Nov 27 17:51:29 1999
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 RAA19004
	for <diffserv-archive@ietf.org>; Sat, 27 Nov 1999 17:51:29 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA23766;
	Sat, 27 Nov 1999 17:05:34 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id RAA23733
	for <diffserv@optimus.ietf.org>; Sat, 27 Nov 1999 17:05:30 -0500 (EST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07945
	for <diffserv@ietf.org>; Sat, 27 Nov 1999 17:05:53 -0500 (EST)
Received: from blv-hub-01.boeing.com ([192.48.21.11])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA02595
	for <diffserv@ietf.org>; Sat, 27 Nov 1999 14:05:54 -0800 (PST)
Received: from [199.191.48.134] by blv-hub-01.boeing.com for diffserv@ietf.org; Sat, 27 Nov 1999 14:05:47 -0800
Received: by engr04.arl.bna.boeing.com (UCX V4.1-12A, OpenVMS V7.1 Alpha);
	Sat, 27 Nov 1999 17:04:58 -0500
From: "Albert Manfredi" <albert.e.manfredi@boeing.com>
To: "Brian E Carpenter" <brian@hursley.ibm.com>,
        "Diff Serv" <diffserv@ietf.org>
Subject: RE: [Diffserv] Diff-Serv Router Policies on ACK packets
Date: Sat, 27 Nov 1999 17:05:45 -0500
Message-Id: <NDBBIBKKCLEFDFDGHCNMOEMMCAAA.albert.e.manfredi@boeing.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
In-Reply-To: <383EF60D.A5F9EE85@hursley.ibm.com>
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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

Brian E Carpenter wrote:

> Diffserv (the topic of this WG) is clearly a stateless
> one-way hop-by-hop
> mechanism. So this discussion - however important it is -
> is simply
> out of scope for this mailing list.

Glad to see this reiterated by the co-Chair. I've seen some evidence
of cracks forming in this simple goal.

> As has been said from the beginning, if you want
> symmetric behavior you need
> symmetric service level specifications, and nothing in
> diffserv prevents this.
> But it isn't this WG's job to worry about this.

True, but people always want to know how this is possible given that
TCP is not going to mark its ACK packets with any special code
point.

Certainly one can envision that over "default" service, ACK packets
will get symmetric treatment, though. And this default service, over
the diffserv net, _could_ be something better than BE.

Bert
manfredi@arl.bna.boeing.com


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



From diffserv-admin@ietf.org  Mon Nov 29 09:57:23 1999
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 JAA01561
	for <diffserv-archive@ietf.org>; Mon, 29 Nov 1999 09:57:23 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA12699;
	Mon, 29 Nov 1999 08:36:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id IAA12666
	for <diffserv@optimus.ietf.org>; Mon, 29 Nov 1999 08:36:39 -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 IAA19713;
	Mon, 29 Nov 1999 08:37:06 -0500 (EST)
Message-Id: <199911291337.IAA19713@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: Mon, 29 Nov 1999 08:37:05 -0500
Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
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 for Diffserv
	Author(s)	: D. Grossman
	Filename	: draft-ietf-diffserv-new-terms-02.txt
	Pages		: 6
	Date		: 24-Nov-99
	
This memo captures Diffserv working group agreements concerning new
and improved terminology. It is intended as a living document for use
by the Diffserv working group, and especially for use of authors of
Diffserv drafts.  It is expected that the terminology in this memo
will be incorporated into the existing Diffserv RFCs when they are
updated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-diffserv-new-terms-02.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-02.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:	<19991124120357.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-diffserv-new-terms-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-diffserv-new-terms-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991124120357.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From diffserv-admin@ietf.org  Mon Nov 29 19:21:35 1999
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 TAA18004
	for <diffserv-archive@ietf.org>; Mon, 29 Nov 1999 19:21:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA28862;
	Mon, 29 Nov 1999 18:43:47 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id SAA28827
	for <diffserv@optimus.ietf.org>; Mon, 29 Nov 1999 18:43:42 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01804
	for <diffserv@ietf.org>; Mon, 29 Nov 1999 18:44:07 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA21238
	for <diffserv@ietf.org>; Mon, 29 Nov 1999 15:43:37 -0800 (PST)
Message-ID: <38430FFC.24E1D0C8@cisco.com>
Date: Mon, 29 Nov 1999 15:45:00 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] WG Last Call: draft-ietf-diffserv-phbid-00.txt
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit


This is to note that we are in Working Group Last
Call on draft-ietf-diffserv-phbid-00.txt:
http://search.ietf.org/internet-drafts/draft-ietf-diffserv-phbid-00.txt

It was agreed in the WG meeting in DC that the document should procede.

Comments should be sent to the list as a follow up to this message.
The last call will end on December 14. 

        Kathie and Brian

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



From diffserv-admin@ietf.org  Tue Nov 30 05:08:20 1999
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 FAA22067
	for <diffserv-archive@ietf.org>; Tue, 30 Nov 1999 05:08:19 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA20214;
	Tue, 30 Nov 1999 04:00:36 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id EAA20183
	for <diffserv@optimus.ietf.org>; Tue, 30 Nov 1999 04:00:32 -0500 (EST)
Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20567
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 04:00:58 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id KAA19569;
	Tue, 30 Nov 1999 10:59:12 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14403.37344.316874.936318@lohi.eng.telia.fi>
Date: Tue, 30 Nov 1999 10:59:12 +0200 (EET)
To: Kathleen Nichols <kmn@cisco.com>
Cc: diffserv@ietf.org
Subject: [Diffserv] WG Last Call: draft-ietf-diffserv-phbid-00.txt
In-Reply-To: <38430FFC.24E1D0C8@cisco.com>
References: <38430FFC.24E1D0C8@cisco.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

since some phb groups may have many code points, not all of which
are necassarily in use by a particular service, a mask would be a more
flexible solution than the single 14th bit.

-- juha

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



From diffserv-admin@ietf.org  Tue Nov 30 09:08:07 1999
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 JAA10284
	for <diffserv-archive@ietf.org>; Tue, 30 Nov 1999 09:08:07 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA25634;
	Tue, 30 Nov 1999 07:55:01 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id HAA25603
	for <diffserv@optimus.ietf.org>; Tue, 30 Nov 1999 07:54:56 -0500 (EST)
Received: from lohi.eng.telia.fi (root@lohi.eng.telia.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04254
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 07:55:23 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id OAA20085;
	Tue, 30 Nov 1999 14:55:22 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14403.51514.836096.120311@lohi.eng.telia.fi>
Date: Tue, 30 Nov 1999 14:55:22 +0200 (EET)
To: diffserv@ietf.org
Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-02.txt
In-Reply-To: <199911291337.IAA19713@ietf.org>
References: <199911291337.IAA19713@ietf.org>
X-Mailer: VM 6.75 under Emacs 19.34.1
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

  PHB Scheduling Class: A PHB group for which a common constraint is
  that ordering of packets must be preserved

i think we agreed that only ordering of packets that belong to the same
microflow must be preserved.

-- juha



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



From diffserv-admin@ietf.org  Tue Nov 30 10:50:36 1999
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 KAA05846
	for <diffserv-archive@ietf.org>; Tue, 30 Nov 1999 10:50:35 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA28253;
	Tue, 30 Nov 1999 09:29:10 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id JAA28220
	for <diffserv@optimus.ietf.org>; Tue, 30 Nov 1999 09:29:06 -0500 (EST)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21417
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 09:29:32 -0500 (EST)
Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id GAA24941; Tue, 30 Nov 1999 06:28:53 -0800 (PST)
Message-Id: <4.1.19991130090145.00ada850@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 30 Nov 1999 09:27:09 -0500
To: Juha Heinanen <jh@lohi.eng.telia.fi>, Kathleen Nichols <kmn@cisco.com>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [Diffserv] WG Last Call: draft-ietf-diffserv-phbid-00.txt
Cc: diffserv@ietf.org
In-Reply-To: <14403.37344.316874.936318@lohi.eng.telia.fi>
References: <38430FFC.24E1D0C8@cisco.com>
 <38430FFC.24E1D0C8@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org

I don't see how this could work. A field over which the mask might 
be applied is prohibited by the definition of the DSCP [RFC 2474]:

   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.

While the recommended DSCPs for AF encode the different drop precedences
in bits 3 and 4, all values are in use even if not distinguished [RFC 2597]:

   Within each AF class, a DS node MUST accept all three drop precedence
   codepoints and they MUST yield at least two different levels of loss
   probability.

Although the distinction beween just two levels of drop precedence
is encoded in bit 3 in the recommended DSCPs, this encoding cannot
be relied upon for other PHB groups because of the prohibition above.
It also seems unlikely that recommended DSCPs for new standard PHB
groups would be able to find bit-fields to enable the masking proposal
because of the coverage of CSC, EF and AF.

   If a DS node only implements two different levels of loss probability
   for an AF class x, the codepoint AFx1 MUST yield the lower loss
   probability and the codepoints AFx2 and AFx3 MUST yield the higher
   loss probability.
   ...
                        Class 1    Class 2    Class 3    Class 4
                      +----------+----------+----------+----------+
     Low Drop Prec    |  001010  |  010010  |  011010  |  100010  |
     Medium Drop Prec |  001100  |  010100  |  011100  |  100100  |
     High Drop Prec   |  001110  |  010110  |  011110  |  100110  |
                      +----------+----------+----------+----------+

John

At 10:59 AM 11/30/1999 +0200, Juha Heinanen wrote:
>since some phb groups may have many code points, not all of which
>are necassarily in use by a particular service, a mask would be a more
>flexible solution than the single 14th bit.


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



From diffserv-admin@ietf.org  Tue Nov 30 17:36:45 1999
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 RAA00389
	for <diffserv-archive@ietf.org>; Tue, 30 Nov 1999 17:36:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA10232;
	Tue, 30 Nov 1999 16:32:05 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id QAA10200
	for <diffserv@optimus.ietf.org>; Tue, 30 Nov 1999 16:32:01 -0500 (EST)
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28381
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 16:32:23 -0500 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA42506; Tue, 30 Nov 1999 21:31:51 GMT
Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA24022; Tue, 30 Nov 1999 21:31:44 GMT
Message-ID: <384441F6.7110649B@hursley.ibm.com>
Date: Tue, 30 Nov 1999 15:30:30 -0600
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: John Schnizlein <jschnizl@cisco.com>
CC: Juha Heinanen <jh@lohi.eng.telia.fi>, Kathleen Nichols <kmn@cisco.com>,
        diffserv@ietf.org
Subject: Re: [Diffserv] WG Last Call: draft-ietf-diffserv-phbid-00.txt
References: <38430FFC.24E1D0C8@cisco.com>
	 <38430FFC.24E1D0C8@cisco.com> <4.1.19991130090145.00ada850@diablo.cisco.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.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit

I agree with John (speaking as co-author of the draft). The PHBID is not intended
to convey semantics.

   Brian

John Schnizlein wrote:
> 
> I don't see how this could work. A field over which the mask might
> be applied is prohibited by the definition of the DSCP [RFC 2474]:
> 
>    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.
> 
> While the recommended DSCPs for AF encode the different drop precedences
> in bits 3 and 4, all values are in use even if not distinguished [RFC 2597]:
> 
>    Within each AF class, a DS node MUST accept all three drop precedence
>    codepoints and they MUST yield at least two different levels of loss
>    probability.
> 
> Although the distinction beween just two levels of drop precedence
> is encoded in bit 3 in the recommended DSCPs, this encoding cannot
> be relied upon for other PHB groups because of the prohibition above.
> It also seems unlikely that recommended DSCPs for new standard PHB
> groups would be able to find bit-fields to enable the masking proposal
> because of the coverage of CSC, EF and AF.
> 
>    If a DS node only implements two different levels of loss probability
>    for an AF class x, the codepoint AFx1 MUST yield the lower loss
>    probability and the codepoints AFx2 and AFx3 MUST yield the higher
>    loss probability.
>    ...
>                         Class 1    Class 2    Class 3    Class 4
>                       +----------+----------+----------+----------+
>      Low Drop Prec    |  001010  |  010010  |  011010  |  100010  |
>      Medium Drop Prec |  001100  |  010100  |  011100  |  100100  |
>      High Drop Prec   |  001110  |  010110  |  011110  |  100110  |
>                       +----------+----------+----------+----------+
> 
> John
> 
> At 10:59 AM 11/30/1999 +0200, Juha Heinanen wrote:
> >since some phb groups may have many code points, not all of which
> >are necassarily in use by a particular service, a mask would be a more
> >flexible solution than the single 14th bit.
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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



From diffserv-admin@ietf.org  Tue Nov 30 20:36:22 1999
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 UAA28565
	for <diffserv-archive@ietf.org>; Tue, 30 Nov 1999 20:36:21 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA14908;
	Tue, 30 Nov 1999 19:38:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.8.8) with ESMTP id TAA14878
	for <diffserv@optimus.ietf.org>; Tue, 30 Nov 1999 19:38:25 -0500 (EST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02581
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 19:38:50 -0500 (EST)
Received: from cisco.com (dhcp-o-38-206.cisco.com [171.71.38.206])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA19416
	for <diffserv@ietf.org>; Tue, 30 Nov 1999 16:38:20 -0800 (PST)
Message-ID: <38446E52.E8DD658A@cisco.com>
Date: Tue, 30 Nov 1999 16:39:46 -0800
From: Kathleen Nichols <kmn@cisco.com>
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: diffserv@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Diffserv] Minutes from DC
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id:  <diffserv.ietf.org>
X-BeenThere: diffserv@ietf.org
Content-Transfer-Encoding: 7bit



Diffserv Working Group meeting, Wahington D.C.

Chairs: Brian Carpenter and Kathie Nichols
Reporter: David Black

----- Monday Evening Session, November 8, 1999 -----

-- Agenda Bashing and WG status

Core WG drafts today.  Tomorrow will take up unsolicited drafts.

-- New Terminology - Dan Grossman, Motorola
        (draft-ietf-diffserv-new-terms-01.txt)

This document's purpose is to capture group decisions on terminology and
taxonomy
        for use in future documents.  Summary of these changes:

(1) Use the terms Service Level Specification and Traffic Conditioning
Specification, not
        Agreements (latter implies business contracts).
(2) The definition of PHB Group in RFC 2475 doesn't fit the entire set
of AF classes.
        Hence, AF is a type of PHB Group.  AF1x, AF2x, AF3x, and AF4x
are instances of
this
        type, only the instances are PHB Groups.  The next update of RFC
2597 will reflect
this.
(3) The DS Field is no longer the entire TOS octet.  DS Field is the 6
MSBs of the
(former)
        IPv4 TOS Octet and IPv6 Traffic Class octet.  The other two bits
are currently
        unused by diffserv.  DSCP is a value in the DS Field.
draft-bradner-iana-allocation-02.txt
        (soon to be an RFC) is an example of this usage.
(4) MPLS needs notion of a set of Behavior Aggregates with a common
ordering constraint.
        Terms: PHB Scheduling Class = PHB group that has a common
ordering constraint
        Ordered Aggregate = Set of Behavior Aggregates that share an
ordering constraint.
        The words "All of the packets of an OA are members of the same
PHB scheduling
class."
        are problematic due to the use of "members of".  Francois Le
Faucheur has provided
        an alternative: "An Ordered Aggregate is the set of Behavior
Aggregates that
correspond to
        the PHBs of a PHB Scheduling Class".  This will be incorporated
into the draft.
The terms in (4) are actually applicable to any device that polices an
edge interface,
MPLS just happened to encounter the need for these terms first, but
they're not specific
to MPLS

Reference [3] in the draft (RFC 2597) needs to be corrected.

An issue was raised that an ordering constraint affects packets within
the same microflow;
not reordering the Ordered Aggregate is sufficient to achieve this
property, but not
necessary.
On the other hand working involving the term microflow seems to be a bit
strong to put in
a core
diffserv document.  The next version of document will have a parenthesis
around the word
microflow
to reopen this issue.

All other issues in this document are considered to be closed.

-- PHB ID Draft - Scott Brim, Newbridge
        (draft-ietf-diffserv-phbid-00.txt)

This is a minor update to the PHB ID draft (draft-brim-...) from Oslo.
This is a teneral purpose approach to signal PHBs (as opposed to DSCPs).
Have added a flag to indicate whether PHBID is a single PHB or a set
(Bit 14).
Sets are as defined in the appropriate document, for unusual sets (e.g.,
2
        of the 3 AF 1x PHBs), a list of the PHBs should be signalled.
Also added a few examples.
Standard PHBs use recommended DSCP, otherwise IANA allocates a 12 bit ID
value.
        Bit 15 is set to 1 to indicate latter case.

Next step is to last call this on the mailing list.  No opposition to
this in the meeting.

-- A Conceptual Model for Diffserv Routers - Brian Carpenter, WG
co-chair
        (draft-ietf-diffserv-model-01.txt)

The authors are Yoram Bernet, Andrew Smith, and Steve Blake, but Brian
is presenting due
        to absence of Andrew and Steve

Changes since previous draft:
        - New Glossary
        - Allow all model elements to be associated with both ingress
and egress
interfaces
        - Queues are first class elements in the model
        - Routing core function characterized: zero loss/zero delay in
conceptual model
                Actual loss/delay gets reflected in traffic conditioning
elements of
conceptual
                model.
        - MPLS LSRs acting as Diffserv routers: discussion added,
although the DS Field
                is hidden from an MPLS router.  This creates some
complications.
        - Meters are now separate with more discussion of simple and
multi-bucket meters.
                Appendix A contains a concrete definition of a token
bucket.
        - Mux, mirror, enqueue, and null action elements added.
A mirror makes a logical copy not a physical one, mirror may need to be
replaced with
        another word as part of clarifying text, "tee" is one possible
replacement,
        "inverse mux" is another, "splitter" is a third.  Both of these
changes need
        to be made to the text.
        - Lots of details added on queue parameters and queue sets. 
Shaping queue
                also defined.
Removal of items from a queue is not modelled well.  Queues can be
thought of as
having both a buffering element and a scheduling discipline that can be
considered
separately.  Dan Grossman will send some suggested language to the list.
        - Traffic conditioning blocks can be composed of any elements
connected in any
                fashion, and TCBs are recursive, and hence can be
connected with TCBs
                and other elements to form yet other TCBs.
        - TCBs have 1 input and one output:
This is an oversight and will be removed in the next version (e.g.,
Figure 8 is a TCB
with one input and multiple outputs).

The overall motivation for modelling queues is to have enough detail to
be able to push
rules down to routers - need enough details of how the queue works to
write these rules
in a standard fashion, but don't want to specify every last
implementatation detail.

A discussion ensued about specific queue parameters, such as minimum
service rate.
The motivation for what was done is that min and max rate are reasonably
generic,
and going beyond there gets into implementation-specific details very
quickly.
These are supposed to be primitive elements (e.g., could model a complex
implementation
queue as being logically composed of multiple primitive queues in the
model).

Overall caution - this is not supposed to be a prescription for hardware
designers.

        - New section on security considerations.
        - Appendix A is a new example.

Open Issues ...
- Appendix A token bucket definition is fine as is.
- SRTCM meter cannot be built out of a set of that sort of token
buckets.  This
is an important example as it's very close to Cisco CAR.  The meters in
this
draft are examples, but need to check MIB to make sure that this meter
can be
modelled adequately there.  Pointing to description of this meter in the
AF
RFC is an alternative to describing it here, as the cascading token
buckets
example is easier to describe.

Comment: Put some restrictions on the composition rules to avoid
ridiculous things.

Monitoring elements will be generalized to count without an indication
of
        direction so that a monitor can track queue size. 
Discussion of specific resolution text will have to be on the list where
all the 
        authors can participate.

- Should traffic conditioner blocks be allowed to contain classifiers?
        Seems to be an ok thing to do given how definition of a TCB has
evolved,
        but will not be changed to allow this, as there was no
compelling reason to do so.
[note from kmn: this TCB is not to be confused with the definition of
"traffic
conditioners" in rfcs 2474&2475. Those explicitly do not include
classifiers.]

- RSVP module: discussed on list, RSVP is only an example, hence the
module needs
        a more generic name.  Functionality is to handle QoS information
that is
dynamically
        signalled, potentially on a relatively fine grain.  MPLS LSP
setup protocol can
        also be used as an example here.

Comment: Cable Device MIB has a large amount of policy extensibility,
based on classifying
        packets to an arbitrary number that then has its own set of
tables.

- Should MPLS LSRs be mentioned in the model?  Yes, MPLS classifiers are
an important
        part of a router implementation.

- Do class selectors require additional queue parameters?  No comments
in meeting.

Open issues, especially queue issues need to be taken to list for
resolution.

-- Diffserv MIB - Kwok Ho Chan, Nortel
        (draft-ietf-diffserv-mib-01.txt)

MIB draft didn't quite make cutoff, but really needs to be discussed.

Added Andrew Smith's IP 6-tuple MF classifier.
Added info on where the classifier configuration information came from.

The latter precipitated a long discussion on whether a more generic
approach
to indicating the source of arbitrary information, not just classifier
configuration information was in order.  No clear resolution, as much
of the room did not understand the issues well enough to express an
opinion.  This is complicated by the forthcoming PIB discussion in
the OPS configuration management BOF, and hence the whole matter has
been taken under advisement by the MIB draft authors.

The queueing text has been clarified to allow multiple queues/scheduling
        disciplines to be used on the same interface.
Discussion on the list determined that the Meter Pass and Meter Fail
objects
        should be allowed to point to anything - the draft will be
updated to
        reflect this.

Queueing issues came up here again.  Andrew Smith is expected to provide
some text on the use of minimum and maximum rates.  Subclassing to add
additional queue parameters was mentioned as a possible structure.  Van
Jacobson will send a detailed proposals to the list on:
        - This subclassing approach to queues
        - A more general approach to configuring token buckets.
        - Changing the meter specification so that the count can never
be negative.

Next version will add a table to specify an interface role.  This is a
policy
        WG concept that makes higher level provisioning easier to do.

Final addition is that the MIB draft needs a diagram and usage section
to clarify
        relationship of tables, how they are intended to be used, and
how this relates
        to the model.

Still have work to do on this document -- there are issues to be taken
to the list.
        May need an interim meeting to make progress faster than the
list has been,
        but should try email on list first.

-- Diffserv and Tunnels - David Black, EMC

Your intrepid scribe presented this, hence all I can do is refer to the
draft.

Two conclusions:
        (1) The final slide of the presentation raised open issues. 
This will
                be taken to the list for discussion before preparing a
new version.
        (2) WG consensus is that this is important, and the next version
of this
                draft should be a WG draft (i.e., draft-ietf-diffserv-
...).

-- Closing Remarks, Kathie Nichols, WG co-chair

Would like to focus on issues that need to be resolved to encourage
diffserv deployment.

----- Tuesday Afternoon Session, November 9, 1999 -----

This is the unsolicited draft session.  These notes capture the brief
resolution
of what to do with each of the unsolicited drafts, as well as salient
points that
were discussed.

-- SNMP-based QoS Programming Interface MIB for Routers
        (draft-kanada-diffserv-qospifmib-00.txt)

Portions of this draft are candidates to be merged into the diffserv
MIB, especially
the classifier objects.  The authors of this draft need to take this up
with the
MIB draft authors, and additional suggestions for things to merge should
be sent
to the list.

-- Rate Adaptive Shapers (draft-bonaventure-diffserv-rashaper-01.txt)

This should be discussed on the list and then may be advanced as an
Informational
        RFC as complement to RFC 2697 and 2698 if the WG approves via
the list.

-- draft-bless-diffserv-multicast-00.txt

Multicast issues need to be taken up at some point, but WG has other
more pressing
matters that need to be attended to first.  This draft is primarily
about how to
add diffserv to multicast routing, and is proposed as material to
incorporate
into the diffserv architecture RFC (2475).  Needs extensive WG
discussion in order
to revise RFC 2575 (Section 5).

Provisioning material should be taken up with Traffic Engineering WG,
not here.

There's also some issll WG work on a multicast branch in the middle of a
diffserv
        network in the intserv over diffserv work.

Need to make sure that the scope is clear before taking up as WG work
item,
        but problem area is important to address.

-- draft-bless-diffserv-lbe-phb-00.txt

Less than Best Effort PHB.  Part of the proposed solution to multicast
problems
identified in previous draft.  Also useful for background data, penalty
boxed flows,
and deploying multimedia apps in a way that won't disrupt existing
traffic.

Significant discussion occurred both in the meeting and on the list
about whether
a new PHB is necessary.  The WG needs to address this set of problems,
but the need
for a new PHB is an open issue that will be taken to the list.  If a new
PHB is
needed, then it can be decided whether this is the right base document
to start from.

One proposal was to remap DSCP 0 to be the same as Class Selector 2,
thus turning
Class Selector 1 into LBE.

-- Time Sliding Window Three Color Marker
(draft-fang-diffserv-tc-tswtcm-00.txt)

This is a TCP-friendly marker that works better than token bucket for
TCP running
through RIO-like droppers.  Comes in 2 and 3 color versions.  There are
experimental
results that will be reported in Broadcom '99 (December).

The experimental results should be made available to the WG, and then it
would be
reasonable to have this draft progress to become an experimental RFC. 
The authors
will post a message to the list containing URLs for all of their
results.

The diffserv WG is not currently progressing traffic conditioning
documents as
        standards track RFCs.

-- draft-fu-diffserv-security-00.txt

Despite none of the the authors of this draft being at the session,
comments were
made that the draft has some merit because it looks at problems caused
by boundaries
not working correctly - diffserv assumes that edges do work correctly
and interior
nodes depend on this.  Looking at what happens when this assumption is
accidentially
or deliberately false is of interest, although this draft is at best
very preliminary,
and in particular needs to have the configuration protocol material
removed and 
taken up with the appropriate protocol WGs.

-- draft-lin-diffserv-gtc-00.txt

The authors of this draft were not present and did not provide any
presentation
material, and hence the draft was not discussed.  If they would like the
WG
to do something with this draft, send the request to the list.

-- draft-nadas-diffserv-experience-01.txt

Update of a previous draft presented at the Oslo decides BOF.  This is
primarily
to provide information to the WG, atlhough an Informational RFC is not
the best
way to publish this sort of results.  The WG thanks the authors for
their efforts
in making their results available as an Internet-Draft, and encourages
others
with similar results to do likewise.

-- Expedited Forwarding with Dropping PHB
        (draft-dieder-diffserv-phb-efd-00.txt)

EF for wireless to deal with peculiarities in that domain.  Wireless
will always drop
        packets under some circumstances.  The proposed PHB eliminates
congestion
        drops, but allows drops caused by media effects in wireless. 
This PHB may
        also be useful for fixed networks, to absorb otherwise unused EF
capacity.

[kmn: I explicitly noted in the meeting that this proposes a different
PHB than
the PHB called EF in RFC 2598.]

Needs more discussion on list to decide whether to advance this as a
standards track
        document, experimental document, or not at all.

-- The Multimedia Color Marker (draft-medina-mmcm-00.txt)

Adaptive color marker for audio/video streams.  Modification to Juha
Heinanen's three
        color marker.  Adds 3rd Token bucket to limit inbound traffic
and drop proactively
        on ingress rather than reactively when problems occur.
Goal is to increase delivery probability of green packets by dropping
yellow/red at
        edge node that knows the difference as opposed to somewhere
inside.

An opinion was expressed that marker documents should not also discuss
dropping.

The draft needs more feedback, and support from group.  Relationship to
the existing
        informational marker RFCs (2697 and 2698) is particularly
important to discuss
        on the list.

-- Interoperability PHB group
(draft-kilkki-diffser-interoperability-00.txt)

This draft reraises a proposal to define PHBs that can be used
end-to-end rather
than edge-to-edge within a domain.  This idea was rejected by the WG
almost a
year and a half ago at the Cambridge, MA interim meeting, due to
opposition from
major ISPs.

Representatives of two medium sized network operators opposed
consideration of
this material here, with one suggesting that the general topic of
inter-ISP
service interoperability belonged in an ISP industry forum, not the
IETF.

-- End of Meeting Comments

Overall, the areas that seem to be of strong interest are: Multicast
issues,
        Less than Best Effort PHB, and EF with dropping PHB. The merits
of
	the approaches proposed at the meeting weren't clear though. 

Diffserv over specific link layers (primarily PHBs) should be done via
changes to the
        issll WG charter, not in the diffserv WG.

A comment was made that the diffserv WG needs to start discussion of
services to avoid
to avoid inventing new PHBs for services that can be implemented by
appropriate
configuration of existing PHBs.

More discussion on these topics to come on the list.

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