Re: [8023-CMSG] Server/NIC analogy
Ben,
I think that the situation described is a good justification for rate
limiting.
In general, if a device cannot service its input queue at line rate then
it will be unable to implement the prioritization policy decisions. In
that case it is much better to limit the rate of the link so that the
sender can make the appropriate decision regarding re-ordering,
buffering, discarding etc.
I think that the question remains whether this rate limiting mechanism
needs to be dynamic or whether it is sufficient to be pseudo-static. In
your example, I assume that the server that is unable to cope with line
rate traffic will always be uniformly incapable. There is no reason for
it to tell the sender on a packet by packet basis that it cannot handle
line rate traffic.
Hugh.
Benjamin Brown wrote:
> All,
>
> During a private discussion this afternoon regarding the results of
> last week's meeting, the concept of feedback came up - whether
> it was necessary or not. There was some level of discussion about
> this during the meeting but no one seemed to be able to provide an
> adequate justification for providing congestion feedback and why
> the more common approach of packet drop wasn't adequate.
>
> During this afternoon's discussion, I came up with something that
> I think might be justification. I'm probably just painting a big target
> on my chest but let's see how this goes.
>
> Consider a stand-alone server with a 1G Ethernet NIC. Today's
> CPUs could easily generate enough traffic to swamp the 1G
> Ethernet link (okay this is a bit of an assumption on my part
> but if they can't today they will be able to tomorrow). I don't
> build these things, nor have I looked at their architecture all
> that closely in a number of years, but I'll step out on a limb and
> state that there's a (most likely proprietary) mechanism for the NIC
> to tell the CPU that the link is too slow to handle all the packets
> that it is trying to transmit. I'll step even farther out on that same
> limb and state that the mechanism is not packet drop.
>
> Now, let's use this analogy to consider a server card in a backplane
> that communicates to the world via a port interface line card. The
> server card communicates to the port interface line card using a
> link compliant with the newly emerging Backplane Ethernet standard.
> (Okay, so I'm looking a little into the future.) If you consider the
> entire chassis analogous to the server/NIC in my initial example
> then it would seem plausible that you would want to communicate
> buffer congestion on the port interface line card back to the
> server card using a mechanism other than packet drop.
>
> I'll just close my eyes now. Fire at will.
>
> Ben
>
> --
> -----------------------------------------
> Benjamin Brown
> 178 Bear Hill Road
> Chichester, NH 03258
> 603-491-0296 - Cell
> 603-798-4115 - Office
> benjamin-dot-brown-at-ieee-dot-org
> (Will this cut down on my spam???)
> -----------------------------------------
>