a vote for asymmetric connections in a session

[Mike Kazar <kazar@icubed.com>]

Folks,

Here are my reasons for preferring the asymmetric connection model to the 
symmetric connection model, in decreasing order of importance.

1.  Implementing a sliding window protocol for seqRn processing is likely 
to be as hard, or harder, as implementing TCP.  Getting something that 
works will be easy, but getting something that works well, even when 
various iSCSI TCP connections are running at different rates is likely to 
be an "interesting" research problem.  Yet connections running at different 
rates is likely to occur in real life quite frequently, sometimes due to 
different connections seeing different packet drop events in a somewhat 
congested network, sometimes due to different connections taking different 
paths (the whole *goal* of multiple connections in a session, after all).

Furthermore, the sliding window state machine for a given session's seqRn 
processing is running at N times the event rate of an individual TCP 
connection's state machine (N is the # of connections in a session), making 
it even more challenging to implement.

2.  It is easier to implement target-specific load sharing mechanisms if 
the target gets to choose, perhaps with input from the host, the connection 
on which a particular transfer should be performed.  In the symmetric 
proposal, the host chooses the connection to use completely on its own.

	Mike
		(kazar@spinnakernet.com)