Subject: [rddp] Supertransport?

From: [email-masked]
Date: Wed, 16 Apr 2003 15:55:01 -0400

I'm pulling together a couple of related issues in a single response.

Dwight Barron asked:

> Does the existence of iSCSI markers and CRC create any more
> of a new supertransport protocol by overcoming the same
> limitations of TCP?

No - it's not an issue for iSCSI because iSCSI is unambiguously
a ULP and is not trying to provide a general data transfer mechanism
for use by unrelated protocols.  For example, HTTP over iSCSI makes
little to no sense.  In contrast, RDDP is trying to be a transport
"shim" that provides services to unrelated protocols - for example,
HTTP over RDDP does make sense when large amounts of data are involved.

Caitlin Bestler asked:

> > (1) The "proof" requirement that two communicating stacks can't get
> > confused about the format of communication applies to the entire RDDP
> > protocol stack running over TCP, not just the issue of whether a
> > modified vs. unmodified TCP is being used.
> 
> ULP responsibility for matching peers has been the rule for IP protocols
> throughout history.  Why the change?

What's actually changed here is the willingness to consider the
idea of a transport "shim".  ULPs currently unambiguously select
their transport protocol by causing selection of the IP protocol
number (e.g., TCP = 6, UDP = 17, SCTP = 132).  Two peers who are
confused at this level (e.g., TCP vs. SCTP) won't get very far
because IP protocol stacks tend to demux on the IP protocol number.

The idea of using another IP protocol number to unambiguously
indicate RDDP functionality has been overwhelmingly rejected by
the RDDP WG for reasons that we don't need to go back over here.
Among the reasons for the "proof" requirement is that rejection
of use of a different IP protocol number does not absolve the
RDDP WG of its obligation of ensuring that transport level
functionality is unambiguously selected.  ULPs will still need
to do peer matching above RDDP.

Also, as Jeff Mogul wrote:

	(This is a requirement because the IESG says it is a
	requirement; it doesn't matter what my personal technical
	judgement is, because the IESG has the last say.  I've
	been there before.)

But I do hope I've provided a little more insight ...

Thanks,
--David

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