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

[Michael Tuexen <[e-mail]>]

> On 13. Aug 2021, at 09:33, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> Hi Michael,
> thanks for the explanation.
> In my opinion, when reading the various rfcs the term "path" has always been (b) because (a) is not possible.
> Moving from (c) to (b) is not prohibited from the current rfc4960, but it's actually an implementor's choice
> as long as it doesn't break the protocol.
Hi Claudio,

I would say that you can implement a full-mesh flavour of SCTP and, if done well, I would
expect that implementation to be interoperable with an RFC 4960 compliant one.

But implementing a full-mesh flavour requires several changes to the protocol,
the API (and therefore for the applications using it) and also about the
parametrisation.
> 
> Should the meaning of "path" being made clear?
> In section 1.3 it's stated as (a):
>   o  Path: The route taken by the SCTP packets sent by one SCTP
>      endpoint to a specific destination transport address of its peer
>      SCTP endpoint.  Sending to different destination transport
>      addresses does not necessarily guarantee getting separate paths.
Sure. What about using:

<dt>Path:</dt>
<dd>
<t>The route taken by the SCTP packets sent by one SCTP endpoint to a specific
destination transport address of its peer SCTP endpoint.
Sending to different destination transport addresses does not necessarily
guarantee getting separate paths.
Within this specification, a path is identified by the destination transport
address, since the routing is assumed to be stable.
This includes in particular the source address being selected when sending
packets to the destination address.</t>
</dd>

Best regards
Michael
> 
> Best regards,
> Claudio.
> 
> 
> -----Original Message-----
> From: Michael Tuexen <[e-mail]> 
> Sent: Thursday, August 12, 2021 2:04 PM
> To: Claudio Porfiri <[e-mail]>
> Cc: Magnus Westerlund <[e-mail]>; rrs=[e-mail] <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] SCTP 4960bis and Path versus Destination only handling of congestion and recovery state?
> 
>> On 12. Aug 2021, at 09:10, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
>> 
>> 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.
> Hi Claudio,
> 
> I think the usage of the word path is the problem. I can be used at least in three different
> ways:
> (a): as a sequence of hops (or IP addresses) between a source and a destination.
> (b): as a pair of source and destination addresses
> (c): as a destination address
> 
> I think we agree on that (a) is the precise definition of it. (b) is a simplification of
> (a), which makes sense if there is no way to know the intermediate nodes. So this makes
> sense to be use in the transport layer and I guess that is the reason you are referring
> to this notion of path. (c) is another simplification which makes sense if you don't assume
> that you know/control the source address. (c) is an acceptable simplification as long as
> you consider the source address being a function of the destination address, which does not
> vary on short time frame.
> 
> I hope we can agree on the above.
> 
> The definition, which was *intended* when writing the original SCTP specification (RFC 2960),
> was (c).
> 
> Moving from (c) to (b) is a change of the protocol. I would suggest that if you want to
> have a "full meshed flavour of SCTP", you write up an ID, where the differences are
> described in detail. This is not as simple as changing all parameters/procedures we now
> have per destination address to having them per source/address pair.
> 
> Just to be crystal clear: I'm not against having a full meshed flavour of SCTP, it
> is just not the flavour which was originally intended and described by RFC 2960, RFC 4960
> and RFC 4960bis.
> 
> I agree already to a suggestion from Magnus to make it explicit, that if the SCTP
> stack has an indication, that the path (in the sense of (a)) towards a destination
> might have changed (for example, because a different DSCP code point is used or a
> different source address is used), the relevant per destination parameters like
> cwnd and rtt measurements needs to be reset to its initial states. This was always
> intended, but not made explicit.
> 
> Best regards
> Michael
> 
> 
>> 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]
>>> 
>>> 
>>> 
>>