RE: Framing Formats

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Framing is not intended for error recovery.  See the discussion in the iSCSI
requirements draft and on Julian's web site
http://www.haifa.il.ibm.com/satran/ips/Randy-Haagens-Framing_r1.pdf

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Rod Harrison [mailto:rod.harrison@windriver.com]
> Sent: Tuesday, July 10, 2001 12:42 PM
> To: ips@ece.cmu.edu
> Subject: RE: Framing Formats
> 
> 
> 
> 	Byte stuffing will kill the performance of software
> implementations.
> 
> 	Do we really believe re-synching in this way is necessary?
> Remember that the host SCSI layer will retry failed
> commands. I believe we will see error rates low enough to
> make pushing recovery back onto the host a viable solution.
> 
> 	- Rod
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On
> Behalf Of
> Mike Parkhurst
> Sent: Tuesday, July 10, 2001 6:24 PM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> Subject: RE: Framing Formats
> 
> 
> In my previous posting I was referring to the TCP-unaware
> variety. At
> the heart of the matter is whether we trust the underlying
> transport
> mechanism or not. If we don't, then there has to be some
> sort of
> error-recovery procedure for when information/data is lost
> in transit.
> If we do trust it, then the iSCSI specification is
> simplified and we
> assume that the protocol is riding on an error free link.
> 
> But to go back to the point of this thread....
> 
> Byte and word stuffing mechanisms have been proven to work
> for many
> years. Picking a 32 bit number reduces the chances of it
> showing up in
> the data stream. Even if it does the stuffing mechanism
> would mask it.
> 
> Mike
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]
> On Behalf Of
> Black_David@emc.com
> Sent: Tuesday, July 10, 2001 7:07 AM
> To: Julian_Satran@il.ibm.com
> Cc: ips@ece.cmu.edu
> Subject: Framing Formats
> 
> NOTE: iSCSI tag removed because there's FCIP-related
> material in this message.
> 
> > We don't want this thread to be started again in this
> forum.
> > For anything related to framing go to the TSWG or to the
> RDMA mailing
> list.
> 
> I think Julian may have jumped for that conclusion a little
> too quickly.
> Certainly, there are topics that belong on those mailing
> lists:
> 
> - TCP-aware framing mechanisms are in the domain of TSVWG.
> Use
> 	of URG and PSH for framing is not going to happen.
> - RDMA mechanism discussions belong on the RDMA list - this
> 	is not an official IETF list.
> 
> Beyond these, there are a couple of topics that are fair
> game
> for the IPS list:
> 
> - TCP-unaware framing mechanisms intended for specification
> as
> 	part of an IPS protocol; this includes markers, as well as
> 	the synchronization recovery mechanism proposed for FCIP.
> - Discussion of appropriate requirements (e.g., should
> markers
> 	be specified as "MUST implement" with some additional
> 	rules about which end of a connection controls their
> 	usage on what traffic?).
> 
> The requirements issue is definitely an open issue at this
> point
> in time.  As for alternatives to markers, a fairly high
> level of rigor
> will be expected of approaches that scan data looking for
> some
> distinctive pattern - it basically needs to be the case that
> this
> sort of scan and detect algorithm cannot get confused by any
> pattern appearing in a data payload (read or write data for
> iSCSI).  A motivating example to think about is where trace
> data that includes the distinctive pattern (e.g., from a
> sniffer)
> is being written to or read from a file.
> Byte and word stuffing mechanisms to ensure that
> the pattern the algorithm is looking for can't appear in
> data
> are one way to accomplish this, but there are others.
> 
> While I'm on this topic, let me note that the algorithm in
> Annex A of the -03 FCIP draft does not meet this "cannot
> get confused" criterion.  For FCIP, it is possible to meet
> this criterion without resorting to stuffing techniques -
> the
> basic idea is to scan enough incoming data so that there
> have to be valid headers in there, note every possible
> header found, and their relationships based on length
> fields.  If the resulting situation is ambiguous/confusing,
> restart and/or abandon the attempt to re-establish
> synchronization.  A considerably improved algorithm
> should appear in the -04 version of the FCIP draft based
> on some offline discussion with some of the draft authors.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
>