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

[Robert Snively <rsnively@Brocade.COM>]

The Stone and Partridge paper is mostly not applicable to an iSCSI
environment.  The principal failure mechanisms were major software
bugs in the driver stack of PC-oriented machines.  Such software
bugs would quickly be rung out in any iSCSI host driver and in
any iSCSI target and would certainly not exist in an enterprise
environment.  The 1 in 10 billion range is the more likely
environment.

Bob

>  -----Original Message-----
>  From: Jon Hall [mailto:jhall@emc.com]
>  Sent: Monday, April 02, 2001 2:49 PM
>  To: ips@ece.cmu.edu
>  Subject: Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
>  
>  
>  
>  I thought (?) Stone and Partridge concluded somewhere in the
>  range between one packet in 16 million to one packet in 10
>  billion.
>  
>  But, what percent of an iSCSI flow is comprised of iSCSI pdu
>  headers?  Is there a credible flow model for deciding the
>  probability of the one packet containing a StatSN?
>  
>  -Jon
>  
>  Pierre Labat writes:
>  >"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