Subject: [rddp] Out of order TCP processing

From: [email-masked]
Date: Thu, 5 Dec 2002 00:45:08 -0500

David,

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

I believe that can be answered with a qualified "yes" based in part
on the discussion at the tsvwg meeting in Atlanta, and also on
the discussion of shared buffers in RFC 793.  The qualification
involves separation of placement (received bytes go into a buffer)
from delivery (that buffer is passed to the application or protocol
above TCP/MPA) - out-of-order placement is acceptable, but out-of-order
delivery is not, and the next version of the MPA draft will need an
explicit buffer ownership model and specification that forbids the
upper level app/protocol from looking at memory that may contain
placed data that has not been delivered.

While there is some degree of AD and TSVWG buy-in, I would not want
to characterize it as a blank check.  As I've said before, whatever
the WG proposes to do in this area will be held to a high technical
standard.

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

Viewpoint noted.

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