Subject: Re: differential services tos octet

From: Steve Deering <[email-masked]>
Date: Thu, 16 Oct 1997 14:37:36 -0700

Sigh.  I proofread my messages 3 or 4 times before sending them, and mistakes
*still* slip through.

When I wrote:

> Half of the capacity of the C-D link is being wasted, when it could have
> been used to increase customer satisfaction.

that should have been "One third of the capacity of the C-D link is being
wasted...".

And when I wrote:

> There is no penalty to the application for doing so, since the routers at
> the dropping points ensure that its DP traffic is not threatened by its
> own (or anyone elses) non-DP traffic.

I got "DP" and "non-DP" mixed up.  It's the non-DP traffic that is not
threatened by the DP traffic.

Sorry about that.

Steve

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 17 Oct 1997 10:26:23 +0300

steve's argument about where the extra traffic should be dropped has
been going on long time also on other forums than ietf.  abr keeps
congestion out of the atm core and causes packets to be buffered and
dropped at the edge routers, whereas ubr allows all traffic up to a
certain peak rate into the core and then drops extra packets fairly at
the congestion points inside the network.

it is true that is would be nice not to admit any such traffic to the
network that would get droped anyway later, but a scheme that keeps
congestion out of the core can be too complex and expensive to implement
or can result into underutilization of the core.  

in the current internet, there is no incentive for a user to control the
amount of traffic it is sending (unless the isp charges per by (possibly
undelivered) packet).  being able to tell which packets are important
and paying extra for their guaranteed delivery is certainly an easy to
implement improvement as compared to the current situation.  what comes
to the out-of-profile packets, the situation remains as it is today.

-- juha

---

From: Steve Deering <[email-masked]>
Date: Fri, 17 Oct 1997 12:15:05 -0700

> the congestion points inside the network.

Is ABR the one that uses hop-by-hop flow control to push congestion
back towards the source?  I am most emphatically *not* advocating
hop-by-hop flow control for the Internet!

> or can result into underutilization of the core.

A conforming TCP keeps (persistant) congestion out of the core, and does
not result in underutilization of the core.  I suppose you could say TCP
was too complex and expensive to implement, but I don't think we would
have an Internet if that investment had not been made.  A similar
investment needs to be made in providing end-to-end congestion detection
and adaptation for non-TCP types of traffic, and that will happen sooner
(and people will stop hacking their TCP's to make them more aggressive)
if the router behavior is such that persistent-drop-causing applications
or transport protocols are given worse performance than well-behaved ones.

> undelivered) packet).

It's worse than that.  There are positive incentives for sending excess
traffic, in that a user gets more bandwidth by being more aggressive.
We need to reverse the incentive structure.  Adding support for drop
preference makes it even worse, rather than better (at least that appears
to be the case for the sort of drop preference that is used to distinguish
degrees of importance of packets or in-versus-out of profile -- I'll
reserve judgement on SIMA's style of drop preference until I've had a
chance to study it.)

>  being able to tell which packets are important

No, I think you are going to make it worse for "out-of-profile" (i.e.,
most Internet traffic), when you could instead make it better.

Steve

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Oct 1997 10:52:27 +0300

steve,

i didn't suggest that you were advocating abr style flow control for the
internet, but simply tried to tell that the problem where to handle
congestion is by now means a new one.

of course it would be nice if everyone would be running just conforming
tcp sessions.  that would keep congestion out of the core, but an isp
cannot rely (and for good reasons) on that.  there must for an isp a
means to tell, which packets contribute to the congestion (i.e. are
out-of-profile) and the more dp bits you have, the more accurately it
can be done.

how is that?  the more you exceed your profile, the higher dp you will
get and the network will catch you sooner.  also, nothing prevents a
diff service internet router from applying the xred techniques as well.

-- juha