Re: SCTP for CARD?
"James Kempf" <[email protected]> Fri, 9 Apr 2004 15:04:27 -0700
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <[email protected]> |
We could make SCTP a SHOULD rather than MUST. But in order to resolve Ted
and Thomas's Discuss, I think it would be best if we didn't ask IANA to
allocate a port for UDP until we know whether CARD will go to Proposed
Standard, and rather encourage people to experiment with an ephemerial port.
For UDP, if we include that as a SHOULD, there will be some changes
necessary. For example, the current fixed backoff timers are not acceptable
from a Transport standpoint, exponential backoff needs to be used.
Personally, I think we need to encourage people to experiment with this.
Perhaps we can suggest both, and not make either a requirement
(SHOULD/MUST), thereby encouraging people to try it out.
jak
----- Original Message -----
From: "Eunsoo Shim" <[email protected]>
To: "James Kempf" <[email protected]>; "Dirk Trossen"
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Friday, April 09, 2004 2:39 PM
Subject: Re: [Seamoby] 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
> >
>
>