Re: [tsvwg] SCTP question

[Michael Tuexen <[e-mail]>]

> On 12. Nov 2018, at 12:36, [e-mail] wrote:
> 
> Michael,
> 
> Thank you for your response and your continued support in aiding our understanding. Your reply would seem to indicate that there are separate methods for re-transmitting INITs and Data Chunks defined within RFC4960.
> 
> We both seem to agree that RFC7829 is effectively an alternative method to RFC4690 to handle Data Chunks allowing the re-transmission to an alternative path. As the consensus from the responses of the IETF has been that the "SHALL" should have been capitalised, it seemed reasonable to me for the DATA Chunk re-transmission rules to be applied. However, if this is not the case, I  am still not clear where in RFC4960 the re-transmission of INIT's is described and in particular the use of alternate addresses for each re-transmission. 
RFC7829 is introducing a potentially failed path state for allowing faster failovers
in case of link failures. It doesn't really deal with INIT chunks.

RFC 4960 has no explicit statements regarding the retransmissions of INIT chunks.
On of the reasons is that when RFC 2960 was written, the API for initiating an
SCTP association was the ASSOCIATE() primitive (see section 10.1.B)), which 
only accepts a single addresses of the peer.

Adding support of providing multiple addresses of the peer was "only" done
in RFC 6459 (Socket API for SCTP), section 9.9. Therefore there is no explicit
text in RFC 4960 and the precise selection of remote addresses is left
implementation specific.

However, when an API of an implementation allows providing multiple IP addresses
for the peer, I expect an implementation to use these multiple addresses. If
they are used round robin, first IPv4 then IPv6 or vice versa, or by a different
method is left open. However, timers have to be manages per remote address.

The examples I provided is based on the way the FreeBSD kernel stack behaves.
> 
> The only documentation I can see specifically referenced in RFC4960 for the Initialisation of an Association is RFC2252 (section 1.5.1 Paragraph 2), which suggests that the INIT's are sent to the same destination address. Could you please clarify the appropriate 
> section(s) please.
RFC 2252 is only about the computation of the cookie. Nothing else.

I hope this makes things clearer.

Best regards
Michael
> 
> many thanks
> 
> Perry Wilks 
> BT Technology
> Signalling Protocols Lead 
> SDIN Architecture & Design Team 
> TLB35
> Email: [e-mail] 
> Tel: [phone]
> British Telecommunications plc 
> Registered office: 81 Newgate Street London EC1A 7AJ 
> Registered in England no. 1800000 
> "This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual (s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately". 
> Activity and use of the  British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.
> 
> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]] 
> Sent: 08 November 2018 20:13
> To: Wilks,PB,Perry,TLB35 R
> Cc: Eardley,PL,Philip,TUD1 R; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [tsvwg] SCTP question
> 
>> On 8. Nov 2018, at 11:33, [e-mail] wrote:
>> 
>> Michael,
>> 
>> Many thanks for your engagement on this. It is much appreciated. I would like to ask some other questions
>> 
>> I have concerns about path. Is there something that logs the route taken from client to server? If not, then how does a client know that more than one path is available? Even if there is more than one path how does a client know of their existence at initiation?
> Hi Perry,
> 
> SCTP doesn't know the path in the sense of a sequence of nodes between the sender and receiver.
> 
> All it knows is the remote address and some implementations might be able to choose the source address
> for specific destination addresses.
> 
> If the application provides multiple remote IP address when initiating the association (using sctp_connectx() in the
> socket API) the can try all of them. Whether the paths towards the different remote addresses are disjoint or
> share a link isn't know by SCTP. If disjointness is required, this has to be ensured by the network layout.
>> 
>> The description of path in RFC4960 states that when sending to a different destination IP address the same path may or may not be used. This implies that the client cannot know the path and that by changing the destination IP address the path taken may be the same or may be different. 
> Right. All an SCTP endpoint controls is the remote address it uses and some implementations might be able
> to choose the local address.
>> 
>> RFC4960 extract
>> 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
> Yepp.
>> 
>> Also we observed that RFC2522 and RFC7829 indicate that INIT Retransits are to the same destination IP address until x retransmits is reached.
> Not sure why you are referring to RFC2522 (Photuris: Session-Key Management Protocol).
> 
> I think RFC7829 deal with transmission of DATA chunks and the path management.
> 
> Best regards
> Michael
>> 
>> I look forward to your response.
>> 
>> Many thanks 
>> 
>> Perry Wilks 
>> BT Technology
>> Signalling Protocols Lead 
>> SDIN Architecture & Design Team 
>> TLB35
>> Email: [e-mail] 
>> Tel: [phone]
>> British Telecommunications plc 
>> Registered office: 81 Newgate Street London EC1A 7AJ 
>> Registered in England no. 1800000 
>> "This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual (s) or the entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately". 
>> Activity and use of the  British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.
>> 
>> -----Original Message-----
>> From: Michael Tuexen [mailto:[e-mail]] 
>> Sent: 05 November 2018 22:52
>> To: Eardley,PL,Philip,TUD1 R
>> Cc: Proshin, Maksim; [e-mail]; Wilks,PB,Perry,TLB35 R; [e-mail]; [e-mail]
>> Subject: Re: [tsvwg] SCTP question
>> 
>>> On 5. Nov 2018, at 18:32, [e-mail] wrote:
>>> 
>>> Michael, all,
>>> 
>>> What do you think is the best way of progressing with this? I noticed that draft-ietf-tsvwg-rfc4960-errata has just been approved by IESG - I guess the plan is now to work on the actual rfc4960bis, so it could be incorporated there? (don't think I-D has been started?)  Is it best if we actually submit an Errata?
>> Hi Philip,
>> 
>> sorry for not responding earlier...
>> 
>> Since draft-ietf-tsvwg-rfc4960-errata has been approved, I would suggest the following:
>> 
>> The point being discussed is that RFC 4960 uses words like shall/must/should, but they
>> are not in capital letter. We already made sure the all "New Text" entries in
>> draft-ietf-tsvwg-rfc4960-errata resolve this. The words have been changed to
>> SHALL/MUST/SHOULD or have been changed to some wording avoiding any ambiguity.
>> 
>> The current plan for rfc4960bis is to get out an internet draft which contains
>> rfc 4960 with all fixes from draft-ietf-tsvwg-rfc4960-errata applied.
>> Then it is planned to go through the text and clean up the remaining ambiguities.
>> That would cover the issue reported by Perry.
>> To make sure it is covered, you could open an issue at
>> https://github.com/sctplab/rfc4960bis
>> to make sure we don't forget it. 
>>> 
>>> Perry W is also very interested to know whether he interprets the implications of this correctly:-
>>> 
>>> << Our understanding is (assuming that the 'shall' in the note should be uppercase) that the rules as for the DATA CHUNK are followed.
>>> This means that there is a separate timer for each destination IP address.  The changeover to try a different IP address only takes place after X retransmissions to the same IP address. When X is reached a transmission to an alternative IP address is made.
>>> Is our understanding correct?
>> Timers and counters are per path. Whether multiple addresses are used, depends on how the association
>> was initiated. Assume the server has three IP addresses A, B, and C.
>> Assume furthermore, RTO.Initial = 1 second, RTO.Max = 60 seconds, Max.Init.Retransmits = 8.
>> Case 1: The client only provides a single address when initiate the association, for example by calling connect(A).
>> You would observe:
>> 0 INIT towards A
>> 1 INIT towards A
>> 3 INIT towards A
>> 7 INIT towards A
>> 15 INIT towards A
>> 31 INIT towards A
>> 63 INIT towards A
>> 123 INIT towards A
>> 183 INIT towards A
>> 
>> Same for COOKIE-ECHO retransmissions, even if the server provides A, B, and C in the INIT-ACK, because
>> B and C would not be verified.
>> 
>> Case 2: The client provides all three addresses when initiating the association, for example by calling sctp_connectx(A,B,C).
>> 0 INIT towards A
>> 1 INIT towards B
>> 2 INIT towards C
>> 3 INIT towards A
>> 5 INIT towards B
>> 7 INIT towards C
>> 9 INIT towards A
>> 13 INIT towards B
>> 17 INIT towards C
>> 
>> Same the COOKIE-ECHO retransmissions.
>> 
>> Does that help?
>> 
>> Best regards
>> Michael
>> 
>>>>> 
>>> 
>>> I'm not sure whether this worthwhile discussing during the WG meeting on wed - the agenda looks quite tight (and neither Michael, Perry nor I are in Bangkok, I think)
>>> 
>>> Thanks
>>> phil
>>> -----Original Message-----
>>> From: Michael Tuexen [mailto:[e-mail]] 
>>> Sent: 22 October 2018 21:32
>>> To: Eardley,PL,Philip,TUD1 R <[e-mail]>
>>> Cc: Proshin, Maksim <[e-mail]>; [e-mail]; Wilks,PB,Perry,TLB35 R <[e-mail]>; [e-mail]; [e-mail]
>>> Subject: Re: [tsvwg] SCTP question
>>> 
>>>> On 22. Oct 2018, at 12:01, [e-mail] wrote:
>>>> 
>>>> Do other people agree?- especially Randall, as editor of RFC4960, and other people who've been involved a lot with SCTP?
>>> I agree with the other people... I interpret it as a SHALL.
>>> 
>>> When doing conformance testing (which I do once in a while), I expect the INITs and COOKIE-ECHOs to be retransmitted based on the timer rules (Start with RTO.Initial, double until reaching RTO.Max). If the peer is multihomed and this is configured, one has to consider if the multiple address are used for retransmitting the INITs and COOKIE-ECHOs.
>>> 
>>> I know that the use of shall sometimes causes confusion and we will likely resolve this when working on RFC 4960bis.
>>> 
>>> You can forward my address to your colleague in case he has further questions. I wrote two implementations of the ETSI conformance test suite for SCTP:
>>> * https://github.com/nplab/ETSI-SCTP-Conformance-Testsuite
>>> This is based on an extended version of packetdrill and can be used to test socket based
>>> implementations like the FreeBSD or Linux kernel implementation. Working on Solaris support.
>>> * https://github.com/nplab/sctp-tests
>>> This can be used for blackbox testing and is based on the SCTP Test Tool stt.
>>> 
>>> Best regards
>>> Michael
>>>> Thanks
>>>> phil
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Proshin, Maksim [mailto:[e-mail]]
>>>> Sent: 17 October 2018 09:32
>>>> To: Neil Horman <[e-mail]>; Eardley,PL,Philip,TUD1 R 
>>>> <[e-mail]>
>>>> Cc: Wilks,PB,Perry,TLB35 R <[e-mail]>; [e-mail]
>>>> Subject: RE: [tsvwg] SCTP question
>>>> 
>>>> Hi Neil,
>>>> 
>>>> In general it's not correct to say that "shall" is the same as SHALL. Thus RFC 8174 explains that "only UPPERCASE usage of the key words have the defined special meanings".
>>>> Saying this anyway I think that RFC 4960 actually means SHALL/MUST in that note.  
>>>> 
>>>> BR, Maxim
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: tsvwg [mailto:[e-mail]] On Behalf Of Neil Horman
>>>> Sent: Tuesday, October 16, 2018 20:36
>>>> To: [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> Subject: Re: [tsvwg] SCTP question
>>>> 
>>>> On Tue, Oct 16, 2018 at 02:42:05PM +0000, [e-mail] wrote:
>>>>> A colleague of mine, Perry, has a couple of questions about SCTP RFC4960. He's in the BT design team on Signalling protocols and concerned about conformance testing amongst other issues.
>>>>> 
>>>>> The statement is on page 57 of RFC4960  (section on Association initialisation) "Note: T1-init timer and T1-cookie timer shall follow the same rules given in Section 6.3."
>>>>> The question is: how should the "shall" be interpreted in this sentence? Does it mean that the S6.3 rules MUST be followed? Or does it mean that the S6.3 rules are optional - in which case, are there any thoughts about rules other than those in S6.3?
>>>>> 
>>>> The conventions section indicates that they keyword SHALL is goverened 
>>>> by RFC2119, which asserts SHALL is synonomous with the keywork MUST.  
>>>> That is to say that the phrase above on page 57 of RFC4960 is an 
>>>> absolute requirement.  You have to have the T1-init and T1-cookie 
>>>> timer follow the same rules given in Section 6.3
>>>> 
>>>> Neil
>>>> 
>>>>> Thanks,
>>>>> Best wishes,
>>>>> Philip Eardley
>>>>> Research and Innovation
>>>>> This email contains BT information, which may be privileged or confidential.. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
>>>>> We monitor our email system, and may record your emails.
>>>>> British Telecommunications plc
>>>>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
>>>>> England no: 1800000
>>>>> 
>>>> 
>>> 
>> 
>