Subject: RE: [Tsvwg] Spurious RTOs and SCTP

From: [email-masked]
Date: Fri, 21 Mar 2003 02:57:23 +0200

> > Actually, this brings up a more broad question - as SCTP and TCP
> > share (basically) the same mechanisms for congestion control, etc.,
> > is it worthwhile for TCP mechanisms also to discuss their 
> > applicability for SCTP?  My opinion is that they should.
> 
> I agree. What would be ideal is for new mechanisms to somehow 
> abstract the problem and solution so that they can be applied to both 
> protocols. It may not always be possible though, but at least a
> discussion of applicability to both protocols is useful.

I agree in general. But I see roughly three options:

1) Write the spec so that TCP and SCTP are handled side by side. This could make detailed algorithm descriptions pain, since TCP and SCTP have different set of variables and conventions. Additionally, SCTP has nice features such as SACKs and duplicate TSNs, which are optional in TCP and not always available.
2) Create a dedicated section for TCP and another section for SCTP in the same draft.
3) Have one small document for TCP and another for SCTP (if needed).

I guess you meant something like (1) and John had something closer to (2) in mind?

Considering our F-RTO draft, I feel (1) quite undesirable, as the algorithm description currently refers to TCP-specific parameters, and patching the algorithms with SCTP could be difficult to read. (2) & (3) would seem easier cases, of which I would favour (3), because I believe the TCP F-RTO is in pretty good shape, and I wouldn't want to delay it unnecessarily because of tweaking with the SCTP-side. Besides, it seems somewhat logical to me to have different documents for handling different transport protocols. However, I'd be happy to hear opinions on this.

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 21 Mar 2003 03:06:55 -0500 (EST)

On Fri, 21 Mar 2003 [email-masked] wrote:

> 1) Write the spec so that TCP and SCTP are handled side by side. This
> could make detailed algorithm descriptions pain, since TCP and SCTP
> have different set of variables and conventions. Additionally, SCTP
> has nice features such as SACKs and duplicate TSNs, which are optional
> in TCP and not always available.

> Considering our F-RTO draft, I feel (1) quite undesirable, as the
> algorithm description currently refers to TCP-specific parameters, and
> patching the algorithms with SCTP could be difficult to read. (2) &

Actually, I had in mind a combination of (1) and (2). A draft can have
the problem statement generic for the two transport protocols, and then
dedicate a separate section for specific solutions for TCP and SCTP.

> (3) would seem easier cases, of which I would favour (3), because I
> believe the TCP F-RTO is in pretty good shape, and I wouldn't want to
> delay it unnecessarily because of tweaking with the SCTP-side.
> Besides, it seems somewhat logical to me to have different documents
> for handling different transport protocols.

I understand your point, but my concern is that we'll end up with some
solutions for TCP and some for SCTP... when all or most solutions can be
applied to both. Then someone has to go through a second pass and apply
the TCP solutions to SCTP and vice-versa. If the solutions are drastically
(or even moderately) different, maybe it makes more sense to have separate
drafts. I think a good example of when both protocols can be addressed in
one draft is when spurious rtxs need to be identified via duplicate tsn
reports. TCP uses DSACKs and SCTP uses DupTSNs, but there is very little
difference in the two.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 21 Mar 2003 11:25:53 -0600

On 3/21/03, [email-masked] wrote:

>> I agree. What would be ideal is for new mechanisms to
>> somehow abstract the problem and solution so that they
>> can be applied to both protocols. It may not always be
>> possible though, but at least a discussion of
>> applicability to both protocols is useful.
>
>1) Write the spec so that TCP and SCTP are handled side by
>side. This could make detailed algorithm descriptions
>pain, since TCP and SCTP have different set of variables
>and conventions. Additionally, SCTP has nice features such
>as SACKs and duplicate TSNs, which are optional in TCP and
>not always available.

Would it be feasible to define a single document which
specified a set of transport neutral terms that would be
compatible with TCP, TCP with SACKs, SCTP and DCP (and the
mapping of those terms to each congestion controlling
transport protocol)?

That way new algorithms can be proposed once, and the
mapping to each transport would be known.

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