Re: FW: Proposal for accomodating 10.0000 and 9.58464 line rates
A local flow control mechanism should be possible such that a "resume" msg from
the local flow-control countermanding the "pause" from the remote flow-control.
However, Mick's comment does raise the issue of the "effectiveness" of the
802.3x flow control when the local flow control is used. Specifically, if the
local flow control is in effect, the MAC won't be able to transmit the .3x PAUSE
frame. In other words, the MAC now needs to lower the watermark for which it
sends the PAUSE frame. This may be a small issue compared to the packet buffer
sizing issue, but a monkey rench nonetheless.
My real problem with the whole discussion of accomodating the 9.58464 rates for
direct feed into a WAN is that no one has bothered with the buffer sizing issue.
The buffer in a LAN switch will normally be just big enough to accomodate the
specified link distance such that the .3x flow control will be effective. By
allowing the a LAN link to feed "directly" into a WAN link via a PHY "repeater",
we'll be making it really easy for a customer to plug a LAN switch at the end of
the very long distance WAN link, thus potentially losing the benefit of the .3x
flow control. I would REALLY like to see some simulation results that can
clarify this. Until then, it seems best to "require" the use of a switch at the
LAN/WAN boundary. Such switch will have a WAN I/F with lots of buffers for the
long distance link and the customer won't run the risk of mistaking one for the
other.
Peter
"Mick Seaman" <mick@xxxxxxxxxxx> on 07/23/99 07:12:52 PM
Please respond to mick@xxxxxxxxxxx
Sent by: "Mick Seaman" <mick@xxxxxxxxxxx>
To: stds-802-3-hssg@xxxxxxxx
cc: (Peter Wang/HQ/3Com)
Subject: FW: Proposal for accomodating 10.0000 and 9.58464 line rates
Howard,
I'm not sure this is the same argument at all, since there is quite a
difference between the local flow control scenario and the remote one.
Doesn't using frame based flow control from the PHY locally make things more
complex.
There might be two sources for flow control signals, the local PHY and the
remote MAC, presumably these would have to be distinguished, otherwise a
'resume' message (whatever this is called) from one might countermand
'pause' message from the other.
Alternately is the PHY both a source and a sink for flow control frames from
both sides of it (local and remote), like a low function bridge?
My apologies if this is all clear from a presentation given at the last HSSG
meeting.
Mick
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Howard
Frazier
Sent: Friday, July 23, 1999 5:28 PM
To: stds-802-3-hssg@xxxxxxxx
Subject: Re: Proposal for accomodating 10.0000 and 9.58464 line rates
Not only did Shimon and I present the CRS deferral flow control
mechanism to the 802.3x Task Force 4 years ago, we were granted a patent
on it. US Pat No 5,784,559 Full Duplex Flow Control was assigned to
Sun Microsystems, Inc, and issued on July 21, 1998.
After much careful consideration, 802.3x rejected CRS deferral flow
control in favor of the frame based flow control which was eventually
incorporated into the standard. One of the points of general agreement
was that CRS based flow control offered no performance advantage over
frame based flow control, while frame based flow control could be
applied over a variety of media, and at a variety of speeds.
The idea of using frame based flow control as a solution to the problem
of adapting a 10 Gbps MAC to a 9.?????? PHY has been previously
suggested in this debate. As Rich Taborek mentioned earlier today,
there have been no counter arguments to this proposal offered.
I contend that, rather than creating a new flow control mechanism for
10 Gigabit Ethernet, it would be preferable to make use of the flow
control mechanism that we have already defined. We don't need another
flow control mechanism in Ethernet, and we certainly don't need to
rehash old debates.
Howard Frazier