No subject

various off-loading of record exchanges, the prospect of holding a partial
packet due to lack of physical frame alignment is unacceptable.  The amount
of memory available within an ASIC is limited to about 64K bytes or less
otherwise the yields become unacceptable due to the growing die size.  This
on-chip memory however offers the speed needed to buffer the high data rates
seen in these new levels of performance demanded.  If you allow a partial
packet, you will require a bit less than 2 x packet size x number of
concurrent exchanges.  Anyone designing an ASIC will balk at that as they do
not know the number of concurrent exchanges.

The types of off-loading also has an impact on the transport conventions or
standards in addition to this record alignment requirement.  The API for
SCTP allows for the API to signal when a record size violation is made to
allow an immediate correction at the sender.  SCTP also allows pulling back
data if there is a problem.  TCP has served well as a byte stream transport.
I suspect SCTP will serve well as a record transport for these new off-load
engines.  Why must there be a conversion of TCP into an aligned record
transport?  Isn't that why they developed SCTP?

Doug

>
> Hi Mike,
>
> I hope this e-mail can respond to a couple of your very good and
> thought-provoking points.
>
> I'll use the term upper-layer protocol (ULP) to talk about the protocol
> riding on top of TCP. Some examples of ULPs include iSCSI, SSL, NFS, and
> RDMA.
>
> There are two properties we were looking to get from TCP:
>
> 1) finding NLP message boundaries in segments received out-of-order
>
> This involves having some signalling discipline for message boundaries.
>
> There are several ways other than the one we proposed of providing this
> property (including techniques that do not modify the TCP sender). These
> include having  a header periodically in the TCP stream (say every 1000
> bytes) or a byte-stuffing technique like COBS.
>
> 2) application messages not spanning segments
>
> This simplifies the receiver as it does not have to deal with cases where
> ULP headers span segments or
> where ULP datagrams are broken across TCP segments.
>
> I don't believe that property #2 can be had without modifying the
> TCP sender
> a la the proposal presented.
>
> -----------
>
> One could question how critical property #2 is. After all, if
> stuff arrives
> mostly in order except for the occasional drop, you can keep a bit of
> application state from packet to packet. I would still argue that property
> #2 makes life on the fast path a good deal easier for the receiver.
>
> -Costa
>
>
>