Draft: draft-trammell-taps-interface

Commentary: 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 was n'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 . 
 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 would n'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 ? 
 : first , I did n'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 '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 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 is n'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 .
Paragraph (version A):
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.
Paragraph (version A):
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.