Subject: RE: [rddp] SCTP mapping - Multiple Streams

From: "Williams, Jim" <[email-masked]>
Date: Wed, 5 Mar 2003 10:00:18 -0500

Randall Stewart wrote:
> Caitlin Bestler wrote:
> > From there you need to perform per-stream processing.
> > This is a simple lookup within the context of the already
> > found association. This is the *only* step that having a
> > one-association / one-stream pairing would save.
> > 
> > Meanwhile it would avoid savings in association setup
> > (a four-way handshake), Acks (the overhead of which could
> > be shared with multiple  streams) and congestion control
> > (each stream would have to do its own slow start).
> > 
> > [1] An established association is where the performance
> > issues are most important. Matching an incoming SCTP packet
> > during association setup and teardown is more complex, as
> > is currently being discussed in the sctp-implementors list.
> >  
> 
> Another savings would be the amount of state.. A SCTP
> association (or TCP connection for that matter) is a
> fairly heavy weight thing.. it takes memory to hold
> all of that state blob that makes up the association/connection.
> On the other hand, each stream usually takes around 8 - 16
> bytes (depending on the implementation.. and I bet you
> could get it real low if you had the unordered optimization
> you mention previously)... As such this is much smaller
> than having N * sizeof(tcb) connections... Quite a
> signifigant savings...

I think you present some of the design tradeoffs and there's
certainly merit in what you say.  I might tend to evaluate
the tradeoffs a bit differently, but fortunately we don't
need to resolve that as implementations may choose different
paths.  Reasonable people can differ on this (and unreasonable
people like me can really differ :).

I would suggest the following thought experiment as an
interesting diversion if nothing else.

   Assume that the cost of de-referencing any pointer
   is (1000 + N), where N is the size in bytes of the
   object which is pointed to.  If the object is variable
   size,  then N is the maximum size the object is
   allowed to have, not the actual size.  Once the cost
   of resolving the pointer is paid, computation using
   the contents of the object, and modification of
   the contents of the object are free.

   Subject to the above, think about what the minimum
   cost implementation of SCTP would look like.

The above is certainly a gross oversimplification
of the behavior of hardware accelerated protocol
processors, but gives some flavor of the differences
from traditional software implementations.  It also
might give some clue as to why I have raised the
issues that I have.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 5 Mar 2003 10:52:24 -0600

On 3/5/03, Williams, Jim wrote:

>> > This is a simple lookup within the context of the
>> > already found association. This is the *only* step
>> > that having a one-association / one-stream pairing
>> > would save.
>> > 
>> > (a four-way handshake), Acks (the overhead of which
>> > could be shared with multiple  streams) and congestion
>> > control (each stream would have to do its own slow
>> > start).
>> > 
>> > [1] An established association is where the
>> > performance issues are most important. Matching an
>> > incoming SCTP packet during association setup and
>> > teardown is more complex, as is currently being
>> > discussed in the sctp-implementors list.
>> >  
>> 
>> fairly heavy weight thing.. it takes memory to hold all
>> of that state blob that makes up the
>> association/connection.
>> On the other hand, each stream usually takes around 8 -
>> 16 bytes (depending on the implementation.. and I bet
>> you could get it real low if you had the unordered
>> optimization you mention previously)... As such this is
>> much smaller than having N * sizeof(tcb) connections...
>> Quite a signifigant savings...
>
>I think you present some of the design tradeoffs and
>there's certainly merit in what you say.  I might tend to
>evaluate the tradeoffs a bit differently, but fortunately
>we don't need to resolve that as implementations may
>choose different paths.  Reasonable people can differ on
>this (and unreasonable people like me can really differ :).
>

OK, let me be more explicit about the degreee of
optimization that is possible. The SCTP overhead per
stream for a DDP-apapted association can in fact be
as low as zero.

DDP produces only Data Chunks which are:

-- complete, both the B and E bits are set.
   All fragmentation is either performed at the DDP
   layer or at the IP layer. Each SCTP Data Chunk
   represents a complete DDP Segment.
-- unordered

Therefore the SCTP layer can always deliver the Data
Chunk to the LLP immediately. There is no per-stream
processing or reordering required. The Stream ID is
essentially nothing more than pass-through ULP data.
(With the execption that the sender MAY perform some
form of fairness allocation across streams).

The 8 to 16 bytes that Randall referred to are only
needed to support ordered delivery. Any implementation
that defers creation of this data until a stream is
actually used will have *zero* SCTP overhead from the
mere existence of a stream. 

More importantly, whether or not the data structure to
support ordering for stream X exists, there is no need
to consult it when placing unordered data for stream X.

The bottom line: for placement of unordered data chunks
the Stream ID has no signifigance to the SCTP layer.
It is merely passed through to the DDP receiver.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp