Re: R2TDataSN

[julian_satran@il.ibm.com]

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" <someshg@yahoo.com> on 05/03/2001 20:40:06

Please respond to someshg@yahoo.com

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
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