RE: iSCSI spec qs.

[julian_satran@il.ibm.com]

Nimesh,

There where long and hot debates about why this is needed and how it should
be achieved.
On the mailing archives you will find docs describing in some detail the
rational (there is a ID by Randy Haagens and an older memo I wrote on
www.haifa.ibm.com/satran/ips)
I'll certainly do a bad job trying to summarize all that went on in half a
page but I am sure you will find searching through the archive rewarding.
Look for the words framing and RDMA.

If you still feel that you need explanations please give me a call next
week.

Regards,
Julo

"Nimesh Ray" <nimesh@confluencenetworks.com> on 20/03/2001 19:58:46

Please respond to "Nimesh Ray" <nimesh@confluencenetworks.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  RE: iSCSI spec qs.




Hello Julian,

I am still not sure what value add is provided by the Synch and Steering
model.

1. Does it avoid allocating any memory for assembly at the TCP layer ? If
so, how would TCP recover lost packets ?

2. Does this require modifications to the "legacy TCP implementations" ? If
so, what are the modifications required ?

3. How does the synch and steering layer help according to the proposal ?
You would still need to allocate the buffers at the Synch and steering
layer
to provide redundant functionality that is already provided by TCP.

The way I think of TCP is a dedicated, reliable connection. What you send
at
one end is what you get at the other end with all packet recovery taken
care
of at the TCP layer. So, in that case, iSCSI message framing is not an
issue.

Thanks for your input..

Regards,

Nimesh



-----Original Message-----
From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
Sent: Friday, March 16, 2001 2:29 AM
To: Nimesh Ray
Subject: Re: iSCSI spec qs.




There issue is for both TCP and iSCSI. If you are building adapter that
have to place
the data somewhere and data arrives out of order you have to place it
somewhere (even if you don't deliver it). That may be the final destination
or some temporary memory.

In the later case you will have:

1- to provide large amounts of temporary memory (possibly on the card)
2-copy data later

Both are expensive and should be avoided.

Regards,
Julo

"Nimesh Ray" <nimesh@confluencenetworks.com> on 15/03/2001 22:47:57

Please respond to "Nimesh Ray" <nimesh@confluencenetworks.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI spec qs.




Hello Julian,

This is in reference to the iSCSI spec section 1.2.8 Message
Synchronization
and Steering. The following statement in section 1.2.8.2 page 21.

"On the incoming path, the Synch and Steering layer extracts the Synch &
Steering information from the TCP stream. Then it helps deliver (steer) the
data stream to its final location and/or recover iSCSI PDU boundaries when
some TCP packets are lost or received out of order"

Seems like the assumption above is that you can receive packets out of
order
or lose packets if you are a client of TCP. Now as far as my understanding
goes, TCP guarantees in-order and in-sequence guaranteed delivery of
packets
to the clients of TCP, in this case iSCSI. So, the receiver of the message
should see exactly what the sender sent, with all the error recovery of
lost
packets done by the TCP layer. I believe that is exactly the rationale that
went into selecting iSCSI over TCP.

So, unless there is something else I do not understand, the "Synch and
Steering" layer above TCP is not needed.

Could you please clarify on this ?

Thanks,

Nimesh