Subject: RE: SCTP for RDDP

From: "Williams, Jim" <[email-masked]>
Date: Thu, 19 Dec 2002 17:29:07 -0500

> -----Original Message-----
> From: Qiaobing Xie [mailto:[email-masked]]

> I think the easiest and cleanest way to not support multi-homing and
> remain compliant is to:
>  * always advertise a single local address when sending your INIT or
> INIT-ACK;
>  * accept and keep the full list of address(es) your peer gives you;

This is the problem.  How many addresses do I reserve space for?
If I reserve space for 10, do I abort the association if the 
remote end sends 11?

I am sure a software based implementation would simply malloc
a list of whatever size was needed to hold all of them, and
abort the association if the malloc failed.  While it is 
possible to do this in an embedded hardware accelerated
implementation, it is worth serious effort to avoid.

>  * when validating an incoming packet, use all the peer's 
> addresses, so
> you will not get the above ABORT situation.
>  * when sending (including both fresh sends and retrans), only use one
> of the peer's address as dest addr.
> 
> This way, you no longer need to code the CC, RTO, heartbeat,
> reachability, etc, on multiple destination addresses, since you will
> always only use 1 dest addr to send.

OK, but the bigger problem is being able to bound the worst case
size of the association state representation.  Minimizing the
typicial size is much less important.  Oversizing is fine
as long as the maximum is finite, known, and managable.

> Sending and receiving gaps reported in SACKs have too much implication
> to the behaviors of the protocol. I wouldn't want to skip that.

I wouldn't want to skip it either.  But I would like to limit the
number of gap ack blocks in each direction to three.  If three
is not enough, how about six?  The answer I don't want is
"as many as the remote end wants".  He can send me 137, by
I will only note the first three.

My concern was I don't know if this violates a "MUST" in the spec.

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Dec 2002 17:00:32 -0600

> If I reserve space for 10, do I abort the association if the

SCTP does not dictate how or how much resource you must put aside for an
association. Therefore, you can always set your own internal resource
bound and reject an association with a "out of resource" error. This is
completely legal. E.g., you can have your impl to handle max 3 peer dest
addr. If you get an INIT or INIT-ACK with >5 addr, send an
"out-of-resource" ERROR back and reject the association. In fact, any
robust implementation must set this internal bound.

> implementation, it is worth serious effort to avoid.

ditto.

> as long as the maximum is finite, known, and managable.

ditto.

> My concern was I don't know if this violates a "MUST" in the spec.

Again, the "MUST" is meant to make the spec theoretically sound. My
feeling is that to ignore some of the gaps in either direction will have
some performance penalty and thus should be allowable. One possibility
is that you will lose some opportunity to perform fast retransmission
that is supposed to be a performance enhancer. 

In the spirit that one can always be more conservative than the spec, I
think it should even be allowable if one says "I will trade fast
retransmission for simplicity". IMO, it is ok. For example, by giving up
fast retransmission capability, you could remove a lot of complexity. As
far as one does not do anything more aggressive than the spec and does
not claim such a lite version a general purpose SCTP stack, then he/she
should be politically correct :-)

-Qiaobing

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 20 Dec 2002 07:26:28 -0600

Jim a couple of comments...

>implementation, it is worth serious effort to avoid.
I think Q mentioned this but I will re-iterate it as well.. You can always
set up your resource limits the way you want.. then if you don't like what
the peer gives you (i.e. 28 addresses) send an abort(out-of-resource). I 
believe
one of the early versions of SCTP for IOS did this only it was even more
restrictive... you had to tell it which addresses were expected on each 
side..
If you missed one the association would get an abort() .. I think it has
changed from that now.. but it WAS and IS legal to do this...

>as long as the maximum is finite, known, and managable.
Which you can do completely within the bounds of the protocol by
sending a ABORT(out-of-resource).

>My concern was I don't know if this violates a "MUST" in the spec.

I do believe the implementors-guide makes sending gap-ack-blocks a 
must.. however
I think one could limit these to some fixed number and still be ok... 
performance
would suffer.. but it is legal as long as you put in 1 gap ack block 
when you
have one (or more)...

So I would think one could limit this to "six" and be within legal 
bounds... you will
not perform as well in lossy situations.. but that is probably ok..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)