Subject: [tsvwg] Erik Kline's No Objection on draft-ietf-tsvwg-rfc4960-bis-17: (with COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 15 Dec 2021 16:56:04 -0800

Erik Kline has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-bis-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[general; comment]

* I suspect that my notion of {src,dst} transport address tracking doesn't
  align with the model under which this was developed.  There are several
  places where parameters associated with a given destination address might
  be tracked on a {src,dst} basis, at least for implementations for which the
  accompanying complexity was deemed justified.

  Some observations are made in this context; I don't expect they need to be
  considered at this (bis) point in time.

[S2.7; nit]

* s/Describe ... more precise/Describe ... more precisely/

[S5.2; question]

* In light of Path Verification discussion in 5.4 is one of the reasons
  that a (duplicate) COOKIE-ECHO chunk might arrive a consequence of
  path probing during connection setup?

[S5.4, S7.3, S8.3; question]

* Is the assumption here that there will be only be one source address
  selected for each proposed destination address?  I would have thought
  that if the INIT and INIT-ACK each had multiple IP addresses that the
  probed paths (and thus paths along which PMTU discovery would be
  performed) could in fact be the union of the Cartesian cross product of
  all {INIT} x {INIT-ACK} addresses of matching address family.

[S6; nit]

* At first I thought "out of the blue" might be replaced with something
  less idiomatic for non-native English readers, but I see that S8.4
  goes so far as to craft the OOTB acronym.  Perhaps add this phrase and
  a one-sentence summary (and maybe a link to S8.4) to the list of key terms
  in Section 2.3.

[S6.5; question]

* Does this mean that the first unordered user message within a stream
  uses a Stream Sequence Number of previous+1 and that all subsequent
  unordered messages on that stream MUST use the same sequence number
  (of that first unordered message)?

  (The fact that unordered messages don't cause an increase in sequence
  numbers struck me as a bit odd/unnecessary.)

[S8.2; nit]

* s/user ought avoid/user ought to avoid/

[S11.1.5; comment]

* It may be too late, but it seems like an optional

      [,source transport address]

  might be part of the API for platforms that might want to allow sending
  from more than one validated/active source address.

[S11.1.7; comment]

* It may be too late, but should there be an optional local transport
  address to indicate at which local address a message was sent?

  I get that packets might arrive at multiple local addresses, but given
  that (I think) they can be sent from multiple remote addresses and there
  is a parameter to return the sender's address, I just thought...

[S11.1.9; comment]

* It may be too late, but should there be an optional source transport
  address parameter as well?

[S11.1.10; comment]

* It may be too late, but should there be an optional source transport
  address parameter as well?

---

From: [email-masked]
Date: Thu, 23 Dec 2021 11:44:10 +0100

> On 16. Dec 2021, at 01:56, Erik Kline via Datatracker <[email-masked]> wrote:
> 
Hi Erik,

thanks for you comments. See my answers inline.

Best regards
Michael
>  accompanying complexity was deemed justified.
The specification was designed without assuming that the sender can control
the source address. If the sender can control the source address, you can do
things differently, but this requires several changes and some procedures
change from O(n) to O(n*m) (where n is number of remote addresses and m is
the number of local addresses).
Please note also, that for the initial use case, it was assumed that the
nodes are connected via n networks, which are independent and do not allow
cross routing. So the additional complexity would not give you anything.
This might have changed and there was an indication by Ericsson that they
might come up with a specification on how to implement SCTP with your
suggested {src,dst} tracking. I would expect such a node to be interoperable
with a node compliant to this specification.
> * s/Describe ... more precise/Describe ... more precisely/
Fixed.
>  path probing during connection setup?
No, path probing is not done via COOKIE-ECHO. Receiving a duplicate
COOKIE-ECHO is normally related to retransmissions or duplications in
the network.
>  all {INIT} x {INIT-ACK} addresses of matching address family.
It is assumed that the IP implementation selects the source address, not the
SCTP implementation. It is further assumed that the selection done by
the IP implementation only changes slowly.
The goal of path verification is to check if the peer really owns an address
it pretends to own. For PMTUD it is assumed that the source address selected
by the IP stack only changes rarely. Same applies for path supervision. It is
checked if the peer address is reachable using the source address selected
by the IP implementation.
>  a one-sentence summary (and maybe a link to S8.4) to the list of key terms
I added:
<dt>Out Of The Blue (OOTB) Packet:</dt>
<dd>
<t>A correctly formed packet, for which the receiver can not identify the
association it belongs to.
See <xref target='sec_handle_out_of_the_blue_packets'/>.</t>
</dd>
>  numbers struck me as a bit odd/unnecessary.)
Section 6.6 contains:

The 'Stream Sequence Number' field in a DATA chunk with U flag set to 1
has no significance. The sender can fill the 'Stream Sequence Number'
with arbitrary value, but the receiver MUST ignore the field.

In FreeBSD, we just use 0 when sending unordered DATA chunks.
> * s/user ought avoid/user ought to avoid/
Fixed.
>  from more than one validated/active source address.
This depends on the ability to control the source address. Since this is
not assumed, the source address can't be selected here.

Please also note the you can't specify the source address in the SCTP
socket API defined in RFC 6458.
>  is a parameter to return the sender's address, I just thought...
Same as above. Also not specified in RFC 6458.
>  address parameter as well?
See above.
>  address parameter as well?
See above.