Subject: [Tsvwg] PR SCTP

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Mar 2003 08:57:35 -0600

Greeings:

The new version of PR-SCTP is now available...

http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-prsctp-03.txt

Please have a close look at it.. the authors all feel it is fully
baked and ready to move forward... comments would be most
welcome :>

The feature (its been rolling around for quite some time) provides
a partial reliablility. It has been sucessfully tested at the
last SCTP Bakeoff with two implementations.. and many present
said it would be showing up soon in their implementation as
well :->

Thanks

R

--
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

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

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 4 Mar 2003 11:19:46 -0600

>3.3.1 Sending Forward-TSN-Supported param in INIT
>
> If an SCTP endpoint supports the FORWARD TSN chunk, then
> any time it sends an INIT during association
> establishment, it SHOULD include the
> Forward-TSN-supported parameter in the INIT chunk to
> indicate this fact to its peer.

Does an SCTP endpoint supporting this capability mean that
the implementation has this capability, or that the local
ULP has also enabled the capability?

It strikes me that partial reliability is only of use for
a ULP that is explicitly aware of it, and therefore would
enable it locally for the endpoint.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Mar 2003 14:11:38 -0600

> ULP has also enabled the capability?

Capability referes to the stack being able to do pr-sctp.. not
the application. The application, would need to send with
a flag to note that the message has a time limit (for example).

If the app was un-aware of the capability then it would
not get used...

> enable it locally for the endpoint.
Just because the peer endpoints are capable of PR-SCTP does
not mean it would be used by the application...

I think I may be missing your point.. If the app does
not wish to use it.. it won't period.. No matter
if the two stacks support it.

The PR-SCTP document is concentrating on the protocol
aspects and mechanisms.. just like TCP timestamps or
TCP-Sack etc... if the O/S puts an interface to
disable the behavior (such as BSD has to turn on/
off timestamps or SACK via sysctl) that is outside
the scope of this document and would be more apt
to show up in a sockets api like document..

R

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 4 Mar 2003 14:25:32 -0600

>if the two stacks support it.
I was seeking clarification on the issue of whether a
stack should send this information in all INITs that it
generates, or if it should only do so when there has been
some indication from the application layer that there is
a need for the feature.

In other words, should an INIT being sent for an endpoint
that has never needed partial reliability before and does
not need it now, *change* when this draft is adopted?

Or should the INITs supporting endoints that are unrelated
to partial reliability simply omit this parameter, even
if in fact they have the code to support partial reliability
on other endpoints when the application layer needs it?

Does the capability exist *for an endpoint* because the
library has been upgraded, or should the application layer
be expected to somehow activate the capability?

I believe that applications that do not require new
capabilities would prefer for the advertisements of their
endpoints to remain unchanged even as new features are
defined. If the new features are irrelevant to the
application should they change packets on the wire?

Caitlin Bestler

---

From: Randall Stewart <[email-masked]>
Date: Tue, 04 Mar 2003 18:14:52 -0600

> application should they change packets on the wire?

I would tend to deem this a user interface issue. I could see
a O/S provider making an option that says:

Don't tell the peer that you support feature X, because I
just don't plain want to do it...

R

---

From: Allison Mankin <[email-masked]>
Date: Tue, 04 Mar 2003 20:18:26 -0800

We will have some time on the agenda in SF to discuss
PR SCTP as well.  We're going to publish a tentative
agenda for the meeting very shortly.

Allison