Re: [8023-CMSG] Server/NIC analogy
Hugh,
For the BPE link between the server and the port interface line
card, static rate control is a good idea. Depending upon the speed
of that link (1G, 2.5G, 10G, other) the server should absolutely
be rate limited to that speed. However, since that "NIC" is on the
same card as the server, I view that as capable of using the same
proprietary mechanism that the stand-alone server/NIC solution
uses.
The kind of thing that is more interesting is the situation where
the port interface line card is a switch, serving multiple servers.
If the output port(s) of the switch can't support the bandwidth
destined to it (them), it may be reasonable to throttle back the
source server(s).
The reason I think this works is because of the (very) small
number of hops back to the source. In a multiple hop, multiple
switch, poorly constrained network, it might be difficult if not
impossible to expect to push feedback to the source where it
can be effectively used. It may not work at all if the number of
hops is greater than 1, unless the protocol is such that the message
returned somehow reflects enough information (is DA enough?)
to tell the source which path is congested. However, the number
of packets in the pipe all the way back to the source may simply
be too high to make this feasible at all.
To me, it seems the question is whether a protocol that may be
limited to only 1 hop (if the receiver is not the source, the message
is ignored and the old packet drop mechanism is used) can
satisfy any set of 5 criteria. If the protocol is not limited to a
single hop, then I would be curious to know how it gets back
to the source, with what latency (round trip time in terms of
more packets to receive), and how it doesn't move the point
of congestion.
Regards,
Ben
Hugh Barrass wrote:
> 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???)
>> -----------------------------------------
>>
>
--
-----------------------------------------
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???)
-----------------------------------------