Subject: RE: [Diffserv] Re: An apology...

From: Barani Subbiah <[email-masked]>
Date: Tue, 25 Jan 2000 11:50:36 -0800 (PST)

Signaling is an integral part of QoS provisioning that includes traffic 
policing/shaping, classifiers, and Scheduling. All these mechanisms are needed 
in order to guarantee QoS with "reosurce efficiency". We can throw more bw but 
it may not be efficient. It would be nice to find out the middle point with 
additional bw (we dont have to save every byte of resources) and a lightweight 
signaling that would solve the QoS problem.

Barani

> From [email-masked]  Tue Jan 25 10:26:11 2000
> Return-Path: <[email-masked]>
> Received: from new-york.3com.com (new-york.nsd.3com.com [129.213.96.114])
	by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id KAA03624;
	Tue, 25 Jan 2000 10:26:09 -0800 (PST)
> Received: from seattle.3com.com (seattle.3com.com [129.213.157.13])
	by new-york.3com.com (8.8.8/8.8.8) with ESMTP id KAA18207;
	Tue, 25 Jan 2000 10:26:06 -0800 (PST)
> Received: from optimus.ietf.org (ietf.org [132.151.1.19])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id KAA13234;
	Tue, 25 Jan 2000 10:26:03 -0800 (PST)
> Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12908;
	Tue, 25 Jan 2000 13:14:19 -0500 (EST)
> Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12878
	for <[email-masked]>; Tue, 25 Jan 2000 13:14:14 -0500 (EST)
> Received: from wingate.calynet.com (216-200-28-155.snj0.flashcom.net 
[216.200.28.155])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05532
	for <[email-masked]>; Tue, 25 Jan 2000 13:15:31 -0500 (EST)
> Received: from MAIL-CLUSTER.calynet.com (exch-node-b.calynet.com 
[192.168.0.11]) by wingate.calynet.com with SMTP (Microsoft Exchange Internet 
Mail Service Version 5.5.2448.0)
	id Z63X4S7X; Tue, 25 Jan 2000 10:16:43 -0800
> Received: by MAIL-CLUSTER.calynet.com with Internet Mail Service (5.5.2448.0)
	id <ZP3H2XD1>; Tue, 25 Jan 2000 10:05:58 -0800
> Message-ID: <[email-masked]>
> From: Mudassir Tufail <[email-masked]>
> To: "'Juha Heinanen'" <[email-masked]>, [email-masked]
> Cc: Stefaan De Cnodder <[email-masked]>,
        Ping Pan
	 <[email-masked]>,
        Omar Elloumi <[email-masked]>, RSVP <[email-masked]>,
        diffserv <[email-masked]>, [email-masked]
> Subject: RE: [Diffserv] Re: An apology...
> Date: Tue, 25 Jan 2000 10:05:53 -0800
> X-Mailer: Internet Mail Service (5.5.2448.0)
> Sender: [email-masked]
> Errors-To: [email-masked]
> X-Mailman-Version: 1.0
> Precedence: bulk
> List-Id: <diffserv.ietf.org>
> X-BeenThere: [email-masked]
> Status: RO
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-MD5: HB1Yb7zgxce8MyBWd+cNiA==
> Content-Length: 1881
> 
> > 
> > Istvan Cselenyi writes:
> > 
> >  > So imargine the situation in a few years when every telephony 
> >  > session is moved to the internet (what many of us wishes) 
> > and new kind 
> >  > of real-time applications are spreading all over...
> > 
> > telephone sessions will always be so small percentage of overall
> > internet traffic that we don't need any signalling for that.  diffserv
> > bits in the packets are well enough.
> > 
> > -- juha
> > 
> 
> Not clear, curious to know how this is possible. I will appreciate if you
> can explain it more.
> 
> As per my understanding, just the DiffServ bit in the packets would not be
> sufficient. It is regardless of the percentage of telephone traffic (or any
> real time traffic) on the internet. Signaling is required to do two
> important things: 1) call admission control and 2) resource allocation to an
> admitted call. The same is valid, as well, for networks where resources are
> policy-managed.
> 
> Omar Elloumi wrote:
> > One question that come in mind is: do we need resource
> > reservation for VoIP traffic in DiffServ networks?
> >  
> 
> Yes, resource management policy dictates what percentage of total available
> resources are to be allocated to a traffic aggregate, say VoIP.
> Consequently, VoIP call will go through an admission control. This ensures
> that 1) admitted calls get guaranteed QoS and 2) lower priority classes do
> not face starvation.
> 
> Mudassir
> CALY Networks
> 295 Santa Anna Court        Tel: (408) 730 8800 ext 245
> Sunnyvale, CA 94086         Fax: (408) 730 2448 
> 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 26 Jan 2000 21:52:16 -0500 (EST)

This whole discussion on signalling seems to be confusing
a few things. In Intserv, you had:

  -  an explicitly signalled request for access to 
      the network (via RSVP)
  AND
  - Dynamically configured router resources to meet
     the needs of the RSVP request

In Diffserv, the basic architecture facilitates a 2X2 matrix 
of options:

 1. Implicit signalling + Statically configured router resources
 2. Explicit signalling + Statically configured router resources
 3. Explicit signalling + Dynamic configuration of router resources.
 4. Implicit signalling  + Dynamic configuration of router resources

Option 1 is the option being adopted today to enable widespread
deployment of Diffserv. It does not preclude the emergence of
wide-spread use of explicit signalling However, the need to develop a
signalling mechanism for Diffserv is independent of whether network
resources are configured statically or dynamically. 

It seems to me that signalling schemes or revectored RSVP schemes 
should not be directly coupled with the provisioning
of router resources. 

Regards
Nabil Seddigh
[email-masked]

Mudassir Tufail writes:

>......... It is regardless of the percentage of telephone traffic 
> (or any real time traffic) on the internet. Signaling is required 
> to do two important things:
>       1) call admission control and 2) resource allocation
>           to an admitted call. The same is valid, as well, 
>   for networks where resources are policy-managed.
>