Subject: Re: PILC ASYM document

From: Sally Floyd <[email-masked]>
Date: Tue, 14 Mar 2000 14:12:30 -0800

Lloyd -

>To me, the growing emphasis on TCP-friendliness for these mechanisms
>indicates the limited scope for evolution available. The mechanisms
>need to display the same level of aggression as TCP to coexist well
>with TCP.

I agree that the requirement for TCP-friendliness limits the scope
for evolution of best-effort traffic competing in FIFO queues with
TCP.  I think of diffserv as the mechanism that will allow
transport-level evolution past TCP-friendliness.  E.g., I could
imagine a class of traffic, labeled by the diffserv field, that is
segregated from best-effort TCP, and that operates by its own rules.
E.g., a class for congestion-based pricing; a class for per-flow
scheduling and users optimizing their own utility functions; a
class for flows all using class-X-compatible congestion control,
etc.  (I don't know what the mechanism is for ensuring that all
routers along the path understand diffserv class X, or something
else appropriate, but I imagine that will come...)

I don't understand what prevents the incremental deployment of 
rate-based pacing, by the way.  Are you suggesting that rate-based
TCP flows competing with regular TCP flows would face starvation?
I wouldn't think so.

- Sally
--------------------------------
http://www.aciri.org/floyd/
--------------------------------

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 15 Mar 2000 11:21:14 +0000 (GMT)

On Tue, 14 Mar 2000, Sally Floyd wrote:

> transport-level evolution past TCP-friendliness.  

Yes - however, making diffserv adequately TCP-friendly (how do you
handle the asymmetry of most TCP connections? What happens when
responsive TCP and unresponsive UDP-based traffic share a class?) is a
problem in itself.

> rate-based pacing, by the way.

There's currently a lack of clear performance benefit as motivation.
No performance benefit or slight degradation == no incentive to
change.

> Are you suggesting that rate-based

Aggarwal et al's paper had Reno consistently outperforming rate-based
pacing (end of section D) from slow start with large buffer
sizes. That's IMO sufficient disincentive to deploy rate-based pacing
as is.

http://www.cs.washington.edu/homes/savage/
Understanding the Performance of TCP Pacing,
Amit Aggarwal, Stefan Savage, and Tom Anderson,
to appear in Proceedings of the 2000 IEEE Infocom
Conference, Tel-Aviv, Israel, March, 2000.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: mukul goyal <[email-masked]>
Date: Wed, 15 Mar 2000 09:37:51 -0500 (EST)

> responsive TCP and unresponsive UDP-based traffic share a class?) is a

I think that Sally was suggesting that some traffic classes in diffserv
can be used by non-TCP-friendly traffic.

Just for information, the other problem regarding TCP and UDP sharing a
traffic class has been studied in some details. We have an Internet Draft
on the issue. Our finding is that you have to mark 'excess' traffic of TCP
and UDP flows differently in order to achieve fair distribution of excess
resources. (Here, excess means unreserved resources.) The draft can be
seen at:
http://www.cis.ohio-state.edu/~jain/ietf/afstdy.htm

I think there is a draft/paper on the issue from Nortel folks also (N
Seddigh et al).

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 15 Mar 2000 15:48:06 +0000 (GMT)

[This is now off-topic for pilc; discussion ends here.]

On Wed, 15 Mar 2000, mukul goyal wrote:
> | On Tue, 14 Mar 2000, Sally Floyd wrote:
> | > On Tue, 14 Mar 2000, Lloyd Wood wrote:
> | > |To me, the growing emphasis on TCP-friendliness for these mechanisms
> | > |indicates the limited scope for evolution available. The mechanisms
> | > |need to display the same level of aggression as TCP to coexist well
> | > |with TCP.
> | > 
> | > I agree that the requirement for TCP-friendliness limits the scope
> | > for evolution of best-effort traffic competing in FIFO queues with
> | > TCP.  I think of diffserv as the mechanism that will allow
> | > transport-level evolution past TCP-friendliness.  
> | 
> | Yes - however, making diffserv adequately TCP-friendly (how do you
> | handle the asymmetry of most TCP connections? What happens when
> | responsive TCP and unresponsive UDP-based traffic share a class?) is a
> | problem in itself.
> 
> resources.

Oh, draft-goyal-diffserv-afstdy-00.txt.

Unlike the position expressed in the conclusions of your draft, we
have shown that it is not necessary for the classifier to distinguish
between TCP and UDP packets in order to meaningfully utilize the three
drop precedences while treating TCP and UDP fairly. (Distinguishing
between TCP and UDP in the network is generally a bad idea, and
then there's IPSec.)

http://www.ee.surrey.ac.uk/Personal/G.Pavlou/Publications/Conference-papers/Andrik-00a-abstract.html

A fair traffic conditioner for the assured service in a differentiated
services Internet 
I. Andrikopoulos, L. Wood, G. Pavlou
to appear in the proceedings of the IEEE International
Conference on Communications (ICC 2000), New Orleans, June 2000. 

L.

> (Here, excess means unreserved resources.) The draft can be
> seen at:

---

From: mukul goyal <[email-masked]>
Date: Wed, 15 Mar 2000 11:24:43 -0500 (EST)

I guess I will sort this out with Lloyd offline and may be post a summary
of the conclusions reached on this list!