Change:
This API says: Need to clarify if this is a timeout for connection establishment (i.e., how long should the endpoint wait before declaring that failed), or it it's a timeout for data transfer after a connection has been established?
Before you do Initiate, it's the timeout for establishment. After the connection has been established, it's the timeout for data transfer. It was my idea that one notion of a timeout is enough - you will never need both in parallel for the same Connection or Preconnection.
Those seem like two very different timeouts, and ones for which the application may have very different tolerances. Personally, I’ve been averse to giving timeout knobs in general, since choosing good timeouts is hard, and a knob makes developers think they need to turn it. Most of the time, no timeout is best (talk to Stuart). Beyond that, any establishment or receive timeout can just as easily be implemented in the application as they wait for their Ready or Receive Complete event. This knob is a convenience to re-arm a timer, not really a transport service itself.
Move to Appendix A, then?
I agree that these timeout values may be quite different; maybe merging them into only one parameter wasn't a good idea. About this: Let me try to understand this: do you mean to say that the TCP User Timeout should simply be set to a huge number, large enough to basically never fire, and then it's up to the application to decide when to give up? I'd have to think about this... note that this comes via the TCP RFCs => RFC 8303 => minset path, it's not my invention.
NAME I'm not arguing against TCP having a timeout option, but the discussion of this option in the API—especially as a one top-level, cross protocol, all-encompassing timeout—was going in a direction of adding timeouts where we wouldn't otherwise have them. If we had a timeout on overall connection establishment, from Initiate() to Ready(), then that's trying to set a timeout not just on TCP, but on DNS, racing, proxies, TLS, and who knows what else. I tend to see the timeout value as a specific protocol option if anything; sure, you can set a timer on any protocol you want, but is that really a benefit to the application? If a protocol behaves differently than TCP in the future with regards to how it acknowledges data, should setting the TCP User Timeout for how long data can be un-acked apply to this future transport, or are we starting to ossify it?
NAME : first, I didn't think about the timeout being so all-encompassing (DNS, racing, etc.) - but you're right, the way we have it, it becomes like that, and this sure sounds like a horrible idea. So I agree that this should only be a specific protocol option if anything. Regarding "if anything", I understand your arguments and tend to agree with them, too. However, I'm just a little careful about things coming from minset - I think that we must have sound arguments to remove them, of the style "functionality XY covers this, and it can be dealt with inside the transport system because ...". After all, the UTO exists for a reason... Noticing your thumb up for NAME 's suggestion to move this to appendix A, I think we're all in agreement on this approach for now.
Yeah, totally fine with this being in Appendix A for now. Definitely merits more discussion.
see
(mutating this issue to be the place to discuss these options)
It seems we must discuss this more for a different type of timeout. Right now, we have, as the only generic thing: "Timeout for aborting Connection". The description says: "This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment." The "during establishment" part is awkward: as NAME said above, these are quite different timeouts, where the application may have different tolerances. From minset (see appendix C), we need to support: "Specify number of attempts and/or timeout for the first establishment message:" ... and it seems to me to be a reasonable thing to add - sure, the default should be large enough for all these fun types of racing to take place, but if an application is very intolerant of waiting to get a connection, it should be able to say so, right? So my proposal is to remove the "during establishment" text from "Timeout for aborting Connection", and add "Timeout for aborting Connection establishment" (I think number of attempts isn't necessary and just gets silly as a generic thing when we're in fact trying multiple interfaces and protocols), with the description "This property specifies how long to wait before aborting a Connection during establishment."
Suggest adding a reference to the GitHub issue in the appendix, along with the text, to remind us that there's more to do here. Otherwise looks good.

Discussion:
Connections into a Connection Group over a single flow.  This is not a strict requirement.  The default is to not have this option. <del> Suggest a timeout to the Remote Endpoint: This boolean property specifies whether an application considers it useful to propose a timeout until the connection is assumed to be lost.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data

establishment, or before deciding that a connection has failed after establishment.  It is given in seconds. <del> Abort timeout to suggest to the Remote Endpoint: This numeric property specifies the timeout to propose to the Remote Endpoint. It is given in seconds. </del> Retransmission threshold before excessive retransmission notification: This numeric property specifies after how many retransmissions to inform the application about "Excessive