Subject: [rddp] WG chair clarifications

From: [email-masked]
Date: Sat, 7 Dec 2002 00:13:26 -0500

Jim,

> The problem
> is that the WG Chair has tentatively rejected my proposal
> to preserve TCP semantics, and ruled in favor of modified
> TCP semantics that allow out of order data placement.  He
> has also come pretty close to rejecting MPA style markers as
> a mechanism to achieve this.  (Correct me if I am 
> wrong, David.)

I would describe the situation somewhat differently:
- I wouldn't describe the IFT "proposal to preserve TCP
	semantics" as "tentatively rejected".  At this juncture,
	neither our AD nor I are prepared to rule out changes
	to TCP, but any such changes are going to need
	compelling justification.  The overall theme is that
	TCP is demonstrably "not broken" and hence very good
	reasons are needed to "fix it".  IFT is definitely
	useful input at this point, but it's a bit early to
	predict to what extent it'll be in the WG output (and
	likewise for MPA).
- I don't consider out of order placement to be a change to
	TCP semantics as long as delivery is in order.  As
	discussed in the tsvwg Atlanta meeting, RFC 793 anticipated
	that implementations could share buffers between TCP and the
	"user", which could result in this sort of behavior
	 - see the last paragraph of the description of
	"Receive" on pp.48-49, and consider the "Don't Copy
	Data" recommendation in RFC 1122.
- I have yet to see adequate justification for MPA's
	specific marker design.  The general idea of markers
	is not an inherent problem, as a user of TCP is generally
	free to put whatever he/she/it <bleep> well pleases into
	the transmitted bytestream.  MPA proposes to use markers in
	concert with modifications to TCP to produce something
	that is claimed to be of somewhat general utility, and hence
	I think it's fair to hold its marker design decisions
	to a "compelling justification" standard similar to
	that for proposed TCP changes.

At the moment, I don't consider speculation about hypothetical
things that middleboxes could do to be "compelling justification".
If resegmenting middleboxes are going to be a major part of
the design justification, then the discussion will have to
cover what they actually do, where and why they do it,
and to some extent how many there are and likely rationale
for further deployment of them.  Let me suggest RFC 3234
on middlebox taxonomy and possibly RFC 3135 on performance
enhancing proxies as resources that may be useful in
exploring this area.

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