Re: Symmetric vs Asymmetric

[julian_satran@il.ibm.com]

David,

The main reason why we had 2 connections in draft-00 was that we did not
like
the TCP window being closed by a large data transfer preventing commands to
go
through (that is Matt's flow control argument).

Julo

David Robinson <David.Robinson@EBay.Sun.COM> on 08/09/2000 03:31:34

Please respond to David Robinson <David.Robinson@EBay.Sun.COM>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: Symmetric vs Asymmetric




> The biggest issue with the "asymmetric" model is that it is NOT
"asymmetric"
> when there is only 1 TCP connection.  When there is only one TCP
connection,
it
> is the "symmetric" model - both commands and data on the same TCP
connection.
> Then, when there is more than one TCP connection, the behavior is
different.
> It's always easier to implement something that operates that same way all
the
> time, than two different behaviors.
>
> I propose that the asymmetric model mandate at least two TCP connections
> (implies that at least one physical connection will have at least two TCP
> connections running on it) - one for commands, the other for data.  This
has
> other advantages, like commands not being flow controlled by large
transfers
of
> data.

That's not a bug, that's a feature! Having the asymmetric degenerate
into symmetric with just one connection is a good thing.  For starters
it is easier to implement initially or in cheap devices and doesn't
have the baggage that a true symmetric design would require
but is not needed with one connection. I would oppose mandating
two connections minimum, if flow control is a problem then the defacto
configuration will be two connections, but lets not require it.

Personally I would still prefer one connection per LUN, but the
proposed asymmetric model is a good compromise. You could
still deploy an implementation with a connection per LUN and not
have any significant unnecessary baggage. Not true of the symmetric
model.

     -David