On Tue, 2005-03-29 at 17:03, Rick Jones wrote:
> Eventually the TCP will hit its RTX limit and punt the connection, freeing
> buffers kept for retransmission right?
If i read correctly the people arguing for iscsi say thats not good
enough. But they may be having other issues too...
> > On a slightly related topic: is SCSI (not iscsi) considered a reliable
> > protocol?
> > If yes, why would you wanna run a reliable protocol inside another
> > reliable protocol (TCP)?
> Isn't it better to consider TCP a protocol that provides reliable notice of
> (presumed) failure rather than a "reliable protocol?"
You could if the parameters are adequely set (i think).
If both are reliable protocols then they would both have the standard
features and parameters:
- transmit (for simplicty assume window of 1)
loop for X times
- compute next retransmit time, Y, using some algorithm
- wait for ACK
so parameters X and retransmit time is where the conflict is.
If TCP is eagerly retransmitting a lot of bandwidth could be
wasted. if SCSI has X as infinite even more interesting things
In any case i have seen horror stories of what happened to people
who tried to encapsulate an already reliable protocol inside TCP in
order to ship it across the big bad internet. I am pretty sure some
knowledgeable people were involved in getting iscsi going so it cant be
that simple. It would seem preferable to use SCTP instead.