Gert Doering wrote:
Hi,
On Mon, Nov 23, 2009 at 08:41:58AM -0500, Ross Vandegrift wrote:
The answer is very simple: if someone thinks that ethernet flow
control is the answer, the burden of proof is on them to answer
difficult questions about what the actual problem is, what flow
control is going to solve, and why they think that it won't cause more
problems than its worth. At best it does nothing, realistically it
interferes with TCP flow control, and at worst it pauses your storage
and breaks every client.
I tend to disagree with this statement in this broadness. We've seen
problems where lack of flow control combined with a switch with too-tiny
buffers and bursty ingress traffic led to buffer overflow on egress, and
packet loss. If the switch would use flow control here to space the
ingress traffic better (that is: stop and restart the flow for milliseconds
at a time), packet loss would be avoidable.
Of course, this can indeed fire backwards - as in: one egress port is
way overloaded, and flow control spreads the pain from there to all other
egress ports served by the ingress port in question.
So indeed, flow control is not a panacea. I agree with this :-)
An interesting wrinkle (to some) is that stock flow control is not QoS
(i.e. 802.1p codepoint) aware - it's all-or-nothing, meaning your
low-bandwidth diffserv/EF flow gets paused as well as your less-then
best-effort 999.9mbit/sec FTP transfer :o(
There's a flow control extension somewhere for per-802.1p flow control,
but I can't find the references for this.
QoS seems to have gone out of fashion however, so whether this is
relevant is another matter ;o)
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
