From owner-issll@mercury.lcs.mit.edu Thu Apr 6 06:12:54 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06435 for ; Thu, 6 Apr 2000 06:12:54 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA21474 for issll-outgoing; Thu, 6 Apr 2000 04:35:54 -0400 (EDT) Received: from sea.irisa.fr (sea.irisa.fr [131.254.60.17]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA22119 for ; Thu, 6 Apr 2000 04:35:45 -0400 (EDT) Received: from gaaz.irisa.fr (gaaz.irisa.fr [131.254.43.4]) by sea.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA05300; Thu, 6 Apr 2000 10:27:13 +0200 (MET DST) From: Jean-Marc Jezequel Date: Thu, 6 Apr 2000 09:53:08 +0200 Message-Id: <200004060753.JAA02781@gaaz.irisa.fr> Subject: TOOLS Europe 2000 - Call for participation Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk [Apologies if you receive multiple copies of this message] [Please forward this message to colleagues you think might be interested] ------------------------------------------------------------------------- TOOLS Europe 2000 "Enterprise Architecture - Patterns - Components" Mont St Michel & St Malo, France June 5-8, 2000 http://www.tools.com/europe CALL FOR PARTICIPATION TOOLS is the major international conference series devoted to applications of object-oriented technology. TOOLS Europe 2000 focuses on Enterprise Architecture, Patterns, and Components. It will be held in Le Mont St Michel, at the borderline of Normandy and Brittany in the north-west of France, which can easily and quickly be reached from Paris. TOOLS Europe 2000 will continue the commitment to excellence of earlier TOOLS conferences in Europe, Australia, Asia and the USA with an outstanding program: - Top keynotes by J. Coplien, B. Meyer, W. Pree, J. Daniels, I. Graham - 18 tutorials by leading experts in Enterprise Architecture, Patterns, Components, UML, Java, Embeded Software, and more... - 4 workshops, including J. Coplien's two day "Mastery of Patterns" workshop - 7 technical sessions by selected industry and academic presenters - a panel on "What is architecture?" - an exiting social program, with a cocktail diner at "La Mere Poulard", a visit of the of Mt St Michel Abbey, and a visit and banquet in St Malo. Full programme and online registration available from http://www.irisa.fr/TE2000 (Early registration rate applies until May 5, 2000) From owner-issll@mercury.lcs.mit.edu Mon Apr 10 15:04:08 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00466 for ; Mon, 10 Apr 2000 15:04:06 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA06193 for issll-outgoing; Mon, 10 Apr 2000 13:39:47 -0400 (EDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA05418 for ; Mon, 10 Apr 2000 13:39:45 -0400 (EDT) Message-Id: <200004101739.NAA05418@mercury.lcs.mit.edu> Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 10 Apr 2000 10:35:31 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2PRP5B9G; Mon, 10 Apr 2000 11:35:16 -0400 Received: from zcarh014 (zcarh014.ca.nortel.com [47.23.81.6]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HNNLWHZH; Mon, 10 Apr 2000 11:35:15 -0400 Date: Mon, 10 Apr 2000 11:34:29 -0400 (EDT) X-Sybari-Space: 00000000 00000000 00000000 From: "Nabil Seddigh" Reply-To: "Nabil Seddigh" Subject: draft-ietf-issll-diffserv-rsvp-04.txt To: issll@mercury.lcs.mit.edu X-Mailer: Rosa 2.1 HP-UXB.10.20 X-Rosa-Trace: nseddigh@zcarh014 <47.23.81.6> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id NAA06386 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 8bit I was recently pointed to the last call for the draft: I apologize for the late comments but have a few issues with the draft that I thought I should bring out - if anything, to clarify my own understanding. I don't think any of my comments point to any major holes in the draft - just editorial comments, comments to tighten up loosely made statements and a few comments which might deserve more serious consideration (especially in the multicast area) :) Comments are interspersed among the draft text. Regards Nabil Seddigh nseddigh@nortelnetworks.com ---------------------------------------- > Internet Draft > Expires: September, 2000 > Document: draft-ietf-issll-diffserv-rsvp-04.txt March, 2000 > > > A Framework For Integrated Services Operation Over Diffserv Networks > >[....DELETED.....] > > 2.1 Integrated Services Architecture > > The integrated services architecture defined a set of extensions to > the traditional best effort model of the Internet with the goal of Section 2.2 is missing!! > 2.3 RSVP > > [.......DELETED..................] > > The following factors have impeded deployment of RSVP (and the > Intserv architecture) in the Internet at large: > > 1. The use of per-flow state and per-flow processing raises > scalability concerns for large networks. > > 2. Only a small number of hosts currently generate RSVP signaling. > While this number is expected to grow dramatically, many > applications may never generate RSVP signaling. > > 3. The necessary policy control mechanisms -- access control, > authentication, and accounting -- have only recently become > available [17]. > While the above few factors impeded deployment of Intserv, there were clearly many other important factors that hampered acceptance of Intserv as the sole technology solution to provide IP-QoS: 1. Route Pinning - Intserv required nailing down of a path between end-hosts. This connection-oriented approach was foreign to IP networks. 2. It did not provide a solution for what constituted a large portion of Internet traffic - short flows with elastic behaviour. The overhead of end-to-end reservation on a per-flow basis is too large a cost to be incurred by flows that typically transmit no more than a few packets. 3. Intserv focused very much on host-to-host connections and did not seem to allow for the fact that many service agreements would be at a more aggregated level with intermediate management points such the gateway between the enterprise and the service provider or carrier. This seemed to be a clear non-fit with the business model of the Internet. 4. There was difficulty matching the 2 existing service models of Intserv against the requirements for TCP-based apps. While for voice or video, apps would have a sense of their requiremetns (i.e BW, jitter/delay tolerance), this was not quite the case for TCP-based apps. How would a server responding to HTTP requests know what traffic profile parameters to request from the network. > > 2.7 The Framework > > [.................DELETED....................] > > > In one extreme the Diffserv region is pushed all > the way to the periphery, with hosts alone having full Intserv > capability. In the other extreme, Intserv is pushed all the way to > the core, with no Diffserv region. > I have some difficulty understanding the statement: "...hosts alone having full Intserv capability". If I understand the scenario that the sentence depicts, we have all Diffserv routers with RSVP signaling in the end-hosts. Surely this is not Intserv? There's not a single Intserv router along the path between source and destination. Maybe it would be better to reword the sentence along the lines: "In one extreme the Diffserv region is pushed all the way to the periphery, with hosts simply signalling the Diffserv region for resources." > > 3.1 Resource Based Admission Control > > [...DELETED....] > > To further > understand this issue, consider a Diffserv network region providing > only aggregate traffic control with no signaling. In the Diffserv > network region, admission control is applied implicitly by > provisioning policing parameters at network elements. The following statement could be misinterpreted as equating admission control and policing (of course both are very different things): "...admission control is applied implicitly by provisioning policing parameters at network elements" In the above, I would say that some form of static admission control was performed when the PDP allowed the administrator to enter the traffic filter and associated profile into the database. Presumably the PDP wouldn't allow an infinite number of SLSs (or equivalent filter & traffic profile) to be entered into its DB. It must have some way of limiting the SLSs based on some notion of what the network can support. This I would term as static admission control. Once the SLS has been admitted and associated filters/traffic profiles installed, the POLICER then ensures that the traffic profile is adhered to by the traffic stream. So infact, we do have some form of static admission control that is very explicit! What is currently lacking in Diffserv is dynamic admission control that is triggered when a flow is started - either via RSVP signaling or other means. To clarify matters, suggest replacing the term explicit admission control with something like explicitly signaled dynamic admission control. > For example, a > network element at the ingress to a Diffserv network region could be > provisioned to accept only 50 Kbps of traffic for the EF DSCP. > > While such implicit admission control does protect the network to > some degree, it can be quite ineffective. For example, consider that > there may be 10 IP telephony sessions originating outside the > Diffserv network region, each requiring 10 Kbps of EF service from > the Diffserv network region. Since the network element protecting > the Diffserv network region is provisioned to accept only 50 Kbps of > traffic for the EF DSCP, it will discard half the offered traffic. > This traffic will be discarded from the aggregation of traffic > marked EF, with no regard to the microflow from which it originated. > As a result, it is likely that of the ten IP telephony sessions, > none will obtain satisfactory service when in fact, there are > sufficient resources available in the Diffserv network region to > satisfy five sessions. > > In the case of explicit admission control, the network will signal > rejection in response to requests for resources that would exceed > the 50 Kbps limit. As a result, upstream network elements (including > originating hosts) and applications will have the information they > require to take corrective action. The application might respond by > refraining from transmitting, or by requesting admission for a > lesser traffic profile. The host operating system might respond by > marking the application's traffic for the DSCP that corresponds to > best-effort service. Upstream network elements might respond by re- > marking packets on the rejected flow to a lower service level. In > some cases, it may be possible to reroute traffic over alternate > paths or even alternate networks (e.g. the PSTN for voice calls). In > any case, the integrity of those flows that were admitted would be > preserved, at the expense of the flows that were not admitted. Thus, > by appointing an Intserv-conversant admission control agent for the > Diffserv region of the network it is possible to enhance the service > that the network can provide to quantitative QoS applications. > The problem in the above paragraph is not that there is no explicit admission control. Certainly there must have been some form of static admission control to determine that 50Kbps of EF traffic could be admitted at this ingress. However, the problem is that there also needs to be run-time (dynamic) admission control on a more granular (per-flow) basis to determine who gets access to the 50Kbps. Thus, there are really 2 levels of admission control - both are explicit. One is static and works on the granularity of the SLS. The other is dynamic (run-time) and works on a per-5-tuple flow. > > 3.3.1 Host Marking > > [.......DELETED....] Furthermore, if IPSEC encryption is used, > the host may be the only device in the network that is able to make > a meaningful determination of the appropriate marking for each > packet. > Suggest the above statement be somewhat clarified. IPSEC is an issue only for classification based on Layer4-7 information. Many SLSs are specified based on source/dest IP addresses & masks. IPSEC is not an issue for Layer-3 based classification. > Host marking requires that the host be aware of the interpretation > of DSCPs by the network. This information can be configured into > each host. However, such configuration imposes a management burden. > Alternatively, hosts can use an explicit signaling protocol such as > RSVP to query the network to obtain a suitable DSCP or set of DSCPs > to apply to packets for which a certain Intserv service has been > requested. An example of how this can be achieved is described in > [14]. > > 3.3.2 Router Marking > > In the case of router marking, MF classification criteria must be > configured in the router. This may be done dynamically, by request > from the host operating system, or statically via manual > configuration or via automated scripts. > I'm not quite clear what constitutes "MF classification criteria"? Is this the filters on the router? If so, does PDP or Policy Management infrastructure deserve a mention in addition to manual configuration & CLI scripts? > > There are significant difficulties in doing so statically. > Typically, it is desirable to allot service to traffic based on the > application and/or user originating the traffic. Suggest changing the word "typically" to "in some cases" :) In many cases, SLS filters will be based on the IP address of the enterprise gateway as opposed to based on applications or individual users. In this case, all the subsequently mentioned issues become mute. > > 4.2 Service Mapping > > [..........DELETED...............] > > In our framework, Diffserv regions of the network are analogous to > the 802.1p capable switched segments described in [5]. Requests for > Intserv services must be mapped onto the underlying capabilities of > the Diffserv network region. Aspects of the mapping include: > > - selecting an appropriate PHB, or set of PHBs, for the requested > service; > - performing appropriate policing (including, perhaps, shaping or > remarking) at the edges of the Diffserv region; > - exporting Intserv parameters from the Diffserv region (e.g. for > the updating of ADSPECs); If I understood correctly, the above seems to say that Diffserv regions MUST update ADPSEC. This seems like quite a strong requirement. Firstly it is unclear whether the draft is expecting each router along the path in the Diffserv region to update ADSPEC or whether only the border routers will update ADSPEC. Secondly, I'm not sure such a requirement will be that easy to mandate for Diffserv-capable routers. Can the requirement be softened and more details provided on who exactly updates the ADSPEC? > > 4.2.3 Microflow Separation > > Boundary routers residing at the edge of the Diffserv region will > typically police traffic submitted from the outside the Diffserv ^^^^ Extra "THE" ^^^^ [.............DELETED...................] > > 2. Providing per microflow policing at the border routers - this > approach tends to be less scalable than the previous approach. It > also imposes a management burden on the Diffserv region of the > network. However, it may be appropriate in certain cases, for the > Diffserv boundary routers to offer per microflow policing as a > value-add to its Intserv customers. > Just a comment! The above makes it sound like it is undesirable to have microflow policing in border routers. This is certainly true. However, the scenarios in this document depict the diffserv region as a homogeneous entity. In reality, it will consist of multiple individual domains each with their own border routers. If indeed Intserv/Diffserv interoperation is to be successful, some form of micropolicing will be required for border routers. Certainly if flows are to be admitted on a per-flow basis then policing needs to be performed on a per-flow basis. In the absence of route-pinning this will be essential. Edge routers can police the end-host. However, if border routers have no microflow policers what will prevent DS domains from aggregating more flows over a specific adjacent link between domains? > > 4.3 Resource Management in Diffserv Regions > > A variety of options exist for management of resources (e.g., > bandwidth) in the Diffserv network regions to meet the needs of end- > to-end Intserv flows. These options include: > > - statically provisioned resources; > - resources dynamically provisioned by RSVP; > - resources dynamically provisioned by other means (e.g., a form of > Bandwidth Broker). > I think the draft would benefit from clarifying the usage of the term "provisioned resources". In my mind, provisioning resources conjures images queue weights and buffer parameters configuration. Based on reading the following paragraph, I get the sense, the draft is really talking about "who gets access" to the "provisioned resources". > > 5.2 RSVP-Aware Diffserv Network Region > > In this example, the customer's edge routers are standard RSVP > routers. The border router, BR1 is RSVP aware. In addition, there > may be other routers within the Diffserv network region which are > RSVP aware. Note that although these routers are able to participate > in some form of RSVP signaling, they classify and schedule traffic > in aggregate, based on DSCP, not on the per-flow classification > criteria used by standard RSVP/Intserv routers. It can be said that > their control-plane is RSVP while their data-plane is Diffserv. Suggest removing the last line above :) The explanation earlier in the paragraph seems quite sufficient. The last line is more confusing than clarifying! > > 5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region > > Border routers might not use any form of RSVP signaling within the > Diffserv network region but might instead use custom protocols to > interact with an "oracle". The oracle is a hypothetical agent that > has sufficient knowledge of resource availability and network > topology to make admission control decisions. Why usage of the word "HYPOTEHTICAL"? There may be questions about the maturity or scalability of such technology but different forms of the "oracle" exist today in universities, research labs and advanced technology groups. Suggest removing the bias in the above paragraph :) > > 6.2 Protection of Intserv Traffic from Other Traffic > > Network administrators must be able to share resources in the > Diffserv network region between three types of traffic: > > a. End-to-end Intserv traffic - this is typically traffic > associated with quantitative QoS applications. It requires a > specific quantity of resources with a high degree of assurance. > > b. Non-Intserv traffic. The Diffserv region may allocate resources > to traffic that does not make use of Intserv techniques to quantify > its requirements, e.g. through the use of static provisioning and > SLSs enforced at the edges of the region. Such traffic might be > associated with applications whose QoS requirements are not readily > quantifiable but which require a "better than best-effort" level of > service. > > c. All other (best-effort) traffic > > These three classes of traffic must be isolated from each other by > the appropriate configuration of policers and classifiers at ingress > points to the Diffserv network region, and by appropriate > provisioning within the Diffserv network region. To provide > protection for Intserv traffic in Diffserv regions of the network, > we suggest that the DSCPs assigned to such traffic not overlap with > the DSCPs assigned to other traffic. > The above is certainly one way of looking at things. Another way is to say that a Diffserv region has 3 types of traffic: 1. Quantitative 2. Qualitative 3. Best Effort Traffic originating from Intserv would fit into the first type of Diffserv traffic. However, there's no need to isolate Intserv traffic from other traffic that is carried overly "purely" diffserv networks but also has quantitative requirements. It seems to be far too strong a requirement to ask Diffserv providers to isolate Intserv traffic internally. > 7. Multicast > I have a few concerns with this whole section because I'm not sure how feasible the proposed solutions might be. Solution 5 seems to be the only solid solution in this section. > [.............DELETED.....................] > > Consider the following reference network: > > > Non-Diffserv region 2 > ________ > / \ > | | |---| > ________ _____________ | |-|Rx1| > / \ / |--\ |---| | |---| > / \ / /|BR2\-----\ER2| / > |---| | |---| |---| |--|/ |---| \--|____/ > |Tx |-| |ER1|---|BR1|--|RR| | ________ > |---| | |-- | |---| |--|\ |---| /--| \ > \ / \ \|BR3/-----|ER3| | |---| > \________/ \__________|--/ |---| |-|Rx2| > | | |---| > Non-Diffserv region 1 Diffserv region \ / > \______/ > > Non-Diffserv region 3 > > Figure 2: Sample Multicast Network Configuration > > > The reference network is similar to that of Figure 1. However, in > Figure 2, copies of the packets sent by Tx are delivered to several > receivers outside of the Diffserv region, namely to Rx1 and Rx2. > Moreover, packets are copied within the Diffserv region in a "branch > point" router RR. In the reference network BR1 is the ingress router > to the Diffserv region whereas BR2 and BR3 are the egress routers. > > In the simplest case the receivers, Rx1 and Rx2 in the reference > network, require identical reservations. The Diffserv framework [18] > supports service level specifications (SLS) from an ingress router > to one, some or all of the egress routers. This calls for a "one to > many" SLS within the Diffserv region, from BR1 to BR2 and BR3. The above gives the mistaken impression that with today's Diffserv specs it is possible to provide a one-to-many SLS (in this case one-to-two) for multicast traffic. While it is possible to do a one-to-two SLS with VPN-like unicast traffic, this is not the case for multicast. In fact, supporting a one-to-two (or more) SLS for multicast requires new additions to Diffserv. One such example appears in: http://www1.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt > > These problems can be tackled by the following mechanisms: > > 1. If some Intserv-capable routers are placed within the Diffserv > region, it might be possible to administer the network topology and > routing parameters so as to ensure that branch points occur only > within such routers. These routers would support MF classification > and remarking and hold per-flow state for the heterogeneous > reservations for which they are the branch point. Note that in this > case, branch point routers would have essentially the same > functionality as ingress routers of an RSVP-aware Diffserv domain. > It seems to me that the above solution would be an administrator's nightmare. First, how would you identify such key points? Won't they change based on the composition of group membership. Second, won't you have different points for different multicast groups (the multicast tree of each group will probably have a different topology)? It seems to me that the above solution would only work if the multicast groups were quite static and different groups had the same tree - neither or which seems to be a given! > 2. Packets sent on the "non-reserved" branch (from RR towards BR3) > are marked with the "wrong" DSCP; that is, they are not demoted to > best effort but retain their DSCP. This in turn requires over > reservation of resources along that link or runs the risk of > degrading service to packets that legitimately bear the same DSCP > along this path. However, it allows the Diffserv routers to remain > free of per-flow state. > > This is not really a solution to the problem :) Suggest this point is removed. Essentially this point bolsters the conclusion that we cannot support heterogeneous service levels (or bandwidht levels within the same service type) for multicast. > 3. A combination of mechanism 1 and 2 may be an effective > compromise. In this case, there are some Intserv-capable routers in > the core of the network, but the network cannot be administered so > that ALL branch points fall at such routers. > If solution 2 is removed, this solution reduces to solution 1 :) Suggest this solution is also removed. > > 7.2 Multicast SLSs and Heterogeneous Trees > > Multicast flows with heterogeneous reservations present some > challenges in the area of SLSs. For example, a common example of an > SLS is one where a certain amount of traffic is allowed to enter a > Diffserv region marked with a certain DSCP, and such traffic may be > destined to any egress router of that region. We call such an SLS a > homogeneous, or uniform, SLS. However, in a multicast environment, a > single packet that is admitted to the Diffserv region may consume > resources along many paths in the region as it is replicated and > forwarded towards many egress routers; alternatively, it may flow > along a single path. This situation is further complicated by the > possibility described above and depicted in Figure 2, in which a > multicast packet might be treated as best effort along some branches > while receiving some higher QOS treatment along others. We simply > note here that the specification of meaningful SLSs which meet the > needs of heterogeneous flows and which can be met be providers is > likely to be challenging. > > Dynamic SLSs may help to address these issues. For example, by using > RSVP to signal the resources that are required along different > branches of a multicast tree, it may be possible to more closely > approach the goal of allocating appropriate resources only where > they are needed rather than overprovisioning or underprovisioning > along certain branches of a tree. This is essentially the approach > described in [15]. > > Again, the following draft provides examples of meaningful SLS for multicast traffic in Diffserv: http://www1.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt From owner-issll@mercury.lcs.mit.edu Tue Apr 11 15:26:07 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18117 for ; Tue, 11 Apr 2000 15:26:06 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id OAA09697 for issll-outgoing; Tue, 11 Apr 2000 14:18:21 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id OAA11482 for ; Tue, 11 Apr 2000 14:18:19 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRF4GK>; Tue, 11 Apr 2000 11:15:45 -0700 Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRF4FK>; Tue, 11 Apr 2000 11:13:22 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC736@SOL> From: Andrew Smith To: "'Georgios Karagiannis (EMN)'" Cc: issll@lmcs.mit.edu, "'John Wroclawski'" Subject: RE: RSVP on wireless IP Date: Tue, 11 Apr 2000 11:13:18 -0700 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 Georgios, I think all it needs are a few good people who are interested in doing this work to get together, buy a nice strong espresso for John and persuade him to entertain proposals in this area - the ISSLL WG agenda has always been demand-driven (or caffeine-driven?) in the past. Andrew > -----Original Message----- > From: Georgios Karagiannis (EMN) > [mailto:Georgios.Karagiannis@emn.ericsson.se] > Sent: Monday, April 03, 2000 9:10 AM > To: 'Yoram Bernet' > Cc: Simon Oosthoek (EMN); 'Bora Akyol'; 'rsvp@isi.edu'; > issll@lmcs.mit.edu; Geert Heijenk (EMN) > Subject: RE: RSVP on wireless IP > > > Dear all > > In principle, I agree with Yoram's opinion regarding the fact that > RSVP serves to unify the disparate QoS mechanisms of the > different media, including wireless subnetworks. > However, we have not seen any activity of the ISSLL group in > the area of QoS mappings from RSVP to wireless subnetworks. > Perhaps it will be a good idea to enlarge the charter goals > of the ISSLL group in order to include issues that are > relevant to RSVP and wireless networks, e.g., cellular networks. > > Best Regards, > Georgios > > > > > From owner-issll@mercury.lcs.mit.edu Tue Apr 11 21:25:16 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25765 for ; Tue, 11 Apr 2000 21:25:16 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id UAA13239 for issll-outgoing; Tue, 11 Apr 2000 20:33:04 -0400 (EDT) Received: from xavier.nextcomminc.com (root@207-229-111-2.cortland.com [207.229.111.2]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id UAA12449 for ; Tue, 11 Apr 2000 20:33:02 -0400 (EDT) Received: from gambit (really [192.168.1.130]) by nextcomminc.com via smail with smtp id (Debian Smail3.2.0.102) for ; Tue, 11 Apr 2000 17:31:08 -0700 (PDT) Reply-To: From: "Wen-Ping Ying" To: "Andrew Smith" Cc: , Subject: RE: RSVP on wireless IP Date: Tue, 11 Apr 2000 17:35:54 -0700 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.00.2919.6600 Importance: Normal In-Reply-To: <808F64DDB492D3119D3C00508B5D8D733EC736@SOL> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id UAA12560 Sender: owner-issll@mercury.lcs.mit.edu Precedence: bulk Content-Transfer-Encoding: 8bit 802.11 working group has initiated the 802.11e study group to look into QoS related issues over 802.11 network. One major consideration has been to adopt ISSLL model. The May interim meeting will have in-depth discussion on this issue. The link below shows more info on this effort. (The SG chair is John Fakatselis.) http://grouper.ieee.org/groups/802/11/PARs/index.html I encourage people from ISSLL WG to participate. ----------------------------------- Wen-Ping Ying NextComm, Inc. 12413 Willows Rd. NE, #210 Kirkland, WA 98034 (O) 425.825.1770 x 109 (F) 425.825.1780 wying@nextcomminc.com -----Original Message----- From: owner-issll@mercury.lcs.mit.edu [mailto:owner-issll@mercury.lcs.mit.edu]On Behalf Of Andrew Smith Sent: Tuesday, April 11, 2000 11:13 AM To: 'Georgios Karagiannis (EMN)' Cc: issll@lmcs.mit.edu; 'John Wroclawski' Subject: RE: RSVP on wireless IP Georgios, I think all it needs are a few good people who are interested in doing this work to get together, buy a nice strong espresso for John and persuade him to entertain proposals in this area - the ISSLL WG agenda has always been demand-driven (or caffeine-driven?) in the past. Andrew > -----Original Message----- > From: Georgios Karagiannis (EMN) > [mailto:Georgios.Karagiannis@emn.ericsson.se] > Sent: Monday, April 03, 2000 9:10 AM > To: 'Yoram Bernet' > Cc: Simon Oosthoek (EMN); 'Bora Akyol'; 'rsvp@isi.edu'; > issll@lmcs.mit.edu; Geert Heijenk (EMN) > Subject: RE: RSVP on wireless IP > > > Dear all > > In principle, I agree with Yoram's opinion regarding the fact that > RSVP serves to unify the disparate QoS mechanisms of the > different media, including wireless subnetworks. > However, we have not seen any activity of the ISSLL group in > the area of QoS mappings from RSVP to wireless subnetworks. > Perhaps it will be a good idea to enlarge the charter goals > of the ISSLL group in order to include issues that are > relevant to RSVP and wireless networks, e.g., cellular networks. > > Best Regards, > Georgios > > > > > From owner-issll@mercury.lcs.mit.edu Tue Apr 11 23:30:16 2000 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29108 for ; Tue, 11 Apr 2000 23:30:16 -0400 (EDT) Received: (from daemon@localhost) by mercury.lcs.mit.edu (8.9.1/8.9.1) id WAA13810 for issll-outgoing; Tue, 11 Apr 2000 22:37:07 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id WAA12122 for ; Tue, 11 Apr 2000 22:37:06 -0400 (EDT) Received: by SOL with Internet Mail Service (5.5.2650.21) id <2XQRFXKD>; Tue, 11 Apr 2000 19:34:31 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D733EC744@SOL> From: Andrew Smith To: "'wying@nextcomminc.com'" Cc: issll@mercury.lcs.mit.edu, "'P802.1'" , "'Tony Jeffree'" , "'Mick Seaman'" Subject: RE: RSVP on wireless IP Date: Tue, 11 Apr 2000 19:34:30 -0700 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 Right - I did suggest offline to several 802.11 people at the last IEEE 802 plenary meeting that they look into the work already done in ISSLL for supporting IEEE 802.1. One unfortunate aspect of having 802.11 working on this issue is that their meetings typically overlap with 802.1 meetings making it difficult for people to participate in both: the suggestion would be that 802.11 work together with 802.1 (the "higher layer interfaces" working group), at least in order to determine a service interface ("API") that upper layers can use consistently. Whilst 802.1 already had committed to hold its next interim meeting co-located with 802.3, I believe that subsequent ones will likely be co-located with 802.11 making it easier to achieve coordination on this and other issues. Andrew > -----Original Message----- > From: Wen-Ping Ying [mailto:wying@nextcomminc.com] > Sent: Tuesday, April 11, 2000 5:36 PM > To: Andrew Smith > Cc: issll@mercury.lcs.mit.edu; jfakat01@intersil.com > Subject: RE: RSVP on wireless IP > > > 802.11 working group has initiated the 802.11e study group to > look into QoS related issues over 802.11 network. One major > consideration has been to adopt ISSLL model. The May interim > meeting will have in-depth discussion on this issue. The link > below shows more info on this effort. (The SG chair is John > Fakatselis.) > > http://grouper.ieee.org/groups/802/11/PARs/index.html > > I encourage people from ISSLL WG to participate. > > ----------------------------------- > Wen-Ping Ying > NextComm, Inc. > 12413 Willows Rd. NE, #210 > Kirkland, WA 98034 > (O) 425.825.1770 x 109 > (F) 425.825.1780 > wying@nextcomminc.com > > -----Original Message----- > From: owner-issll@mercury.lcs.mit.edu > [mailto:owner-issll@mercury.lcs.mit.edu]On Behalf Of Andrew Smith > Sent: Tuesday, April 11, 2000 11:13 AM > To: 'Georgios Karagiannis (EMN)' > Cc: issll@lmcs.mit.edu; 'John Wroclawski' > Subject: RE: RSVP on wireless IP > > > Georgios, > > I think all it needs are a few good people who are interested > in doing this > work to get together, buy a nice strong espresso for John and > persuade him > to entertain proposals in this area - the ISSLL WG agenda has > always been > demand-driven (or caffeine-driven?) in the past. > > Andrew > > > -----Original Message----- > > From: Georgios Karagiannis (EMN) > > [mailto:Georgios.Karagiannis@emn.ericsson.se] > > Sent: Monday, April 03, 2000 9:10 AM > > To: 'Yoram Bernet' > > Cc: Simon Oosthoek (EMN); 'Bora Akyol'; 'rsvp@isi.edu'; > > issll@lmcs.mit.edu; Geert Heijenk (EMN) > > Subject: RE: RSVP on wireless IP > > > > > > Dear all > > > > In principle, I agree with Yoram's opinion regarding the fact that > > RSVP serves to unify the disparate QoS mechanisms of the > > different media, including wireless subnetworks. > > However, we have not seen any activity of the ISSLL group in > > the area of QoS mappings from RSVP to wireless subnetworks. > > Perhaps it will be a good idea to enlarge the charter goals > > of the ISSLL group in order to include issues that are > > relevant to RSVP and wireless networks, e.g., cellular networks. > > > > Best Regards, > > Georgios > > > > > > > > > > >