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

[Claudio Porfiri <[e-mail]>]

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.

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.

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]
>> 
>> 
>> 
>