Subject: Re: R2TDataSN

From: [email-masked]
Date: Tue, 6 Mar 2001 03:40:57 +0200

Somesh,

1.The only consensus I heard is not to transfer a large amount of data with
one PDU.

2.With DatasN and Sack we dont need any data in a bad header.

3. If an R2T is lost (received at initiator with bad digest) - the
initiator will know that from
the next R2T if the target has several outstanding - very likely at long
distances - and will not have to way for a timeout.   Other uses are
marginal.  Basically it is "part of a command execution" and we can
painless recover
from failures for this case too.

Regards,
Julo

"Somesh Gupta" <[email-masked]> on 05/03/2001 20:40:06

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  R2TDataSN

> R2TDataSN
> ----------
> Sec 6.7.1 has some new content on how to handle lost R2Ts using
> SACKs.  But I noticed that the SACK request (Sec 2.16) has not
> changed to indicate whether the DataSN is a R2T DataSN or just
> a Read PDU DataSN (D bit)
> So do we demux on the read/write operation type?
> And how does this affect PDU loss in bidirectional commands ?
> +++ SACK is ascking for data (DataSN) the target knows
>

Julian,

Regarding the R2TDataSN, I have a comments and a
question.

I think that when a PDU header fails a CRC/checksum check etc,
it is a problem to depend on any information in the header (including
length fields), thereby making any further processing on
the connection unreliable.

What scenarios do you envision where the R2TDataSN is useful.
IN Orlando I think there was clear consensus that application
do not try to transfer very large amounts of data using a
single command.

Thanks,
Somesh

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 6 Mar 2001 07:23:04 -0800

I beg to disagree. If an R2T PDU (header) has bad digest, or any other
header has a bad digest - since you always need the PDU length from
the header, there is some uncertainty associated with further processing.

Are you proposing that the processing machine go into a "speculative"
mode where the processing of the next PDU determines whether we were
successfuly able to skip a bad PDU header? When there is a data digest
error, further stream parsing is deterministic. But not when the PDU
header digest error.

Also the consensus (in my interpretation) was on applications
not transfering very large amounts of data using a single command or
read/write PDU.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, March 05, 2001 5:41 PM
> To: [email-masked]
> Subject: Re: R2TDataSN
> 
> 
> 
> 
> Somesh,
>

---

From: "Venkat Rangan" <[email-masked]>
Date: Tue, 6 Mar 2001 10:00:09 -0800

Somesh,

> When there is a data digest error, further stream parsing is
> deterministic. But not when the PDU header digest error.

Isn't it true that with Synch and Steering layer, you are able to skip past
PDUs with header-digest errors and reach a point where you can begin
deterministically processing the stream? (assuming that the headers used for
Synch and Steering are in-tact).

Of course, in the event that this option is "negotiated out" you don't have
this ability.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Somesh Gupta
Sent: Tuesday, March 06, 2001 7:23 AM
To: [email-masked]; [email-masked]
Subject: RE: R2TDataSN

---

From: "Somesh Gupta" <[email-masked]>
Date: Tue, 6 Mar 2001 10:20:56 -0800

Venkat,

You are right but this does put some additional requirements
on the sync and steering layer (assuming we can agree on one
and that it is not optional).

Consider the marker mechanism as an example. If the marker
falls within the TCP byte stream region which contains the
header, and the header digest fails, then do you trust this
marker or skip to the next marker. Or do we need a sum on the
marker itself.

We do have various recovery mechanisms in the protocol without
detailed state machines or other documentation to make sure
that the mechanisms are really robust and worth including. And
even more important, that we will have interoperable
implementations that are implemented to the standard (rather
than being compliant with some defacto implementation)

I am not saying that these tools do not work, and Julian
(and other smart people)may even have worked them out.
However, the proof is not in the document.

Thanks,
Somesh

> From: Venkat Rangan [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 10:00 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: R2TDataSN
>
>
> Somesh,
>

---

From: "Venkat Rangan" <[email-masked]>
Date: Tue, 6 Mar 2001 17:07:57 -0800

Somesh,

Thanks for your insights.

> marker or skip to the next marker. Or do we need a sum on the

You point out one of the disadvantages of the current marker
approach. In this respect, the word-stuffing proposal as described
in draft-weber-fcip-encaps-00.txt is a better message boundary
identification approach. One key point you bring up is if there
is just a two-bit burst error with one bit on the Header
and the other bit on the Synch-and-Steering header, you've lost
a reliable way of synching to any part of the stream. This is
possible because the Synch-and-steering header can be right smack
in the middle of an iSCSI header. You may also have cases where the
two copies of the Next-iSCSI-PDU-start pointer disagree on
where the next pdu starts. What then?

With constant-overhead-word-stuffing, all is not lost if the synch
words get corrupted - you skip over enough words in the stream
until you find one to synch with. Also, you do not have nearly
the level of with UFL mentioned in section 1.2.8.3 of the
draft. I don't remember all the technical discussion that went
into the selection of current Synch-and-steering, but it does
seem to have some weaknesses.

Regards,

Venkat Rangan
Rhapsody Networks Inc.

---

From: Matt Wakeley <[email-masked]>
Date: Wed, 07 Mar 2001 15:46:10 -0800

> 1.The only consensus I heard is not to transfer a large amount of data with

Ok, then why do you have "Long Data Header" in the document?

-Matt