Re: ISCSI: Urgent Flag requirement violates TCP.

[Matt Wakeley <matt_wakeley@agilent.com>]

Black_David@emc.com wrote:

> A disk drive that does that strikes me as broken.  Abort means abort - to
> claim that
> a command could not be aborted and then complete it successfully sounds like
> a bug, not a feature.

I didn't say that the status for the abort commmand indicated that it was not
aborted.  It could have sent it back immediately indicating "yep, ok, I got it
and will abort".

>
>
> > > FWIW, this can't happen in Fibre Channel because the completion of A
> > > won't be retransmitted.
> >
> > It won't be retransmitted, but it could get re-ordered in the FC traffic,
> so the FC software/firmware also has to deal with it.
>
> Not likely.  On a single connection, there is virtually no FC switchgear out
> there
> that will reorder frames.  Given the increasing scale of FC, we'll doubtless
> see
> routing update effects among FC switches that will lead to reordering in a
> fashion
> similar to IP, but one just does not see reordered FC frames in current
> deployments
> due to conservatism about both scale and configuration management.

Like you said, you don't see it in FC today because there are just little
"islands" of FC lans deployed (so far).  Once these islands grow into continents
or are bridged via WANs (as is proposed by FCoverIP), you'll see a lot more
re-ordering.  Robust implementations need to handle this.


> What's the gain from introducing this additional non-determinism to the
> system?

Less buffering (lower cost) in hardware based or accelerated TCP/iSCSI
implementations, less latency.

> --David

-Matt Wakeley
Agilent Technologies