RE: iSCSI ERT: open issues list#1

[julian_satran@il.ibm.com]

Somesh,

This reminds me that when we first started considering ordering in its
different flavors i briefly considered a dual numbering scheme global and
per connection with the global meant for command ordering  and the per
connection meant for an completely ordered delivery per connection above an
imperfect TCP.
On my notes only 2 lines appear on "why rejected":

1-unneeded serialization of delivery when commands are already executed
2-obviously bad interaction with TCP

It took me yesterday some time to recall the "obvious" - and, like in the
joke, it is obvious!

The ordering over TCP has appeal when done underneath iSCSI as it makes
iSCSI a safe transport in no need for other recovery within a connection.
However in order for it to work it has to have:

- either have a buffer larger that an the one implied by the RTT to keep
the TCP window from blocking when a failed piece is retransmitted
- or drop every piece of information after a failure - i.e. same behavior
as a connection drop

If you attempt this scheme not as a "safety layer underneath iSCSI" i.e.
deliver the numbered pieces
to iSCSI and have it make something out of the numbering then the effect of
unwanted serialization becomes dramatic (as you are unaware of the position
of the missing piece in the puzzle you will have to stop many activities -
even unrelated) and the recovery is not simpler than in the schemes we
have.  A good example is to compare what will happen if you have several
tape writes and a piece of data is dropped in this scheme vs. the
per/command numbering we have in the current draft.

However within the recovery team we will reexamine this scheme and other
versions during this (it has already started for me!) week.

Regards,
Julo

"Somesh Gupta" <someshg@yahoo.com> on 03-05-2001 20:51:00

Please respond to someshg@yahoo.com

To:   Julian Satran/Haifa/IBM@IBMIL, cbm@rose.hp.com
cc:   cbm@rose.hp.com, someshg@yahoo.com, venkat@rhapsodynetworks.com,
      steph@cs.uchicago.edu, ldalleore@snapserver.com, Black_David@emc.com,
      John Hufferd/San Jose/IBM@IBMUS
Subject:  RE: iSCSI ERT: open issues list#1




BTW,

The interim meeting approved a requirement stating (I am
paraphrasing it - hopefully correctly)

iSCSI provides an ordered transport, even in the presence
of errors i.e. iSCSI provides an ordered transport without
excuses.

This would seem to have an impact on the protocol and the
way we handle errors.

Somesh

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Thursday, May 03, 2001 12:27 AM
> To: cbm@rose.hp.com
> Cc: cbm@rose.hp.com; someshg@yahoo.com; venkat@rhapsodynetworks.com;
> steph@cs.uchicago.edu; ldalleore@snapserver.com; Black_David@emc.com;
> hufferd@us.ibm.com
> Subject: Re: iSCSI ERT: open issues list#1
>
>
>
>
> Mallikarjun,
>
> Can we schedule a conference call on Monday  9:30 AM PDT (7:30 PM IDT)
to
> help us close whatever is still open?
> Can you do it?  (this way only I will pay transatlatic rates :-))
>
> Thanks,
> Julo
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com