From owner-issll@mercury.lcs.mit.edu  Tue Jul 11 03:36:27 2000
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 DAA21861
	for <issll-archive@odin.ietf.org>; Tue, 11 Jul 2000 03:36:26 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id CAA04587
	for issll-outgoing; Tue, 11 Jul 2000 02:35:23 -0400 (EDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id CAA04579
	for <issll@mercury.lcs.mit.edu>; Tue, 11 Jul 2000 02:35:21 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA09102 for <issll@mercury.lcs.mit.edu>; Mon, 10 Jul 2000 23:35:21 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id XAA09722 for <issll@mercury.lcs.mit.edu>; Mon, 10 Jul 2000 23:35:18 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id MAA27530;
	Tue, 11 Jul 2000 12:09:56 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJ20N>; Tue, 11 Jul 2000 11:54:54 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBA@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'Brian E Carpenter'" <brian@hursley.ibm.com>,
        Radhakrishna
	 <rk@miel.mot.com>
Cc: "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Tue, 11 Jul 2000 11:54:48 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

This draft is basically to add signaling and admission control capabilities
for
Differentiated Services where in end hosts and access routers can signal the
desired PHBs to network. The mechanisms described in this document can
also be used in intermediate nodes to provide an effective admission control
and involves minimum signaling overheads (no overheads in data path).

Although DCLASS (draft-ietf-issll-dclass-01.txt) object provides a mechanism
to
pass the DSCPs for marking, it does not address -
  (1) how these DSCPs are used (no associated Traffic Conditioning Specs)
   (2) Admission Control

The other drafts in this area (draft-ietf-issll-ds-map-00.txt,
draft-ietf-diffserv-rsvp-02.txt and
draft-ietf-issll-rsvp-aggr-02.txt) require mapping from IntServ to DiffServ
and also does not
address the specifics of admission control.

Hope this helps when you read through the document.

Regards,
......RK

> -----Original Message-----
> From:	Brian E Carpenter [SMTP:brian@hursley.ibm.com]
> Sent:	Monday, July 10, 2000 10:02 PM
> To:	Radhakrishna
> Cc:	diffserv@ietf.org; rsvp@ISI.EDU
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> This is already an area of active work in the ISSLL working group,
> so can you try on their list?
> 
> Thanks
> 
>   Brian Carpenter
>   diffserv co-chair
> 
> Radhakrishna wrote:
> > 
> > The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
> > signaling and admission control in DiffServ networks. It also
> > defines the required RSVP objects. The use of RSVP as described
> > in this document simplifies the processing and can be used by
> > end hosts to signal the required PHBs to the network. It is also
> > useful to the network for admission control purposes and does not add
> > any overheads in data path. It also reduces the processing overheads of
> > RSVP messages.
> > 
> > Please let me know whether anybody has similar idea and whether we
> > can improve this draft for adding admission control mechanisms to
> > DiffServ networks.
> > 
> > Thanks,
> > .....RK
> > 
> > The draft is available at -
> > >
> http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
> > >
> > 
> > _______________________________________________
> > diffserv mailing list
> > diffserv@ietf.org
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 


From owner-issll@mercury.lcs.mit.edu  Tue Jul 11 07:21:19 2000
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 HAA25560
	for <issll-archive@odin.ietf.org>; Tue, 11 Jul 2000 07:21:19 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA00697
	for issll-outgoing; Tue, 11 Jul 2000 06:24:06 -0400 (EDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA00692
	for <issll@mercury.lcs.mit.edu>; Tue, 11 Jul 2000 06:24:04 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA15422; Tue, 11 Jul 2000 03:23:59 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA07355; Tue, 11 Jul 2000 03:23:56 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA16479;
	Tue, 11 Jul 2000 15:58:30 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJJ9B>; Tue, 11 Jul 2000 15:43:28 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBB@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>, r.salles@ic.ac.uk
Cc: diffserv@ietf.org, Radhakrishna <rk@miel.mot.com>,
        "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Tue, 11 Jul 2000 15:43:26 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Since this is an area under ISSLL working group,
I am moving these dicussions to ISSLL mailing list.
However, see my answers inline.

Thanks for your inputs and looking forward to get more.

....RK

> -----Original Message-----
> From:	Tarik Alj [SMTP:aljtarik@cholla.inrs-telecom.uquebec.ca]
> Sent:	Monday, July 10, 2000 9:16 PM
> To:	r.salles@ic.ac.uk
> Cc:	diffserv@ietf.org; rk@miel.mot.com
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> 
> >From: "Ronaldo Salles" <r.salles@ic.ac.uk>
> >To: "Radhakrishna" <rk@miel.mot.com>
> >Cc: <diffserv@ietf.org>
> >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> ...
> >
> >Dear RK,
> >
> >On page 6 you say: "As shown in figure3, policing and admission control
> is
> >done *only* in edge/boundary nodes."
> >
> >On page 3 you say:"Each intermediate node along the path checks the
> >availability of resources on receipt of ResvConf message and passes the
> >ResvConf message to next node if resources are available ..." Isn't it
> >admission control? If yes, your first statement is wrong.
> >
> >regards,
> >rms.
> >
> 
> I support this remark. Furthermore I would like to ask, how would an 
> "intermediate node check the availability of ressources"?
> 
> I would have expected, given the DiffServ context, that admission control
> would 
> happen only at the edge; having the intermediate nodes make themselve
> heard by 
> the edge only if ressources become scarce.
> 
> This sort of session establishment looks a lot like a "simplified
> IntServ", 
> while it could be adequate for EF; isn't it too restrictive for AF
> service? 
> 
	[Radhakrishna]  
	The first statement (page 6), I meant it only for data packets,
where in
	data packets are policed and conditioned for established sessions
	(packets belonging to non-established sessions will be forced to
	 Best Effort). May be admission control is not a right word here and
	I will make this correction in next revision.

	Regarding admission control (to establish a session or not), even
the
	intermediate nodes (if necessary) can be involved along with the
edge
	nodes. With this, the admission control will be better, but with
some
	signaling overheads (much less compared to standard RSVP
processing).
	However, there are no overheads in data path. The draft does not
mandate
	admission control (and RSVP processing) in every node.

	The main intent of this draft is to -
	(1) make end systems (hosts and access nodes) to signal the desired
PHBs to
	     the network (along with associated parameters), and
	(2) network nodes can make use of simplified mechanisms (if
required)
	     to provide effective admission control

	The key points to be observed in the draft are -

	 (1) SESSION which is different from the ones used in IntServ. The
session
	      identifier assigned by the sender (host or edge node) is used
to
	      distinguish different sessions from the same sender. The
sender can
	      aggregate all the application flows that require same PHB on
to same
	      session and can re-negotiate the resources. The use of session
identifier
	      also helps to address the issue with NAT, Tunneling, etc.,
which modify
	      the IP headers.

	 (2) FLOWSPEC which defines how PHBs and their associated parameters
	      are signaled.

	 (3) Less overheads, since the processing is much simplied with less
	      messages (the intermediate nodes will process only Path,
ResvConf
	      and PathTear messages and does not need hop-by-hop forwarding
	      mechanisms along the reverse path) and simplified states &
objects.
	      

> Regards,
> 
> Tarik.
> 
> 
> >
> >----- Original Message -----
> >From: Radhakrishna <rk@miel.mot.com>
> >To: <diffserv@ietf.org>; <rsvp@isi.edu>
> >Sent: Monday, July 10, 2000 6:12 AM
> >Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >
> >
> >The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
> >signaling and admission control in DiffServ networks. It also
> >defines the required RSVP objects. The use of RSVP as described
> >in this document simplifies the processing and can be used by
> >end hosts to signal the required PHBs to the network. It is also
> >useful to the network for admission control purposes and does not add
> >any overheads in data path. It also reduces the processing overheads of
> >RSVP messages.
> >
> >Please let me know whether anybody has similar idea and whether we
> >can improve this draft for adding admission control mechanisms to
> >DiffServ networks.
> >
> >Thanks,
> >.....RK
> >
> >The draft is available at -
> >>  http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
> >>
> >
> ...
> >diffserv mailing list
> >diffserv@ietf.org
> >http://www1.ietf.org/mailman/listinfo/diffserv
> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> Tarik Alj
> 
> INRS-Telecommunications
> Place Bonaventure
> 900 De La Gauchetierre Ouest
> Niveau C, Case Postale 644
> Montreal, Qc, H5A 1C6
> Canada
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/


From owner-issll@mercury.lcs.mit.edu  Tue Jul 11 16:36:20 2000
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 QAA18993
	for <issll-archive@odin.ietf.org>; Tue, 11 Jul 2000 16:36:20 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA01598
	for issll-outgoing; Tue, 11 Jul 2000 15:25:18 -0400 (EDT)
Received: from lulu.it.northwestern.edu (lulu.acns.nwu.edu [129.105.16.54])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA03370
	for <issll@mercury.lcs.mit.edu>; Tue, 11 Jul 2000 15:25:17 -0400 (EDT)
Received: (from mailnull@localhost)
	by lulu.it.northwestern.edu (8.8.7/8.8.7) id OAA00602;
	Tue, 11 Jul 2000 14:25:16 -0500 (CDT)
Received: from rccn.net (dhcp223.it.nwu.edu [129.105.237.223]) by lulu.acns.nwu.edu via smap (V2.0)
	id xma029987; Tue, 11 Jul 00 14:23:38 -0500
Message-ID: <396B7568.619D584F@rccn.net>
Date: Tue, 11 Jul 2000 14:28:40 -0500
From: "Rute C. Sofia" <rute@rccn.net>
Reply-To: rute@nwu.edu
Organization: ICAIR - NU
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Radhakrishna <rk@miel.mot.com>
CC: "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
References: <2C202C0F886DD3119B1200A0C9A85FF405DCBA@xmail.miel.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Radhakrishna wrote:

> This draft is basically to add signaling and admission control capabilities
> for
> Differentiated Services where in end hosts and access routers can signal the
>

Hi,

I have some questions and comments:

In section 1, you mention the use of a "DS session", but do not explain what
you mean by it...

Also, in the same section, last paragraph where you say "unlike standard RSVP
processing...This simplifies the processing in intermediate nodes...and these
nodes mantain a simple state of whether a reservation is set up or not".

So, there will still be the need of keeping status information on each hop
along the way, per microflow...so, how will this scale??

In Section 4., aggregation and resource re-negotiation, you mention the
possibility of using reservation aggregation. Shouldn't this be more explained,
how your model can be used considering RSVP aggregation? After all, DiffServ is
based in flow aggregation and so, mentioning admission control per-microflow is
very necessary, but mentioning admission control per flow aggregate is also
necessary...
How can these new RSVP objects be integrated with the current RSVP aggregation
work?

There are also some issues not mentioned on this draft, such has behavior
related to path changes, possibility of duplicate reservations and also
admission control in multicast scenarios, specially with aggregation...

In section 7., there's a misspelling :-), "The use of ISPEC" should be "The use
of IPSec",

    Regards,
        Rute Sofia






From owner-issll@mercury.lcs.mit.edu  Tue Jul 11 17:37:26 2000
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 RAA21331
	for <issll-archive@odin.ietf.org>; Tue, 11 Jul 2000 17:37:26 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA03834
	for issll-outgoing; Tue, 11 Jul 2000 16:31:17 -0400 (EDT)
Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA03951
	for <issll@mercury.lcs.mit.edu>; Tue, 11 Jul 2000 16:31:16 -0400 (EDT)
Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110])
	by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id QAA11580;
	Tue, 11 Jul 2000 16:34:30 -0400 (EDT)
Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4)
	id QAA15952; Tue, 11 Jul 2000 16:30:45 -0400 (EDT)
Message-Id: <200007112030.QAA15952@cholla.INRS-Telecom.UQuebec.CA>
Date: Tue, 11 Jul 2000 16:30:45 -0400 (EDT)
From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
Reply-To: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
To: jawang@cosinecom.com
Cc: issll@mercury.lcs.mit.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vefm12Ytihw08WlgUxSQmg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk


>From: Jay Wang <jawang@cosinecom.com>
>To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>, r.salles@ic.ac.uk
>Cc: diffserv@ietf.org, rk@miel.mot.com
>Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>Date: Tue, 11 Jul 2000 12:26:29 -0700
>MIME-Version: 1.0
>
>Well, I think the author's intend was to stress that the
>admission control is "administered" or "coordinated" at 
>the edge.  So that the application, such as the service 
>management system, needs to ONLY interface with the edge 
>nodes to enforce admission control.  Also for the question 
>regarding how an intermediate node would check its resource 
>availability, I am not sure how this is different from an 
>edge node? When a session is set up, say by RSVP, along the 
>way if the edge nodes know how to handle the accounting 
>with respect to its resource, why can't the intermediate 
>node do the same thing?

I agree, but then, doesn't this adds complexity (scale, etc) to session set-up?


Regards,

Tarik.
  
>
>regards,
>
>- Jay Wang
>
>-----Original Message-----
>From: Tarik Alj [mailto:aljtarik@cholla.inrs-telecom.uquebec.ca]
>Sent: Monday, July 10, 2000 8:46 AM
>To: r.salles@ic.ac.uk
>Cc: diffserv@ietf.org; rk@miel.mot.com
>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>
>
>
>>From: "Ronaldo Salles" <r.salles@ic.ac.uk>
>>To: "Radhakrishna" <rk@miel.mot.com>
>>Cc: <diffserv@ietf.org>
>>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>...
>>
>>Dear RK,
>>
>>On page 6 you say: "As shown in figure3, policing and admission control is
>>done *only* in edge/boundary nodes."
>>
>>On page 3 you say:"Each intermediate node along the path checks the
>>availability of resources on receipt of ResvConf message and passes the
>>ResvConf message to next node if resources are available ..." Isn't it
>>admission control? If yes, your first statement is wrong.
>>
>>regards,
>>rms.
>>
>
>I support this remark. Furthermore I would like to ask, how would an 
>"intermediate node check the availability of ressources"?
>
>I would have expected, given the DiffServ context, that admission control
>would 
>happen only at the edge; having the intermediate nodes make themselve heard
>by 
>the edge only if ressources become scarce.
>
>This sort of session establishment looks a lot like a "simplified IntServ", 
>while it could be adequate for EF; isn't it too restrictive for AF service? 
>
>Regards,
>
>Tarik.
>
>
>>
>>----- Original Message -----
>>From: Radhakrishna <rk@miel.mot.com>
>>To: <diffserv@ietf.org>; <rsvp@isi.edu>
>>Sent: Monday, July 10, 2000 6:12 AM
>>Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>>
>>
>>The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
>>signaling and admission control in DiffServ networks. It also
>>defines the required RSVP objects. The use of RSVP as described
>>in this document simplifies the processing and can be used by
>>end hosts to signal the required PHBs to the network. It is also
>>useful to the network for admission control purposes and does not add
>>any overheads in data path. It also reduces the processing overheads of
>>RSVP messages.
>>
>>Please let me know whether anybody has similar idea and whether we
>>can improve this draft for adding admission control mechanisms to
>>DiffServ networks.
>>
>>Thanks,
>>.....RK
>>
>>The draft is available at -
>>>  http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
>>>
>>
>...
>>diffserv mailing list
>>diffserv@ietf.org
>>http://www1.ietf.org/mailman/listinfo/diffserv
>>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>Tarik Alj
>
>INRS-Telecommunications
>Place Bonaventure
>900 De La Gauchetierre Ouest
>Niveau C, Case Postale 644
>Montreal, Qc, H5A 1C6
>Canada
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

Tarik Alj

INRS-Telecommunications
Place Bonaventure
900 De La Gauchetierre Ouest
Niveau C, Case Postale 644
Montreal, Qc, H5A 1C6
Canada

514 875-1266 #2036 (email preferred)



From owner-issll@mercury.lcs.mit.edu  Tue Jul 11 17:37:35 2000
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 RAA21342
	for <issll-archive@odin.ietf.org>; Tue, 11 Jul 2000 17:37:34 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA03946
	for issll-outgoing; Tue, 11 Jul 2000 16:28:42 -0400 (EDT)
Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA03913
	for <issll@mercury.lcs.mit.edu>; Tue, 11 Jul 2000 16:28:36 -0400 (EDT)
Received: from cholla.INRS-Telecom.UQuebec.CA (cholla [192.26.211.110])
	by ozias.inrs-telecom.uquebec.ca (8.9.1/8.9.1) with ESMTP id QAA11561;
	Tue, 11 Jul 2000 16:31:47 -0400 (EDT)
Received: from cholla by cholla.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4)
	id QAA15948; Tue, 11 Jul 2000 16:28:02 -0400 (EDT)
Message-Id: <200007112028.QAA15948@cholla.INRS-Telecom.UQuebec.CA>
Date: Tue, 11 Jul 2000 16:28:02 -0400 (EDT)
From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
Reply-To: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
To: rk@miel.mot.com
Cc: issll@mercury.lcs.mit.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DKOlxRdVAzIFhTtTKHA9EA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc 
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Please see comments inline. CC'ing ISSLL.

<... snip...>

>> 
>	[Radhakrishna]  
>	The first statement (page 6), I meant it only for data packets,
>where in
>	data packets are policed and conditioned for established sessions
>	(packets belonging to non-established sessions will be forced to
>	 Best Effort). May be admission control is not a right word here and
>	I will make this correction in next revision.
>
>	Regarding admission control (to establish a session or not), even
>the
>	intermediate nodes (if necessary) can be involved along with the
>edge
>	nodes. With this, the admission control will be better, but with
>some
>	signaling overheads (much less compared to standard RSVP
>processing).
>	However, there are no overheads in data path. The draft does not
>mandate
>	admission control (and RSVP processing) in every node.


	Maybe some precision about this should be added to the draft. To 
identify when such processing is necessary at intermediate nodes. 
	Also does the establishment of a session suppose the establishment of a 
path for a given session (e.g. packet of a given AF (fex) session would all 
follow the same hop by hop path)? This maybe restrictive and might not scale 
well.
	
>
>	The main intent of this draft is to -
>	(1) make end systems (hosts and access nodes) to signal the desired
>PHBs to
>	     the network (along with associated parameters), and

	Isn't this supposed to be done via DSCPs? Each packet carrying its own 
desired PHB? 
	
	
>	(2) network nodes can make use of simplified mechanisms (if
>required)
>	     to provide effective admission control
>
>	The key points to be observed in the draft are -
>
>	 (1) SESSION which is different from the ones used in IntServ. The
>session
>	      identifier assigned by the sender (host or edge node) is used
>to
>	      distinguish different sessions from the same sender. The
>sender can
>	      aggregate all the application flows that require same PHB on
>to same
>	      session and can re-negotiate the resources. The use of session
>identifier
>	      also helps to address the issue with NAT, Tunneling, etc.,
>which modify
>	      the IP headers.


	Then aggregation should be considered separatly? There are aggregation 
mechanisms for RSVP + DiffServ PDBs, these should be considered too?
	
>
>	 (2) FLOWSPEC which defines how PHBs and their associated parameters
>	      are signaled.
>
>	 (3) Less overheads, since the processing is much simplied with less
>	      messages (the intermediate nodes will process only Path,
>ResvConf
>	      and PathTear messages and does not need hop-by-hop forwarding
>	      mechanisms along the reverse path) and simplified states &
>objects.
>	      

	I think it would be interesting to do some sort of a "case study" where 
the draft would examine intra-DS-domain and inter-DS-domain use of RSVP as well 
as going through a non-DS domain. It would help clarify is really meant by "PHB 
signalling".
	


Regards,

Tarik.











Tarik Alj
INRS-Telecommunications
Place Bonaventure
900 De La Gauchetierre Ouest
Niveau C, Case Postale 644
Montreal, Qc, H5A 1C6
Canada

514 875-1266 #2036 (email preferred)



From owner-issll@mercury.lcs.mit.edu  Wed Jul 12 05:46:13 2000
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 FAA14479
	for <issll-archive@odin.ietf.org>; Wed, 12 Jul 2000 05:46:12 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id DAA07584
	for issll-outgoing; Wed, 12 Jul 2000 03:50:15 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id DAA07672
	for <issll@mercury.lcs.mit.edu>; Wed, 12 Jul 2000 03:50:14 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id AAA05176; Wed, 12 Jul 2000 00:50:11 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id AAA21712; Wed, 12 Jul 2000 00:50:09 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id NAA12550;
	Wed, 12 Jul 2000 13:24:52 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJNSY>; Wed, 12 Jul 2000 13:09:47 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBD@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'rute@nwu.edu'" <rute@nwu.edu>, Radhakrishna <rk@miel.mot.com>,
        jawang@cosinecom.com,
        "'aljtarik@cholla.inrs-telecom.uquebec.ca'"
	 <aljtarik@cholla.inrs-telecom.uquebec.ca>
Cc: "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Wed, 12 Jul 2000 13:09:40 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

See my response inline.

.....RK

>From: Jay Wang <jawang@cosinecom.com>
>To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>,
r.salles@ic.ac.uk
>Cc: diffserv@ietf.org, rk@miel.mot.com
>Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>Date: Tue, 11 Jul 2000 12:26:29 -0700
>MIME-Version: 1.0
>
>Well, I think the author's intend was to stress that the
>admission control is "administered" or "coordinated" at 
>the edge.  So that the application, such as the service 
>management system, needs to ONLY interface with the edge 
>nodes to enforce admission control.  Also for the question 
>regarding how an intermediate node would check its resource 
>availability, I am not sure how this is different from an 
>edge node? When a session is set up, say by RSVP, along the 
>way if the edge nodes know how to handle the accounting 
>with respect to its resource, why can't the intermediate 
>node do the same thing?

I agree, but then, doesn't this adds complexity (scale, etc) to session
set-up?
	[Radhakrishna]  
	Yes, it does add some complexity when the intermediate nodes are
	involved in admission control, but much less compared to standard
	RSVP processing. If the network is adequately provisioned, only
	edge nodes are enough to enforce the admission control.
	The resource availability is checked against the PHB and its
parameter
	values requested in FLOWSPEC.

	The intermediate node is not very different from edge node in terms
admission
	control. But its role is only in keeping sessions and the accounting
	information (how much bandwidth available for various PHBs), so that
	it can involve in admission control. It is also possible that
edge/intermediate
	node can aggregate sessions that belong to same PHB based on the
	destination address of the receiver edge node (the address in
ResvConf message).
	I know the aggregation mechanisms are not well explained in the
draft and I will
	add that in next revision. But the main intent of the draft is to
provide PHB signaling
	and admission control mechanisms with sub-set of RSVP mechanisms, so
that
	end hosts and edge nodes can take advantage without going for
complex IntServ to
	DiffServ mapping mechanisms.

	Also aggregation is not the only mechanism to address the
scalability and complexity
	issues. We could use statistics based approach where you can
maintain just one
	session (that has largest timeout value) per PHB and keep monitoring
the resource
	availability between ResvConf and Path messages of the session.

> From:	Rute C. Sofia [SMTP:rute@rccn.net]
> Sent:	Wednesday, July 12, 2000 12:59 AM
> To:	Radhakrishna
> Cc:	'issll@mercury.lcs.mit.edu'
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> Radhakrishna wrote:
> 
> > This draft is basically to add signaling and admission control
> capabilities
> > for
> > Differentiated Services where in end hosts and access routers can signal
> the
> >
> 
> Hi,
> 
> I have some questions and comments:
> 
> In section 1, you mention the use of a "DS session", but do not explain
> what
> you mean by it...
	[Radhakrishna]  
	DS session no different from RSVP session, except that it is
identified by
	sender address (host or edge node) and an identifier assigned by the
sender.
	This uniquely identifies the session in DiffServ network.

> Also, in the same section, last paragraph where you say "unlike standard
> RSVP
> processing...This simplifies the processing in intermediate nodes...and
> these
> nodes mantain a simple state of whether a reservation is set up or not".
> 
> So, there will still be the need of keeping status information on each hop
> along the way, per microflow...so, how will this scale??
	[Radhakrishna]  
	Yes, there is need for keeping status information leading to
scalability problems,
	but the amount of information and the processing is much simpler
(processing
	of ResvConf message is enough to enforce admission control). All the
nodes
	may not be required to enforce admission control (in the case of
adequate
	provisioning). Aggegation is another mechanism to address the
scalability
	problem, where in edge nodes can aggregate the sessions (see my
response
	above).

> In Section 4., aggregation and resource re-negotiation, you mention the
> possibility of using reservation aggregation. Shouldn't this be more
> explained,
> how your model can be used considering RSVP aggregation? After all,
> DiffServ is
> based in flow aggregation and so, mentioning admission control
> per-microflow is
> very necessary, but mentioning admission control per flow aggregate is
> also
> necessary...
> How can these new RSVP objects be integrated with the current RSVP
> aggregation
> work?
	[Radhakrishna]  
	Yes, aggregation is not well explained in this draft and I will add
more details in
	next version. The aggregation can be acheived based on PHB_ID and
the
	deaggregator (receiver edge node). By having edge node to request
for confirmation
	for all the Resv messages passing through it back to the senders (or
generated by it),
	any node in the network can aggregate the sessions belonging to same
PHB and
	destined to the receiver edge node.

	If you use statistics based approach explained above, you don't need
aggregation
	since will be maintaining only session per PHB (see my response in
the begining
	of this mail).

> There are also some issues not mentioned on this draft, such has behavior
> related to path changes, possibility of duplicate reservations and also
> admission control in multicast scenarios, specially with aggregation...
	[Radhakrishna]  
	Since session establishment is dependent on Path & ResvConf message
	in forward path, and also the session is uniquely identifed by
sender's address
	and session identifier (assigned by the sender), as of now I don't
see any
	issues. But, I agree with you that these needs to be looked in
greater detail
	with possible scenarioes.

> In section 7., there's a misspelling :-), "The use of ISPEC" should be
> "The use
> of IPSec",
	[Radhakrishna]  
	Thanks, I will correct it the next version.

>     Regards,
>         Rute Sofia
> 
> 
> 


From owner-issll@mercury.lcs.mit.edu  Wed Jul 12 08:40:52 2000
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 IAA19449
	for <issll-archive@odin.ietf.org>; Wed, 12 Jul 2000 08:40:52 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA00916
	for issll-outgoing; Wed, 12 Jul 2000 07:02:15 -0400 (EDT)
Received: from judy.ic.ac.uk (judy.ic.ac.uk [155.198.5.28])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id HAA00911
	for <issll@mercury.lcs.mit.edu>; Wed, 12 Jul 2000 07:02:13 -0400 (EDT)
Received: from juliet.ic.ac.uk ([155.198.5.4])
	by judy.ic.ac.uk with esmtp (Exim 2.12 #1)
	id 13CKHH-0005p1-00; Wed, 12 Jul 2000 12:02:07 +0100
Received: from hide.ee.ic.ac.uk ([155.198.120.14] helo=eecfsag2.ee.ic.ac.uk)
	by juliet.ic.ac.uk with esmtp (Exim 2.12 #1)
	id 13CKHL-0002wO-00; Wed, 12 Jul 2000 12:02:11 +0100
Received: from hyperion ([155.198.135.7] helo=rq18y)
	by eecfsag2.ee.ic.ac.uk with smtp (Exim 1.90 #1)
	id 13CKHG-0004Z5-00; Wed, 12 Jul 2000 12:02:06 +0100
Message-ID: <00af01bfebf1$1b6f7c00$0787c69b@ee.ic.ac.uk>
From: "Ronaldo Salles" <r.salles@ic.ac.uk>
To: "Tarik Alj" <aljtarik@cholla.inrs-telecom.uquebec.ca>
Cc: <jawang@cosinecom.com>, <issll@mercury.lcs.mit.edu>,
        "Radhakrishna" <rk@miel.mot.com>
References: <200007112030.QAA15952@cholla.INRS-Telecom.UQuebec.CA>
Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Wed, 12 Jul 2000 12:05:36 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

My point of view is that admission control procedures at the edges "should"
indeed differ from the ones performed in the core (if any). According to the
DiffServ's main concept each node in a DS-domain (ingress/egress/core) has
different resposibilities and therefore intermediate nodes can not manage
sessions/connections even in the "control plane". If we go in this direction
we'll be moving from DiffServ to ... (IntServ?). Signaling is *definitively*
not an issue carried out on  the DiffServ WG.
On the other hand, a real DS-domain can not discard admission control and
the work on "draft-rk-diffserv-rsvp-sig-00.txt" is very important in this
sense.
I think the question is more general: what's the role of core (intermidiate)
nodes regarding admission control in a DS-domain?

regards,
rms.


----- Original Message -----
From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
To: <jawang@cosinecom.com>
Cc: <issll@mercury.lcs.mit.edu>
Sent: Tuesday, July 11, 2000 9:30 PM
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt



>From: Jay Wang <jawang@cosinecom.com>
>To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>,
r.salles@ic.ac.uk
>Cc: diffserv@ietf.org, rk@miel.mot.com
>Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>Date: Tue, 11 Jul 2000 12:26:29 -0700
>MIME-Version: 1.0
>
>Well, I think the author's intend was to stress that the
>admission control is "administered" or "coordinated" at
>the edge.  So that the application, such as the service
>management system, needs to ONLY interface with the edge
>nodes to enforce admission control.  Also for the question
>regarding how an intermediate node would check its resource
>availability, I am not sure how this is different from an
>edge node? When a session is set up, say by RSVP, along the
>way if the edge nodes know how to handle the accounting
>with respect to its resource, why can't the intermediate
>node do the same thing?

I agree, but then, doesn't this adds complexity (scale, etc) to session
set-up?


Regards,

Tarik.

>
>regards,
>
>- Jay Wang
>
>-----Original Message-----
>From: Tarik Alj [mailto:aljtarik@cholla.inrs-telecom.uquebec.ca]
>Sent: Monday, July 10, 2000 8:46 AM
>To: r.salles@ic.ac.uk
>Cc: diffserv@ietf.org; rk@miel.mot.com
>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>
>
>
>>From: "Ronaldo Salles" <r.salles@ic.ac.uk>
>>To: "Radhakrishna" <rk@miel.mot.com>
>>Cc: <diffserv@ietf.org>
>>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>...
>>
>>Dear RK,
>>
>>On page 6 you say: "As shown in figure3, policing and admission control is
>>done *only* in edge/boundary nodes."
>>
>>On page 3 you say:"Each intermediate node along the path checks the
>>availability of resources on receipt of ResvConf message and passes the
>>ResvConf message to next node if resources are available ..." Isn't it
>>admission control? If yes, your first statement is wrong.
>>
>>regards,
>>rms.
>>
>
>I support this remark. Furthermore I would like to ask, how would an
>"intermediate node check the availability of ressources"?
>
>I would have expected, given the DiffServ context, that admission control
>would
>happen only at the edge; having the intermediate nodes make themselve heard
>by
>the edge only if ressources become scarce.
>
>This sort of session establishment looks a lot like a "simplified IntServ",
>while it could be adequate for EF; isn't it too restrictive for AF service?
>
>Regards,
>
>Tarik.
>
>
>>
>>----- Original Message -----
>>From: Radhakrishna <rk@miel.mot.com>
>>To: <diffserv@ietf.org>; <rsvp@isi.edu>
>>Sent: Monday, July 10, 2000 6:12 AM
>>Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
>>
>>
>>The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
>>signaling and admission control in DiffServ networks. It also
>>defines the required RSVP objects. The use of RSVP as described
>>in this document simplifies the processing and can be used by
>>end hosts to signal the required PHBs to the network. It is also
>>useful to the network for admission control purposes and does not add
>>any overheads in data path. It also reduces the processing overheads of
>>RSVP messages.
>>
>>Please let me know whether anybody has similar idea and whether we
>>can improve this draft for adding admission control mechanisms to
>>DiffServ networks.
>>
>>Thanks,
>>.....RK
>>
>>The draft is available at -
>>>  http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
>>>
>>
>...
>>diffserv mailing list
>>diffserv@ietf.org
>>http://www1.ietf.org/mailman/listinfo/diffserv
>>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>
>Tarik Alj
>
>INRS-Telecommunications
>Place Bonaventure
>900 De La Gauchetierre Ouest
>Niveau C, Case Postale 644
>Montreal, Qc, H5A 1C6
>Canada
>
>
>
>_______________________________________________
>diffserv mailing list
>diffserv@ietf.org
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

Tarik Alj

INRS-Telecommunications
Place Bonaventure
900 De La Gauchetierre Ouest
Niveau C, Case Postale 644
Montreal, Qc, H5A 1C6
Canada

514 875-1266 #2036 (email preferred)




From owner-issll@mercury.lcs.mit.edu  Wed Jul 12 09:16:30 2000
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 JAA21054
	for <issll-archive@odin.ietf.org>; Wed, 12 Jul 2000 09:16:29 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA01217
	for issll-outgoing; Wed, 12 Jul 2000 07:54:52 -0400 (EDT)
Received: from motgate3.mot.com ([144.189.100.103])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id HAA01219
	for <issll@mercury.lcs.mit.edu>; Wed, 12 Jul 2000 07:54:50 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id EAA22698; Wed, 12 Jul 2000 04:52:14 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id EAA08288; Wed, 12 Jul 2000 04:53:22 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id RAA06176;
	Wed, 12 Jul 2000 17:28:06 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJ3XR>; Wed, 12 Jul 2000 17:13:01 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCBF@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'Ronaldo Salles'" <r.salles@ic.ac.uk>,
        Tarik Alj
	 <aljtarik@cholla.inrs-telecom.uquebec.ca>
Cc: jawang@cosinecom.com, issll@mercury.lcs.mit.edu,
        Radhakrishna
	 <rk@miel.mot.com>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Wed, 12 Jul 2000 17:13:00 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Your are right. The admission control procedures in the core
should be simple and scalable. However, by having limited sessions
and using them only for those applications which would benefit them
(for example VOIP applications where you can provision for few hundreds
voice calls in each node) will help to reduce the management burden.
One of goal of this draft to simplify the management of such sessions,
if at all they are required. For other applications, you could use simple
statistics based approach which may not be 100% accurate, but
better than nothing. Aggregation is other solution.

I think you missed some earlier discussions on these issues and have
attached them below.

Regards,
.....RK

> -----Original Message-----
> From:	Ronaldo Salles [SMTP:r.salles@ic.ac.uk]
> Sent:	Wednesday, July 12, 2000 4:36 PM
> To:	Tarik Alj
> Cc:	jawang@cosinecom.com; issll@mercury.lcs.mit.edu; Radhakrishna
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> My point of view is that admission control procedures at the edges
> "should"
> indeed differ from the ones performed in the core (if any). According to
> the
> DiffServ's main concept each node in a DS-domain (ingress/egress/core) has
> different resposibilities and therefore intermediate nodes can not manage
> sessions/connections even in the "control plane". If we go in this
> direction
> we'll be moving from DiffServ to ... (IntServ?). Signaling is
> *definitively*
> not an issue carried out on  the DiffServ WG.
> On the other hand, a real DS-domain can not discard admission control and
> the work on "draft-rk-diffserv-rsvp-sig-00.txt" is very important in this
> sense.
> I think the question is more general: what's the role of core
> (intermidiate)
> nodes regarding admission control in a DS-domain?
> 
> regards,
> rms.
> 
	-----Original Message-----
	From:	Radhakrishna [SMTP:rk@miel.mot.com]
	Sent:	Wednesday, July 12, 2000 1:10 PM
	To:	'rute@nwu.edu'; Radhakrishna; jawang@cosinecom.com;
'aljtarik@cholla.inrs-telecom.uquebec.ca'
	Cc:	'issll@mercury.lcs.mit.edu'
	Subject:	RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt

	See my response inline.

	.....RK

	>From: Jay Wang <jawang@cosinecom.com>
	>To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>,
	r.salles@ic.ac.uk
	>Cc: diffserv@ietf.org, rk@miel.mot.com
	>Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
	>Date: Tue, 11 Jul 2000 12:26:29 -0700
	>MIME-Version: 1.0
	>
	>Well, I think the author's intend was to stress that the
	>admission control is "administered" or "coordinated" at 
	>the edge.  So that the application, such as the service 
	>management system, needs to ONLY interface with the edge 
	>nodes to enforce admission control.  Also for the question 
	>regarding how an intermediate node would check its resource 
	>availability, I am not sure how this is different from an 
	>edge node? When a session is set up, say by RSVP, along the 
	>way if the edge nodes know how to handle the accounting 
	>with respect to its resource, why can't the intermediate 
	>node do the same thing?

	I agree, but then, doesn't this adds complexity (scale, etc) to
session
	set-up?
		[Radhakrishna]  
		Yes, it does add some complexity when the intermediate nodes
are
		involved in admission control, but much less compared to
standard
		RSVP processing. If the network is adequately provisioned,
only
		edge nodes are enough to enforce the admission control.
		The resource availability is checked against the PHB and its
	parameter
		values requested in FLOWSPEC.

		The intermediate node is not very different from edge node
in terms
	admission
		control. But its role is only in keeping sessions and the
accounting
		information (how much bandwidth available for various PHBs),
so that
		it can involve in admission control. It is also possible
that
	edge/intermediate
		node can aggregate sessions that belong to same PHB based on
the
		destination address of the receiver edge node (the address
in
	ResvConf message).
		I know the aggregation mechanisms are not well explained in
the
	draft and I will
		add that in next revision. But the main intent of the draft
is to
	provide PHB signaling
		and admission control mechanisms with sub-set of RSVP
mechanisms, so
	that
		end hosts and edge nodes can take advantage without going
for
	complex IntServ to
		DiffServ mapping mechanisms.

		Also aggregation is not the only mechanism to address the
	scalability and complexity
		issues. We could use statistics based approach where you can
	maintain just one
		session (that has largest timeout value) per PHB and keep
monitoring
	the resource
		availability between ResvConf and Path messages of the
session.

	> From:	Rute C. Sofia [SMTP:rute@rccn.net]
	> Sent:	Wednesday, July 12, 2000 12:59 AM
	> To:	Radhakrishna
	> Cc:	'issll@mercury.lcs.mit.edu'
	> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
	> 
	> Radhakrishna wrote:
	> 
	> > This draft is basically to add signaling and admission control
	> capabilities
	> > for
	> > Differentiated Services where in end hosts and access routers
can signal
	> the
	> >
	> 
	> Hi,
	> 
	> I have some questions and comments:
	> 
	> In section 1, you mention the use of a "DS session", but do not
explain
	> what
	> you mean by it...
		[Radhakrishna]  
		DS session no different from RSVP session, except that it is
	identified by
		sender address (host or edge node) and an identifier
assigned by the
	sender.
		This uniquely identifies the session in DiffServ network.

	> Also, in the same section, last paragraph where you say "unlike
standard
	> RSVP
	> processing...This simplifies the processing in intermediate
nodes...and
	> these
	> nodes mantain a simple state of whether a reservation is set up or
not".
	> 
	> So, there will still be the need of keeping status information on
each hop
	> along the way, per microflow...so, how will this scale??
		[Radhakrishna]  
		Yes, there is need for keeping status information leading to
	scalability problems,
		but the amount of information and the processing is much
simpler
	(processing
		of ResvConf message is enough to enforce admission control).
All the
	nodes
		may not be required to enforce admission control (in the
case of
	adequate
		provisioning). Aggegation is another mechanism to address
the
	scalability
		problem, where in edge nodes can aggregate the sessions (see
my
	response
		above).

	> In Section 4., aggregation and resource re-negotiation, you
mention the
	> possibility of using reservation aggregation. Shouldn't this be
more
	> explained,
	> how your model can be used considering RSVP aggregation? After
all,
	> DiffServ is
	> based in flow aggregation and so, mentioning admission control
	> per-microflow is
	> very necessary, but mentioning admission control per flow
aggregate is
	> also
	> necessary...
	> How can these new RSVP objects be integrated with the current RSVP
	> aggregation
	> work?
		[Radhakrishna]  
		Yes, aggregation is not well explained in this draft and I
will add
	more details in
		next version. The aggregation can be acheived based on
PHB_ID and
	the
		deaggregator (receiver edge node). By having edge node to
request
	for confirmation
		for all the Resv messages passing through it back to the
senders (or
	generated by it),
		any node in the network can aggregate the sessions belonging
to same
	PHB and
		destined to the receiver edge node.

		If you use statistics based approach explained above, you
don't need
	aggregation
		since will be maintaining only session per PHB (see my
response in
	the begining
		of this mail).

	> There are also some issues not mentioned on this draft, such has
behavior
	> related to path changes, possibility of duplicate reservations and
also
	> admission control in multicast scenarios, specially with
aggregation...
		[Radhakrishna]  
		Since session establishment is dependent on Path & ResvConf
message
		in forward path, and also the session is uniquely identifed
by
	sender's address
		and session identifier (assigned by the sender), as of now I
don't
	see any
		issues. But, I agree with you that these needs to be looked
in
	greater detail
		with possible scenarioes.

	> In section 7., there's a misspelling :-), "The use of ISPEC"
should be
	> "The use
	> of IPSec",
		[Radhakrishna]  
		Thanks, I will correct it the next version.

	>     Regards,
	>         Rute Sofia
	> 
	> 
	> 



> ----- Original Message -----
> From: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
> To: <jawang@cosinecom.com>
> Cc: <issll@mercury.lcs.mit.edu>
> Sent: Tuesday, July 11, 2000 9:30 PM
> Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> 
> 
> >From: Jay Wang <jawang@cosinecom.com>
> >To: "'Tarik Alj'" <aljtarik@cholla.inrs-telecom.uquebec.ca>,
> r.salles@ic.ac.uk
> >Cc: diffserv@ietf.org, rk@miel.mot.com
> >Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >Date: Tue, 11 Jul 2000 12:26:29 -0700
> >MIME-Version: 1.0
> >
> >Well, I think the author's intend was to stress that the
> >admission control is "administered" or "coordinated" at
> >the edge.  So that the application, such as the service
> >management system, needs to ONLY interface with the edge
> >nodes to enforce admission control.  Also for the question
> >regarding how an intermediate node would check its resource
> >availability, I am not sure how this is different from an
> >edge node? When a session is set up, say by RSVP, along the
> >way if the edge nodes know how to handle the accounting
> >with respect to its resource, why can't the intermediate
> >node do the same thing?
> 
> I agree, but then, doesn't this adds complexity (scale, etc) to session
> set-up?
> 
> 
> Regards,
> 
> Tarik.
> 
> >
> >regards,
> >
> >- Jay Wang
> >
> >-----Original Message-----
> >From: Tarik Alj [mailto:aljtarik@cholla.inrs-telecom.uquebec.ca]
> >Sent: Monday, July 10, 2000 8:46 AM
> >To: r.salles@ic.ac.uk
> >Cc: diffserv@ietf.org; rk@miel.mot.com
> >Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >
> >
> >
> >>From: "Ronaldo Salles" <r.salles@ic.ac.uk>
> >>To: "Radhakrishna" <rk@miel.mot.com>
> >>Cc: <diffserv@ietf.org>
> >>Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >...
> >>
> >>Dear RK,
> >>
> >>On page 6 you say: "As shown in figure3, policing and admission control
> is
> >>done *only* in edge/boundary nodes."
> >>
> >>On page 3 you say:"Each intermediate node along the path checks the
> >>availability of resources on receipt of ResvConf message and passes the
> >>ResvConf message to next node if resources are available ..." Isn't it
> >>admission control? If yes, your first statement is wrong.
> >>
> >>regards,
> >>rms.
> >>
> >
> >I support this remark. Furthermore I would like to ask, how would an
> >"intermediate node check the availability of ressources"?
> >
> >I would have expected, given the DiffServ context, that admission control
> >would
> >happen only at the edge; having the intermediate nodes make themselve
> heard
> >by
> >the edge only if ressources become scarce.
> >
> >This sort of session establishment looks a lot like a "simplified
> IntServ",
> >while it could be adequate for EF; isn't it too restrictive for AF
> service?
> >
> >Regards,
> >
> >Tarik.
> >
> >
> >>
> >>----- Original Message -----
> >>From: Radhakrishna <rk@miel.mot.com>
> >>To: <diffserv@ietf.org>; <rsvp@isi.edu>
> >>Sent: Monday, July 10, 2000 6:12 AM
> >>Subject: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> >>
> >>
> >>The draft-rk-diffserv-rsvp-sig-00.txt discusses the use of RSVP for
> >>signaling and admission control in DiffServ networks. It also
> >>defines the required RSVP objects. The use of RSVP as described
> >>in this document simplifies the processing and can be used by
> >>end hosts to signal the required PHBs to the network. It is also
> >>useful to the network for admission control purposes and does not add
> >>any overheads in data path. It also reduces the processing overheads of
> >>RSVP messages.
> >>
> >>Please let me know whether anybody has similar idea and whether we
> >>can improve this draft for adding admission control mechanisms to
> >>DiffServ networks.
> >>
> >>Thanks,
> >>.....RK
> >>
> >>The draft is available at -
> >>>
> http://www.ietf.org/internet-drafts/draft-rk-diffserv-rsvp-sig-00.txt.
> >>>
> >>
> >...
> >>diffserv mailing list
> >>diffserv@ietf.org
> >>http://www1.ietf.org/mailman/listinfo/diffserv
> >>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> >
> >Tarik Alj
> >
> >INRS-Telecommunications
> >Place Bonaventure
> >900 De La Gauchetierre Ouest
> >Niveau C, Case Postale 644
> >Montreal, Qc, H5A 1C6
> >Canada
> >
> >
> >
> >_______________________________________________
> >diffserv mailing list
> >diffserv@ietf.org
> >http://www1.ietf.org/mailman/listinfo/diffserv
> >Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> Tarik Alj
> 
> INRS-Telecommunications
> Place Bonaventure
> 900 De La Gauchetierre Ouest
> Niveau C, Case Postale 644
> Montreal, Qc, H5A 1C6
> Canada
> 
> 514 875-1266 #2036 (email preferred)
> 


From owner-issll@mercury.lcs.mit.edu  Wed Jul 12 14:38:31 2000
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 OAA07913
	for <issll-archive@odin.ietf.org>; Wed, 12 Jul 2000 14:38:31 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA09608
	for issll-outgoing; Wed, 12 Jul 2000 13:41:52 -0400 (EDT)
Received: from lulu.it.northwestern.edu (lulu.acns.nwu.edu [129.105.16.54])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA09566
	for <issll@mercury.lcs.mit.edu>; Wed, 12 Jul 2000 13:41:47 -0400 (EDT)
Received: (from mailnull@localhost)
	by lulu.it.northwestern.edu (8.8.7/8.8.7) id MAA10788;
	Wed, 12 Jul 2000 12:41:36 -0500 (CDT)
Received: from rccn.net (dhcp223.it.nwu.edu [129.105.237.223]) by lulu.acns.nwu.edu via smap (V2.0)
	id xma010236; Wed, 12 Jul 00 12:40:32 -0500
Message-ID: <396CAEB9.55F0C252@rccn.net>
Date: Wed, 12 Jul 2000 12:45:29 -0500
From: "Rute C. Sofia" <rute@rccn.net>
Reply-To: rute@nwu.edu
Organization: ICAIR - NU
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Radhakrishna <rk@miel.mot.com>
CC: "'rute@nwu.edu'" <rute@nwu.edu>, jawang@cosinecom.com,
        "'aljtarik@cholla.inrs-telecom.uquebec.ca'" 
 <aljtarik@cholla.inrs-telecom.uquebec.ca>,
        "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
References: <2C202C0F886DD3119B1200A0C9A85FF405DCBD@xmail.miel.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> > In section 1, you mention the use of a "DS session", but do not explain
> > what
> > you mean by it...
>         [Radhakrishna]
>         DS session no different from RSVP session, except that it is
> identified by
>         sender address (host or edge node) and an identifier assigned by the
> sender.
>         This uniquely identifies the session in DiffServ network.
>

Ok, what I meant was that you didn't explained what it was in the draft...so,
in order to have the general idea, one has to read the whole draft...a better
approach would be to explain what you meant before using the term...

> >
> > So, there will still be the need of keeping status information on each hop
> > along the way, per microflow...so, how will this scale??
>         [Radhakrishna]
>         Yes, there is need for keeping status information leading to
> scalability problems,
>         but the amount of information and the processing is much simpler
> (processing
>         of ResvConf message is enough to enforce admission control). All the
> nodes

Yes, this reduces the amount of processing when compared to RSVP. But there are
still some issues:

- you mention that the receiver, when getting the Path message, creates a DS
session and generates an Resv that has info on the PHB. So, you suppose that
the receiver (edge) has info on the PHB??  How will it know about it, shouldn't
the sender be the one to have access to this information? Wouldn't it be better
if the sender (edge *or* client host), knowing what it needs, asked (probed)
the network for resources (bw, delay, etc)) according to services agreed and
then classified the flows, thus already having the reservation established?

- according to this method, what happens if there's a multimedia multicast
session, and the sender doesn't yet know where to ask for the info, i.e., where
the receivers are, if there are any receivers (setup phase)? Also, the
receivers will join and leave in a dynamic way...

>

>         may not be required to enforce admission control (in the case of
> adequate
>         provisioning). Aggegation is another mechanism to address the

>

:-). Humm, adequate provisioning in IP networks...
Aggregation might be thinked of as not another mechanism, but as a
complementary one, that might be more efficient when thinking of the DS control
plane, no?

>
>

    Regards,
        Rute Sofia





From owner-issll@mercury.lcs.mit.edu  Thu Jul 13 05:12:25 2000
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 FAA10468
	for <issll-archive@odin.ietf.org>; Thu, 13 Jul 2000 05:12:24 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA10275
	for issll-outgoing; Thu, 13 Jul 2000 04:08:25 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA30730
	for <issll@mercury.lcs.mit.edu>; Thu, 13 Jul 2000 04:08:23 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id BAA27426; Thu, 13 Jul 2000 01:08:20 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id BAA02871; Thu, 13 Jul 2000 01:08:18 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id NAA09071;
	Thu, 13 Jul 2000 13:39:16 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJR09>; Thu, 13 Jul 2000 13:24:10 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCC0@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'rute@nwu.edu'" <rute@nwu.edu>, Radhakrishna <rk@miel.mot.com>
Cc: jawang@cosinecom.com,
        "'aljtarik@cholla.inrs-telecom.uquebec.ca'"
	 <aljtarik@cholla.inrs-telecom.uquebec.ca>,
        "'issll@mercury.lcs.mit.edu'"
	 <issll@mercury.lcs.mit.edu>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Thu, 13 Jul 2000 13:24:09 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

See my response inline.

....RK

> -----Original Message-----
> From:	Rute C. Sofia [SMTP:rute@rccn.net]
> Sent:	Wednesday, July 12, 2000 11:15 PM
> To:	Radhakrishna
> Cc:	'rute@nwu.edu'; jawang@cosinecom.com;
> 'aljtarik@cholla.inrs-telecom.uquebec.ca'; 'issll@mercury.lcs.mit.edu'
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> > > In section 1, you mention the use of a "DS session", but do not
> explain
> > > what
> > > you mean by it...
> >         [Radhakrishna]
> >         DS session no different from RSVP session, except that it is
> > identified by
> >         sender address (host or edge node) and an identifier assigned by
> the
> > sender.
> >         This uniquely identifies the session in DiffServ network.
> >
> 
> Ok, what I meant was that you didn't explained what it was in the
> draft...so,
> in order to have the general idea, one has to read the whole draft...a
> better
> approach would be to explain what you meant before using the term...
	[Radhakrishna]  
	Good input. I will add it in next revision.

> > >
> > > So, there will still be the need of keeping status information on each
> hop
> > > along the way, per microflow...so, how will this scale??
> >         [Radhakrishna]
> >         Yes, there is need for keeping status information leading to
> > scalability problems,
> >         but the amount of information and the processing is much simpler
> > (processing
> >         of ResvConf message is enough to enforce admission control). All
> the
> > nodes
> 
> Yes, this reduces the amount of processing when compared to RSVP. But
> there are
> still some issues:
> 
> - you mention that the receiver, when getting the Path message, creates a
> DS
> session and generates an Resv that has info on the PHB. So, you suppose
> that
> the receiver (edge) has info on the PHB??  How will it know about it,
> shouldn't
> the sender be the one to have access to this information? Wouldn't it be
> better
> if the sender (edge *or* client host), knowing what it needs, asked
> (probed)
> the network for resources (bw, delay, etc)) according to services agreed
> and
> then classified the flows, thus already having the reservation
> established?
	[Radhakrishna]  
	Even though you create a session on getting Path message, actual
reservation
	(allocation of resources) happens on the receipt of ResvConf
message.
	Since this is DiffServ domain, the edge node and the hosts on the
receiver
	side are aware of what PHBs are available (if they are not aware, it
does not
	matter. They can always request standard PHB suited for their
traffic and if the
	network does not support the request will be rejected), but they
won't know the
	actual resources (bw, buffers). Hence the receiver will signal the
required PHB
	along with the parameters through Resv message. The model is same
	as RSVP, but only difference is resource allocation happens with
ResvConf
	message. By doing this, there is no issue with the multicast because
	reservations are initiated by the receivers.

	The sender can signal the desired PHB (PHB_ID), but it can not
signal the PHB
	parameters as it is not aware of what is there on receiver side.
Since the receivers
	are the ones to choose the PHB parameter values, it is better the
choice of PHB
	should be left to the receiver. This provides greater flexibility in
terms each
	receiver (say in case of multicast) can request PHB depending on its
capability.

> - according to this method, what happens if there's a multimedia multicast
> session, and the sender doesn't yet know where to ask for the info, i.e.,
> where
> the receivers are, if there are any receivers (setup phase)? Also, the
> receivers will join and leave in a dynamic way...
	[Radhakrishna]  
	Since the reservation is receiver intiated, you don't have these
issues.
	Also one thing we can do is to base setup on ResvConf message for
	intermediate nodes so that the session will not be established for
the
	receivers that are not up.

> >
> 
> >         may not be required to enforce admission control (in the case of
> > adequate
> >         provisioning). Aggegation is another mechanism to address the
> 
> >
> 
> :-). Humm, adequate provisioning in IP networks...
> Aggregation might be thinked of as not another mechanism, but as a
> complementary one, that might be more efficient when thinking of the DS
> control
> plane, no?
> 
> >
> >
> 
>     Regards,
>         Rute Sofia
> 
> 


From owner-issll@mercury.lcs.mit.edu  Thu Jul 13 13:29:16 2000
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 NAA00948
	for <issll-archive@odin.ietf.org>; Thu, 13 Jul 2000 13:29:15 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id LAA27939
	for issll-outgoing; Thu, 13 Jul 2000 11:58:03 -0400 (EDT)
Received: from lulu.it.northwestern.edu (lulu.acns.nwu.edu [129.105.16.54])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id LAA28074
	for <issll@mercury.lcs.mit.edu>; Thu, 13 Jul 2000 11:58:00 -0400 (EDT)
Received: (from mailnull@localhost)
	by lulu.it.northwestern.edu (8.8.7/8.8.7) id KAA11179;
	Thu, 13 Jul 2000 10:57:59 -0500 (CDT)
Received: from rccn.net (dhcp223.it.nwu.edu [129.105.237.223]) by lulu.acns.nwu.edu via smap (V2.0)
	id xma010850; Thu, 13 Jul 00 10:56:42 -0500
Message-ID: <396DE7DF.3A4D6EAE@rccn.net>
Date: Thu, 13 Jul 2000 11:01:35 -0500
From: "Rute C. Sofia" <rute@rccn.net>
Reply-To: rute@nwu.edu
Organization: ICAIR - NU
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Radhakrishna <rk@miel.mot.com>
CC: "'rute@nwu.edu'" <rute@nwu.edu>, jawang@cosinecom.com,
        "'aljtarik@cholla.inrs-telecom.uquebec.ca'" 
 <aljtarik@cholla.inrs-telecom.uquebec.ca>,
        "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
References: <2C202C0F886DD3119B1200A0C9A85FF405DCC0@xmail.miel.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> >
> > - you mention that the receiver, when getting the Path message, creates a
> > DS
> > session and generates an Resv that has info on the PHB. So, you suppose
> > that
> > the receiver (edge) has info on the PHB??  How will it know about it,
> > shouldn't
> > the sender be the one to have access to this information? Wouldn't it be
> > better
> > if the sender (edge *or* client host), knowing what it needs, asked
> > (probed)
> > the network for resources (bw, delay, etc)) according to services agreed
> > and
> > then classified the flows, thus already having the reservation
> > established?
>         [Radhakrishna]
>         Even though you create a session on getting Path message, actual
> reservation
>         (allocation of resources) happens on the receipt of ResvConf
> message.
>         Since this is DiffServ domain, the edge node and the hosts on the
> receiver
>         side are aware of what PHBs are available (if they are not aware, it
> does not
>         matter. They can always request standard PHB suited for their
> traffic and if the
>         network does not support the request will be rejected), but they
> won't know the
>         actual resources (bw, buffers). Hence the receiver will signal the
> required PHB
>         along with the parameters through Resv message. The model is same
>         as RSVP, but only difference is resource allocation happens with
> ResvConf
>         message. By doing this, there is no issue with the multicast because
>         reservations are initiated by the receivers.
>
>         The sender can signal the desired PHB (PHB_ID), but it can not
> signal the PHB
>         parameters as it is not aware of what is there on receiver side.
> Since the receivers
>         are the ones to choose the PHB parameter values, it is better the
> choice of PHB
>         should be left to the receiver. This provides greater flexibility in
> terms each
>         receiver (say in case of multicast) can request PHB depending on its
> capability.
>

So, if I can understand, you intend to use RSVP as it works (receiver based) to
do admission control on a model that needs this process on the edges of a
defined domain, specially, that needs the edge on the sender side to know
before any forwarding about services available...

And what if we are speaking of sender/edge receiver/edge on different domains,
the most likely case? How will this work with PHB, has you mention that the
receiver will now about them? Also, if you mention that the receiver "will"
find out about the SLA and PHB, then you are using simply a signaling protocol,
but you still have to have something like a BB to mantain all the info about
services...so, you withdraw from BB the process of edge configuring, but will
not avoid having them...

Another thing about your draft is that you always think of sender/receiver as
being on the edge. What happens if sender/receiver are host clients?? How can
they know about PHB? That is not mentioned in the draft, but in the DS model,
it is clear that clients might be able to do traffic classification.


>

    Regards,
        Rute Sofia



From owner-issll@mercury.lcs.mit.edu  Mon Jul 17 10:28:28 2000
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 KAA01954
	for <issll-archive@odin.ietf.org>; Mon, 17 Jul 2000 10:28:27 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA22718
	for issll-outgoing; Mon, 17 Jul 2000 09:21:58 -0400 (EDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA22660
	for <issll@mercury.lcs.mit.edu>; Mon, 17 Jul 2000 09:21:56 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA06877; Mon, 17 Jul 2000 06:21:51 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA00546; Mon, 17 Jul 2000 06:21:50 -0700 (MST)]
Received: from xmail.miel.mot.com (xmail.miel.mot.com [217.1.84.38])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id SAA02210;
	Mon, 17 Jul 2000 18:56:34 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <KSPFJ7XA>; Mon, 17 Jul 2000 18:41:23 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF405DCC7@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'rute@nwu.edu'" <rute@nwu.edu>, Radhakrishna <rk@miel.mot.com>
Cc: jawang@cosinecom.com,
        "'aljtarik@cholla.inrs-telecom.uquebec.ca'"
	 <aljtarik@cholla.inrs-telecom.uquebec.ca>,
        "'issll@mercury.lcs.mit.edu'"
	 <issll@mercury.lcs.mit.edu>
Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
Date: Mon, 17 Jul 2000 18:41:22 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

See my response inline.

....RK

> -----Original Message-----
> From:	Rute C. Sofia [SMTP:rute@rccn.net]
> Sent:	Thursday, July 13, 2000 9:32 PM
> To:	Radhakrishna
> Cc:	'rute@nwu.edu'; jawang@cosinecom.com;
> 'aljtarik@cholla.inrs-telecom.uquebec.ca'; 'issll@mercury.lcs.mit.edu'
> Subject:	Re: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt
> 
> > >
> > > - you mention that the receiver, when getting the Path message,
> creates a
> > > DS
> > > session and generates an Resv that has info on the PHB. So, you
> suppose
> > > that
> > > the receiver (edge) has info on the PHB??  How will it know about it,
> > > shouldn't
> > > the sender be the one to have access to this information? Wouldn't it
> be
> > > better
> > > if the sender (edge *or* client host), knowing what it needs, asked
> > > (probed)
> > > the network for resources (bw, delay, etc)) according to services
> agreed
> > > and
> > > then classified the flows, thus already having the reservation
> > > established?
> >         [Radhakrishna]
> >         Even though you create a session on getting Path message, actual
> > reservation
> >         (allocation of resources) happens on the receipt of ResvConf
> > message.
> >         Since this is DiffServ domain, the edge node and the hosts on
> the
> > receiver
> >         side are aware of what PHBs are available (if they are not
> aware, it
> > does not
> >         matter. They can always request standard PHB suited for their
> > traffic and if the
> >         network does not support the request will be rejected), but they
> > won't know the
> >         actual resources (bw, buffers). Hence the receiver will signal
> the
> > required PHB
> >         along with the parameters through Resv message. The model is
> same
> >         as RSVP, but only difference is resource allocation happens with
> > ResvConf
> >         message. By doing this, there is no issue with the multicast
> because
> >         reservations are initiated by the receivers.
> >
> >         The sender can signal the desired PHB (PHB_ID), but it can not
> > signal the PHB
> >         parameters as it is not aware of what is there on receiver side.
> > Since the receivers
> >         are the ones to choose the PHB parameter values, it is better
> the
> > choice of PHB
> >         should be left to the receiver. This provides greater
> flexibility in
> > terms each
> >         receiver (say in case of multicast) can request PHB depending on
> its
> > capability.
> >
> 
> So, if I can understand, you intend to use RSVP as it works (receiver
> based) to
> do admission control on a model that needs this process on the edges of a
> defined domain, specially, that needs the edge on the sender side to know
> before any forwarding about services available...
	[Radhakrishna]  
	Yes, this model uses RSVP as it works and adds those capabilities
that
	are needed for PHB signaling and admission control.

> And what if we are speaking of sender/edge receiver/edge on different
> domains,
> the most likely case? How will this work with PHB, has you mention that
> the
> receiver will now about them? Also, if you mention that the receiver
> "will"
> find out about the SLA and PHB, then you are using simply a signaling
> protocol,
> but you still have to have something like a BB to mantain all the info
> about
> services...so, you withdraw from BB the process of edge configuring, but
> will
> not avoid having them...
	[Radhakrishna]  
	The receiver will request the required PHB through PHB_ID (RFC2836)
which
	works across domains. The edge nodes in different domains have do
appropriate
	remarking/mapping. The receiver does not need to know SLAs. If there
are appropriate
	SLAs exist to service the the request, it will be admitted,
otherwise it will be rejected.

> Another thing about your draft is that you always think of sender/receiver
> as
> being on the edge. What happens if sender/receiver are host clients?? How
> can
> they know about PHB? That is not mentioned in the draft, but in the DS
> model,
> it is clear that clients might be able to do traffic classification.
	[Radhakrishna]  
	The sender/receiver could be edge or host client. Since the
reservation is based on PHB_ID,
	it should work for both. In case of host client, the edge node has
to just do admission
	control based on SLA and the resources requested by the host client.


> >
> 
>     Regards,
>         Rute Sofia


From owner-issll@mercury.lcs.mit.edu  Wed Jul 19 10:30:45 2000
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 KAA24232
	for <issll-archive@odin.ietf.org>; Wed, 19 Jul 2000 10:30:43 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA16445
	for issll-outgoing; Wed, 19 Jul 2000 09:08:29 -0400 (EDT)
Received: from zrtps06s.us.nortel.com ([47.140.48.50])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA15574
	for <issll@mercury.lcs.mit.edu>; Wed, 19 Jul 2000 09:08:27 -0400 (EDT)
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com;
          Wed, 19 Jul 2000 09:02:19 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <P1NF3C80>; Wed, 19 Jul 2000 09:02:18 -0400
Message-ID: <13E2EF604DE5D111B2E50000F80824E8035B6824@zwdld001.ca.nortel.com>
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: mailing list problem
Date: Wed, 19 Jul 2000 09:02:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFF181.8FF9EF20"
X-Orig: <hmsyed@americasm01.nt.com>
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

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_01BFF181.8FF9EF20
Content-Type: text/plain


Hi, 

I have been trying to subscribe to ISSLL mailing list. I am not receiving
any confirmation nor i am receiving any e-mails from the discussion group.
So i conclude that i am not getting the subscription. I guess there is some
problem with the list. Does anyone has any clue??

regards

Hamid Mahmood Syed			
Software Engineer					Ph: (613) 763-6553
Advanced Wireless Technology Lab				Fax:(613)
763-2686
Nortel Networks
Email:hmsyed@nortelnetworks.com

                   *** The contents of this email are Nortel Networks
confidential***


------_=_NextPart_001_01BFF181.8FF9EF20
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.2652.35">
<TITLE>mailing list problem</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have been trying to subscribe to =
ISSLL mailing list. I am not receiving any confirmation nor i am =
receiving any e-mails from the discussion group. So i conclude that i =
am not getting the subscription. I guess there is some problem with the =
list. Does anyone has any clue??</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">regards</FONT>
</P>

<P><B><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma">Hamid Mahmood =
Syed</FONT></B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><I><FONT COLOR=3D"#808080" SIZE=3D2 FACE=3D"Tahoma">Software =
Engineer&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;</FONT> <FONT =
COLOR=3D"#008080" SIZE=3D2 FACE=3D"Tahoma">Ph:</FONT><FONT =
COLOR=3D"#808080" SIZE=3D2 FACE=3D"Tahoma"> (613) 763-6553</FONT></I>
<BR><I><FONT COLOR=3D"#808080" SIZE=3D2 FACE=3D"Tahoma">Advanced =
Wireless Technology Lab&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;</FONT> <FONT =
COLOR=3D"#008080" SIZE=3D2 FACE=3D"Tahoma">Fax:</FONT><FONT =
COLOR=3D"#808080" SIZE=3D2 FACE=3D"Tahoma">(613) 763-2686</FONT></I>
<BR><I><FONT COLOR=3D"#808080" SIZE=3D2 FACE=3D"Tahoma">Nortel Networks =
&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;</FONT> <FONT =
COLOR=3D"#008080" SIZE=3D2 FACE=3D"Tahoma">Email:</FONT><FONT =
COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Tahoma">hmsyed@nortelnetworks.com</FONT></I>
</P>

<P><I><FONT COLOR=3D"#808080" SIZE=3D2 =
FACE=3D"Tahoma"></FONT></I><I><B></B><B>&nbsp;<FONT COLOR=3D"#800000" =
SIZE=3D1 =
FACE=3D"Tahoma">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>&nbsp;<FONT =
COLOR=3D"#800000" SIZE=3D2 FACE=3D"Tahoma"> ***</FONT> <FONT =
COLOR=3D"#800000" SIZE=3D2 FACE=3D"Times New Roman">The contents of =
this email are Nortel Networks confidential***</FONT></B></I>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFF181.8FF9EF20--


From owner-issll@mercury.lcs.mit.edu  Mon Jul 24 08:07:07 2000
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 IAA05820
	for <issll-archive@odin.ietf.org>; Mon, 24 Jul 2000 08:07:06 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA20272
	for issll-outgoing; Mon, 24 Jul 2000 06:52:50 -0400 (EDT)
Received: from nscolmar.colmar.uha.fr (nscolmar.colmar.uha.fr [194.167.108.34])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA20271
	for <issll@mercury.lcs.mit.edu>; Mon, 24 Jul 2000 06:52:45 -0400 (EDT)
From: conf@colmar.uha.fr
Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31])
	by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA15029;
	Mon, 24 Jul 2000 12:16:04 +0200
Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51])
	by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07691;
	Mon, 24 Jul 2000 12:46:58 +0100 (WET DST)
Message-Id: <3.0.1.32.20000724135255.00936410@colmar.colmar.uha.fr>
X-Sender: conf@colmar.colmar.uha.fr
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Mon, 24 Jul 2000 13:52:55 +0200
To: conf@colmar.colmar.uha.fr
Subject: Call for papers of ICN'01 & Final program of ECUMN'00
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Please feel free to circulate this following :

	- call for papers of <bold>ICN'01</bold> (see
<underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr/=
ICN01.html</color></underline>
) AND=20

	- final program of <bold>ECUMN'00</bold>  (see=
 <underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr=
/ECUMN2000.html</color></underline> )

to interested colleagues.

Accept our sincere apologies if you receive multiple copies.

----------------------------------------------------------------------------=
---

<center><bold>     CALL FOR PAPERS=20

IEEE International Conference on Networking=20

ICN'01=20

July 11-13, 2001 - CREF, Colmar, France=20

</bold></center>

GENERAL INFORMATION=20


The 2001 International Conference on Networking (ICN'01) is sponsored by=
 IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized=
 by academic, research and industrial societies will be held at the=
 Technical Institute, Colmar, part of the University of Haute Alsace,=
 France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of=
 Colmar is ideally situated in the eastern part of France, near the German=
 and Swiss borders. The city of Colmar has been working on its own=
 Metropolitan Area Network (MAN) project, called OASICE, including LAN=
 interconnection, PBX interconnection and interactive video. An exhibition=
 illustrating these topics will be organized for industrial companies and=
 development research institutes.=20

In order to encourage closer interaction between academic and industrial ATM=
 research communities, we solicit both academic research papers and=
 industrial contributions.=20


TOPICS OF SPECIAL INTEREST=20


Topics of interest include, but are not limited to the following:=20

 =20

  Communications switching and routing =20

Communications modeling =20

Communications security =20

Computer communications =20

Multimedia and multicast communications =20

Internet environment =20

Network Management and control =20

Quality of Service (IntServ, DiffServ, =85) =20

Wireless Communications (Satellite, WLL, 3G) =20

Voice over IP =20

Java, Tina, Corba architectures Network signaling =20

ATM networks =20

ATM/IP integration =20

Integrated services =20

Traffic engineering =20

Telecommunication networks architectures =20

Performance evaluation, simulation =20

Mobile agents, active and intelligent networks =20

Applications and case studies =20

Protocol design and evaluation =20

MPLS=20



These topics can be discussed in term of concepts, state of the art,=
 standards, implementations, running experiments and applications.=20


INSTRUCTIONS FOR AUTHORS=20


Mail four papers or E-mail preferably in Word 6 format, or alternately a=
 postscript version of a 2000-word extended abstract summarizing an original=
 work. All the manuscripts must be written in English. The top of the first=
 page of each paper should include the title of the paper, authors' name,=
 position, address, telephone and fax numbers, e-mail of the author=
 responsible for correspondence and a list of four keywords. The deadline=
 for submission of all extended abstracts is December 10, 2000 with=
 notification of acceptance by February 20, 2001. Submission of camera-ready=
 paper is by March 30, 2001.=20

Authors of accepted papers will be invited to submit full-length manuscripts=
 for inclusion in the proceedings with ISBN.=20


All submitted papers should be sent to the following address:=20


Pascal LORENZ=20

University of Haute Alsace=20

IUT - Department GTR=20

34 rue du Grillenbreit=20

68008 Colmar, France=20

Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20

E-mail: lorenz@colmar.uha.fr=20


Check our Web page at=
 <underline><color><param>0000,0000,fefe</param>http://iutsun1.colmar.uha.fr=
/ICN01.html</color></underline> for the latest information concerning the=
 conference.=20

Best papers will be forwarded for consideration in a special issue of a=
 journal.=20


TUTORIALS AND WORKSHOPS=20


Tutorials and workshops provide overviews of current high interest topics.=
 Proposals for half of full day tutorials are due by December 10, 2000.=20


INTERNATIONAL ADVISORY COMMITTEE=20


R. Addie (Australia) - University of Southern Queensland=20

K. Begain (Jordan) - Mu'tah University=20

A. Benslimane (France) - University of Belfort-Montbeliard=20

B. Bing (Singapore) - Ngee Ann Polytechnic=20

D. Bonjour (France) - CNET=20

A. Brandwajn (USA) - University of California Santa Cruz=20

J.P. Coudreuse (France) =96 Mitsubishi=20

J. Crowcroft (UK) =96 University College London=20

S. Fdida (France) =96 LIP6=20

B. Gavish (USA) - Vanderbilt University=20

H. Guyennet (France) - University of Franche-Comte=20

J. Halpern (USA) =96 Newbridge=20

Z. Hulicki (Poland) =96 University of Cracow=20

R. Israel (France) - IEEE=20

A. Jajszczyk (Poland) - University of Mining & Metallurgy=20

A. Jamalipour (Australia) - University of Sydney=20

S. Kota (USA) - Lockeed Martin=20

D. Kouvatsos (UK) - University of Bradford=20

S. Kumar (USA) =96 Ericsson=20

G.S. Kuo (Taiwan) =96 National Central University=20

F. Le Faucheur (France) - Cisco=20

M. Lee (Korea) =96 Dongshin University=20

P. Lorenz (France) - University of Haute Alsace=20

H.. Mouftah (Canada) - Queen's University=20

G. Omidyar (USA) - Computer Sciences Corp.=20

J.J. Pansiot (France) - University of Strasbourg=20

M. Potts (Switzerland) - Martel=20

Z. Mammeri (France) - University of Toulouse=20

N. Mastorakis (Greece) - Military Institutions of University Education=20

S. Moyer (USA) - Bellcore=20

R. Muraine (France) - Newbridge=20

G. Pujolle (France) - University of Versailles-Saint-Quentin=20

S. Rao (Switzerland) - Ascom=20

A. Reid (UK) - British Telecom=20

S. Ritzenthaler (France) - Newbridge=20

P. Rolin (France) - ENST Bretagne=20

R. Saracco (Italy) - CSELT=20

G. Swallow (USA) - Cisco=20

H. Tobiet (France) =96 Clemessy=20

M. Trehel (France) =96 University of Franche-Comte=20

V.A. Villagra (Spain) =96 University of Madrid=20

E. Vazquez Gallo (Spain) =96 University of Madrid=20

O. Yang (Canada) - University of Ottawa=20


IMPORTANT DATES=20


Extended Abstract due: December 10, 2000=20

Notification of acceptance: February 20, 2001=20

Deadline for full-length camera-ready manuscript: March 30, 2001=20


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

<center><bold>1st IEEE European Conference on Universal Multiservice=
 Networks  ECUMN'2000

 October 2-4, 2000 - CREF, Colmar, France

FINAL PROGRAM

</bold></center>=20

08:30 - 18:30 Conference Registration


<underline>Monday October 2, 2000

</underline>

09:00 - 09:20 Opening Address=20


09:20 - 10:30 Tutorial Session 1

Internet Services over Mobile and Wireless Networks: Architectures and=
 Protocols

G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,=
 USA


10:30 - 11:00 Coffee Break


11:00 - 12:15 Network Architecture and Convergence

Chair: S. Ritzenthaler, Newbridge, France


MPLS and Next Generation Access Network

A. Kankkunen, Integral Access Inc, USA


Deutsche Telekom's View on Network Convergence

L. Falkenhagen Deutsche Telekom AG, Germany


A Functional Architecture for End-to-end Quality-of-Service in a=
 Multi-domain Network

E. Pagani, G.P. Rossi, University of Milano, Italy


12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence


13:00 - 14:30 Lunch


14:30 - 16:15 Traffic=20

Chair: M. Villen, Telefonica I+D, Spain


The Relevance of the Bufferless Analysis for Traffic Management in=
 Telecommunication Networks

G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,=
 University of Karlskrona/Ronneby, Sweden


Mapping of Loss and Delay Between IntServ and DiffServ

T. Chahed, G. H=E9buterne, C. Fayet, National Institute of=
 Telecommunications, France


Resource Demand of Aggregated Resource Reservations

J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland


Characterization of the MPEG-2 Video Traffic Generated by DVD Applications

A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,=
 University of Mining and Metallurgy, Poland


14:30 - 16:15 Interworking between narrow band and broadband networks

Chair: S. Chakraborty, Technical University of Helsinki, Finland


Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and=
 Services Support

L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.=
 Papadopoulos, University of Patras, Greece


Extending the Internet with the Intelligent Network Capabilities

B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,=
 France


A Suitable Service Discipline for ATM-Ethernet Interconnection

J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain


Interoperability of ATM-Ethernet Interworking System: Design and Congestion=
 Control

R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,=
 Tinisia ; K. Torki, INPG, France


16:15 - 16:45 Coffee Break


16:45 - 18:30 Routing

Chair: P. Chemouil, France Telecom R&D, France


Adaptive Routing and Load Balancing of Ephemeral Connections

M. Heusse, ENST de Bretagne, France


A new Multi-Services Rerouting Algorithm

A. Gueroui, University of Versailles, France ; L. Mokdad University of=
 Dauphine, France ; J. Ben-Othman University of Paris 6, France


Extending Mobile IP-v6 with Multicast to Support Mobile Networks in  IPv6

T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola=
 Labs, France


16:45 - 18:30 Interworking between IP and ATM

Chair: M. Potts, Martel, Switzerland


Topology Optimization of IP over ATM

L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland


Resource Reservation with Boomerang via Open Interfaces

M. Maliosz, Budapest University of Technology and Economics, Hungary


Efficient Translation of Network Performance Parameters for Transport of IP=
 Packets over Cell-Switched Subnetworks

J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,=
 Germany


Design of Adaptive Access Network and Control Protocol

H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform=
 Laboratories, Japan


19:15 Reception - Town Hall


<underline>Tuesday October 3, 2000

</underline>

09:00 - 10:45 End to end traffic Control (1)

Chair: U. Krieger, Deutsche Telecom, Germany


Guaranteed QoS for TCP flows in ATM-based DiffServ Networks

T. M=FCller, Dresden University of Technology, Germany


Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks

S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,=
 National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,=
 Taiwan


An Efficient Weight Assignment Process for GPS Servers

G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des=
 T=E9l=E9communications, France


Some Aspects of RTP - TCP Coexistence in Universal Multiservice  Networks

R. Chodorek, University of Mining and Metallurgy, Poland


09:00 - 10:45 Mobile Networks and Mobile Services

Chair: G. Omidyar, Computer Sciences Corp, USA


Voice Enabled Request and Response for Mobile Devices Supporting WAP=
 Protocol: the Constraints

A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian=
 Institute of Technology, India


IP based enhanced Data Casting Services over Radio Broadcast Networks

W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,=
 Germany


Location-Dependant and Value Added Services (VAS) for Mobile Communications

P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20


The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony=
 Operators in the Liberalization of Telecommunications

D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National=
 Technical University of Athens, Greece


10:45 - 11:15 Coffee Break


11:15 - 13:00 Multicast

Chair: G. Girardi, CSELT, Italy


A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain=
 Multicast Routing Environment

M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco


A New Routing Algorithm for Delay-Constrained Dynamic Multicast

T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.=
 Tanaka, Waseda University, Japan


Remote Time-Alignment of Interactive Services through Efficient Multicast=
 Algorithms

A. Borella, G. Cancellieri, University of Ancona, Italy


Key Establishment for IGMP Authentication in IP Multicast

T. Hardjono, B. Cain, Nortel Networks, USA


11:15 - 13:00 IP Test-beds

Chair: H. Tobiet, NMG, France


Real-Time Multimedia Services over Internet

A. Benslimane, Technical University of Belfort-Montb=E9liard, France


Telephony over IP: Theoretical Modelling and Lab Experiments

P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy


User-domain Multiservice Architecture for Wired and Wireless IP  Networks

L. Cheng, I. Marsic, The State University of New Jersey, USA


A Testbed Environment for the Performance Evaluation of Modular Network=
 Architectures

D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy


13:00 - 14:30 Lunch


14:30 - 16:15 Modeling

Chair: G. H=E9buterne, INT, France


Estimation of the Renewal Function by Empiral Data - A Bayesian  Approach

N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova=
 Deutsche Telekom, Germany


Modeling Access Networks for Quality of Service

F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and=
 Technology, USA ; D.R. Vaman, Megaxess, USA


Managing Wireless Internet Information of Electronic Advertising

E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,=
 Tohoku University, Japan


Performance Evaluation of a full Memory Multidestination Protocol for=
 Satellite Based Reliable Multicast with and without Local Recovery

H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological=
 University, Singapore


14:30 - 16:15 Tariffs and Bandwidth Allocation

Chair: P. Lorenz, University of Haute Alsace, France


INEDAC Project: A Tool to Calculate Interconnection Tariff based on a=
 Bottom-up Method

J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;=
 R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany


Auction Method and its Performance in a Dynamic Bandwidth Allocation Service

E. Takahashi, Y. Tanaka, Waseda Universiy, Japan


Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video=
 Streams to Variable Channel Bandwidth

H.F. Raynaud, M. Luong, University of Paris Nord, France


Robust Topology for Enterprise Networks against Diverse Tariff Structures

T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT=
 Service Integration Laboratories, Japan


16:15 - 16:45 Coffee Break


16:45 - 18:30 End to end Traffic Control (2)

Chair: G. H=E9buterne, INT, France


An Architecture of QoS Services for a Core Internet Network over DTM

C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.=
 Moreno, University Carlos III of Madrid, Spain


Congestion Avoidance for Unicast and Multicast Traffic

A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France


MPOA and QoS Support in LIS Internetworking Environments

I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK


A Method for Increasing Throughput based on Packet Striping

F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France


16:45 - 18:30 Advanced Networking

Chair: G.V. Morson, Cambridge Network, England


A New Network Service Environment using Active Network

K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan


Adaptive Applications over Active Networks: Case Study on Layered Multicast

L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium


Integrated Performance Monitoring of Client/Server Software

C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany


Who needs Addresses ?

V. Guruprasad, IBM, USA


20:00 Gala Dinner - Restaurant Meistermann


<underline>Wednesday October 4, 2000

</underline>

09:00 - 10:00 Tutorial Session 2

Chair: P. Rolin, France Telecom R&D, France


Active Networks and its Management

M. Brunner, NEC Europe Ltd, Germany


10:00- 10:30 Coffee Break


10:30 - 11:45 New Architectures for New Services

Chair: A. Gravey, ENST-Bretagne, France


A Novel Architecture for Efficient Protocol Processing in High Speed=
 Communication Environments

G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,=
 Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,=
 Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),=
 Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,=
 J.A. Sanchez, Lucent Technologies, The Netherlands


Using T=E9l=E9domotis Interface for a new Multiservice Network applied to=
 Monitoring the Elderly

T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,=
 University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,=
 France


Video and Interactive Internet access in a DVB Network

R. Jaeger, BetaResearch, Germany


11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services


13:00 - 14:30 Lunch


14:30 Visit of Vialis







From owner-issll@mercury.lcs.mit.edu  Thu Jul 27 16:59:45 2000
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 QAA03512
	for <issll-archive@odin.ietf.org>; Thu, 27 Jul 2000 16:59:43 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id PAA30089
	for issll-outgoing; Thu, 27 Jul 2000 15:47:40 -0400 (EDT)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id PAA27946
	for <issll@mercury.lcs.mit.edu>; Thu, 27 Jul 2000 15:47:38 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <p04310100b5a641ef725b@[18.26.0.167]>
Date: Thu, 27 Jul 2000 15:47:07 -0400
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Pgh ISSLL mtg CANCELLED, and status report
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk


Hi folks,

A couple of things.

First, we are planning to CANCEL the ISSLL meeting presently 
scheduled for the Pittsburgh IETF next week. This is, basically, 
because in our view there isn't currently enough on the agenda to 
justify a meeting.

In light of this, we thought a brief status report was in order.

1) The WG submitted four documents for publication as RFC's in May. These are:

    A Framework For Integrated Services Operation Over Diffserv Networks
    draft-ietf-issll-diffserv-rsvp-05.txt

    Format of the RSVP DCLASS Object
    draft-ietf-issll-dclass-01.txt

    Specification of the Null Service Type
    draft-ietf-issll-nullservice-00.txt

    RSVP Reservations Aggregation
    draft-ietf-issll-rsvp-aggr-02.txt

The next step in this process is that these documents are reviewed by 
the IESG and then either put forward for IETF last call or returned 
to us to address any concerns raised by IESG members. We had 
allocated some meeting time for addressing any comments from the IESG 
or IETF last calls on these docs, but it turns out that they have not 
made it through this process yet, so we do not need this time.


2) The WG has one outstanding draft:

    Integrated Service Mappings for Differentiated Services Networks
    draft-ietf-issll-ds-map-00.txt

We had planned to have a revised version of this draft to discuss at 
the meeting, but unfortunately this did not get finished in time. 
There is a substantial amount of new technical work relevant to this 
draft under way - notably but certainly not only by Anna Charny, 
Jean-Yves Le Boudec, and Jim Roberts - but we did not have time to 
get all of this work into I-D form by the deadline. A new version of 
this draft will be issued shortly after the IETF.


3) Two drafts relevant to ISSLL were submitted by individual authors 
right before the I-D deadline. Although these drafts are not 
presently on the WG's work list and the authors did not ask for 
meeting time, we want to bring them to the attention of the WG.

- The first, draft-hamid-issll-hcap-00.txt, addresses some issues 
with the use of DCLASS objects raised in the course of the authors' 
implementation work. This work is related to the "DCLASS negotiation" 
issue raised in the WG at the recent Washington, DC, IETF. At that 
time the WG chose not to pursue the issue further, but it may be 
appropriate to give this a second look. Please send your comments to 
the mailing list.

- The second, draft-rk-diffserv-rsvp-sig-00.txt, has already received 
some discussion on the ISSLL mailing list. The author has not asked, 
and the WG chairs haven't yet considered, whether this work would be 
appropriately for the WG, but again any and all comments are welcome.

Cheers,
John and Eric




From owner-issll@mercury.lcs.mit.edu  Thu Jul 27 17:30:54 2000
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 RAA10383
	for <issll-archive@odin.ietf.org>; Thu, 27 Jul 2000 17:30:52 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA03967
	for issll-outgoing; Thu, 27 Jul 2000 16:27:13 -0400 (EDT)
Received: from [18.26.0.167] (sinope.lcs.mit.edu [18.26.0.167])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA15934
	for <issll@mercury.lcs.mit.edu>; Thu, 27 Jul 2000 16:27:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <p04310101b5a648ce0fef@[18.26.0.167]>
Date: Thu, 27 Jul 2000 16:26:38 -0400
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Mailing List Cleanup
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Folks,

It's been a while since we purged the ISSLL mailing list of old dead 
addresses, and the level of bounced mail has become a bit high.

Sometime in the next few days I'm going to remove addresses that are 
returning persistent permanent errors. When this is done I'll send 
another note. If you've received this but don't receive a second note 
by Sunday evening it's possible that I deleted you by accident. If 
so, and you want to stay on the list, please send me email directly 
to get things fixed up.

---

As usual with lists that are maintained by majordomo, the easiest way 
to subscribe or unsubscribe from the ISSLL list is by sending email 
to issll-request@mercury.lcs.mit.edu _from the address you wish to 
subscribe/unsubscribe_ with the word 'subscribe' or 'unsubscribe' in 
the body of the message.

    To: issll-request@mercury.lcs.mit.edu
    From: xxx@yyy.com
    Subject: <anything you want here, doesn't matter>

    (un)subscribe


Cheers,
John W.




From owner-issll@mercury.lcs.mit.edu  Mon Jul 31 10:20:34 2000
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 KAA12010
	for <issll-archive@odin.ietf.org>; Mon, 31 Jul 2000 10:20:33 -0400 (EDT)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA21493
	for issll-outgoing; Mon, 31 Jul 2000 09:16:46 -0400 (EDT)
Received: from [147.73.133.144] (wireless-133-144.ietf.marconi.com [147.73.133.144])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA21374
	for <issll@mercury.lcs.mit.edu>; Mon, 31 Jul 2000 09:16:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu
Message-Id: <v04220800b5ab2b6b68a3@[166.142.25.31]>
Date: Mon, 31 Jul 2000 09:12:47 -0400
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: ISSLL mailing list cleanup completed
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Folks,
The issll mailing list cleanup I mentioned last week is complete.

Thanks,
John