RE: Point-to-Point Links
All,
For the statement:
802.3x flow control was designed for relatively short Ethernet links. In fact, it was initially designed for Fast Ethernet links. The maximum 1GE link distance is 5km. Even this is long for 802.3x flow control. 10GE 40km links are quite a stretch. 802.3x over a SONET cloud...
I have a response of:
In the words of the 802.3x clause editor, "802.3x flow control is completely independent of both speed and of link distance (fiber, copper, or barbed wire. Use of barbed wire simply increases the cost of the physical layer)".
For the users of 802.3x flow control, there is a well defined management variable to account for the link delay. While this link distance variable is available, it is a little hard to find and a foward reference should be added to Clause 31. I will submit such a comment.
This link delay is independent of the N*Pause_Quantum allowed for MDI to upper layer processing delay response. As the following delays are all available,
link delay between end station and its link partner,
link partner MDI to MAC, and
link partner total processing time,
then the total time between a pause frame transmit from an end station to last frame received from the link partner can be calculated. This allows an implementator to size the required receive buffers/memory. Note that not all implementations will have enough receive memory for very long links. If such existing or new equipment looks at the the management variable for link length and has not enough receive memory to store all the bits in transit, then it can auto-negotitate to no flow-control for that link length.
Given that previous clauses have defined for the link partner:
an allowed delay in units of pause quantum (from receive to transmit at the MDI), and
the total allowed delay from the MDI to the MAC, then
a subtraction provides the processing time available to an upper layer.
As the total time delay from the MDI to the MAC to the upper layer processing is finite, the 10Gig standard MUST specify how the total delay is to be split among the various layers. No one layer can be allowed to hog the entire budget (else someone will send the XAUI thru a frame relay channel, thus bypassing the issue of SONET Path, Line, etc., and not allow component interchangeability).
As the present 40 Pause_Quantum is arbitrary and can be changed, the question is not whether or not to specify, but what the specific delay allowance for each layer should be, and is the 40 Pause_Quantum enough time.
Tom Mathey
(Any further questions can be sent directly to me at <tmathey@xxxxxxxxxxxxxx> ).
>> The original intent of my message was to make sure we
>> were making explicit statements rather than implicit
>> ones. Simply stating that .3x flow control only works
>> over point-to-point links doesn't really capture the
>> issue.
>>
>> After more thought and reading your comments, I tend
>> to agree with you both, that .3x flow control was not
>> intended for links such as the multiple sections and
>> lines of a WAN link and should not be supported. I
>> would like to see this explicitly stated in the draft.