Re: Proposal for accomodating 10.0000 and 9.58464 line rates
Howard,
The reason I suggested a PHY based control was that the issue is based
on the PHY's transmit FIFO overflowing, not the adjacent node's receive FIFO
or some other upstream blocking. Different problems often require
different remedies.
If the OC-192 PHY is receiving at full line rate, there will be no way
for a PHY to insert a flow-control frame into its receive stream without
dropping data, and this would be a much more complicated implementation.
If you are suggesting that the MAC residing at the other end of the OC-192
link should assert a flow-control frame, what criteria would
there be to drive this action? The MAC would be receiving less than
its maximum rate and if there was no upstream blocking, it would be
very happy as the PHY on the other end of the link overflowed.
I believe that this matter is best solved with a PHY based signal.
Was your assertion of the Sun patent intended to suggest that there may
the IP may not be available for us to use in the standard if this method
achieves concensus?
Thanks,
Dan Dove
--
___________ _________________________________________________________
_________ _/ ___________ Daniel Dove Principal Engineer __
_______ _/ ________ dan_dove@xxxxxx LAN PHY Technology __
_____ _/ ______ Hewlett-Packard Company __
____ _/_/_/ _/_/_/ _____ Workgroup Networks Division __
____ _/ _/ _/ _/ _____ 8000 Foothills Blvd. MS 5555 __
_____ _/ _/ _/_/_/ ______ Roseville, CA 95747-5555 __
______ _/ ________ Phone: 916 785 4187 __
_______ _/ _________ Fax : 916 785 1815 __
__________ _/ __________________________________________________________
hfrazier@xxxxxxxxx wrote:
>
> 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