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 ; 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 ; 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 ; Thu, 7 Dec 2000 11:49:46 +0100 (CET) Message-ID: <002101c0603b$baeff980$8001a8c0@oleane.com> From: "Peter Lewis" To: 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
VoDSL Europe : the = deployment=20 scenario, Paris 16-19 January.
The international = conference.
Visit the real first VoDSL = exhibition=20 ever organized:
http://www.upperside.fr/= bavodsl2001.htm
------=_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 ; 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 ; Fri, 8 Dec 2000 19:38:05 -0500 (EST) Mime-Version: 1.0 X-Sender: jtw@mercury.lcs.mit.edu (Unverified) Message-Id: Date: Fri, 8 Dec 2000 19:39:59 -0500 To: issll@mercury.lcs.mit.edu From: John Wroclawski 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 ; 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 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 ; 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 ; 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 ; Wed, 13 Dec 2000 08:58:48 +0530 Message-ID: <2C202C0F886DD3119B1200A0C9A85FF401981C22@xmail.miel.mot.com> From: Radhakrishna To: "'wnk@fub.it'" , Radhakrishna , "'radhakrishna@cportcorp.com'" Cc: "'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 To: "'rute@nwu.edu'" , Radhakrishna Cc: jawang@cosinecom.com, "'aljtarik@cholla.inrs-telecom.uquebec.ca'" , "'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 To: 'Ronaldo Salles' , Tarik Alj Cc: jawang@cosinecom.com, issll@mercury.lcs.mit.edu, Radhakrishna 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 >To: "'Tarik Alj'" , 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 > To: > Cc: > Sent: Tuesday, July 11, 2000 9:30 PM > Subject: RE: [Diffserv] draft-rk-diffserv-rsvp-sig-00.txt > > > > >From: Jay Wang > >To: "'Tarik Alj'" , > 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" > >>To: "Radhakrishna" > >>Cc: > >>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 > >>To: ; > >>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 ; 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 ; 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: 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" To: "Hamid Syed" Cc: 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 ; 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 ; 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 ; Fri, 15 Dec 2000 23:53:10 -0800 Message-ID: <04dc01c06736$1f5b5cb0$3a0514ac@sbarber2k> From: "Simon Barber" To: , , , Cc: 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" 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 ; 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 ; 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 ; Sat, 16 Dec 2000 13:14:06 -0300 From: "SBRC 2001" To: Subject: SBRC 2001: Call for Papers Date: Sat, 16 Dec 2000 14:11:55 -0200 Message-ID: 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 ; 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 ; 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 ; Mon, 18 Dec 2000 10:27:34 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E805B224FA@zwdld001.ca.nortel.com> From: "Hamid Syed" To: "'Yoram Bernet'" Cc: issll 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: 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 RE: draft-ietf-issll-rsvp-cap-01.txt

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-- 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 ; 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 ; 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: Thread-Topic: draft-ietf-issll-rsvp-cap-01.txt Thread-Index: AcBpB0rYnzHaWcoNS+6QLF1lITqwFwABlZXg From: "Yoram Bernet" To: "Hamid Syed" Cc: "issll" 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 ; 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 ; 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 ; Thu, 21 Dec 2000 11:03:09 +0100 (MET) From: Michael Welzl To: 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: 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 ; 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 ; 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: 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 ; 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 ; Tue, 26 Dec 2000 03:54:25 -0500 (EST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:54:14 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6142342FA@itc-eml2.lannet.com> From: Dan Romascanu 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? " 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 ; 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 ; Tue, 26 Dec 2000 10:29:18 -0500 (EST) Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 10:28:54 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980CC62288@uniwest1.redstonecom.com> From: "Crawley, Eric" To: "'Dan Romascanu'" , "'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 > >