From: TWARWICK@madge.com (Trevor Warwick P&T-SP) Date: 14 Mar 95 18:37:35 Subject: Re: flow control contribution Here is the original text that I sent on the 802.5 list... ============================================================================ At the January 1995 interim meeting of 802.5, I volunteered to provide some notes describing the possible uses of the DTR "Flow Control" option. This option was introduced into the draft DTR standard after the November plenary, and after some discussion in January, it was decided to rename the option "Transmit Control", which more accurately reflects its function. The current draft describes Flow Control (which I'll now call Transmit Control) as a mechanism to allow the Station or the C-Port to stop the other end of the link from transmitting LLC and MAC frames. This is acheived by one end of the link sending a Transmit Control MAC frame with a particular subvector ("STOP") , which causes the receiver to set an internal control flag which stops it transmitting. Transmission is only restarted when a subsequent Transmit Control frame ("RESTART") is received, which resets the internal flag and thus removes the hold condition. I argued at the January meeting that this mechanism was useless for general purpose flow control, for the following reasons: 1) Since it acts on the link between the Concentrator and the Station, it acts on all active LLC users of the link. 2) There is nothing defined in LLC to allow end to end flow control to be signalled between a pair of communicating stations, so there is no way that the oft-quoted "higher layers" can get involved in triggering this low level mechanism in the DTR MAC protocol. 3) There is no way of propagating this low level mechanism across a heterogeneous network of 802.5 (or indeed 802.anything) LANs. It only works locally to a single concentrator. Additionally, the mechanism as described in 802.5r/D0.1 stops LLC and MAC frames from being transmitted, but there is no description in D.01 of how the heartbeat process is affected by the halting of MAC frame transmission. There is also the interesting case where both ends simultaneously send a Transmit Control "STOP" frame. I propose that if the mechanism is to remain in the standard, then it should only apply to LLC frames. Practical uses for the Transmit Control mechanism: C-Port stops Station -------------------- This would apparently be useful to help the Concentrator deal with a temporary lack of frame buffers. A typical situation where this can occur is where there are many ports on a Concentrator all trying to talk to a single port (which might have a server attached to it, for example). The Concentrator can quickly use up all its buffers in the output queue for that single port, and have to throw away further frames that it receives. This is a recognised problem in the Ethernet switching world today, especially for low-end switches with tiny amounts of buffer memory. If the Concentrator could stop the Stations from transmitting before all the buffers had been used, less frames would be dropped, which is a Good Thing. However, there is then the further question of what the effect is on the internal processes of a Station when it receives a Transmit Control "STOP" frame. With some implementations, all the higher layer entities in the Station which are doing the transmitting may end up being stalled, which is the anticipated behaviour. However, other implementations may simply end up throwing the frames away internally (say at the interface between LLC and the device driver due to a lack of transmit buffers). Thus, the internal implementation of the Station determines the real utility of the C-port to Station Transmit Control. Station stops C-Port -------------------- I can't see a great need for this, apart from on a link where a C-Port is emulating a DTR station, in which case both ends ought to have the same capability for stopping each other. It could be argued that a Station should have a way of stopping the C-Port transmitting frames if the Station knows that it is not going to process them. But, should the C-Port then discard all frames, or did the Station want the C-Port to queue up all the pending frames for transmission when the Station could deal with them ? As there is no end-to-end process involved, this option simply allows the Station to push some of its buffering requirements off onto the C-Port. Summary ------- I think that the current Transmit Control mechanism could be useful in a pure DTR switch, where the connected Stations had the useful behaviour of stalling their internal transmit processes on receipt of a Transmit Control "STOP" frame. I can think of more than one driver and protocol stack implementation that happens to behave like this already, and one that doesn't. This is not a statistically valid sample. I don't think that anything about the current mechanism is so useful that we must include it in the standard, so I would be happy to go along with the views of the MAC implementers on whether it stays. -- Trevor Warwick email : twarwick@madge.com Madge Networks, voice : +44 (0)753 661401 Sefton Park, Bells Hill, fax : +44 (0)753 661011 Slough, England.