Subject: [Seamoby] SCTP for CARD?

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Apr 2004 13:11:10 -0700

Folks,

While working to resolve the AD Review comments about congestion and
transport on CTP, it occured to me that the same comments might apply to
CARD for the interrouter protocol (Section 5.2.1), since the two protocols
will be running inter-router in the same kinds of networks. SCTP (RFC 2960)
has some very nice features that make it attractive for this purpose,
including a partial reliability mode (see draft-ietf-tsvg-prsctp-03.txt, now
on the RFC Editor queue) which allows an application to cause congestion
retransmits to be cancelled if a realtime constraint is not met. One
difference is that the interrouter CARD presumably won't have such a
realtime constraint, because it won't be run when the MN asks for the CARD
information, but rather during updates of the caches on both routers, due to
changes in the network configuration. The CARD spec is somewhat ambiguous on
this point, Section 4.4.2 seems to imply that it will be run if the router
has a cache miss and thus would have a realtime constraint, while in Section
4.2.2, it says that if the current AR doesn't have the capabilities, it
should return an error message to the MN, not poll all the local CARs. The
latter sounds more likely to be the better performer in the end, but SCTP
could accommodate either case.

Another advantage of using SCTP is that we can use the same port for both
CARD and CTP and use the PPI to differentiate them. The PPI is the Payload
Protocol Identifier that tells what protocol is in the payload. This would
allow us to address the Discuss from Ted Hardie and Thomas Narten, about
allocating scarce port resources to experimental protocols.

Finally, since CARD is experimental, I think this would be an excellent
opportunity to try out SCTP in a real application, without impacting
anybody's product or deployment plans. If it doesn't work, we can always
revert to using UDP when and if CARD is taken to proposed standard.

So, I'd like to propose that we replace the current somewhat ambiguous
specification for UDP between ARs with SCTP, and multiplex with CTP over the
same port.  There would be no change to the AR-MN transport.

Comments? Please send them by next Thurs.

            jak

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

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Sat, 10 Apr 2004 15:31:05 -0500

James:

Just a couple  of comments on SCTP and the CARD.. in
particular on PR-SCTP..

James Kempf wrote:

>retransmits to be cancelled if a realtime constraint is not met
>
One does NOT have to only use PR-SCTP for realtime constraints.
In ipfix SCTP is being used and if both endpoints support PR-SCTP
the router sending to the collector will discard using PR-SCTP not
when the real-timelyness (is that a word :-0) of the data is in
question but instead when the router becomes very busy and
hits a  buffer limitation imposed on it... PR-SCTP has two pieces
in it.. the actual mechanism that must be used by  both
sender and reciever.. and then above that the sender side
service model on what causes it to expire a packet. In the PR-SCTP
draft/soon-to-be RFC only time based reliability .. i.e. its too old, so
chuck it.. is specifed.. but it is possible (as we are doing in IPfix) to
use a different service model as to why you expire a data message.

>. One

This would be very interesting.. Thomas and Eric pushed the
use of PPID in lieu of ports and it would be good to see an
application emerge that would use them for what they were
intended :-D

and one other thought...

You really need to specify a MUST for a transport.. and MAY
for any optional thing.. otherwise you will get all sorts of
inter-action problems where my implementation does
SCTP and yours does UDP... assuming you can get
the IESG to approve UDP.. I know for IPFIX they would
not due to the congestion issue...

R

-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)