Subject: RE: [Seamoby] SCTP for CARD?

From: Dirk Trossen <[email-masked]>
Date: Fri, 9 Apr 2004 07:56:20 -0500 (CDT)

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-masked]>
To: [email-masked], [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Apr 2004 10:53:58 -0700

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-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, April 09, 2004 5:56 AM
Subject: RE: [Seamoby] SCTP for CARD?

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Apr 2004 15:04:27 -0700

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-masked]>
To: "James Kempf" <[email-masked]>; "Dirk Trossen"
<[email-masked]>; <[email-masked]>; <[email-masked]>
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,
> >
> > > including a partial reliability mode (see
draft-ietf-tsvg-prsctp-03.txt,
> > now
> > > 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
> > > specification for UDP between ARs with SCTP, and multiplex with CTP
over
> > the

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 9 Apr 2004 17:39:21 -0400

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

due
ambiguous

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Apr 2004 16:04:37 -0700

So of the people who commented on this, only one comment was negative,
others seemed to feel that, given CARD's experimental status, exploring the
use of SCTP would be a good idea.

I'm preparing a revised version of the draft now, I will include SCTP as
required, in order to ensure good interoperabilitity for people who don't
care about the transport, but also put in a paragraph stating that people
may explore other transport options to find out what works best. We're also
doing something similar to this with CTP.

I expect to have revised versions of both drafts available for review by
Monday.

            jak