Thanks very much for going to the effort it must have taken to put your answer together.

Your explanation is very easy to understand (and ‘picture’), I will have a look at the pdf (url) this evening whilst I’m studying.

Many thanks again,

Richard

TCP uses somewhat sophisticated “end-to-end” flow-control model based on sliding-window concept. This model implicitly accounts for the RTT between the endpoints, available end-to-end bandwidth and buffer space utilization at each endpoint. Note that TCP interprets packet loss as a sign of congestion in the transmission path.

802.3x Flow-Control is based on a “hop-by-hop” local concept, e.g. it only takes in account the loading of the link between a stations and a switch. Moreover, it’s up to NIC driver to decide whether to send the PAUSE frame and how long to hold the locally connected sender, and this process probably does not involve consulting with TCP/IP stack.

Therefore, as you can see, 802.3x flow-control may affect TCP performance in the following manner:

1) Changing the effective RTT between the endpoints by introducing artificial delay
2) Causig excessive packet drops and resulting in TCP slowing the sending rate
3) Possibly introducing TCP flows “synchronization” issue due to tail-end dropping behavior

However, while this surely affects TCP end-to-end flow control, it’s not necessarily affecting it in a bad way. On contrary, it may even improve TCP performance – but this should be a subject to a separate study.

The following IEEE abstract demonstrates that people have been concerned with this interaction and even made some studies already.

http://ieeexplore.ieee.org/iel5/9789/30874/01431675.pdf

Thanks for the great post.

I once ‘broke’ a network by including “flowcontrol receive desired” in a macro applied to the configuration of all ‘uplinks’.

Please can you clarify something for me –> Can ethernet flowcontrol ‘break’ TCP’s mechanisms for flow control in any way?
Somebody once mentioned it to me and it had me thinking…

Richard