Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

[Pierre Labat <pierre_labat@hp.com>]

"Mallikarjun C." wrote:

> To be fair to data SACK, one could think of an upper bound
> on the unack'ed data - agreed on at the login time.  While not
> requiring acks on every PDU, it gives targets the deterministic
> maximum on the buffer size they have to keep around if they
> choose to "reliably" support data SACK.  The current answer of
> "replay buffer size/IO size", IMHO, is simply not attractive.
> Also to be fair to data SACK, I believe FCP-2 allows sequence-level
> error recovery in an I/O.
>
> However, I think that it's extremely useful to include a discussion
> in the draft of  the TCP checksum "escape" statistics and the
> device types for which this was considered an absolute requirement
> to make forward progress at this error rates (like huge tape
> backups?) - essentially the reasons that convinced Julian to define
> this mechanism in. That gives credibility and acceptance to this,
> or alternately may lead to the consensus that data SACK is not required.
> --
> Mallikarjun

About  TCP checksum "escape" statistics what i saw is :

A) Jonathan Stone,Craig Partridge, "When the CRC and TCP Checksum Disagree"
 http://www.acm.org/sigcomm/sigcomm2000/conf/abstract/9-1.htm

1 escape in 200 millions

B) V. Paxson "1999 End-to-End Internet Packet Dynamics."
   http://www.aciri.org/vern/papers.html

 1 escape in 300 millions

C) J. Stone et. al "Performance of Checksums and CRC's over Real Data"
  IEEE/ACM Transactions on Networking, Vol. 6, No. 5, October 1998

http://dev.acm.org/pubs/articles/journals/ton/1998-6-5/p529-stone/p529-stone.pdf

Less than 1 escape in 10e17 segments when taking into
account the link layer AAL5 CRC. (see page 540 left column on top).




Taking the worst is 1 in 200 millions.

Regards,

Pierre