Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv Extension s related questions/comments

From: Bora Akyol <[email-masked]>
Date: Thu, 1 Jun 2000 14:15:34 -0700

> -----Original Message-----
> From: Grenville Armitage [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 1:48 PM
> To: Bora Akyol
> Cc: 'Brian E Carpenter'; [email-masked]
> Subject: Re: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> Extensions related questions/comments
> 
> 
> 
> 
> Bora Akyol wrote:
> > 
> > Here is a specific problem:
> > 
> > Even though DS WG has defined specific codepoints (one of 
> which is AF and is
> > quite generic in terms of applicability to services), the 
> architecture also
> > allows for arbitrary codepoints and arbitrary remappings 
> between codepoints.
> 
> I'm not seeing the problem. A basic, conformant HW implementation
> only needs to support the default codepoints, no?  Supporting other
> codepoints for the same PHB is allowed, but not required. Call it
> an opportunity for product differentiation.
> 

Yes, but does it make sense. What is the compelling reason to use
non-standard codepoints, especially when crossing DS boundaries.

> 	[..]
> > I do realize that there are ways to overcome these 
> problems, but HW cycle
> > times are unlike software. In this regard, the lack of 
> standardized (and not
> > so flexible) mechanisms and the lack of definition of 
> standardized services
> > (which are intentionally left out of the scope of the DS 
> WG) is causing a
> > lot of heartaches for HW development.
> 
> How is the lack of e2e service models causing problems for per-hop HW?
> (I can see it causing a problem for diffserv per se, but you
> should still be able to build a router that offers HW speed AFxy or EF
> behaviors before anyone's figured out how to anything e2e with them)
> 

Isn't this an oversimplication? One needs to know how to use the HW so that
the right features get designed into it which will suffice for at least the
next 2-3 years. What I was trying to say above is that, due to the lack of
experience with DS at a service level, the "normal" usage of the defined
mechanisms have not emerged and that is what the problem is.

Regards

Bora

> cheers,
> gja
> ______________________________________________________________
> __________
> Grenville Armitage                    
> http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Thomas Eklund <[email-masked]>
Date: Thu, 8 Jun 2000 09:34:51 +0200

Hi Juha,
Good question. But yes we have metering and policing.

It has in terms of QoS MF classifier, Marker, Meter, Queue Mgt, Scheduler,
Buffer Mgt, Dropper ...

The classifier can do packet filtering from layer 1-4 (statful inspection)
at the same time..

There is a lot of propriatery solutions in order to optimize the hardware
architechure to achieve full diffserv support , which I can tell about under
a NDA...

Best Regards 
 Thomas

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2000 5:28 PM
> To: Thomas Eklund
> Cc: 'Brian E Carpenter'; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: "This is a gripe" [was Re: [Diffserv] MPLS Diffserv
> Extension s related questions/comments
> 
> 
> Thomas Eklund writes:
> 
>  > If you look at our product which is a 
> switch/router-on-a-chip in ASIC it
>  > runs a full MF classifier and have full diffserv (queeing, 
> scheduling etc.)
>  > support for 16 GigabitEthernet full duplex ports wirespeed!!
> 
> i didn't find in the documents any support for metering and policing.
> 
> -- juha
>