Subject: Re: Comments on draft-ellesson-tos-00.txt

From: Ed Ellesson <[email-masked]>
Date: Wed, 03 Dec 1997 13:59:58 -0500

Paul, 

Thanks for the discussion points.  

At 08:47 PM 12/2/97 -0500, Paul Ferguson wrote:

>o I'm not really keen on using the IPsec compliance issue as
>  a method to ensure compliancy with everything in the universe.
>  I'm much more concerned about delivering a real-world diff-serv
>  application that can be used today. Philosophical debates on
>  whether IPsec is real or not is another issue entirely.

This is not an IPsec compliance issue at all, in our opinion, and we were
certainly not trying to use it to ensure compliance with anything, other
than with differential services functionality that *is already real and
in-service*. In point of fact, the routers in between our end systems do
not have to "support" IPsec, or "be compliant" with IPsec.  They don't even
have to know that IPsec is there.  The problem is:  We know that IPsec will
be used by our customers in our end systems, and we know that IPsec will
cover up the UDP/TCP port values and protocol id, thus eliminating the
clues that routers currently have to classify packets according to traffic
type.  The routers can ignore this and try to decipher what is supposed to
be the port number at the header offset, but I don't think that will do
much good :-) 
 
As far your point about delivering something real, that is my goal as well.
I don't think it gets any more real than the queuing preference and
bandwidth allocation functionality that you and other router vendors are
already delivering today, and that our mutual customers are using in
thousands of networks all over the world. Differential services
functionality exists and is in service today and has been proven successful
in thousands of networks.  Why not standardize a mapping which allows
network operators to continue using existing diffserv functionality which
is already working today?  

I think we need a solution that works for both the public internet and
private corporate intranets and extranets, especially since a number of
network operators are looking forward to supporting both across their
internet infrastructures via virtual private networking. 

>o Again, I remain unconvinced that ECN actually gives us anything
>  useful. At least in the short term (and perhaps in the long term).
>  In any event, I don't endorse any diff-serv proposal today that
>  encourages the explicit use of ECN. I believe that the simple
>  delay & drop semantics expressed in draft-ferguson-delay-drop-00.txt
>  are sufficient. As an aside, several of us have determined to combine
>  drafts after the IETF next week -- namely Juha and I. Perhaps this will
>  give more credence to the methods we endorse.
>

I will bow to the ECN gurus to defend it, since I am not as qualified to do
so as they.  I would only argue that if ECN has yet to prove its worth, we
should at least reserve some space in the header to allow it be added in
the future.  I don't think the discussion is closed on this yet.  Our
proposal can go either way.

Regarding whether the semantics expressed in your draft our sufficient, I
am not clear here on what the requirements are which your draft was meant
to satisfy, other than providing "reasonable levels of differentiation".
We have some specific requirements which we listed in our draft, not the
least of which was supporting the differential services capabilities which
have already been deployed and have proven to be successful.  

>o I think we agree on non-adaptive flow treatment, as well as the methods
>  of using a token-bucket on ingress to measure/shape/mark traffic.

Yes, we want to support this at the ingress to a network, but we don't
think you can rely on this exclusively.  Many of our customer's networks
are too large to rely on completely surrounding them with traffic
shaper/policer boxes in a "flash cut".  There is also the problem of
interaction with other networks in extranet arrangements and over vpn's.
Our customers' networks have to continue to work with prioritization for
business critical traffic, through whatever migration and  experimentation
periods we traverse, to arrive at the new differential services
technologies and models. 

We are also not sure that simply marking the packets at the edge is a
complete solution, without preserving the ability to do some class-based
things in the core of the network, given that you can't always be sure of
completely uniformity of policy throughout the network.

In other words, we have to preserve the existing differential services
capabilities as we move towards the new.  Do you agree with this point?  
   
>o We definitely do *not* agree on bit semantics. This is obviously an
>  area of discussion. I believe you have made it much too complex,
>  especially in the area of ECN -- I believe this should be excluded,
>  at least in the first iteration of a working diff-serv implementation.
 
I understand your point.  Please see ECN comments above.  If there is
consensus that ECN adds no value, we can drop it from our proposal with no
change to the service class concept; however, I don't think we have reached
that consensus.  

>o I have a definite appreciation for the RSVP message interworking
>  issues, however, I decided not to tackle them in the first iteration
>  of my draft. I'm not sure that we should actually try to solve all
>  problems at the onset, but rather, discuss them in more detail. This
>  will require input from the RSVP and inserv wg's.

With the service class concept in our draft, we show how it can be applied
to solving the intserv/rsvp flow aggregation problem, should the working
group think that this is a useful consideration.  We think it is important
for any new bit allocations of the TOS byte to avoid precluding such a
solution in the future.  If you allocate the TOS bits to multiple drop and
delay preferences, and don't leave any space for solving the flow
aggregration problem, I think you run the risk of throwing away much of the
value and promise of all the good rsvp/intserv work that has gone before. 

The problem with not considering intserv/rsvp now, is this: One thing that
is critical to making intserv aggregation work, in our view, is that
intserv aggregated flows have to have their own separate queue and
bandwidth allocation in the routers, separated from the non-intserv traffic
for queuing purposes.  We have no argument with the idea that more than two
*strict* priority levels in a network is problematic, because you may never
get to service the lower priority queues due to starvation.  This makes it
very important to combine bandwidth allocation with delay prioritization
queuing, and, for intserv, to allocate separate queues with their own
bandwidth allocation to serve the intserv premium grades of traffic flows,
when they are aggregated to reduce state in the core of the network.  If
you don't do this, somebody is going to get starved.  In our draft, we
simply show that our service class concept supports this.  

If there is consensus that the diff serv participants do not want to force
the complexity of supporting aggregated intserv on every router that
implements the diff serv standard, that's ok...we can make it optional for
those that want to experiment with intserv aggregation.  If that reduces
the complexity enough to make the service class concept acceptable, I think
we can be open to that.  I just think its one additional selling point that
our service class concept accomodates intserv aggregation; whereas, I don't
think the other proposals on the table do.  It's certainly not meant to be
the only selling point :-)

I think we also said in the draft that the code points we proposed for
intserv aggregation can be used as network-specific code points at the
option of the network operator, so we don't think we are pushing complexity
on anyone.

>I believe this at least gives us some issue to discuss prior to
>next week, no?

Absolutely.  Thanks!

Regards, 

Ed Ellesson
Sr. Engineer, TCP/IP Technology Management
IBM Networking Software Products
Research Triangle Park, NC 
[email-masked]
919-254-4115