Subject: [Tsvwg] Future of TCP and SCTP

From: "Uri Elzur" <[email-masked]>
Date: Wed, 20 Mar 2002 13:47:28 -0800

1) In the ROI BOF yesterday, a statement has been made that "SCTP is a main
stream Transport protocol" and that RDMA/DDP mapping to SCTP, will encourage
application use of SCTP in the future. 
 
SCTP is not immune from IP packet drops and out-of-order reception, hence,
like TCP a high speed flow-through NIC would either buffer out-of-order
packets (expensive and not scalable at 10 Gbps and beyond) or place data
out-of-order but indicate to ULP in order. (side comment: it seems to be a
discussion on RDMA list, whether SCTP even provides the hints to the
Receiver to enable placement of out-of-order data or buffering is required
in any case)
 
2) TCP = Protocol of the past ??? TSVWG agrees there is value in framing TCP
as evident by admittance of draft-ietf-tsvwg-tcp-ulp-frame-00. However, a
single bit in the TCP header or a TCP option, that could have been used to
make it simple, are "reserved for future use"
 
What is the future direction for TCP? Isn't SCTP the future?
 
Sorry if I missed something
 
thx
 
Uri

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 20 Mar 2002 17:19:15 -0800

Uri,

See comments interspersed-

On March 20, 2002 1:47 PM Uri Elzur ([email-masked]) wrote:
>
> 1) In the ROI BOF yesterday, a statement has been made that "SCTP is a
> main stream Transport protocol" and that RDMA/DDP mapping to SCTP, will
> encourage application use of SCTP in the future.
>

When SCTP is used in the unordered mode, there is no buffering required in
the event of packet loss.  In this case it is immune from required buffering
in such events and would be very suitable for high speed data processing.
Hints are provided by the DDP shim that sits above SCTP as defined in the
specification written by Randall and myself.  Although this draft is about
to change to include a TLV style structure similar to SCTP for immediate
data needed by RDMA, this does provide requisite hints needed for any
reception order direct placement.

> 2) TCP = Protocol of the past ??? TSVWG agrees there is value in framing
> TCP as evident by admittance of draft-ietf-tsvwg-tcp-ulp-frame-00.
However,
> a single bit in the TCP header or a TCP option, that could have been used
> to make it simple, are "reserved for future use"

This TUF draft is not a standards track as I understand.  This draft also
has problems yet to be resolved.  In addition, it does not address improved
error handling.  Making new use of the TCP header bits may find such changes
highly detrimental to existing install base or simply not function.  If you
find a problem with SCTP, there is a much greater likelihood of it being
resolved.  The same is not true for TCP.  The IETF has strongly recommended
SCTP for this type of application.  DDP needs idempotent packets provided by
SCTP.

> What is the future direction for TCP? Isn't SCTP the future?

TCP has a future as TCP.  SCTP has a future as SCTP.  They have different
features where SCTP fulfills DDP needs where TCP supports legacy.  SCTP can
be adapted to handle TCP protocols however.  The SCTP-DDP draft helps with
partial write issues as example.

> Sorry if I missed something

If it were up to me, I would have booted this camel's nose from under the
tent.  Thanks for the soapbox.

Doug

> Uri

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 20 Mar 2002 16:09:12 -0600

Uri:

Some in-line comments for you to consider..

> Uri Elzur wrote:
> main stream Transport protocol" and that RDMA/DDP mapping to SCTP,
> will encourage application use of SCTP in the future.
> 
> SCTP is not immune from IP packet drops and out-of-order reception,
> hence, like TCP a high speed flow-through NIC would either buffer
> out-of-order packets (expensive and not scalable at 10 Gbps and
> beyond) or place data out-of-order but indicate to ULP in order. (side
> comment: it seems to be a discussion on RDMA list, whether SCTP even
> provides the hints to the Receiver to enable placement of out-of-order
> data or buffering is required in any case)

Well this is true only if you are fragmenting packets at the SCTP
layer. This is the minor issue that David Black talked about in
his presentation. Basically if SCTP fragments say a 8k send into
8 1k packets... the first packet would have the BE bits set to "B".
This would tell DDP that it can find its placement information in
the header and thus find the buffer... however the issue is if 
the second packet (call it TSN 2) is dropped.. when TSN 3 arrives
in the third packet there is NO way to tell where in the buffer
that you are placing this fragmented message that TSN 3 goes.. since
the size of TSN2 is unknown (it could be guessed but this is
difficult).

Now an alternative EASY fix for this is NEVER fragment at the
SCTP layer. You enable the option in the sockets api that turns
OFF SCTP fragmentation and will instead give an ERROR back to
the ULP if it try's to exceed the fragmentation size. Thus
ALL packets would arrive with the BE bits set to 1 (both bits)
and thus EVERY packet would have a DDP header that could be
USED by the NIC to steer the data to the correct memory location.

This would then effect that packet drops would require NO buffering
on the NIC and instead any data arriving at the NIC COULD be
directly steered to a user buffer (if that is what the RDMA layer
is doing)...

Hope this helps a small bit in showing you how easy it is
to DDP/Frame SCTP :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)