Subject: [Tsvwg] FW: I-D ACTION:draft-culley-iwarp-mpa-00.txt

From: [email-masked]
Date: Wed, 18 Sep 2002 10:25:50 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 18, 2002 7:56 AM
Subject: I-D ACTION:draft-culley-iwarp-mpa-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Marker PDU Aligned Framing for TCP Specification
	Author(s)	: P. Culley et al.
	Filename	: draft-culley-iwarp-mpa-00.txt
	Pages		: 31
	Date		: 2002-9-17
	
A framing protocol is defined for TCP that is fully compliant with 
applicable TCP RFCs and fully interoperable with existing TCP 
implementations. The framing mechanism is designed to work as a 
'shim' between TCP and higher-level protocols, preserving the 
reliable, in-order delivery of TCP while adding the preservation of 
higher-level protocol record boundaries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-culley-iwarp-mpa-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-culley-iwarp-mpa-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-culley-iwarp-mpa-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Wed, 18 Sep 2002 10:25:53 -0400

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Sep 2002 22:56:00 -0700

> higher-level protocol record boundaries.

Seems like we've seen this (or something very close) before. I'll repeat 
the question I asked then: why not use SCTP?

Joe

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 00:28:59 -0600

Joe,

I too would like to hear the answer to that question.

Certainly SCTP supports DDP approaches quite nicely.  It does
not permit DDP to place out of order DATA chunks into the ULPDU
directly, but it is far easier to describe a mechanism for SCTP
(e.g, extension for ULPDU offset in DATA Chunk header) than for
TCP to acheive this.  Then there are all the other advantages
that the application would get from SCTP as well.

So, I reiterate as well: why not use SCTP?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: allyn <[email-masked]>
Date: Thu, 19 Sep 2002 10:51:40 -0700

No reason not to use SCTP, to the contrary, every reason to use it. The 
RDMA protocols - DDP and RDMA protocols are to be transport independent and 
there is to be a mapping to both SCTP and to TCP. The MPA draft is for 
framing to allow mapping to TCP.
What do you think about the details of the proposal?

Allyn

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Sep 2002 12:02:07 -0600

Allyn,

Hmmm.  I did not see SCTP in the draft.  Is there a draft for SCTP?
The TCP version looks like very serious changes for little to no gain
with possible impacts on both host and network performance.  SCTP, on
the other hand, does this all day long.

--brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 19 Sep 2002 11:17:35 -0700

allyn wrote:
> RDMA protocols - DDP and RDMA protocols are to be transport independent 
> and there is to be a mapping to both SCTP and to TCP. The MPA draft is 
> for framing to allow mapping to TCP.

I have the same concerns the last time I saw this sort of thing:

- TCP semantics change:
	consider a sequence of FPDUs (or in TCP, segments) sent:
	1,2,3,4
	and let '2' be dropped by the channel.

	now close the connection.

	what does the receiver pass to the application?
	- in TCP, only 1

	- in this (not-TCP), 1,3,4

- once the semantics change, it's not TCP
	having dual stacks (TCP and not-TCP), and using
	a handshake to pick between them doesn't make
	the protocol "interoperable"

	if you want different semantics, use a different
	transport protocol number.

- not-TCP specifies PDU sizes that cause problems
	in particular, TCP uses the interface MTU or path MTU
	as the unit of both transmission and congestion control.

	this uses the application PDU as the unit in both cases.

	this implies that:
	- IP fragmentation will be more likely to occur, and all
	the copy avoidance and direct data placement desired at the
	TCP layer will be obviated by the copying now occuring during
	IP reassembly.

	- not-TCP won't be able to retransmit the portion actually lost;
	instead, it'll retransmit the entire FPDU.

	- not-TCP will adjust its congestion window in larger chunks
	than TCP, potentially swamping competing TCP flows.

(not intended to be a complete list, but a start)

Joe