Subject: SCTP for RDDP

From: "Williams, Jim" <[email-masked]>
Date: Thu, 19 Dec 2002 10:36:33 -0500

I have been looking at the implications of using 
SCTP for RDDP.  This would typically be a small
embedded implementation with severely limited
resources (SCTP on the NIC card),
and am trying to understand how this would work.
I am starting from zero with respect to SCTP knowledge
so apologies in advance if some of my questions
are from basic ignorance.

1. 

It seems that multi-homing will be of limited
value for RDDP.  An implementation can certainly
advertise only a single local address, by how
is the case handled where the remote end sends
too many IP addresses?  Since remote addresses
for an association consume non-trivial local
resources, the implementation will want to set
a limit (quite possible one) on the this.
My impression is that SCTP sets no limit on
this, and provides no simple mechanism for 
one end to reject a subset of the addresses
offered by the other end.

One possibility is to simply ignore some of 
the addresses offered by the other end.
The creates a problem if a packet arrives from
one of those addresses.  The naive behavior
would be to respond with an ABORT, but that
would not be correct.  Alternative behavior
of receiving an "out of the blue" packet
might be to use the VTag as a hash key to 
recover any matching association.  If there
is one, and the parameters all match except
the source address, then ignore the packet
rather than sending an ABORT.

2.

It seems that window management could
be simplified a lot by assuming outstanding
data is equal to
( (last_TSN_sent - last_cum_TSN_ack) * MTU ).
This would result in overly conservative
behavior, but seems like it would be
compliant and not perform badly.  Is this
correct?

3.

It seems that an implementation may want
to limit the amount of information sent
in a SACK, and limit the amount of information
it pays attention to for incoming SACKs.
I am not totally clear on the MAY/MUST 
boundary here.  Are implementations free
to regard gap ack blocks and duplicate TSNs
as hints the may be ignored or withheld when
convenient (to bound resource usage)?

Thanks, Jim

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 19 Dec 2002 15:23:03 -0600

Hi, Jim,

> rather than sending an ABORT.

To abort a legit peer is not good.

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;
 * 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.

> compliant and not perform badly.  Is this

I am not sure about performance of this. But, yes, being more
conservative is surely going to be considered compliant.

> convenient (to bound resource usage)?

Sending and receiving gaps reported in SACKs have too much implication
to the behaviors of the protocol. I wouldn't want to skip that.
Duplicate TSNs are mostly hints and I think you should be fine if you
choose to ignore them, especially your associations are most likely
singly-homed.

-Qiaobing