Subject: RE: The problem with tagging packets

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Fri, 07 Nov 1997 11:43:49 +0200

On 6 Nov 97 at 8:15 Dimitrios Stiliadis wrote:

> A Drop Bit is definately required to tag packets out of
> profile or excessive use of resources. What are the
> rest going to do ? and how ?

The advantage of several drop preference levels does not situate in   
simple fixed cases. If you suppose that you have a fixed bandwidth   
demand, a fixed traffic profile, at a fixed point of time, in a fixed   
point in the network, then you may well conclude that one bit is enough.

But, I am not using that kind of assumptions. My assumptions are:

1. several ISPs and customers want to use flat-rate charging
2. bandwidth demand of a customer may vary considerably and quickly from   
time to time
3. the overall load situation in the network varies considerably between   
idle and busy hours
4. at a given time, load situation in different parts of network could   
differ significantly
5. most of the traffic uses tcp/ip protocol, which in practice prevents   
using any simple fixed profile method

Therefore, I am convinced that it is at least useful, if not inevitable,   
to use more than one DP bit. Shortly, we need more dynamics than what one   
bit can offer.

.. Kalevi

---

From: Wu-chang Feng <[email-masked]>
Date: Fri, 07 Nov 1997 11:11:08 -0500

I believe the burden is on you to actually show that one bit isn't enough.
There's been several pieces of work which have shown that one bit is enough
to dynamically adapt to what's going on in the network.

I think the majority of people agree on one-bit DP but definitely not
multi-bit DP.  It seems to me that the best approach would be to only
allocate one bit for now, see how well/poorly it provides service
differentiation, and then look at allocating the additional bits.

Wu

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 07 Nov 1997 17:06:59 -0500

>to dynamically adapt to what's going on in the network.

No, I'm afraid we're going to have to agree to disagree here,
as granularity is what I've resoundingly heard service provider's
articulate. No offense, but I'm driven by their desires, not yours.

>differentiation, and then look at allocating the additional bits.

I have seen no such consensus.

- paul

---

From: David Black <[email-masked]>
Date: Sat, 08 Nov 1997 17:52:20 -0500

> to dynamically adapt to what's going on in the network.

Even with high priority non-adaptive apps and catastrophic topology changes?
If the network topology is fixed and all the apps are perfectly behaved (like
TCP), this might work, but in reality, we need more than two levels.

John Curran of GTE is quoted in a recent issue of the Cook report as saying
that GTE plans to waste half the capacity of the new fiber they're pulling to
get immunity to catastrophic failures -- the fiber is installed in a
bidirectional ring and the unused half is reserved to take the capacity of a
severed link by running it the other way around the ring.  There's an obvious
opportunity to sell that bandwidth (as best effort with no reliability in the
case of catastrophic failures) provided that a mechanism exists to dump that
traffic into bitbuckets immediately upon catastrophic failure (and charge
more to people who don't want their traffic treated that way).  The bit we use
to avoid congestion in a normally functioning network will not help take
advantage of this opportunity.

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Wu-chang Feng <[email-masked]>
Date: Mon, 10 Nov 1997 02:03:36 -0500 (EST)

>> Even with high priority non-adaptive apps and catastrophic 

We've been using the priority bit in conjunction with end-host congestion
control to get the desired behavior across a range of scenarios.
The marking/sending at the end-host reacts to what is going on in the
network.  (Whether or not service differentiation is being done, whether
or not all of its packets are being dropped, whether or not there is
enough available bandwidth in the network, etc. etc.)  Without this sort 
of end-host adaptation, you run the risk of congestion collapse regardless 
of the priority marking.

Wu

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 10 Nov 1997 10:56:41 +0100

> articulate. No offense, but I'm driven by their desires, not yours.

Paul, just to let people on the list get more awareness of the reasons why ISPs
like more granularity, drop to the list some of their more urgent needs.

Thanks

P.S. Isn't MPLS going to satisfy them on this side too?

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 10:22:33 +0000

>> articulate. No offense, but I'm driven by their desires, not yours.

well, i wish they'd spoken up in memphis and munich - they were
resoundingly silent about fine grain requirements....
but quite noisy about requiremnets that sounded like simple differential
models.....

 >like more granularity, drop to the list some of their more urgent needs.

yes, that would be helpful - isn't italtel an ISP anyhow?

 >P.S. Isn't MPLS going to satisfy them on this side too?

um, what has mpls got to do with  this? its just an implementation subplot
to keep the atm folk quiet isnt it? :-)

 jon

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 06:50:51 -0500

>of end-host adaptation, you run the risk of congestion collapse regardless 

In all practicality, one cannot depend on the end-systems to responsibly
mark their own packets. Congestion at the first-hop router can also be
mitigated by a preferential drop mechanism.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 07:00:41 -0500

>like more granularity, drop to the list some of their more urgent needs.

I'm not going to try to regurgitate the reasoning that I've been provided,
but I have had several larger ISP's articulate the need for 'more than a
couple' of levels of service differentiation. If I'm not mistaken, some
of these concerns were expressed at the Memphis IETF.

>P.S. Isn't MPLS going to satisfy them on this side too?

It depends what you are referring to. MPLS certainly offers flexibility
in traffic engineering (e.g. explicit MPLS-switched paths for specific
traffic classes), but to the best of my knowledge, simple diff-serv
mechanisms will be similar to what has already been proposed elsewhere
(e.g. mapping IP-layer IP precedence to the MPLS shim).

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 07:05:20 -0500

Allow me to modify this:

Congestion at the first-hop router can also be
mitigated by a preferential drop mechanism, such as
FRED.

- paul

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 12:22:00 +0000

>mitigated by a preferential drop mechanism.
 
i thought this was the purpose of the subscription/profile mechanism

the bit is to do with whether ne wants to use as profile, and also if
one is using it, whether one was in our our of it as one passes the
ingress points

ingress routers might use (implicit?) measurement 
to confirm whether something is within profile or not....
or there may be (ipsec) reasons to believe and end system
sometimes.....

i dunno though
, we seem sometimes to be going round in circles between the architecture
of diff-serv (as per clark and jacobson) and the detailed architecture
of the interface....often i suspect, because some folks dont perceive
the big picture architectural difference between diff-serv and
int-serv....

 jon

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 07:29:03 -0500

>to confirm whether something is within profile or not....

Yes, exactly.

> [...] because some folks dont perceive

Ditto.

- paul

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 10 Nov 1997 13:59:16 +0100

[...]
 
> yes, that would be helpful - isn't italtel an ISP anyhow?

No, it isn't, Jon. It's a manufacturer.  
 
> to keep the atm folk quiet isnt it? :-)

Oh, really?

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 10 Nov 1997 14:52:17 +0100

> of these concerns were expressed at the Memphis IETF.

Are you sure what they were asking for are multiple levels of drop priority?
I'm only asking you to help us on the list to have a clearer view of ISPs' needs so that we can
get along with the most suitable solution to accommodate them. I'm not trying to
argument against your proposal. 

> (e.g. mapping IP-layer IP precedence to the MPLS shim).

Since one of the lower layers is ATM, and since the label is going to be placed
in the header, and in the header you only have the CLP bit to indicate drop priority,
why should we place additional troubles to MPLS people ( both you and me are involved).
Is it a simple minded or naive thought? I apologize if it is.

Still waiting for ISPs' needs.

Alessio

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 14:08:36 +0000

>Is it a simple minded or naive thought? I apologize if it is.
 
this is why the ISSLL work happened _after_ the level 3 work - there
are lots of ways of doing QoS mapping, which are not only QoS service
type specific, but also depend on the entire level 3 architecture and
its interaction with level 2.

you have to _signal_ for an SVC with ATM (unless you are thinking
about using the block transfer services already yet!and even there,
there are initial values for ABT - e.g. immeiate transfer etc)) 
and you can convey ANY level of fancy QoS when you signal an SVC to 
layer 2.....

i think its a red herring (there are about 9 different GS and CL
mappings for IP to ATM already.....)

 >Still waiting for ISPs' needs.
 
agree...it'd be good to hear why these need more bits for more
concurrent per source flows with different priorities ,
rather than just fancier profiles selected by a bit...

 jon

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Mon, 10 Nov 1997 09:17:03 -0500 (EST)

Paul,

> of these concerns were expressed at the Memphis IETF.

I totaly agree with you. However, you have not pursuaded me 
yet that efficient service differentiation can be done by
using multiple drop bits. In all my requests for formal
technical arguments, I get answers of the form : ISPs like it ...
 
I am sorry, but this is not enough ...
 
Dimitri

---

From: Tracy Mallory <[email-masked]>
Date: Mon, 10 Nov 1997 08:05:56 -0800

> of these concerns were expressed at the Memphis IETF.

A few more cents worth: It seems that 1) we are arguing from two 
perspectives: net/backbone-centric and user/edge-centric, 2) still
sharing the goal of a single spec(that's good), but 3) want to get
our preferred way(not so good). 

The two-perspectives view has come up before, but keeps getting 
submerged. I happen to think that from the user/edge perspective,
a single bit is just right. It's simple and sufficient for any
given application. KISS.

I can also see that an ISP with a large backbone, lots of 
contractual and marketing concerns, AND lots of expertise might
want more than two levels of control. I've heard that the next 
generation of backbone routers will support 4-8 priority levels.
However queueing priority is really precedence, and orthogonal to
the drop flags. So I'd give the network one bit of drop precedence
too (MBZ(ero)/MBI(gnored) from/to the application. One bit conforms
with my KISS desires (doesn't necessarily satisfy all of 'em;-).
It would allow a network (an ISP backbone, for instance) to 
protect itself by marking stuff that should be preferentially 
dropped (cheaper services)in order to meet it's contractual needs.

Please correct me if I'm wrong, but it's my impression that the
the extra levels of service that an ISP would want to apply are not
defined so much by the packet contents as by the pipe in which they
arrived, and this leads me to think that independent bits is the 
way to go.

And just to muddy things, I'd argue that a router/switch should
only  use one of these bits at a time. Either it's playing the 
network role, and uses the ISP bit, or it's playing an edge role 
and looks at the user bit. The user/edge bit should be end/edge to
end: it should be available to each ISP cloud along the way, and 
perhaps even for the end(destination) system in some cases.

Regards,

Tracy

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Nov 1997 19:47:06 +0200

i'm running an isp and very much would like to START with a simple model
of one delay bit and one dp bit.  IF after getting experience about the
behaviour of the system, it turns out that more bits are needed in
either category, then it would be nice if we had not EXCLUDED that
possibility in the design of the tos field.  so i don't want to
complicate the implementation nor the service model unless i absolutely
need to and that is not apparent to me at this point.

-- juha

---

From: [email-masked] (Hyogon Kim)
Date: Mon, 10 Nov 1997 14:31:53 -0500 (EST)

Juha,

>need to and that is not apparent to me at this point.

Are you saying this is _the_ last time we can define the bits and that's
it? When we can throw away existing definitions of TOS and IP
precedence as some argue?

I understand people being nervous thinking that what cisco did to 
IP precedence can happen again unless we secure the bits NOW and force the 
router vendors agree to the bit allocation. However, if we can make
them agree to the new bit allocation (or so you think), wouldn't it be 
also true that we can make them agree to the gradual bit allocation?
Like bit 3 for delay priority and bit 7 for drop preference for
example for the 1st generation diff-serv routers? If by 2000 our
experience with 2-level diff-serv routers calls for 4-level or even
8-level diff-serv then why not write another RFC then?

-- Hyogon
------------------------------------------------------------------------------
Hyogon Kim ([email-masked])	       		       |        (201) 829-4728
Research Scientist				       |           MCC 1B-225B
Internet Architecture Research Laboratory	       |      445 South Street 
Bell Communications Research			       |  Morristown, NJ 07960
------------------------------------------------------------------------------

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Nov 1997 21:55:54 +0200

that is fine with me.  as long as there are bits left available for the
future, i can live with 1+1 now.

-- juha

---

From: Sanjay Mithal <[email-masked]>
Date: Mon, 10 Nov 1997 22:10:33 -0500

Juha,

Why would you need more than one bit for the drop priority  if the router is 
perflow enabled. Assuming that most reasonable next generation routers will be,
as I pointed out in my earlier message, packet classification will done on 
fields in the IP header other than just TOS, thereby allowing for greater 
granularity of flow separation. Thus one bit per packet per flow together with 
the flow heirarchy inside the router and an additional (implementation 
specific) mapping function will ascertain packet drop sequence.

Secondly, as a service provider why would you want to standardize the use of 
additional bits ? It would appear to me that service providers should be using 
this opportunity (i.e., the entire diff-serv discussion) to place requirements 
on custom service creation and deployment on common hardware platforms, thus 
distinguishing their service from another providers using similar equipment.

Sanjay 
-- 
Sanjay Mithal
Member of Technical Staff
High Speed Networks Research Dept.
Room 4C-528, Bell Laboratories,
Holmdel, NJ 07733.

Tel: (732) 332-5163
Fax: (732) 834-5379

[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Nov 97 12:47:16 JST

Jon;

> to keep the atm folk quiet isnt it? :-)

Yes, but so is DP bit.

						Masataka Ohta

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 10 Nov 1997 19:35:59 -0500

Juha,

You and I agree, I think, completely.

- paul

---

From: Geoff Huston <[email-masked]>
Date: Tue, 11 Nov 1997 22:25:09 +1100

>specific) mapping function will ascertain packet drop sequence.

I have a lot of problems with this question, as in my mind it does
highlight the difference in designing a transportation switching
system which protocols have to like or lump, and designing
a protocol -aware system which transportation systems have to
adapt to.

How can a TCP session figure out WHICH packets to put a single
DP bit on?All? None? Every second one when TCP moves
into congestion avoidance?

I suspect that the real world would prefer to set ALL packets for a TCP
session at a fixed relative level of DP, hence the requirement for a 
drop probability graduated at various levels, rather than the clumsy
ATM and Frame "kill me" single bit which becomes so cumbersome
to reengineer back into upper level protocols.

>distinguishing their service from another providers using similar equipment.

HUH?

As a service provider my PRIMARY task is to interoperate.

I NEED commonly defined quality semantics to allow end to end
interoperation of distinguished services.

I need a whole heap of varying semantics and custom solution
like a hole in the head.

Maybe this is a short and sharp response, but quite frankly its
common semantics and interoperability that make things like
global telephony and global IP work.

Its wacko custom solutions and attempts to differentiate
at way toolow a level which mean I have to carry
a bagful of silly power adaptors everytime I catch a plane.
I'd never consider repeating such a fundamental mistake
in redefining the demantics of the TOS and precedence
bits in the IPv4 header.

Geoff

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 11 Nov 1997 13:55:01 +0200

Why would you need more than one bit for the drop priority if the
   router is perflow enabled. Assuming that most reasonable next
   generation routers will be, as I pointed out in my earlier message,
   packet classification will done on fields in the IP header other than
   just TOS, thereby allowing for greater granularity of flow
   separation. Thus one bit per packet per flow together with the flow
   heirarchy inside the router and an additional (implementation
   specific) mapping function will ascertain packet drop sequence.

i fully agree that one dp bit PLUS access to the ip header is enough,
since the router can find out which flows are using how much bandwidth.
however, noone has yet explained to me how the flows can be identified
when ip packets and parts of their headers are encrypted according to
ip-sec.  since more and more companies are using internet for
interconnecting their offices, more and more of the traffic will be
encrypted.  so any solution that assumes access to tcp/udp port numbers
is not acceptable.

i'm asking this on this list the third time already:  how can one
identify flows in encrypted in packets?

-- juha

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 11 Nov 1997 11:54:19 +0000

>into congestion avoidance?

um, exactly: it would be VERY dangerous to let a TCP sdheme use Drop
Perference 

yo could have a serious mess if some TCPs did and some didnt

drop preference, surely, if it has any sense at all (apart from simple
precedence which obviously is useful) is for multilayer video codeing,
or for inter and intra-coded video where there are packets with
DISTINCT importance or unimportance in a single flow....even there,
thjere are other approaches (send on 2 sessions or more being one
possiblty already used in many multicast coding schemes and reliable
schemes too)
 
 >to reengineer back into upper level protocols.

agree.....

the point is that 1 TCP doesnt know what another does, and we want to
keep it that way - actually, TCP assumes other TCPs do the same _sort
of thing_ but not necessarily WHEN they do it (e.g. phase of different
sources slow starts)

messing with this would lead to (more) osvcilatory traffic (just has
been observed with TCP over FR and TCP over ABR....already....it makes
things worse

the wroclawaski/clark proposal for a TCP "goodput" profile, is the
opposite - put some profile of a normal simple TCP into the router,
not put more work into the end system (actually, though, i still don't
see what their queue manager looks like, but i guess i need to read
the web page John just announced...)

 >in redefining the demantics of the TOS and precedence
 
but are you happy with 1 bit (saying pay more)?

cheers

 jon

---

From: "Alessio Casati" <[email-masked]>
Date: Tue, 11 Nov 1997 14:37:17 +0100

> identify flows in encrypted in packets?

There exist, to the best of my knowledge ( I ask any IPSEC guy to correct
my highly likely errors) two kinds of encriptions based on ESP, namely tunnel mode
and transport mode encription. Tunnel mode encription encripts the whole packet
(and mostly relays on some security agent to provide encription and security associations).
Transport mode encription is related to the encription of the transport level, that is
of the IP payload. 
So, when tunnel mode encription is used many flows would be more likely hidden by encription
and proper treatment must be performed by a proper service selection at the security agent level.
You can only identify the aggregate. In transport level encription SRC and DST are very likely to
identify end hosts. So service subscription is more likely to take place at the end hosts.

Having said this, the SPI (Security parameter index or something like this) field in the ESP header 
helps to identify security association, therefore the SPI plus SRC/DST IP addresses should suffice 
to get what you need.

Anyway, you would not be able to know the transport level content (IPSEC guys correct me if I'm 
wrong) unless you are able to perform decription.

Take what I said with some doubt, since I only had some chance of reading some RFC (1825,26,27) 
a long time ago and now I know there's some new work being done.

alessio

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Nov 1997 15:16:15 +0100

In your previous mail you wrote:

=> only IPv6 has a part of the solution with the flow info field
(udp/tcp ports can be expensive to get with extension header
mechanism then classification tools should use only the (first) header).
But there is no agreement about the way to use flow infos in ESP tunnels
even it should be easy if ISPs accept classification by customers...

Regards

[email-masked]

PS: of course it is possible to encapsulate IPv4 packets
on IPv6 (secure) tunnels.

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 11 Nov 1997 14:19:25 +0000

>Huh? 

 >I think you really have not understood how to tune TCP performance in a per 
 >flow system. I suggest that you refer to Lakshman, Stiliadis et. al. in to 
 >appear in Infocom'98.

um, it better appear in Windows 97, or its a non starter - i thin
kthat that is what geoff is after - i think yo umay have
misinterpreted his tone (he is sharp, but never rude in my
experience)_

things that rely on fancy research results on tuning TCP in client
systems are likely to take about as long to deploy as RSVP+WFQ - i.e.
useful contributioins in medium to long term, but...

btw:

how do we refer to a paper "to appear" (or even after the conference
given IEEE infocom doesnt put all papers online for free, unlike ACM SIGCOMM)

is there a URL for
a) the paper
b) the code (for 95, Nt 4 and 5 and/or u**x)?

and can infocom not be scheduled concurrent to IETF if they want to
have more influence on the real world! :-) :-) :-)

cheers

 jon

---

From: Sanjay Mithal <[email-masked]>
Date: Tue, 11 Nov 1997 08:22:39 -0500

Huh? 

> As a service provider my PRIMARY task is to interoperate.

While I respect your need to interoperate, I would also suggest that if you 
wish to distinguish your service from another providers, you had better start 
thinking about how to do so on "common" hardware platforms. I could provide you
with a service model that is flexible, and interoperable, but then I merely 
work for an equipment vendor ;-)
 
> I need a whole heap of varying semantics and custom solution

I suggest that you refrain from profanity in public, because it merely 
indicates a limitation on your ability to think through a solution. This is a 
forum for technical discourse, not verbal abuse.

Sanjay

Tel: (732) 332-5163
Fax: (732) 834-5379

---

From: Roch Guerin <[email-masked]>
Date: Tue, 11 Nov 97 10:08:36 -0500

>have more influence on the real world! :-) :-) :-)

Jon,
That's a cheap one.  We've got to book dates and hotel reservation way
before the IETF makes meeting dates available.  So it would seem to me
that it's the other way around, or maybe this is all a plot to prevent
the Infocom crowd from influencing the IETF ;-) ;-) ;-}

Roch

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 11 Nov 1997 15:40:01 +0000

>the Infocom crowd from influencing the IETF ;-) ;-) ;-}
 
the IMRs (see below) list IETFs and SIGCOM and Usenix and related
conferences....perhaps IEEE, ACM and IETF (and interop) should
coordinate a bit more altogether...

ACM has its own internal conference clash detection (which admittedly
failed with sigcomm and sigops in europe too far apart this summer)....but a more
global one would benefit complimentary organisations more.....

thats enough about this here, but i thought the int-serv crowd
(largely a cross over with ATM forum too) represents a key potneitla
pool of overlapped interest......

 jon

CALENDAR
--------

Last update 09/30/97

The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:

               <[email-masked]>

Please note: The Secretariat does not maintain on-line information
for the events listed below.

A copy of this calendar is available as follows:

VIA FTP
-------
IETF Information is available by anonymous FTP from several sites.

        US East Coast Address:  ds.internic.net (198.49.45.10)
        US West Coast Address:  ftp.isi.edu (128.9.0.32)
        Europe Address:  nic.nordu.net (192.36.148.17)
        Pacific Rim Address:  munnari.oz.au (128.250.1.21)
        Africa Address:       ftp.is.co.za (196.4.160.12)

WWW
-------
<http://www.ietf.org/home.html> Click on the link for "meetings" and
you should find an entry "listing of other Internet related events".

************************************************************************

1997
----

Oct. 6-10         NetWorld+Interop                Atlanta, GA
Oct. 6-10         ANSI X3T11  (host by FSI)       Tucson, AZ
Oct. 7-10         COMDEX Internet '97 and Object World '97
                  Internet Forum Europe (IFE) & Object
                     World Frankfurt (OWF)        Frankfurt, Germany
Oct. 15-17        USENIX Conf. on Domain-Specific
                     Languages (DSL)              Santa Barbara, CA
Oct. 20-23        NetWorld+Interop                Paris, France
Oct. 23-24        TERENA General Assembly         Madrid
Oct. 24-26        1st Int'l Enterprise Distributed
                   Objected Computing Wrkshop
                   EDOC '97                       Gold Coast, Australia
Oct. 23-25        ETSI                            Nice, France
Oct. 26-31        11th USENIX Sys. Admin
                    Conference (LISA '97)         San Diego, CA
Oct. 27-28        NANOG 11 Meeting                Phoenix, AZ
Oct. 27-28        Mobile Agents & Security Wrkshp Baltimore, MD
Oct. 27-30        NetWorld+Interop                London
Oct. 27-31        EWOS Workshops                  Brussels
Oct. 28-31        IEEE Int'l Conf. on
                      Network Protocols           Atlanta, GA
Nov. 3-5          APPN Implementers Workshop      Raleigh, NC
Nov. 3-5          Int'l Test Conference 1997
                  Sheraton Washington Hotel       Washington, DC
Nov. 3-7          ANSI X3T10 '97
Nov. 3-7          SPIE Int'l Symposium
                   Voice, Video & Data Communications
                   Conf. on Performance & Control of
                   Network System - Special Session on
                   Switching & Traffic Mgmt in
                   High Speed Networks            Dallas, TX
Nov. 3-7          2nd French/Brazilian Symposium
                  on Distributed System Architectures:
                  Telecommunication Multimedia Architectures
                                                  Ceara, Brazil
Nov. 8-14         ACM MULTIMEDIA '97              Seattle, WA
Nov. 10-14        IEEE 802 Plenary  Queen Elizabeth, Montreal
Nov. 12-13        8th Maryland Workshop on
                   Very High Speed Networks       Baltimore, MD
Nov. 12-13        CEN/CENELEC/ETSI                Brussels
Nov. 19-21        ICCC'97                         Cannes, France
Nov. 24-26        PROMSMmNet '97
                   Multimedia Networking          Santiago, Chile
Nov. 27-28        NetWorld+Interop                Sydney, Australia
Nov. 30-Dec 5     ATM Forum                       Singapore
Dec. 1-3          30th IEEE/ACM Int'l Symposium
                   on Microarchitecture           RTC, NCA
Dec. 1-5          ANSI X3T11 (host by DPT)        Orlando, FL
Dec. 2-3          EWOS Assembly                   Brussels
Dec. 8-12         40th IETF (Host: Newbridge)     Washington, DC
Dec. 8-12         OIW (Firm)
Dec. 8-11         USENIX Symposium on Internet Technology
                      and Systems)                Monterey, CA
Dec. 8-11         GigNet                          San Jose, CA
Dec. 17-19        97 Int'l Sym. on Communications Hsinchu, Taiwan

TBA               TELECOM '97 Asia                TBA

1998
-----------
Jan 6-8           W3C Interest Group Mtg          TBA
Jan.              RIPE29                          Amsterdam (tbd)
Jan 26-29         7th USENIX Security Symposium   San Antonio, TX
Feb. 8-13         ATM Forum                       Anaheim, CA
Feb 7-9           DCI'S Internet Expo             San Jose, CA
Mar. 2-3          USENIX New Network
                   Technologies Symposium         Salt Lake City, UT
Mar. 9-11         2nd Euromicro Working Conf. on
                   Soft. Maint. & Reeng.          Florence, Italy
Mar. 9-13         IEEE 802 Plenary                Irvine, CA
Mar. 11-13        Internet Society NDSS '98: Symposium on
                   Network & Distributed Sys. Security
                   Catamaran Resort Hotel         San Diego, CA
Mar. 16-18        APPN Implementers Workshop      Raleigh, NC
Mar. 29-Apr 2     IEEE INFOCOM '98 - Hotel Nikko  San Francisco, CA
Mar. 30-Apr. 3    41st IETF  (No Host)            Los Angeles, CA
Mar. 30-Apr. 3    NetWorld+Interop                Singapore
Apr. 3-4          IEEE "OPENARCH '98"             San Francisco, CA

Apr. 6-10         wmATM'98  1st Int'l Workshop on
                   Wireless Mobile ATM Implementation
                                                  Hangzhou, China
Apr. 12-17        WWW7                            Brisbane, Australia
Apr. 18-23        CHI '98 (ACM SIGCHI)            Los Angeles, CA
Apr. 19-24        ATM Forum                       Berlin, Germany
Apr 20-22         W3C Interest Group Mtg          TBA
May               RIPE30                          Stockholm (tbd)
May 5-8           Networld+Interop '98            Las Vegas, NV
SPRING 1998       TELECOM '97 Africa              Midrand, South Africa
Jun. 7-11         ENCOM '98 in conjunction with
                   ICC/SuperComm '98              Atlanta, GA
Jun 13-17         USENIX '98 Technical Conf.      New Orleans, LA
Jun 16-18         DCI's Internet Expo             Chicago, IL
Jul. 6-10         IEEE 802 Plenary                San Diego, CA
Jul. 21-24        INET '98                        Geneva, Switzerland
Jul. 26-31        ATM Forum                       Portland, OR
Aug. 23-29        15th IFIP World. Com. Conf.     Vienna, Austria and
                                                   Budapest, Hungary
Aug. 24-28        42nd IETF                       Chicago, IL
Aug. 29-Sep 4     SIGCOMM '98                     Vancouver, CANADA
Sep 1-3           DCI's Internet Expo             Boston, MA
Oct. 4-9          ATM Forum                       Gold Coast, Australia
Oct 20-22         W3C Interest Group Mtg          TBA
Oct 21-23         Networld+Interop '98            Atlanta, GA
Oct. 26-29        TERENA (host by DFN)            Dresden, Germany
Nov. 9-13         IEEE 802 Plenary                Albuquerque, NM
Nov. 29-Dec 4     ATM Forum                       Nashville, TN
Dec. 6-11         12th Systems Administration Conf.
                    (LISA '98)                    Boston, MA
Dec. 7-11         43rd IETF (Tentative)           TBD

1999
-----

Feb. 7-13         ATM Forum (tentative)           TBA
Feb 23-25         W3C Interest Group Mtg          TBA
Apr. 18-24        ATM Forum (tentative)           TBA
May 11-14         Networld+Interop '99            Las Vegas, NV
May 31-Jun 4      WWW8                            Toronto, CANADA
Jun 4-6           W3C Interest Group Mtg          TBA
Jul. 18-24        ATM Forum (tentative)           TBA
late Aug          SIGCOMM '99 (West Coast US)     TBA
Sep. 21-23         W3C Interest Group Mtg         TBA
Sep. 26-Oct 2     ATM Forum (tentative)           TBA
Oct. 8-14         TELECOM '99                     Geneva, Switzerland
Oct. 13-17        Networld+Interop '99            Atlanta, GA
Nov. 28-Dec 4     ATM Forum (tentative)           TBA

2000
-----

May 9-11        Networld+Interop '00              Las Vegas, NV
late Aug        SIGCOMM 2000                      Europe (tentative)
Sep 25-29       Networld+Interop '00              Atlanta, GA

The TERENA Calendar for October 1997 may be found on URL:

http://www.terena.nl/news/calendar.html

+++++++++++++++++++++++++++++++++++++++++++++
+                                           +
+       TERENA Secretariat                  +
+       Singel 466-468                      +
+       1017 AW Amsterdam                   +
+       the Netherlands                     +
+                                           +
+       email <[email-masked]>       +
+                                           +
+         tel: +31 20 639 1131              +
+         fax: +31 20 639 3289              +
+                                           +
+++++++++++++++++++++++++++++++++++++++++++++

SOFTBANK FORUMS
---------------

SOFTBANK Forums
303 Vintage Park Drive
Foster City, CA  94404
(650) 578-6900
Fax: (650) 525-0194
http://www.sbforums.com

1998 Future Event Calendar

Business Conferences & Expositions

Seybold Seminars New York
Jacob K. Javits Convention Center
New York, NY
http://www.seyboldseminars.com
Customer Service
(888) 800-8922 (U.S. & Canada)
(650) 372-7072 (International)
Conference:             Mar 16-20, 1998
Exposition:             Mar 17-19, 1998

Networld+Interop 98 Singapore
Singapore International Convention
and Exhibition Centre
Singapore
http://www.interop.com/events
Information
011 (65) 227 5755
Conference:             Mar 30-Apr 3, 1998
Exhibition:             Apr 1-3, 1998

Comdex Japan
Makuhari Messe
Tokyo, Japan
Information
011 (81) 3 5642 8433
Conference:             Apr 6-9, 1998
Exposition:             Apr 6-9, 1998

Support Services Conference & Expo 98
Washington DC Convention Center
Washington DC
http://www.sbforums.com/ssce
Customer Service
(800) 801-1354 (U.S. only)
(719) 531-5138 (International)
Housing
(800) 754-8378 (U.S. & Canada)
(650) 378-6643 (International)
Conference:             Apr 20-22, 1998
Exposition:             Apr 19-22, 1998

Networld+Interop 98 Las Vegas
Las Vegas Convention Center
Las Vegas, NV
http://www.interop.com/events
Customer Service
(800) 944-4629 (U.S. & Canada)
(650) 372-7090  (International)
Conference:             May 4-8, 1998
Exhibition:             May 5-7, 1998

Networld+Interop  98 Tokyo
Makuhari Messe
Tokyo, Japan
http://www.interop.com/events
Information
011 (81) 3 5642 8433
Conference:             June 1-5, 1998
Exhibition:             June 3-5, 1998

Learning Technology
Georgia World Congress Center
Atlanta, GA
http://interactive.sbforums.com
Registration (SOFTBANK Knowledge Interact)
(800) 909-9848 (U.S. only)
(719) 531-6522 (International)
Housing
(888) 611-2189 (U.S. & Canada)
(650) 372-7084 (International)
Conference:             June 14-17, 1998
Exhibition:             June 14-17, 1998

Seybold San Francisco
Moscone Convention Center
San Francisco, CA
http://www.seyboldseminars.com
Customer Service
(888) 473-9265 (U.S. & Canada)
(650) 372-7078 (International)
Conference:             Aug 31-Sept 4, 1998
Exposition:             Sept 1-3, 1998

Support Service Conference & Expo West
Moscone Convention Center
San Francisco, CA
http://www.sbforums.com/ssce
Registration (SOFTBANK Knowledge Interact)
(800) 801-1354 (U.S. only)
(719) 531-6522 (International)
Housing
(800) 754-8378 (U.S. & Canada)
(650) 378-6643 (International)
Conference:             Sept 8-11, 1998
Exposition:             Sept 8-10, 1998

Windows NT Intranet Solutions
Moscone Convention Center
San Francisco, CA
http://www.wintis.com
Customer Service
(888) 800-8920 (U.S. & Canada)
(650) 372-7071 (International)
Conference:             Sept 8-10, 1998
Exposition:             Sept 8-10, 1998

Networld+Interop 98 London
Earls Court 2
London, England
http://www.interop.com/events
Information
011 (44) 0181 261 4415
Conference:             Oct 13-15, 1998
Exhibition:

Networld+Interop 98 Atlanta
Georgia World Congress Center
Atlanta, GA
http://www.interop.com/events
Customer Service
(800) 962-6513 (U.S. & Canada)
(650) 372-7079 (International)
Conference:             Oct 19-23, 1998
Exhibition:             Oct 21-23, 1998

Windows NT Intranet Solutions Japan
Makuhari Messe
Tokyo, Japan
Information
011 (81) 3 5642 8433
Conference:             Nov 4-6, 1998
Exhibition:             Nov 4-6, 1998

Networld+Interop 98 Paris
Porte de Versailles
Paris, France
http://www.interop.com/events
Information
011 (33) 1 46 39 5656
Conference:             Nov 4-6, 1998
Exhibition:

Networld+Interop 98 Sydney
Sydney Convention Center
Sydney, Australia
http://www.interop.com/events
Information
011 (61) 2 9369 1242
Conference:             TBA
Exposition:             Nov 23-27, 1998

Java Internet Business Expo *
Jacob K. Javits Convention Center
New York, NY
http://www.javaexpo.sbforums.com
Customer Service
(888) 528-2397 (U.S. & Canada)
(650) 372-7069 (International)
Conference:             Dec 7-10, 1998
Exposition:             Dec 8-10, 1998

Seybold Seminars Tokyo
Makuhari Messe
Tokyo, Japan
http://www.seyboldseminars.com
Information
011 (81) 3 5642 8433
Conference:             Dec 8-11, 1998
Exposition:             Dec 9-11, 1998

Strategic Networks Seminars

Strategic Networks offers one-day seminars for Interop Remote Access,
Interop NetSwitch, Interop WAN, and Interop Secure ManageNet
periodically throughout the year in various locations in the United
States.  For registration information, please call Strategic Networks
at 800-898-7488. For sponsor opportunities, please call Strategic
Networks at 800-999-7624.

Help Desk Institute Regional Seminar and Expo Series

Help Desk Institute offers several seminar series periodically
throughout the year in various locations across the United States.
For registration information, please call (800) 248-5667 or (719)
531-5138 .

Software Support Professionals Association (SSPA)

SSPA offers a variety of support programs throughout the year which
include executive forums, software support conferences, and monthly
on-line roundtable and executive sessions. For a description of the
events and for registration information, please call SSPA at (800)
801-1354 or (719) 531-6522.

SOFTBANK Knowledge Interact Seminars

SOFTBANK Knowledge Interact offers SkillTech Professional Seminars
periodically throughout the year in various locations throughout the
United States.  For a calendar of 1997 events and registration
information, please call SOFTBANK Knowledge Interact at 800-34-TRAIN.

All dates are subject to change
Revision date: 9/25/97
*Indicates an addition or correction

---

From: Wu-chang Feng <[email-masked]>
Date: Tue, 11 Nov 1997 11:04:18 -0500 (EST)

> not put more work into the end system (actually, though, i still don't

We tried this.   The problem is that TCP is bursty enough to require a
large profile in order to accomodate it (ACK compression, etc).  In our 
simulations we policed the source with a token bucket.  The token bucket 
needed to be large in order to accomodate the dynamics of the TCP source.  
A large token bucket allows a large amount of priority packets to be 
injected into the network at a particular moment in time causing substantial
priority packet loss in ERED/RIO queues which kills performance.

Wu