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

[Claudio Porfiri <[e-mail]>]

Hi all,
in case of local multihoming, SCTP delivers packets to the IP layer by means of different Access Points,
this doesn't mean that SCTP knows the Source IP address but at least it knows the Access Points (Sockets or whatever).
Multiple Access points leads to paths.
On the other hand having SCTP the path probing, and not allowing path probing to probe the paths is a contradiction.
In my opinion the path related concepts have to be clarified.

BR,
Claudio

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Randall Stewart
Sent: Friday, July 23, 2021 11:40 PM
To: Michael Tuexen <[e-mail]>
Cc: Magnus Westerlund <magnus.westerlund=[e-mail]>; [e-mail]
Subject: Re: [tsvwg] SCTP 4960bis and Path versus Destination only handling of congestion and recovery state?

+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 <[e-mail]> wrote:
> 
>> On 23. Jul 2021, at 16:29, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
>> 
>> Hi,
>> 
>> During the WG last call of https://protect2.fireeye.com/v1/url?k=82ddf52f-dd46cc29-82ddb5b4-86ee86bd5107-7c6a0a3739c4f18d&q=1&e=6f5bc71d-1116-43fd-8afa-06aa74b7407a&u=https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tsvwg-rfc4960-bis%2F%26source%3Dgmail-imap%26ust%3D1627666968000000%26usg%3DAOvVaw0TYVMyyxOg2m44NWxV5Bf- 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
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> 
> 

------
Randall Stewart
[e-mail]