Fibre Channel Credits vs. FCoE's "Pause"

1.  At 1Gbps a FC frame is 4km long, at 2Gbps a frame is 2km long, and at 4Gbps a frame is 1km long.

2. A 10km cable is 20km round trip.  Round trip must be accounted for since the R_RDY packet reply from the distant end needs to traverse this distance before the source receives it and can continue to send.  The goal is the saturate the link with as much traffic as possible.  In order to do this, you must allocate enough B2B credits, which is essentially the allocation of buffer resources.

3. On 10km cable @ 2Gbps we need 10 BB credits, 100km cable @ 1Gbps we need  50 BB credits, etc. This is basic link engineering with Fibre Channel.  Calculate the amount of B2B credits you need, assign them to the switches, and you should have no worries.  You still may need to worry about latency, and of course you will always have to consider the bandwidth delay product of any link to understand it's true capacity, but your lossless needs will be handled. If you try to do this with FCoE you may end up in a bad race condition.  There may be substantial frames in flight by the time the distant end generates a PAUSE.  Ethernet is not a guaranteed delivery medium, so the in flight stream is not going to be buffered by the sender.  Frames could get dropped, and lots of them.  This issue doesn't really exist on a localized data center converged network, because the speeds are so fast (10GB, typically at least 4GB for FC alone), and the distances so small (meters not kilometers) that things can be handled in relative harmony, a hysteresis does not exist that would leave to the type of adverse condition that may exist on a WAN. I am not saying it will not work, and no doubt some people will try it and may be doing it today.  FCoE is great in the data center, it's not the right tool for the job on the WAN, use FCIP or FC instead.