Subject: RE: differential services bof

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Fri, 22 Aug 1997 16:21:10 +0200

On the basis of recent discussion in the mailing list I try to clarify   
some of the key aspects.

Firstly, there has been some discussion about what is the right   
punishment of bad abusers - hard dropping or something similar. Now with   
SIMA service (as I have it designed) the situation is somewhat different   
than with most other services, namely, everyone is allowed to send as   
much packets into network as ever possible. In that sense there are no   
abusers at all. Some traffic engineers are concerned with the possible   
waste of network resources - which is quite understandable concern.   
However, on the network point of view there is not any big problem,   
because at every multiplexing point in the network all excessive low   
priority packets can be dropped if needed. Note that the decision can be   
made before any complicated procedures, because each packet directly   
contains the priority information. Therefore, the abusers cannot effect   
the service quality of other customers, except if the abusers have high   
NBR (which means that they are paying as much as the other customers).   
Anyway, we can imagine traffic cases where SIMA brings about some wasting   
of resources, but in my mind that is quite a small price compared with   
SIMAs simplicity and high utilization.

As to the RSVP, my opinion is that it could be suitable for certain   
special cases like video conferences, but it is not reasonable to apply   
it to the great majority of flows. And if possible, it could be quite   
nice to avoid it totally, since the management of a network with RSVP   
(and all other things needed with it) will not be too simple. SIMA may   
fulfill this wish, although we need more independent research to assess   
this issue.

There seems to be quite differing views on the question, what kind of   
service definition is needed between ISP and a customer. For some   
applications hard guarantees could be practical, but in most cases it   
will be very difficult to formulate any useful guarantee (e.g., if the   
application uses tcp/ip). In general, my view to this issue is that a   
typical customers will have an overall satisfaction level regarding the   
ISP services (compared with the price of the service). I hope that there   
will be so much competition in this field that users can change the ISP   
if the service is not satisfactory. In addition, there is obvious demand   
for independent studies in which the quality to price ratio of different   
ISPs is studied. Therefore, I am not very concerned about the quality of   
individual flows (let the customer decide what is important).

Congestion is one of the key words in our discussion. Unfortunately, it's   
actual meaning is not so evident as could be assumed. Firstly, I am sure   
that there will always be enough traffic to fill any Internet type of   
network, if the service is free of charge. Secondly, I am sure as well,   
that if the charging level is high enough, congestion can be totally   
avoided. Thirdly, the real traffic demand varies from time to time.   
Therefore, my interpretation is that at a certain instant, there is a   
(theoretical, of course) charging level which is able to fill the network   
but will not induce congestion. An ISPs target could be to find at least   
approximately this charging level. (I do not know what would economists   
say about this idea :-). Now the good news: SIMA does this automatically   
(but all the 3 priority bits are needed).

Finally, some words about the real-time service in SIMA. The basic   
principle is to make possible a real-time service with a small delay and   
delay variation for interactive applications. This could be done simply   
by using two buffers as described in the draft (or in slide # 12). My   
belief is that two classes is in practice enough, but if more is needed,   
they could be implemented quite straigthforwardly by adding parallel   
buffers. With 2 bit we obtain 4 classes. Anyway, there must really   
significant difference between buffer sizes in order to get enough   
difference in the "feeling" of different service classes. My proposal is   
not to specify any strict delay limit for the real-time service, because   
it obviously depends on the network technology used. But in order to be a   
practical the service must meet the actual requirements of IP-phone, I   
think.

regards,
                 --- Kalevi

---

From: Sally Floyd <[email-masked]>
Date: Sat, 08 Nov 1997 17:20:18 PST

Dave -

Apologies for being over two months late in answering this,
but I want to clarify.  (I had been reading some of my flood
of backed-up mail by most recent threads first...)

>Having said all that, let me put a question about which I am puzzled. Sally
>Floyd objected to drop preference, on the following grounds.  If you have
>responsive flows that adapt their sending rate, it may work fine. But if
>you have hostile flows that just keep sending, you get the network full of
>useless "out" packets, which flow part way through the net, messing up
>other out packets on the way, only to be discarded. Sally  catagorizes this
>as a form of congestion collapse.

I don't object to drop preference.  I object to drop preference
as a **substitute** for end-to-end congestion control.  I don't
have any objections at all to drop preference **in conjunction**
with end-to-end congestion control.

...
>So now let me put words in _Sally's_ mouth...  I think what she said was
>that if we used priority rather than drop preference, this would get
>better. 

What I hope that I said (what I should have said, at any rate) is that
the only way to avoid this form of congestion collapse is to use
end-to-end congestion control.  That is, if "out" packets are dropped,
some form of end-to-end congestion control should ultimately result in
reducing the arrival rate of that flow's "out" packets on that link.
Similarly, given that these are not "guaranteed" per-flow end-to-end
reservations, if "in" packets are dropped, some form of end-to-end
congestion control should result in sooner-or-later reducing the
arrival rate of that flow's "in" packets on that link.  Possibly along
with complaints about unsatisfactory service...

I don't think that priority scheduling makes this either better or
worse.  This form of congestion collapse could occur with either drop
preference or with a priority-based service, in the absence of
end-to-end congestion control.  The only valid reasons that I can see
not to use some form of end-to-end congestion control are (1) you are
essentially on your own private end-to-end line, so it is nobody else's
business what you are doing with your bandwidth; or (2) you have rather
strong guarantees that there is enough bandwidth for what you are
sending, that you are free to use, along the entire end-to-end path
that your packets are taking.

- Sally