Re: SCTP for CARD?

James,

Could we make SCTP an option rather than the required transport protocol as
suggested by Dirk?
I am reluctant to bring in SCTP to test CARD at this moment.
What do you think?

Eunsoo

> Dirk,
>
> We could specify that people can experiment with UDP (MAY), but we don't
> need to ask for an IANA port allocation. In the CTP draft, the new
transport
> section says SCTP is required but people are encouraged to experiment with
> ICMP or UDP to determine what is best. We could do the same for CARD.
>
> How does that sound?
>
>             jak
>
>
> ----- Original Message ----- 
> From: "Dirk Trossen" <[email protected]>
> To: <[email protected]>; <[email protected]>;
> <[email protected]>; <[email protected]>
> Sent: Friday, April 09, 2004 5:56 AM
> Subject: RE: [Seamoby] SCTP for CARD?
>
>
> > 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
> >
> >
>
>
>
> _______________________________________________
> Seamoby mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/seamoby
>