Subject: re: re: qry on traffic policing

From: Andrew Smith <[email-masked]>
Date: Tue, 10 Jun 1997 22:58:38 -0700

juha,

the hope was to be somewhat more granular than that: it seems
that relying on the tos fields from applications and then lumping
together
all gs or cl into the same category would not lead to efficient
admission
control or else to a fairly useless approximation of the expected
service: but it is certainly something that needs studying in more
detail.
one proposal is to have several gs classes of different delay bounds
e.g. 1ms, 10ms, 100ms: a flow would be admitted to an appropriate
class based on the requested tspec/etc. and then told by the network
which class to use.

there will be a new id on this proposal within the next week or so.

we should move this to the issll list as it's more appropriate there.

andrew

***********************************************************************
andrew smith                            tel: +1 (408) 342-0985
extreme networks                        fax: +1 (408) 342-0990
1601 s. de anza blvd. #220              http://www.extremenetworks.com
cupertino ca 95014                      em:  [email-masked]
***********************************************************************

> ----------
> From: 	Juha Heinanen[SMTP:[email-masked]]
> Sent: 	Tuesday, June 10, 1997 10:29 PM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Re: RE: Qry on Traffic Policing
> 
> i would suggest to use the same coding in the ip tos field and in
> 802.1p
> qos field so that there would be one-to-one mapping.  three service
> classed might be adequate:  real time, guaranteed bandwidth, and best
> effort.  the third bit could indicate the priority level within the
> class.  that would give networks a change to implement qod without any
> explicit resource reservation protocol.
> 
> -- juha
>

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 11 Jun 1997 12:41:25 +0300

i have nothing against having more granularity as long as the
granularity can be expressed by at most 3 bits.  some code points might
also get consumed by the downgraded real time or guaranteed packets.

-- juha
------------------------
   From: Andrew Smith <[email-masked]>
   Cc: [email-masked], issll <[email-masked]>
   Date: Tue, 10 Jun 1997 22:58:38 -0700
   X-Priority: 3
   MIME-Version: 1.0
   X-Mailer: Internet Mail Service (5.0.1457.3)
   Content-Type: text/plain

   juha,

   andrew

---

From: Subramaniam Vincent <[email-masked]>
Date: Wed, 11 Jun 1997 15:10:02 -0700 (PDT)

> service: but it is certainly something that needs studying in more

  Andrew, I am not sure I understand the admission control part clearly 
  What do you think is worth studying ? Whether per flow/user admission 
  control into a class can be independently combined with the application
  itself setting some tos bits for some of its packets ? thanks. 

-vince