Draft: draft-ietf-taps-interface

Commentary: This and addresses a comment about soft errors by in : " Notification of Excessive Retransmission " is made a Selection Property There 's now an " Excessive Retransmission " Event ( just like the one for Soft Errors ) The preference to receive Soft Errors is also made a Selection Property 
 Oops sorry , will fix 
 - the latter was exactly my thinking . if someone does n’t want these notifications they can just ignore them . 
 I think we should not standardise this . I also do n't think that IETF transports typically provide this control , nor do I think this is really useful to have . So I 'd argue the API should be silent about these three things ! 
 I agree with  that you can probably remove them . If anything I would see it as a Connection properties , not as Selection properties . How likely is it that you will have two transport stacks to select from where one supports soft errors the other not and this is what you will want to use to make a decision ? Does not seem like a strong use case . 
 To  's point , how widely do we expect these to be supported for various protocols ? And is the meaning of excessive retransmits consistent across protocols that do retransmission ( TCP , SCTP , QUIC ) ? 
 I certainly agree that it seems unlikely that someone will want to insist on a transport that offers " Notification of Excessive Retransmission " . Removing this selection property is fine by me . Regarding soft errors , I could agree but I 'm less sure - so just to double check , are we really all sure we do n't want to offer this kind of control ? What if applications really want to be able to receive ICMP messages , e.g. to insist on doing their own PMTUD ? mentions that , if anything , they should be Connection Properties : I agree with that ; they were both Connection Properties before , but with unfitting wording ( fixing this was a part of this split ) . I think they should both be described as events , like we already have it for soft errors only : https://taps- We should n't remove them altogether : if we did , this would AFAIK be our only divergence from minset . To answer question , I do nt know what most implementations do about these two things - but here 's a spec backtrace that talks about TCP and UDP ( for other protocols , " do nothing " is a safe choice here I guess ): About " Notification of Excessive Retransmission " , minset 's Appendix A.1 says : o Notification of Excessive Retransmissions ( early warning below abortion threshold ) Protocols : TCP Optimizing because it is an early warning to the application , informing it of an impending functional event . Implementation : via ERROR.TCP . Implementation over UDP : do nothing ( there is no abortion threshold ) . RFC 8303 , section 4.1 ( " pass 2 " ) , says about ERROR.TCP : " The reported conditions include at least : ICMP error message arrived and excessive retransmissions . " For the soft errors bit , minset also points at ERROR.UDP(-Lite ) , which , in RFC 8303 , is described to just return soft errors , nothing else . For both protocols , the text points back at " errorreport " from pass 1 , which in TCP 's case points back at section 4.2.4.1 in RFC 1122 : The text also refers to RFC 5461 which may provide more information regarding question . For soft errors from UDP , we need to look at " errorreport " in RFC 8304 , which quotes section 4.1.4 or RFC1122 to say : " UDP MUST pass to the application layer all ICMP error messages that it receives from the IP layer . " and goes on to explain that this is necessary to implement ICMP - based PMTUD . 
 As discussed in 
 Looks good to me . I think there was the idea to have an additional Connection Property , which allows to turn the soft errors on or off on an existing Connection . Do we want to standardize this additional Connection Property as well , or is this too much and we leave it up to the implementation whether such a thing exists ? I tend towards the latter , as I consider this just a convenience function .
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold.  The recommended default is to have this option.
Paragraph (version B):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors.  Note that even if a protocol
supporting this property is selected, not all ICMP errors will
necessarily be delivered, so applications cannot rely on receiving
them.  The recommended default is not to have this option.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed in case sent data was retransmitted more often than a
certain threshold.  When set to true, the effect is twofold: The
application may receive events in case excessive retransmissions.  In
addition, the transport system considers this as a preference to use
transports stacks that can provide this notification.  This is not a
strict requirement.  If set to false, no notification of excessive
retransmissions will be sent and this transport feature is ignored
for protocol selection.
Paragraph (version A):
This property specifies whether an application considers it useful to
be informed when an ICMP error message arrives that does not force
termination of a connection.  When set to true, received ICMP errors
will be available as SoftErrors.  Note that even if a protocol
supporting this property is selected, not all ICMP errors will
necessarily be delivered, so applications cannot rely on receiving
them.  Setting this option also implies a preference to prefer
transports stacks that can provide this notification.  If not set, no
events will be sent for ICMP soft error message and this transport
feature is ignored for protocol selection.
Paragraph (version A):
This property applies to Connections and Connection Groups.  The
recommended default is not to have this option.
Paragraph (version A):
Asynchronous introspection is also possible, via the SoftError Event.
This event informing the application about the receipt of an ICMP
error message related to the Connection.  This will only happen if
the underlying protocol stack supports access to soft errors;
however, even if the underlying stack supports it, there is no
guarantee that a soft error will be signaled.