Subject: [tsvwg] SCTP 4960bis and Path versus Destination only handling of congestion and recovery state?

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Jul 2021 14:29:49 +0000

Hi,

During the WG last call of 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/  I
raised an high level issue in regards to SCTP's handling of paths. In a
number of places the specification states that variables like SRTT and
thus RTO, MTU and congestion window are tracked based on destination
only, not path. There are other places where it clearly takes about
path, where I would assume src-dst pair tracking. 

To me it appears it is far from ideal to continue on this track of
having the spec ignore path differences. And that it is time for SCTP
take the step and clarify this. 

At the same time I understand a change will impact the implementions
that exist. It will also delay the publication of this specification
some additional time. 

I think it would be good to understand if people have opinions if this
should be addressed now or be taken on seperatly. 

Cheers

Magnus Westerlund

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 23 Jul 2021 19:42:21 +0200

> On 23. Jul 2021, at 16:29, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
> 
> During the WG last call of https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/ I raised an high level issue in regards to SCTP's handling of paths. In a number of places the specification states that variables like SRTT and thus RTO, MTU and congestion window are tracked based on destination only, not path. There are other places where it clearly takes about path, where I would assume src-dst pair tracking.
SCTP implementations are not required to be able to select the source address of outgoing
packets. The source address selection is not done in the SCTP implementation, but in the
layer below the SCTP layer, the IP implementation. It is (implicitly) assumed, that the
source address selection is somewhat stable. It would change, if you change the routing
table of of the host. Therefore, SCTP does not track the src/dst address pair at all.

It does make sense, to reset some state variables when the sequence of hops to the peer
changes, including the CC variable, RTT information, pathMTU and others. However, it is
hard for a transport stack to detect this. An SCTP implementation can perform such state
resets if the IP layer notifies it about a change in the source address selection. Detection
of a change in the sequence of hops besides the src address is harder to detect and could
be done by detection changes in received TTL values or hopLimits, drastic changes of the
RTT or by other means. However, nothing like this is specified yet and some of it would
need to have a backchannel.

Only tracking the dst addr was a design decision taken very early in the design on SCTP.
Assuming two nodes by n networks, which are physically separated (to avoid single points
of failures), each end-point would have n * n paths, of which n * (n - 1) are never working
at all and n are expected to work. So not tracking all combinations, but only the dst addr
is much more efficient.
> 
> To me it appears it is far from ideal to continue on this track of having the spec ignore path differences. And that it is time for SCTP take the step and clarify this.
> 
> At the same time I understand a change will impact the implementions that exist. It will also delay the publication of this specification some additional time.
I think we should do the right thing. I have no problem in delaying the document to
fix any issues. But the change suggested is in my view not a fix of an issue. It is
designing a flavour of SCTP based on a different assumption.
> 
> I think it would be good to understand if people have opinions if this should be addressed now or be taken on seperatly.
I agree on this.

Best regards
Michaek

---

From: Randall Stewart <[email-masked]>
Date: Fri, 23 Jul 2021 17:39:44 -0400

+1 to what Michael as said here. SCTP was never designed with the
idea of source based routing.. that is something different and
was explicitly excluded. If someone wants to start a WG to do that
go for it.. but it won’t be SCTP .. call it SCTP+

R

> On Jul 23, 2021, at 1:42 PM, Michael Tuexen <[email-masked]> wrote:
> 
>> During the WG last call of https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/&source=gmail-imap&ust=1627666968000000&usg=AOvVaw0TYVMyyxOg2m44NWxV5Bf- I raised an high level issue in regards to SCTP's handling of paths. In a number of places the specification states that variables like SRTT and thus RTO, MTU and congestion window are tracked based on destination only, not path. There are other places where it clearly takes about path, where I would assume src-dst pair tracking.

------
Randall Stewart
[email-masked]