Subject: Re: [Tsvwg] SCTP: new chunks definition

From: Caitlin Bestler <[email-masked]>
Date: Mon, 02 Mar 2009 08:30:47 PST

>On Mon Mar  2  7:22 , Michael Tüxen <[email-masked]> wrote:On Mar 2, 2009, at 4:11 PM, Caitlin Bestler wrote:
>
>> Michael Tüxen wrote:
>>> Hi Andrey,
>>> first question: Why would you like to have such a mechanism?
>>> Best regards
>>> Michael
>>
>> Having a "V-Tag" that unambiguously identified an association would
>> benefit any form of SCTP-aware network adapter.
>Not sure if you really need "unambiguously". For example if you want
>to use it for a hash table lookup, you must deal with the case
>of multiple entries in the hash bucket anyway. So I do not this
>you get much.

You are assuming that a hash table is relatively free. On a host processor
this is very close to true, especially when the average alias chain is very short.
Having the INIT *seek* to give out only V-Tags that are not already in use
will generally achieve this, without *committing* a resource. Actually
committing a resource is, as you point out, not a good idea.

While working on several different TOE devices, I've speculated on what it
would take to have them support SCTP associations. (Speculation, unfortunately,
because of the nasty chicken-and-egg problem that adding SCTP assist cannot
be done until more people use SCTP, and why should more people use SCTP if
TCP gets all of the hardware assists).

Anyway, what you need is to be able to identify the connection/association/whatever
using on-adapter memory (which is very limited) or a *single* reference to host memory.
If you have to chase a chain of aliases to get the association, then your worst case
gives far worse, and new frames may arrive at any moment. The same risk of being
rear-ended by the next frame applies to tree-based searches as well. The round-trip-time
of accessing off-Adapter memory does not scale as network speeds increase, and any
use of external memory adds to latency which may well undermine any benefits from
the Adapter-based offload you were attempting to implement. Adapter-based recognition
of connections/associations must be very inexpensive or it will not exist at all.

So yes, an unambiguous V-Tag would be worthwhile. The only question is how often
it would be worthwhile and how it compares with workarounds that can be done without
modifying any SCTP specifications.

>On the other hand, when you get an INIT and you choose a v-tag
>and it has to be "unambiguously", then you need to mark it as
>used. This would mean a state change on the reception of an INIT,
>which is not a good thing...
>So I think having a good random generator is the best for an
>end-point.
>

Yes, it is important that any optimized V-Tag still be uniformly
distributed over the entire legal range. You don't eliminate doing
a hash on the V-Tag, merely the possibility of collisions. If this
concept proceeds as an I-D it should be clear on that point.

>Thinking about NAT boxes, you have to deal with collisions. But
>this is described in our NAT ID....

NAT boxes have copious memory compared to an Adapter, particularly
one that is integrated with the Systems Chip or on the motherboard.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 2 Mar 2009 18:08:29 +0100

On Mar 2, 2009, at 5:30 PM, Caitlin Bestler wrote:
>
>> On Mon Mar  2  7:22 , Michael Tüxen  
>> <[email-masked]> wrote:On Mar 2, 2009, at 4:11  
>> PM, Caitlin Bestler wrote:
>>
>>> Michael Tüxen wrote:
>>>> Hi Andrey,
When the INIT gives out an currently unused v-tag and you do not mark
it somehow, how can you be sure that you do not give the same v-tag out
when receiving a different INIT? The probabilities are small, but you
wanted uniqueness...
> TCP gets all of the hardware assists).
At least there are cards which do SCTP checksum offloading...
> reference to host memory.
How do you get this identifier for TCP? Can't you use the same for SCTP?