RE: A Transport Protocol Without ACK

[Roger Cummings <roger.cummings@veritas.com>]

I'm trying for a pre-emptive strike on this particular rathole before it
opens.

Fibre Channel does in fact have some tools with which to implement a
congestion control mechanism, but they are implemented in a class of service
(Class 2) that is not widely used today. The tools are a buffer-to-buffer
flow control scheme (separate from end-to-end flow control) to prevent a
particular fabric element being overwhelmed, and the ability for FC fabrics
to return a special frame (called F_Busy) indicating that onward progress
was not possible - basic Explicit Congestion Notification (ECN). There had
even been talk about the equivalent of a slow-start algorithm, though in the
terms of RFC2914 we had never quite got to AIMD (Additive-Increase
Multiplicative Decrease).

I am NOT proposing that this WG look at these processes. Quite to the
contrary, I'm trying to point out that there a number of significant warts
on this scheme - the fact that it is port-based, not connection or
flow-based, and that the transmitter backoff is implied rather than closely
defined. Whatever we are going to do for congestion control in IP Storage,
it cannot be based on this scheme, which does not even pass a top-level
inspection for suitability.

In summary, Steve wasn't quite correct. Yes FC does have some tools for
responding to the congestion problem in its own domain, but No they are
definitely not what we want for IP Storage.

Regards,







Roger Cummings
VERITAS

roger.cummings@veritas.com

> -----Original Message-----
> From: Stephen Byan [mailto:Stephen.Byan@quantum.com]
> Sent: Tuesday, September 19, 2000 1:02 PM
> To: 'ips@ece.cmu.edu'
> Subject: RE: A Transport Protocol Without ACK
> 
> 
> Y P Cheng [mailto:ycheng@advansys.com] wrote:
> 
> > While the work group 
> > thinks we should
> > take advantage the flow control and congestion management of 
> > TCP/IP, there
> > are alternatives known as BB-credit and EE-credit management. 
> 
> These are flow control mechanisms, not congestion control 
> mechanisms. Fibre
> channel and InfiniBand do not have congestion control of any sort.
> 
> >  The fibre
> > channel adapters make reliable delivery, lost packet detection, and
> > retransmission without TCP/IP.
> > 
> > Randall, you are right, I did not spent time to provide the 
> > working group a
> > draft defining such transaction-oriented protocol.  All I 
> > have provided is
> > an idea that besides TCP/IP.  The designers for SCSI and 
> fibre channel
> > adapters have solved the head-of-queue blocking, the congestion, and
> > retransmission problems.  
> 
> They have not solved the congestion problem. Please read RFC RFC 2914
> "Congestion Control Principles" and RFC 896 "Congestion 
> Control in IP/TCP
> Internetworks".
> 
> Regards,
> -Steve
> 
> Steve Byan
> <stephen.byan@quantum.com>
> Design Engineer
> MS 1-3/E23
> 333 South Street
> Shrewsbury, MA 01545
> (508)770-3414
> fax: (508)770-2604 
> 
>