From owner-issll@mercury.lcs.mit.edu  Thu Dec  7 07:08: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 SMTP id HAA05112
	for <issll-archive@odin.ietf.org>; Thu, 7 Dec 2000 07:08:27 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id FAA10440
	for issll-outgoing; Thu, 7 Dec 2000 05:49:44 -0500 (EST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id FAA09713
	for <issll@mercury.lcs.mit.edu>; Thu, 7 Dec 2000 05:49:42 -0500 (EST)
Received: from oleane (dyn-1-1-002.Vin.dialup.oleane.fr [195.25.4.2]) by smtp2.cluster.oleane.net with SMTP id eB7AnkN42503 for <issll@mercury.lcs.mit.edu>; Thu, 7 Dec 2000 11:49:46 +0100 (CET)
Message-ID: <002101c0603b$baeff980$8001a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <issll@mercury.lcs.mit.edu>
Subject: VoDSL Europe 
Date: Thu, 7 Dec 2000 11:52:01 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C06044.1C574D60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C06044.1C574D60
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

VoDSL Europe : the deployment scenario, Paris 16-19 January.
The international conference.
Visit the real first VoDSL exhibition ever organized:
http://www.upperside.fr/bavodsl2001.htm

------=_NextPart_000_001E_01C06044.1C574D60
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2><STRONG>VoDSL Europe </STRONG>: the =
deployment=20
scenario, Paris 16-19 January.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>The international =
conference.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Visit the real first <STRONG>VoDSL =
exhibition=20
</STRONG>ever organized:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/bavodsl2001.htm">http://www.upperside.fr/=
bavodsl2001.htm</A></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_001E_01C06044.1C574D60--



From owner-issll@mercury.lcs.mit.edu  Fri Dec  8 20:48:51 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 SMTP id UAA03519
	for <issll-archive@odin.ietf.org>; Fri, 8 Dec 2000 20:48:51 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id TAA17743
	for issll-outgoing; Fri, 8 Dec 2000 19:38:07 -0500 (EST)
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 TAA16807
	for <issll@mercury.lcs.mit.edu>; Fri, 8 Dec 2000 19:38:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: jtw@mercury.lcs.mit.edu (Unverified)
Message-Id: <p04330101b6572e0ba549@[18.26.0.167]>
Date: Fri, 8 Dec 2000 19:39:59 -0500
To: issll@mercury.lcs.mit.edu
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: ISSLL Meeting in S.D.
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Folks,

Just to remind you that the ISSLL wg will hold a short meeting at the 
San Diego IETF. We asked for a 1-hour tuesday slot, and got a 2-hour 
slot Wednesday 3:30-5:30 instead. We will not use anything near all 
of it.

AGENDA:

1) Agenda and document status (5 min)

2) Status of draft-ietf-issll-rsvp-aggr-02.txt (10 min)
   (RSVP Reservation Aggregation)

   This document was sent to the IESG for publication some time ago and
   is presently marked for "AD Review". Agenda item is a report on why
   and discussion of whether there is something the WG should do about it.

3) Document draft-ietf-issll-rsvp-cap-01.txt
   (RSVP/DCLASS capability negotiation, the RSVP CAP object)
   (Destined for Proposed Standard)

   This is work in progress on a method for negotiating various capabilities
   and responsibilities between upstream and downstream nodes in a RSVP path.
   The first use of the CAP object is to provide a way to negotiate which node
   will provide the DCLASS object in an intserv/diffserv system. The object
   is extensible to other negotiation situations.

   - presentation of draft and changes from previous version (10 min)
   - discussion

4) (possible) whether/how to continue with Intserv/Diffserv mapping draft
    draft-ietf-issll-ds-map-00.txt; current version has expired without update.

Cheers,
John and Eric



From owner-issll@mercury.lcs.mit.edu  Sat Dec  9 13:28:03 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 SMTP id NAA04097
	for <issll-archive@odin.ietf.org>; Sat, 9 Dec 2000 13:28:01 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA08278
	for issll-outgoing; Sat, 9 Dec 2000 12:17:47 -0500 (EST)
Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA19834;
	Sat, 9 Dec 2000 12:17:40 -0500 (EST)
Message-Id: <200012091717.MAA19834@mercury.lcs.mit.edu>
From: Mail Sender<postmaster@rusgoods.ru>
To: isouza@teledata.cprm.net
CC: issll@mercury.lcs.mit.edu, issll-request@mercury.lcs.mit.edu,
        istpl@singnet.com.sg, itcl@scriptics.com, itcl-request@scriptics.com
Subject: Russian Goods and Service from Moscow
Reply-To: mailsender@mailsender.ru
Date: 09.12.2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk


www.rusgoods.com    www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical 
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . 
  It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes 
watches for the Russian Air Forces , Russian Naval Forces. 
  All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the 
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any 
middlemans.
 The submarine "Kursk" had on board mechanical marine hronometr 6MX. 
 ===============================================================
The "table" of orders.    Here you can to order, to find, to know almost everything, than the Russia is rich, 
everything 
that does not contradict Russian Federation laws. 
Here you can receive or order:

The information about any enterprise, firm, organization, or person in Russia 
The production or any goods of Russian manufactories, and other things if it is possible. 
===============================================================
www.rusgoods.com    www.rusgoods.ru


From owner-issll@mercury.lcs.mit.edu  Tue Dec 12 23:37: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 SMTP id XAA00847
	for <issll-archive@odin.ietf.org>; Tue, 12 Dec 2000 23:37:12 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id WAA27500
	for issll-outgoing; Tue, 12 Dec 2000 22:26:31 -0500 (EST)
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 WAA30102
	for <issll@mercury.lcs.mit.edu>; Tue, 12 Dec 2000 22:26:18 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id UAA26436; Tue, 12 Dec 2000 20:25:58 -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 UAA24601; Tue, 12 Dec 2000 20:25:55 -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 JAA18567;
	Wed, 13 Dec 2000 09:01:29 +0530 (IST)
Received: by xmail.miel.mot.com with Internet Mail Service (5.5.2650.21)
	id <X22N1S51>; Wed, 13 Dec 2000 08:58:48 +0530
Message-ID: <2C202C0F886DD3119B1200A0C9A85FF401981C22@xmail.miel.mot.com>
From: Radhakrishna <rk@miel.mot.com>
To: "'wnk@fub.it'" <wnk@fub.it>, Radhakrishna <rk@miel.mot.com>,
        "'radhakrishna@cportcorp.com'" <radhakrishna@cportcorp.com>
Cc: "'issll@mercury.lcs.mit.edu'" <issll@mercury.lcs.mit.edu>
Subject: RE: questions about draft-rk-diffserv-rsvp-sig-00
Date: Wed, 13 Dec 2000 08:58:47 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C064B4.CE1583C2"
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_000_01C064B4.CE1583C2
Content-Type: text/plain;
	charset="iso-8859-1"

Roberto Winkler,

Thanks for going through this I-D and the comments. I will be
putting a new revision of this I-D and hope it will address all
your questions. Attached below are the discussions we had in the
past, which I think addresses some of your questions.
I will try to answer others within couple of days.

I look forward for more comments.

....RK


-----Original Message-----
From: wnk@fub.it [mailto:wnk@fub.it]
Sent: Tuesday, December 12, 2000 10:46 AM
To: rk@miel.mot.com
Subject: questions about draft-rk-diffserv-rsvp-sig-00



hello,

I maybe late, but I have some questions about your I-D in subject. Hope you
don't mind to receive them and to get clarifications from you.

1 - throughout the paper: is the sending sode (which the IP address in the
session identifier refers to) the source of the data flow or ER1/BR1 ?

3 - second paragraph on page 3 states that '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 the resources are
available' Is this intermediate node RSVP-able or what else ? More, with
reference to the same sentence, what's the reason (apart from reduced
processing inside the core) for letting Path and ResvConf messages flow
hop-by-hop, whereas Resv messages are edge-to-edge ?

4 - have you removed refresh timers both at the edges and in the core
DiffServ network ?

5 - why do you impose that 'Each DiffServ node allows a pre-configured
number of sessions' ?

6 - is R2 in Fig. 2 an RSVP-capable router inside the DiffServ domain ? If
not, then I fear I have understood nothing of your proposal. If yes, then
what's the advantage of your model wrt the one considered by ISSLS WP for
intserv over diffserv (with some RSVP-capable node in the Diffserv region)?
I may guess that you gain something in scalability for the reduced
processing burden (RSVP RESV are not processed inside the core) and the
probably faster scheduling (PHB-oriented), but is the effort of modifying
RSVP worth the goal ?

7 - where is the admission control module in figure 3 ?

8 - are the usual TSpec parameters in the PHB_PARAM element used for
admission control purposes ?

9 - are DS_SESSION and DS_FLOWSPEC objects created by the receiver or by
ER2/BR2?


This was lonfer than I thouth. Thank you very much for your patience and
best regards







Roberto Winkler
Senior Researcher
Fondazione Ugo Bordoni
Via B. Castiglione, 59
00142 Rome Italy

tel +39 0654803411
fax. +39 0654804404
e-mail wnk@fub.it




------_=_NextPart_000_01C064B4.CE1583C2
Content-Type: message/rfc822
Content-Description: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt

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"

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

------_=_NextPart_000_01C064B4.CE1583C2
Content-Type: message/rfc822
Content-Description: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt

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"

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)
> 

------_=_NextPart_000_01C064B4.CE1583C2--


From owner-issll@mercury.lcs.mit.edu  Wed Dec 13 18:01: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 SMTP id SAA08302
	for <issll-archive@odin.ietf.org>; Wed, 13 Dec 2000 18:01:53 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA09848
	for issll-outgoing; Wed, 13 Dec 2000 16:58:23 -0500 (EST)
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA32041
	for <issll@mercury.lcs.mit.edu>; Wed, 13 Dec 2000 16:58:18 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 13 Dec 2000 12:03:34 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Dec 2000 12:04:14 -0800 (Pacific Standard Time)
Received: from DF-MILO.platinum.corp.microsoft.com ([172.30.236.125]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Wed, 13 Dec 2000 12:04:13 -0800
Subject: draft-ietf-issll-rsvp-cap-01.txt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 13 Dec 2000 12:04:13 -0800
Message-ID: <A5769B3C2F02274B9D17F5FB4495DD5F536846@DF-SCOOBY.platinum.corp.microsoft.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Thread-Topic: I-D ACTION:draft-ietf-issll-rsvp-cap-00.txt
Thread-Index: AcAjfkgUjPg3VdwDRUuUTSquTQJDnxBrsEQQ
From: "Yoram Bernet" <yoramb@exchange.microsoft.com>
To: "Hamid Syed" <hmsyed@nortelnetworks.com>
Cc: <issll@mercury.lcs.mit.edu>
X-OriginalArrivalTime: 13 Dec 2000 20:04:13.0984 (UTC) FILETIME=[DD7F8200:01C0653F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id QAA00530
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hamid:

Please pardon my delay in raising these issues. But - here goes:

I am struggling with the real application of the  hcap object. I believe
that it is useful, but - its exact value eludes me. For example, in
section 3.1, you state that: 

"This information can help the network element to decide whether or not
a DCLASS object must be added in a RSVP message for the flow."

and:

"The network edge router will then know that the upstream node/end host
does not require a DCLASS object."

I think that this is presented as the justification for the hcap object,
yet - I don't think that this is really a good justification. Why not
just always add a DCLASS object to RSVP messages? What is the cost of
doing so? What is the difference (in terms of the results) between
always adding the DCLASS object and selectively adding the DCLASS
object? I think that there is no difference - consider the following:

1. No HCAP:
a. Marking capable hosts - DCLASS sent, hosts mark.
b. Non-marking capable hosts - DCLAS sent, hosts do not mark.

2. HCAP:
a. Marking capable hosts - DCLASS sent, hosts mark.
b. Non-marking capable hosts - no DCLASS sent, hosts do not mark.

So - while the hcap object does affect whether or not a DCLASS is sent,
it doesn't seem to effect whether the host actually marks or not. So -
the only value of the hcap object here, is to save the network device
the trouble of sending a DCLASS that would be ignored. But then -
sending a DCLASS object seems to be pretty low cost behaviour.

Similarly, in 3.2, I think that the hcap object is presented as nothing
more than an optimization and a debatable one, at that. The optimization
is to prevent a network element from generating a DCLASS if it is going
to be ignored. The value of this optimization is debatable because the
cost of processing hcap objects and storing related state is not clearly
worth the cost savings of not 'just sending a DCLASS, always'.

I think that there might be a real value to the HCAP object. But - I
think that it is less in telling a network element when to send a DCLASS
and when not to and more in helping a network element to validate the
DSCP provided by hosts. For example - it may be the case that at the
network element, traffic arrives from a variety of hosts. Some of this
traffic is marked purposely, by DCLASS aware hosts. Other is marked
arbitrarily, by 'rogue' hosts. Perhaps this is the utility of the HCAP
object. 

In section 5, it states that the network edge must be manually
configured to either send a DCLASS object, install a filter to cause
marking for a flow, or both. There is a third option - do neither. For
example, consider the ingress router to a diffserv network that offers a
simple static SLA (of the form customer on interfgace A gets to send 1
Mbps of traffic marked EF). In the simplest case, there is no need to
send a DCLASS and no need to mark on behalf of the customer. The
customer simply uses whatever strategies are appropriate for marking and
the provider simply polices to enforce the SLA.

Yoram

 


From owner-issll@mercury.lcs.mit.edu  Sat Dec 16 03:56:03 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 SMTP id DAA00484
	for <issll-archive@odin.ietf.org>; Sat, 16 Dec 2000 03:56:02 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id CAA09247
	for issll-outgoing; Sat, 16 Dec 2000 02:56:25 -0500 (EST)
Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id CAA08780
	for <issll@mercury.lcs.mit.edu>; Sat, 16 Dec 2000 02:56:22 -0500 (EST)
Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com
 (Rockliffe SMTPRA 3.4.2) with SMTP id <B0001148343@mailsrv02.multitude.com>;
 Fri, 15 Dec 2000 23:53:10 -0800
Message-ID: <04dc01c06736$1f5b5cb0$3a0514ac@sbarber2k>
From: "Simon Barber" <simon@firetalk.com>
To: <johan.sjoberg@era.ericsson.se>, <ari.lakaniemi@nokia.com>,
        <QXIE1@email.mot.com>, <csp@isi.edu>
Cc: <issll@mercury.lcs.mit.edu>
Subject: Variable error coding for 3G wireless
Date: Fri, 15 Dec 2000 23:59:31 -0800
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.50.4133.2400
Disposition-Notification-To: "Simon Barber" <simon@firetalk.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

A quick go at getting some of my ideas down. Comments wanted.

Simon.



IP over medium loss channels.

Thrid generation wireless networks will be widespread, and give IP a new
challenge. To date pretty much all L2 transports which IP has run over have
given IP a low bit error rate channel. Where they havn't (typically
wireless) L2 techniques such as FEC and retransmission have been used to
simulate a reliable channel. The reson for this is that the main traffic
type has been TCP - the most used IP transport to date. TCP uses packet loss
to detect congestion, and hence a L2 that drops more than a tiny fraction of
packets causes throughput to drop drastically (note: how does TCP behave
when it receives corrupt packets?). To prevent this happening FEC can be
used. FEC adds redundancy to the data bits on the channel, to allow recovery
of corrupt data. The problem is that to make the channel reliable enough for
TCP, a lot of FEC bits must be added. This makes the channel very
inefficient for data that does not need this level of reliability. A second
technique used is retransmission. This is often used in conjunction with
FEC. ACK or NACK packets are transmitted at L2 to guarantee reliablility of
the IP data. This adds latency that is unacceptable for real-time traffic
(such as voice).

2nd generation digital cellular systems do an excellent job of using a very
scarse resource (radio spectrum) to transmit voice. To achieve the levels of
efficiency required for financially viable operation of these networks (the
spectrum is expensive) - many specialised techniques are used. Now that 3rd
generation digital cellular systems are being developed a big question is
how can the efficiency of 2G cellular voice be combined with the IP network,
ideally in an end-to-end model.

In 2nd gen cellular selective FEC is an important part of the spectral
efficiency. Within a frame from a voice codec transmitted over the air
certain bits are protected with more FEC than other bits - in accordance
with how important those bits are for the decoding of the voice without
artifacts. This technique could also be usefully applied to other data
types, MPEG video for example.

I propose a new IP layer packet header option, to label the importance of
various parts of a packet.

The option could be added by any IP endpoint or by a router (by
stateful(perhaps) inspection of the data in the packet).

The option would list what level of protection should be given to various
parts of the packet. For example for voice data, compressed with the GSM-EFR
codec, the packet headers would be listed as requiring a high level of
protection,  and the GSM data would be listed as requiring protection of
varying levels, just as 2G cellular applies it today.

This technique will increase the size of the packet, but over the critical,
efficiency sensitive links (such as 3G wireless) header compression will all
but completely remove this overhead. The resulting data will be able to
closely approach 2G cellular's efficiency for voice data, and the technique
is general for other data types.

Just as real-time data can be protected by this technique, TCP data could be
protected as well. TCP packets could be marked as requiring a particular
class of reliability. L2 could then use whatever technique necessary to
provide this.

It would be important that the way the importance of various packet parts is
expressed be generic, and not given in terms of specific FEC codes, etc.
This will allow future use of this information on different medium loss
channels.

Issues:

1) The TOS bits already have a 'low loss' marker. This could provide the
necessary distinction for TCP protection, without a new header. I don't know
the current state of these bits.
2) Will the header compression techniques compress IP options?
3) Will there be interactions with existing IP stacks due to the presence of
a new option?
4) Some data types need several (a small number) of different patterns of
protection for different packets - header compression would need to be chang
ed to cope with a small number of different possibilities for the new option
data.
5) How would apps detect when they should add this new option (when there is
a lossy channel) and when not to do so?

Features:
The IP packet payload remains unchanged by the protection information - this
is very good for the end-to-end model. An existing application using GSM
voice over RTP over IP would remain backwards compatible and essentially
unchanged.

Use:

There are 2 ways the new header would be added to IP packets.
1) a new IOCTL in the sockets API would allow setting of error protection.
2) packet inspection and addition by routers.

Simon Barber




From owner-issll@mercury.lcs.mit.edu  Sat Dec 16 12:11: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 SMTP id MAA28372
	for <issll-archive@odin.ietf.org>; Sat, 16 Dec 2000 12:11:32 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id LAA06273
	for issll-outgoing; Sat, 16 Dec 2000 11:13:45 -0500 (EST)
Received: from server.nurcad.ufsc.br (server.nurcad.ufsc.br [150.162.229.1])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id LAA05060
	for <issll@mercury.lcs.mit.edu>; Sat, 16 Dec 2000 11:13:35 -0500 (EST)
Received: from frank (unverified [200.176.78.101]) by server.nurcad.ufsc.br
 (EMWAC SMTPRS 0.83) with SMTP id <B0000015301@server.nurcad.ufsc.br>;
 Sat, 16 Dec 2000 13:14:06 -0300
From: "SBRC 2001" <sbrc2001@nurcad.ufsc.br>
To: <sbrc2001@nurcad.ufsc.br>
Subject: SBRC 2001: Call for Papers
Date: Sat, 16 Dec 2000 14:11:55 -0200
Message-ID: <LPBBLLGBDBKAFHPJOMHHIELJCCAA.sbrc2001@nurcad.ufsc.br>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id LAA06273
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA28372

[Please distribute; we apologize if you receive multiple copies.]

                              SBRC 2001
            19th BRAZILIAN SYMPOSIUM ON COMPUTER NETWORKS
        Florianópolis, Santa Catarina, Brazil; May 22-25, 2001

The Brazilian Symposium on Computer Networks (SBRC) is an annual event
promoted by the Brazilian Computing Society (SBC) and by the  National
Laboratory of Computer Networks (LARC). The SBRC has become  the  most
important forum for professionals interested in computer networks  and
distributed systems in Brazil over the years. In its 19th edition, the
SBRC  will  consist  of  technical  sessions,   tutorials,  workshops,
lectures,  mini-courses  and  panels.  An   exhibition  of   products,
equipment and services is also being organized.

CALL FOR PAPERS FOR THE TECHNICAL SESSIONS

Authors are invited to submit  papers  describing  research  projects,
experimental results and recent developments related, but not limited,
to the following topics:

- high-speed networks;
- wireless communication;
- the Internet: protocols, services and applications;
- quality of service (QoS);
- management of computer and telecommunication networks;
- security;
- middleware;
- distributed multimedia systems;
- distributed systems: algorithms, real-time and fault-tolerance;
- multicomputers and distributed processing;
- performance evaluation;
- specification, verification, implementation and testing of
  distributed systems and protocols;
- mobile agents and active networks;
- multi-agent systems;
- mobile computing.

The submission of papers  will  be  processed  electronically.  Papers
must be written in English or Portuguese, and must  be  in  Postscript
Postscript (please use generic postscript) or PDF (generated by  Adobe
Acrobat) format. Please do not send papers in the .doc format used  by
MS Word. The paper should  have  no  more  than  16  pages,  including
abstract, figures, diagrams, bibliography, etc (please  avoid  figures
in bitmap format). The page size should be A4 (29,7 by 21,0 cm),  with
top margin of 3,0 cm, and bottom  and  side  margins  of  2,5 cm;  the
text should be in 12-point Times font, disposed  in  a  single  column
with no more than 45 lines.  Additional  information  related  to  the
submission of papers can be found at http://www.gta.ufrj.br/sbrc2001.

This call for papers can be found in HTML, PDF, and  doc  formats,  in
both English and Portuguese, at http://www.sbrc2001.ufsc.br.

IMPORTANT DATES
Preliminary version due         Jan 26, 2001
Notification of acceptance      Mar 03, 2001
Final version due               Apr 06, 2001

GENERAL CHAIR OF THE SYMPOSIUM
Jean-Marie Farines
DAS/UFSC and NURCAD/UFSC
E-Mail: farines@lcmi.ufsc.br

CHAIR OF THE PROGRAM COMMITTEE
Otto Carlos Muniz Bandeira Duarte
GTA/UFRJ
E-Mail: otto@gta.ufrj.br

PROGRAM COMMITTEE
Aloysio de Castro Pinto Pedroza - UFRJ
Antônio Alfredo Ferreira Loureiro - UFMG
Carlos Becker Westphall - UFSC
Carlos de Castro Goulart - UFV
Djamel Sadok - UFPE
Edmundo A. de Souza e Silva - UFRJ
Edmundo Roberto Mauro Madeira - Unicamp
Eduardo Whitaker Bergamini - INPE
Eleri Cardozo - Unicamp
Elias Procopio Duarte Jr - UFPR
Guido Lemos de Sousa Filho - UFRN
Jean-Marie Farines - UFSC
Joberto Sergio Barbosa Martins - UNIFACS
Joni da Silva Fraga  - UFSC
José Augusto Suruagy Monteiro - UNIFACS
José Ferreira de Rezende - UFRJ
José Gonçalves Pereira Filho - UFES
Jose Marcos Silva Nogueira - UFMG
José Neuman de Souza - UFC
Julius Leite - UFF
Luís Felipe Magalhães de Moraes - UFRJ
Luiz Eduardo Buzato - Unicamp
Luiz Fernando Gomes Soares - PUC/RIO
Luiz Fernando Rust da Costa Carmo - UFRJ
Marcus Endler - USP
Maria Izabel Cavalcante Cabral - UFPb
Maria Janilce Almeida - UFRGS
Mauricio Magalhães - Unicamp
Michael Stanton - UFF
Nelson Fonseca - Unicamp
Noemi Rodriguez - PUC/Rio
Orlando Loques - UFF
Otto Carlos Muniz Bandeira Duarte - UFRJ
Raimundo José de Araújo Macêdo - UFBA
Ricardo de Oliveira Anido - Unicamp
Rogério Drummond - Unicamp
Rosa Maria M. Leão - UFRJ
Wanderley Lopes de Souza - UFSCar
Wilson Vicente Ruggiero - USP

ORGANIZED BY
UFSC - Federal University of Santa Catarina
NURCAD - High Speed Networks and High Performance Computing Group
DAS - Department of Automation and Systems
INE - Department of Computing and Statistics

PROMOTED BY
SBC - Brazilian Computer Society
LARC - National Laboratory of Computer Networks

ADDITIONAL INFORMATION ABOUT THE SYMPOSIUM
E-Mail: sbrc2001@nurcad.ufsc.br
WWW:    http://www.sbrc2001.ufsc.br



From owner-issll@mercury.lcs.mit.edu  Mon Dec 18 12:23:00 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 SMTP id MAA11592
	for <issll-archive@odin.ietf.org>; Mon, 18 Dec 2000 12:22:55 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA14851
	for issll-outgoing; Mon, 18 Dec 2000 10:29:54 -0500 (EST)
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA15132
	for <issll@mercury.lcs.mit.edu>; Mon, 18 Dec 2000 10:29:44 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 18 Dec 2000 10:27:32 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Y7QJ9W2C>; Mon, 18 Dec 2000 10:27:34 -0500
Message-ID: <13E2EF604DE5D111B2E50000F80824E805B224FA@zwdld001.ca.nortel.com>
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: "'Yoram Bernet'" <yoramb@exchange.microsoft.com>
Cc: issll <issll@mercury.lcs.mit.edu>
Subject: RE: draft-ietf-issll-rsvp-cap-01.txt
Date: Mon, 18 Dec 2000 10:27:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C06907.078E0790"
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_01C06907.078E0790
Content-Type: text/plain;
	charset="iso-8859-1"

Yoram,

Couple of clearifications here..

1. The object is defined as (Capability Object, CAP) NOT "hcap". This means
that it must not be misunderstood as an object which does interact between
the hosts and the edge routers for marking only

2. The intent of the D-mark bit is not just the scenarios you described. I
re-phrase your scenarioes (though I still believe that do not limit CAP
object just for marking or just between end host and edge of the network) 
	1. No CAP:
	a. Marking capable hosts - DCLASS sent, hosts mark.
	b. Non-marking capable hosts - DCLAS sent, hosts do not mark.

	2. CAP:
	a. Marking capable hosts - DCLASS sent, hosts mark. The edge router
assumes a marked traffic arrival and may be just have to install policing
rules 
	b. Non-marking capable hosts - no DCLASS sent, hosts do not mark.
The edge router have to install install filters to mark the traffic from the
end host. So the capability object really provides more intelligent
decisions made at the edge device or at the downstream nodes on RSVP PATH
messages.

Now, as i mentioned before (and also in the draft) that D-mark is an initial
usage case for the CAP object. Other applications/utilities are really out
there and I agree with you that other possible usages of the CAP object must
be captured as well. I would welcome any suggestion in this regard. 

Thanx for your comments anyways.

cheers
-Hamid



> -----Original Message-----
> From:	Yoram Bernet [SMTP:yoramb@Exchange.Microsoft.com]
> Sent:	Wednesday, December 13, 2000 3:04 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	issll
> Subject:	draft-ietf-issll-rsvp-cap-01.txt
> 
> Hamid:
> 
> Please pardon my delay in raising these issues. But - here goes:
> 
> I am struggling with the real application of the  hcap object. I believe
> that it is useful, but - its exact value eludes me. For example, in
> section 3.1, you state that: 
> 
> "This information can help the network element to decide whether or not
> a DCLASS object must be added in a RSVP message for the flow."
> 
> and:
> 
> "The network edge router will then know that the upstream node/end host
> does not require a DCLASS object."
> 
> I think that this is presented as the justification for the hcap object,
> yet - I don't think that this is really a good justification. Why not
> just always add a DCLASS object to RSVP messages? What is the cost of
> doing so? What is the difference (in terms of the results) between
> always adding the DCLASS object and selectively adding the DCLASS
> object? I think that there is no difference - consider the following:
> 
> 1. No HCAP:
> a. Marking capable hosts - DCLASS sent, hosts mark.
> b. Non-marking capable hosts - DCLAS sent, hosts do not mark.
> 
> 2. HCAP:
> a. Marking capable hosts - DCLASS sent, hosts mark.
> b. Non-marking capable hosts - no DCLASS sent, hosts do not mark.
> 
> So - while the hcap object does affect whether or not a DCLASS is sent,
> it doesn't seem to effect whether the host actually marks or not. So -
> the only value of the hcap object here, is to save the network device
> the trouble of sending a DCLASS that would be ignored. But then -
> sending a DCLASS object seems to be pretty low cost behaviour.
> 
> Similarly, in 3.2, I think that the hcap object is presented as nothing
> more than an optimization and a debatable one, at that. The optimization
> is to prevent a network element from generating a DCLASS if it is going
> to be ignored. The value of this optimization is debatable because the
> cost of processing hcap objects and storing related state is not clearly
> worth the cost savings of not 'just sending a DCLASS, always'.
> 
> I think that there might be a real value to the HCAP object. But - I
> think that it is less in telling a network element when to send a DCLASS
> and when not to and more in helping a network element to validate the
> DSCP provided by hosts. For example - it may be the case that at the
> network element, traffic arrives from a variety of hosts. Some of this
> traffic is marked purposely, by DCLASS aware hosts. Other is marked
> arbitrarily, by 'rogue' hosts. Perhaps this is the utility of the HCAP
> object. 
> 
> In section 5, it states that the network edge must be manually
> configured to either send a DCLASS object, install a filter to cause
> marking for a flow, or both. There is a third option - do neither. For
> example, consider the ingress router to a diffserv network that offers a
> simple static SLA (of the form customer on interfgace A gets to send 1
> Mbps of traffic marked EF). In the simplest case, there is no need to
> send a DCLASS and no need to mark on behalf of the customer. The
> customer simply uses whatever strategies are appropriate for marking and
> the provider simply polices to enforce the SLA.
> 
> Yoram
> 
>  

------_=_NextPart_001_01C06907.078E0790
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: draft-ietf-issll-rsvp-cap-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Yoram,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Couple of =
clearifications here..</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">1. The object is =
defined as (Capability Object, CAP)<U><B> NOT</B></U> &quot;hcap&quot;. =
This means that it must not be misunderstood as an object which does =
interact between the hosts and the edge routers for marking =
only</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">2. The intent of the =
D-mark bit is not just the scenarios you described. I re-phrase your =
scenarioes (though I still believe that do not limit CAP object just =
for marking or just between end host and edge of the network) =
</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">1. No </FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">CAP</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a. Marking capable hosts - DCLASS =
sent, hosts mark.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">b. Non-marking capable hosts - DCLAS =
sent, hosts do not mark.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. </FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">CAP</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a. Marking capable hosts - DCLASS =
sent, hosts mark. </FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">The edge router assumes a marked traffic arrival and may =
be just have to install policing rules </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b. Non-marking capable hosts - no =
DCLASS sent, hosts do not mark. </FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">The edge router have to install install filters to mark =
the traffic from the end host. So the capability object really provides =
more intelligent decisions made at the edge device or at the downstream =
nodes on RSVP PATH messages.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Now, as i mentioned =
before (and also in the draft) that D-mark is an initial usage case for =
the CAP object. Other applications/utilities are really out there and I =
agree with you that other possible usages of the CAP object must be =
captured as well. I would welcome any suggestion in this regard. =
</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Thanx for your =
comments anyways.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">cheers</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">-Hamid</FONT>
</P>
<BR>
<BR>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Yoram Bernet =
[SMTP:yoramb@Exchange.Microsoft.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, December 13, 2000 3:04 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Syed, Hamid [WDLN2:AN22:EXCH]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">issll</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 =
FACE=3D"Arial">draft-ietf-issll-rsvp-cap-01.txt</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Please pardon my delay in raising =
these issues. But - here goes:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am struggling with the real =
application of the&nbsp; hcap object. I believe</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that it is useful, but - its exact =
value eludes me. For example, in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">section 3.1, you state that: </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;This information can help the =
network element to decide whether or not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a DCLASS object must be added in a =
RSVP message for the flow.&quot;</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;The network edge router will =
then know that the upstream node/end host</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not require a DCLASS =
object.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think that this is presented as the =
justification for the hcap object,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">yet - I don't think that this is =
really a good justification. Why not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">just always add a DCLASS object to =
RSVP messages? What is the cost of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">doing so? What is the difference (in =
terms of the results) between</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">always adding the DCLASS object and =
selectively adding the DCLASS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">object? I think that there is no =
difference - consider the following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. No HCAP:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a. Marking capable hosts - DCLASS =
sent, hosts mark.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">b. Non-marking capable hosts - DCLAS =
sent, hosts do not mark.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. HCAP:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a. Marking capable hosts - DCLASS =
sent, hosts mark.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">b. Non-marking capable hosts - no =
DCLASS sent, hosts do not mark.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So - while the hcap object does affect =
whether or not a DCLASS is sent,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it doesn't seem to effect whether the =
host actually marks or not. So -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the only value of the hcap object =
here, is to save the network device</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the trouble of sending a DCLASS that =
would be ignored. But then -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sending a DCLASS object seems to be =
pretty low cost behaviour.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Similarly, in 3.2, I think that the =
hcap object is presented as nothing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">more than an optimization and a =
debatable one, at that. The optimization</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is to prevent a network element from =
generating a DCLASS if it is going</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to be ignored. The value of this =
optimization is debatable because the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cost of processing hcap objects and =
storing related state is not clearly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">worth the cost savings of not 'just =
sending a DCLASS, always'.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I think that there might be a real =
value to the HCAP object. But - I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">think that it is less in telling a =
network element when to send a DCLASS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and when not to and more in helping a =
network element to validate the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DSCP provided by hosts. For example - =
it may be the case that at the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">network element, traffic arrives from =
a variety of hosts. Some of this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">traffic is marked purposely, by =
DCLASS aware hosts. Other is marked</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">arbitrarily, by 'rogue' hosts. =
Perhaps this is the utility of the HCAP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">object. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In section 5, it states that the =
network edge must be manually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">configured to either send a DCLASS =
object, install a filter to cause</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">marking for a flow, or both. There is =
a third option - do neither. For</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">example, consider the ingress router =
to a diffserv network that offers a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">simple static SLA (of the form =
customer on interfgace A gets to send 1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Mbps of traffic marked EF). In the =
simplest case, there is no need to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">send a DCLASS and no need to mark on =
behalf of the customer. The</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">customer simply uses whatever =
strategies are appropriate for marking and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the provider simply polices to =
enforce the SLA.</FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C06907.078E0790--


From owner-issll@mercury.lcs.mit.edu  Tue Dec 19 14:35:44 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 SMTP id OAA22701
	for <issll-archive@odin.ietf.org>; Tue, 19 Dec 2000 14:35:39 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA28208
	for issll-outgoing; Tue, 19 Dec 2000 12:55:08 -0500 (EST)
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA20747
	for <issll@mercury.lcs.mit.edu>; Tue, 19 Dec 2000 12:55:06 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 19 Dec 2000 09:00:42 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Dec 2000 09:01:24 -0800 (Pacific Standard Time)
Received: from DF-SCOOBY.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 19 Dec 2000 09:01:24 -0800
content-class: urn:content-classes:message
Subject: RE: draft-ietf-issll-rsvp-cap-01.txt
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 19 Dec 2000 09:01:23 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
Message-ID: <A5769B3C2F02274B9D17F5FB4495DD5F5369F6@DF-SCOOBY.platinum.corp.microsoft.com>
Thread-Topic: draft-ietf-issll-rsvp-cap-01.txt
Thread-Index: AcBpB0rYnzHaWcoNS+6QLF1lITqwFwABlZXg
From: "Yoram Bernet" <yoramb@exchange.microsoft.com>
To: "Hamid Syed" <hmsyed@nortelnetworks.com>
Cc: "issll" <issll@mercury.lcs.mit.edu>
X-OriginalArrivalTime: 19 Dec 2000 17:01:24.0343 (UTC) FILETIME=[518FA070:01C069DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id MAA20817
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Couple of clearifications here.. 
1. The object is defined as (Capability Object, CAP) NOT "hcap". This
means that it must not be misunderstood as an object which does interact
between the hosts and the edge routers for marking only

[Yoram Bernet] OK - noted. I agree that it should not be limited to
host/router interaction.  

2. The intent of the D-mark bit is not just the scenarios you described.


[Yoram Bernet]  Hamid - I agree with you entirely. The problem is that
these are the scenarios that *you* described, right out of the draft and
frankly, in and of themselves, they do not provide any justification for
the CAP. 

I re-phrase your scenarioes (though I still believe that do not limit
CAP object just for marking or just between end host and edge of the
network) 
1. No CAP: 
a. Marking capable hosts - DCLASS sent, hosts mark. 
b. Non-marking capable hosts - DCLAS sent, hosts do not mark. 
2. CAP: 
a. Marking capable hosts - DCLASS sent, hosts mark. The edge router
assumes a marked traffic arrival and may be just have to install
policing rules 
b. Non-marking capable hosts - no DCLASS sent, hosts do not mark. The
edge router have to install install filters to mark the traffic from the
end host. So the capability object really provides more intelligent
decisions made at the edge device or at the downstream nodes on RSVP
PATH messages.

[Yoram Bernet]  So now (in this e-mail) you have added a discussion of
the functionality that might justify the CAP object. As I stated at the
meeting, this issue is much more about filters and marking and so forth
and that's what needs to be talked about. Instead, your draft focuses
exclusively on whether or not a DCLASS object should be sent. The thing
is that the real usage of the cap object with respect to marking, is
quite complicated. When you talk about installing filters - what filters
are these exactly? What remarking is done in different scenarios? Is
marking really the issue or is it policing? 
 
Now, as i mentioned before (and also in the draft) that D-mark is an
initial usage case for the CAP object. Other applications/utilities are
really out there and I agree with you that other possible usages of the
CAP object must be captured as well. I would welcome any suggestion in
this regard. 

[Yoram Bernet] I'm not asking you to capture 'other possible usages'.
I'm asking you to think through the one you already presented more
thoroughly and to justify it. 

My suggestions are:
1. Limit the draft to be nothing more than a definition of the CAP
object.
2. Issue separate draft(s) that each describe a particular use of the
object (e.g. for enabling a host to tell the network that it is capable
of marking) and that clearly explain what the network will do with the
information that is conveyed to it by the CAP object. If you can't
clearly articulate what the network would do with the information in the
CAP object and why it is able to do something better with that
information than it would without it, then that application of the CAP
object can't be justified. I've done a lot of thinking about the
application that you suggest for the CAP object. I think that it's an
important issue to think through. I suspect that it is useful
information, but can't quite articulate yet how it would be used. I've
done a bit of writing on it, but nothing that is ready for consumption
yet. As soon as it is, I will post it to the list.


Thanx for your comments anyways. 
cheers 
-Hamid 

[Yoram Bernet] Regards,
Yoram

-----Original Message----- 
From:   Yoram Bernet [SMTP:yoramb@Exchange.Microsoft.com] 
Sent:   Wednesday, December 13, 2000 3:04 PM 
To:     Syed, Hamid [WDLN2:AN22:EXCH] 
Cc:     issll 
Subject:        draft-ietf-issll-rsvp-cap-01.txt 
Hamid: 
Please pardon my delay in raising these issues. But - here goes: 
I am struggling with the real application of the  hcap object. I believe

that it is useful, but - its exact value eludes me. For example, in 
section 3.1, you state that: 
"This information can help the network element to decide whether or not 
a DCLASS object must be added in a RSVP message for the flow." 
and: 
"The network edge router will then know that the upstream node/end host 
does not require a DCLASS object." 
I think that this is presented as the justification for the hcap object,

yet - I don't think that this is really a good justification. Why not 
just always add a DCLASS object to RSVP messages? What is the cost of 
doing so? What is the difference (in terms of the results) between 
always adding the DCLASS object and selectively adding the DCLASS 
object? I think that there is no difference - consider the following: 
1. No HCAP: 
a. Marking capable hosts - DCLASS sent, hosts mark. 
b. Non-marking capable hosts - DCLAS sent, hosts do not mark. 
2. HCAP: 
a. Marking capable hosts - DCLASS sent, hosts mark. 
b. Non-marking capable hosts - no DCLASS sent, hosts do not mark. 
So - while the hcap object does affect whether or not a DCLASS is sent, 
it doesn't seem to effect whether the host actually marks or not. So - 
the only value of the hcap object here, is to save the network device 
the trouble of sending a DCLASS that would be ignored. But then - 
sending a DCLASS object seems to be pretty low cost behaviour. 
Similarly, in 3.2, I think that the hcap object is presented as nothing 
more than an optimization and a debatable one, at that. The optimization

is to prevent a network element from generating a DCLASS if it is going 
to be ignored. The value of this optimization is debatable because the 
cost of processing hcap objects and storing related state is not clearly

worth the cost savings of not 'just sending a DCLASS, always'. 
I think that there might be a real value to the HCAP object. But - I 
think that it is less in telling a network element when to send a DCLASS

and when not to and more in helping a network element to validate the 
DSCP provided by hosts. For example - it may be the case that at the 
network element, traffic arrives from a variety of hosts. Some of this 
traffic is marked purposely, by DCLASS aware hosts. Other is marked 
arbitrarily, by 'rogue' hosts. Perhaps this is the utility of the HCAP 
object. 
In section 5, it states that the network edge must be manually 
configured to either send a DCLASS object, install a filter to cause 
marking for a flow, or both. There is a third option - do neither. For 
example, consider the ingress router to a diffserv network that offers a

simple static SLA (of the form customer on interfgace A gets to send 1 
Mbps of traffic marked EF). In the simplest case, there is no need to 
send a DCLASS and no need to mark on behalf of the customer. The 
customer simply uses whatever strategies are appropriate for marking and

the provider simply polices to enforce the SLA. 
Yoram 
  


From owner-issll@mercury.lcs.mit.edu  Thu Dec 21 06:07:22 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 SMTP id GAA14656
	for <issll-archive@odin.ietf.org>; Thu, 21 Dec 2000 06:07:22 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id FAA28143
	for issll-outgoing; Thu, 21 Dec 2000 05:03:07 -0500 (EST)
Received: from pelican.tk.uni-linz.ac.at (root@pelican.tk.uni-linz.ac.at [140.78.188.41])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id FAA28573
	for <issll@mercury.lcs.mit.edu>; Thu, 21 Dec 2000 05:03:05 -0500 (EST)
Received: from olibaer (olibaer.tk.uni-linz.ac.at [140.78.92.45])
	by pelican.tk.uni-linz.ac.at (8.9.1a/8.9.1) with SMTP id LAA05713
	for <issll@mercury.lcs.mit.edu>; Thu, 21 Dec 2000 11:03:09 +0100 (MET)
From: Michael Welzl <michael@tk.uni-linz.ac.at>
To: <issll@mercury.lcs.mit.edu>
Subject: 2nd CFP Special session "ABR to the Internet", SCI 2001, ext. abstracts due 31.12.00
Date: Thu, 21 Dec 2000 11:10:16 +0100
Message-ID: <A17BDB85B175D311804E00E07D02A21D27601C@conan.tk.uni-linz.ac.at>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400
Importance: Normal
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id FAA28143
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA14656

Please note that the deadline for submission of extended abstracts
(31. 12.) is getting close.

Our apologies if you receive this message more than once.
Please distribute this call to any of your colleagues who might be
interested.

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


2nd  C A L L   F O R   P A P E R S

Special Session: ABR to the Internet
====================================

THE 5TH WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS
SCI'2001
July, 22-25, 2001

Orlando, Florida(USA)
Sheraton World

http://www.iiis.org/sci/


THE "ABR TO THE INTERNET" SESSION:
ATM's "Available Bit Rate" (ABR) service provides a dramatically reduced
cell loss ratio by means of a signaling mechanism called "Explicit Rate
Feedback"; information from the network is provided to end nodes in order to
facilitate adaptation.
On the contrary, adaptive Internet applications rely on mechanisms that
probe the network in order to avoid congestions; packet loss must be
experienced before it can be avoided on a long term basis. Developers of
commercial applications seem to avoid adaptation because they don't see
enough QoS benefit.


SCOPE:
As a first step, we have seen ECN enhance adaptation on the Internet.
We are looking for papers that represent the next step.

Topics of interest include, but are not limited to, the following questions:
* What data should be provided to end nodes?
* Which QoS could be achieved?
* Where should the signaling take place? (end2end, edge2edge, core, ...)
* How do we deal with path changes?
* Can the signaling be incorporated with DiffServ, MPLS, ...?
* What about fairness issues and TCP-friendliness?


SUBMISSION OF PAPERS:
Prospective authors are invited to submit an extended abstract (about 1.5 to
2 pages) to Michael Welzl (michael@tk.uni-linz.ac.at) in postscript, PDF or
Word 97 format.
English is the official language of SCI 2001, thus all papers must be
submitted and presented in English.


EVALUATION PROCESS:
Papers will be evaluated for originality, significance, clarity, and
soundness.  Each paper will be refereed by several researchers in the
topical area.


THE CONFERENCE:
SCI 2001 is an international forum for scientists and engineers, researchers
and consultants, theoreticians and practitioners in the fields of Systemics,
Cybernetics and Informatics. It is a forum for focused disciplinary
research, as well as for multi, inter and transdiciplinary studies and
projects. One of its aims is to relate disciplines fostering analogical
thinking and, hence, producing input to the logical thinking.

Invited Sessions with high quality papers might be selected for multiple
author book publications. Two books are being published now as result of
good invited sessions.


IMPORTANT DATES:
31. 12.  Submission of extended abstracts (1.5 - 2 pages)
16. 02.  Notification of acceptance
13. 04.  full papers due

All accepted papers are expected to be presented at the conference.


OTHER INFORMATION:
It is planned to hold a BOF session on "ABR to the Internet" at a future
IETF meeting; authors are invited to join this collaborative effort which
may eventually be a realization of this session's topic. Further information
on the BOF can be found at http://www.tk.uni-linz.ac.at/~michael/ptp


SESSION CHAIR / CONTACT:
Michael Welzl
Telecooperation Group
Dpt. of Computer Science
Johannes Kepler University of Linz
Altenberger Str. 69
A-4040 Linz, Austria
Phone: +43 (732) 2468 - 9264
Fax: +43 (732) 2468 - 9829
E-mail: michael@tk.uni-linz.ac.at

SESSION CO-CHAIR:
Prof. Dr. Max Mühlhäuser
TU Darmstadt - FB 20
FG Telekooperation
Alexanderstrasse 6, D-64283 Darmstadt / Germany
Phone: +49 (6151) 16 - 3709
Fax: +49 (6151) 16 - 3052


Refer to http://www.tk.uni-linz.ac.at/~michael/abr2internet for up-to-date
information.



From owner-issll@mercury.lcs.mit.edu  Thu Dec 21 17:48: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 SMTP id RAA03632
	for <issll-archive@odin.ietf.org>; Thu, 21 Dec 2000 17:48:43 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA31655
	for issll-outgoing; Thu, 21 Dec 2000 16:40:58 -0500 (EST)
Received: from haha.cm.nctu.edu.tw ([140.113.13.13])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA31876
	for <issll@mercury.lcs.mit.edu>; Thu, 21 Dec 2000 16:40:56 -0500 (EST)
From: hj4hj6@yahoo.com
Received: from 916vJ4FFC (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34])
	by haha.cm.nctu.edu.tw (8.8.8/8.8.7) with SMTP id FAA02920;
	Fri, 22 Dec 2000 05:37:44 +0800 (CST)
DATE: 21 Dec 00 1:45:20 PM
Message-ID: <VZ5NFG99p6pU2e>
SUBJECT: Improve your stepfamily life
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk

Does your stepfamily life resemble a soap opera more than it does the Brady
Bunch?

The Stepfamily Association of America invites you to participate in THE
NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans
Marriott Hotel.

This is an opportunity, designed by knowledgeable professionals, in
stepfamilies themselves, to help you:
* Make your remarriage a success
* Create bonds with your stepchildren
* Help your children adjust emotionally
* Manage money matters unique to your family
* Get more help from legal, financial, psychological advisors
* Overcome stepfather and stepmother stereotypes
* Elicit cooperation from your children's schools
* Bring more harmony into family life

Complete conference details at http://www.edupr.com
REGISTER ONLINE!

Attend, and also enjoy Mardi Gras week in New Orleans!

Special discounts for couples, students, groups.

HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND
AIRLINE SEATS FILL Special rates for conference attendees. Visit
http://www.edupr.com for discounts. Childcare available through a bonded
local service.

Up to 17 professional development credits available if you are an 			
educator, clinician, financial planner, social worker.

Questions? Email stepfamilyconf@mail.com

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.



From owner-issll@mercury.lcs.mit.edu  Tue Dec 26 04:57:17 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 SMTP id EAA18076
	for <issll-archive@odin.ietf.org>; Tue, 26 Dec 2000 04:57:16 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id DAA06081
	for issll-outgoing; Tue, 26 Dec 2000 03:54:27 -0500 (EST)
Received: from itc-eml2.lannet.com (at.lannet.com [194.90.94.231])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id DAA17654
	for <issll@mercury.lcs.mit.edu>; Tue, 26 Dec 2000 03:54:25 -0500 (EST)
Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21)
	id <XMMDZ0RC>; Tue, 26 Dec 2000 10:54:14 +0200
Message-ID: <15F58915DF84D311AC7D0090279AA6142342FA@itc-eml2.lannet.com>
From: Dan Romascanu <dromasca@avaya.com>
To: "'Crawley, Eric'" <esc@unispherenetworks.com>,
        "'Man.M.Li@nokia.com'"
	 <Man.M.Li@nokia.com>,
        issll@mercury.lcs.mit.edu
Subject: RE: Status of "COPS Usage for Outsourcing Diffserv Resource Alloc
	 atio n? "
Date: Tue, 26 Dec 2000 10:54:13 +0200
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


> draft-salsano-issll-cops-odra-00.txt was never brought up in the ISSLL WG.
> 
	[Dan]  Is this draft available any place? I cannot find it in the
Individual Submissions I-D repository.

	Dan




From owner-issll@mercury.lcs.mit.edu  Tue Dec 26 11:19: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 SMTP id LAA20019
	for <issll-archive@odin.ietf.org>; Tue, 26 Dec 2000 11:19:20 -0500 (EST)
Received: (from daemon@localhost)
	by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA28630
	for issll-outgoing; Tue, 26 Dec 2000 10:29:20 -0500 (EST)
Received: from uniwest1.redstonecom.com ([199.105.223.130])
	by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA27757
	for <issll@mercury.lcs.mit.edu>; Tue, 26 Dec 2000 10:29:18 -0500 (EST)
Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21)
	id <YR97L3D9>; Tue, 26 Dec 2000 10:28:54 -0500
Message-ID: <49FF5C6DDBD8D311BBBD009027DE980CC62288@uniwest1.redstonecom.com>
From: "Crawley, Eric" <esc@unispherenetworks.com>
To: "'Dan Romascanu'" <dromasca@avaya.com>,
        "'Man.M.Li@nokia.com'"
	 <Man.M.Li@nokia.com>,
        issll@mercury.lcs.mit.edu
Subject: RE: Status of "COPS Usage for Outsourcing Diffserv Resource Alloc
	 atio n? "
Date: Tue, 26 Dec 2000 10:28:54 -0500
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

Dan,

Internet Drafts expire after 6 months unless they are updated or under
consideration by the IESG.  You might be able to find a copy on one of the
mirror sites.

	Eric

> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]
> Sent: Tuesday, December 26, 2000 3:54 AM
> To: Crawley, Eric; 'Man.M.Li@nokia.com'; issll@mercury.lcs.mit.edu
> Subject: RE: Status of "COPS Usage for Outsourcing Diffserv Resource
> Alloc atio n? "
> 
> 
> 
> > draft-salsano-issll-cops-odra-00.txt was never brought up 
> in the ISSLL WG.
> > 
> 	[Dan]  Is this draft available any place? I cannot find 
> it in the
> Individual Submissions I-D repository.
> 
> 	Dan
> 
>