Subject: [rddp] RE: [Tsvwg] Concerns about SCTP

From: "Williams, Jim" <[email-masked]>
Date: Thu, 9 Jan 2003 14:36:49 -0500

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
>
> Therefore the challenge, whether over MPA/TCP and/or SCTP,
> is to ensure that the internal bandwidth required to support
> DDP placement will not be swamped by all incoming data.

I am repeating previous stuff here, so I will be brief.
But I think the above is not necessarily desirable.
Implementations may not be able to keep up with the 
link when average size of incoming packet is small.
For those that can, flow control is not an issue; simply
drop packets in the rare instance of buffer overflow.
For those that can't, flow control is an important
problem since incoming packet rate must be throttled to
below link rate, otherwise too many packets may need
to be dropped.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 12 Jan 2003 11:31:05 -0600

On 1/9/03, Williams, Jim wrote:

>> Therefore the challenge, whether over MPA/TCP and/or
>> SCTP, is to ensure that the internal bandwidth required
>> to support DDP placement will not be swamped by all
>> incoming data.
>

I believe the nature of an optimum push-based LLP / DDP
interface changes the dynamics of handling many small
packets.

With a non-DDP interface, small packets can result in a
temporary drop in the available resources. The
implementation can choose to release the unused fragments,
thereby consuming more CPU power and ultimately slowing down
the rate at which the ULPs drain the queue. Or it can stick
with a simpler allocation scheme, optimizing for faster
release of the entire buffer rather than partial release of
the unused portion.

When a large number of small messages arrive, there is more
fragmentation and less available CPU power or there is
wasted space (i.e. the system's capacity is best measured by
the number of packets, not number of bytes).

With non-DDP interfaces, there is typically a hold time on
these buffers. Data is not immediately transferred to the
ULP. Therefore the small-packet-stress induced state will
have a duration that could be long enough to warrant use of
LLP flow control.

An push-based LLP/DDP interface, by contrast, does not
require hold time. The DDP can be required to place the data
*immediately*, and to take note of completion status
immediately.

There can indeed be contention for the host memory bus. That
can lead to delays and even an overload of the host bus
capacity under worst case conditions.

However, I cannot see how such a condition could ever
sustain itself long enough to warrant use of LLP flow
control. The *maximum* delay through the host bus should be
magnitudes lower than the round-trip time over the network.

Basically, LLP deliveries to the DDP layer simply cannot be
held long enough to allow something as slow as LLP flow
control to work.

In the event that placement/completions cannot be delivered
to ULP memory quickly enough then packets will have to be
dropped. That is a given. But I cannot see how LLP flow
control can be applied to a situation where the resource
utilization duration is miniscule compared to the round-trip
time.

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