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

[Claudio Porfiri <[e-mail]>]

Hi,
the usage of the term "path" is actually misleading, at least I see that I am misusing it.
We can only consider pairs of Local IP address and Remote IP address, not all the path.
When related to section 13.3, I think that it should apply to the Source-Destination Pair 
rather than the Destination only, and this is because SCTP cannot assume that
reaching a Destination has the same characteristics from all the Sources at a certain time.
When doing a "path" probing, part of the values of section 13.3 can be already available,
for instance SRTT, RTO, PMTU, state.
About Source Based Routing, currently SCTP is already used in scenarios involving
Security Gateways so that a set of destination addresses can only be reached from
a subset of source addresses, this is not prohibited from rfc4960.

Regards,
Claudio.

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Michael Tuexen
Sent: Sunday, August 8, 2021 2:12 PM
To: Claudio Porfiri <claudio.porfiri=[e-mail]>
Cc: magnus.westerlund=[e-mail]; rrs=[e-mail]; [e-mail]
Subject: Re: [tsvwg] SCTP 4960bis and Path versus Destination only handling of congestion and recovery state?

> On 6. Aug 2021, at 16:01, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> 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).
Hi Claudio,

I'm not sure I understand what you are referring to. In the FreeBSD stack the
SCTP layer just calls ip_output() or ip6_output(). In a userland stack you can
use a raw socket (one for IPv4 and one for IPV6) to provide the SCTP packets to
the IP layer. At least this is supported.
> Multiple Access points leads to paths.
This is a question of what a path is.
> On the other hand having SCTP the path probing, and not allowing path probing to probe the paths is a contradiction.
It probes the availability of remote addresses, not of paths is the sense of
a sequence of hops a packet traverses from the source to the destination.
> In my opinion the path related concepts have to be clarified.
I think they are clear: They are only per remote address. All per "path"
variables are actually per remote transport address. See section 13.3.

Best regards
Michael
> 
> 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]
> 
> 
>