Framing Formats

[Black_David@emc.com]

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
---------------------------------------------------