Subject: [rddp] Urgent discussion redirection

From: [email-masked]
Date: Wed, 4 Dec 2002 01:28:46 -0500

With WG chair hat firmly on and double entendre intended ...

... the current discussion of the Urgent pointer as an alternative
to markers needs to stop here and now.  There are several
reasons for this:

- I believe that the IESG rejection of the iSCSI proposal
	for this use of the Urgent pointer was categorical
	(i.e., don't use the Urgent pointer to solve this sort
	of problem) as opposed to specific to the iSCSI
	proposal.
- The Urgent pointer sure is an attractive nuisance, as it's
	diverted what was looking like a useful discussion of
	requirements and design rationale for markers into
	a discussion of an approach that won't pass muster
	at the IESG as things currently stand.
- If the Urgent pointer approach is to be resurrected, the
	WG will need to have a solid understanding of the
	requirements involved (and a seriously compelling case
	for why the Urgent pointer clearly the best solution).
	We don't have that level of understanding of the
	requirements at the present.

It may be possible to reconsider this cessation of
consideration of the Urgent pointer when where there
is an Internet Draft (probably an individual submission)
that contains a solid description of requirements for markers
and the design rationale for selection of markers over other
approaches (not including the Urgent pointer) that reflects
rough consensus of the WG in both areas.  Until then,
discussion of the Urgent pointer is at best a solution
in search of a problem, and a waste of time and list bandwidth.
Anyone who has a problem or concern about this should contact
me directly off of the list.

This cessation also applies to Push, and permanently in that
case, as Section 4.2.2.2 of RFC 1122 forbids use of Push as
a record marker.

We need to get back to the discussion of requirements and
design issues.  As a reminder, of the state of that discussion,
it was premised on the assumption that we could require TCP
senders to run in aligned mode.  I will send a separate email
on this with my WG chair hat off to avoid further confusion.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: David Borman <[email-masked]>
Date: Wed, 4 Dec 2002 12:10:02 -0600 (CST)

> From: [email-masked]
> Date: Wed, 4 Dec 2002 01:28:46 -0500 
> Subject: [rddp] Urgent discussion redirection
>
...

Perhaps that's a good thing. :-)  So, let me back up two steps.  The
first question that needs to be answered is:

	Is the spec going to explicitly sanction the processing
	of out-of-order TCP segments, and is there buy-in from
	the ADs, TSV and/or IESG?

If the answer is "no", then the discussion is done.  There is no
point in adding markers, discussing TCP Urgent pointers, forcing
alignment of data in packets, or any other schemes.  The data will
be processed in sequence, and the IFT proposal is much cleaner.
Actually, if you strip out markers, then the only real differences
between MPA and IFT is 1 vs. 2 CRCs, and whether or not the data
needs to be padded out.  (Probably not.  If you have markers, the
data has to be padded out to the size of the CRC to avoid a marker
landing in the middle of a CRC; so if you remove markers the only
reason for padding would be to aid in CRC calculation.)

If the answer is "yes", then the next question is how do you find a
DDP header in the out-of-sequence data that you trust is a valid
DDP header?  If you rely strictly on recognizing a DDP header
by scanning the data, then as has already been pointed out you
can get fooled by embedded DDP headers in the DDP payload.  So,
you need some additional out-of-band information to aid in the
identification of a valid DDP header.  That additional information
can be either explicit or implicit.  Using the TCP Urgent pointer
is an example of explicit OOB information.  Markers are a form
of implicit OOB information, in that the markers (and only markers)
are known to be embedded at regular intervals in the data stream.
Making assumptions about the alignment of data in packets is also
implicit OOB information.

Personally, I think that if you are going to allow the processing
of out-of-order TCP segments, then explicit OOB information that
can be easily ignored in the in-sequence case is the cleanest.
But that means putting it in the TCP protocol.  Using the Urgent
pointer is one way to do that, but I've been persuaded that it is
less than clean.  The cleanest way to do it would be to create a new
TCP option.  In either case, unaware middleboxes are much more
likely to break things.

So what you end up with is that you have to embed resyncronization
information into the TCP data stream and have implicit OOB information
about the location of that embedded information so that the remote TCP
can reach up into the TCP data segment of out-of-order TCP segments and
extract information about the resequencing point and use it to process
the out-of-order TCP segments.

Sound ugly?  But that's what markers in the MPA document do.

Is that going to pass muster any more than using the TCP Urgent
pointer or creating a new TCP option?

So, I guess I'm arguing that the processing of out-of-order TCP
segments should be dropped, because the only clean solution would be
to modify the TCP protocol to provide information to allow processing
of out-of-order TCP segments in a generic manner and use that, and
that is probably out of scope for this group.

		-David Borman, [email-masked]
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp