Re: multiple connections

[julian_satran@il.ibm.com]

The command connection role can be taken over by any other connection
 or a new connection.
All commands that have not have their status received will be reissued.
Commad numbering is not needed anymore but status numbering is needed for
recovery.
This proposal is similar to what we had in the 00 draft with the added
restriction that data and status will travel over a single connection and
this connection will be designated.

Julo

David Robinson <David.Robinson@EBay.Sun.COM> on 29/08/2000 10:19:15

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

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: multiple connections




While I am not yet convinced of the actual need for multiple
connections, I agree with Kalman that using a single command
connection will greatly simplify the protocol and error recovery.
I would prefer it over the current propsal.

While this will address the perceived performance problem that
will be addressed by multiple data connections, I don't see how
it will help availability.  Commands are only being sent on one
connection so if it fails there is no redundant path and we are back
to higher level software managing connections.  Exactly what the
other thread is arguing against.

     -David


julian_satran@il.ibm.com wrote:
>
> Dear colleagues,
>
> With all the heated debate about multiple vs. single connection a request
I
> made
> a while ago got no significant reply (neither for nor against).
>
> The request was to consider a proposal made by Kalman Meth to reconsider
> the asymmetric model with the addition of a path selection made by the
> initiator.
>
> This proposal allows removing the command counters - as commands use a
> single TCP connection. The single connection can also be a shared
> data+control connection.
>
> In case of multiple connection the data path to be used is selected and
> maintained until
> the command ends.
>
> Thanks,
> Julo