Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective



Title:
Brad,

Definitely, yes. I won't say that I am categorically against any of the other proposals, it's simply that by my calculations (for both prioritized pause and preemption) indicate that they are not worth doing. I will look forward to seeing some proof that I am wrong before I change my position on those.

Throttling has some demonstrably good behavior in the case where a device cannot service its input queue at line rate, therefore it should ask the upstream device to throttle. This reduces the effective link b/w and allows the device ahead of the choke point to control the congestion (as it should be).

Hugh.

Booth, Bradley wrote:
Message
Hugh,
 
Can we sign you up as a supporter of link throttling and then let the Task Force propose methods of performing that throttling?  I know a number of us have considered pause as a form of throttling, but there are other methods as you've alluded to.  Would it be more palatable to you that the study group request doing congestion management by using link throttling in their PAR?
 
Thanks,
Brad
-----Original Message-----
From: owner-stds-802-3-cm@listserv.ieee.org [mailto:owner-stds-802-3-cm@listserv.ieee.org] On Behalf Of Hugh Barrass
Sent: Friday, May 21, 2004 10:30 AM
To: STDS-802-3-CM@listserv.ieee.org
Subject: Re: [8023-CMSG] Proposed Upper Layer Compatibility Objective

David,

I would suggest that any form of feedback/pause mechanism is inherently flawed, no matter which group does it (with the exception for link throttling that I have already mentioned).

If you think deeply about the problem, you will see that the only way for this to work is to extend the pause so that it goes from the choke point back to the originating source of traffic that's causing the overload. This type of problem has been around since the beginning of networks and has, basically, two approaches for the solution:

1. Drop packets at the choke point (NOT anywhere else). Build upper layer protocols that interpret dropped packets as indications that congestion exists, therefore they reduce the system load. This works!

2. Build a network of channels (or virtual circuits if you will). As a connection is defined from one end point to another, bandwidth is reserved across all the links required for making the connection. This also works, but is deprecated for (normally connectionless) packet networks - traffic is going from each end point to many other end points. Perhaps there will be a resurgence in channelized solutions for self-contained networks, provided that the provisioning and management problem is solved - this will not be Ethernet!

A congestion based pause mechanism has the effect of moving the congestion point. This means that traffic passing through the false congestion point is effected, whereas it wouldn't normally have been. Depending on the network architecture and components, this false congestion may cause increased latency or packet loss for the innocent traffic. This will cause upper layer protocols to mistakenly react to perceived congestion. It will also cause network level traffic management to misinterpret the position of the choke point, causing bad changes to routing configurations.

Hugh.

David Martin wrote:

Matt,

 

Thanks for the reply.

 

I'm trying to stay away from the organizational "where to do it" angle of .3 vs .1 and consider whether there is some backpressure that could be done at a finer granularity like per-VLAN ID or per-CoS.

 

WG locale aside, are you saying you're not a fan of either a per-VLAN ID or per-CoS backpressure mechanism?

 

...