Subject: Juha Heinanen: Re: differential services tos octet

From: Roch Guerin <[email-masked]>
Date: Sat, 18 Oct 97 13:35:50 -0400

Totally agree with Juha on this one.

It is certainly best not to send in the network traffic that will
eventually be dropped, but unfortunately knowing that ahead of time at
the sources is not a simple task.  The ABR service does indeed attempt
to achieve this goal by continuously probing the network to identify
the bottleneck links and make sure that sources do not send at a
higher rate.  Unfortunately, there is a cost associated with that, and
many have argued that it was too high.  

Doing everything at the edges without any explicit info from the
network is no simple task, if you want to achieve it without severely
affecting utilization (I don't know of any scheme that achieves that
in a robust manner, i.e., irrespective of network configuration).  So,
while I certainly think we should encourage adaptive behaviors in
applications, I disagree that it is the only necessary and useful
mechanism.  Adaptive applications alone wont cut it, and there are
benefits in supporting drop precedence (as well as delay precedences).

Roch
------- Forwarded Message

Date:    Fri, 17 Oct 97 10:26:23 +0300 
From:    Juha Heinanen <[email-masked]>
To:      [email-masked]
cc:      [email-masked], [email-masked]
Subject: Re: differential services tos octet

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
Date:    Fri, 17 Oct 97 10:26:23 +0300 
From:    Juha Heinanen <[email-masked]>To:      [email-masked]:      
	  [email-masked], [email-masked]: Re: differential 
	  services tos octet

------- End of Forwarded Message