RE: SCTP for CARD?
Dirk Trossen <[email protected]> Fri, 9 Apr 2004 07:56:20 -0500 (CDT)
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <[email protected]> |
Hi James, excellent idea, in particular considering the experimental status of CARD. One point though. What if an AR does not implement CTP? It would still need an SCTP implementation for CARD which might be more overhead compared to UDP. So do we want to throw out UDP entirely or define it as using UDP as minimal and have SCTP as optional extension, in particular in combination with CTP? Dirk ))) Message sent using Nokia Access Mobilizer -- www.nokia.com/accessmobilizer ((( --- Original Message --- From: ext James Kempf <[email protected]> To: [email protected], [email protected] Date: Thu Apr 08 16:11:10 EDT 2004 Subject: [Seamoby] SCTP for CARD? 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 protected] https://www1.ietf.org/mailman/listinfo/seamoby