Draft: draft-ietf-taps-interface

Commentary: I 'm not 100 % sure , but I believe the DF bit applies only to intermediate hops , not to the originating machine . E.g. , if you have DONTFRAG set on your socket ( or at the system level via pmtud ) and shove 60 K into a sendto ( ) call , the kernel will still happily chop your datagram into multiple < = 1500 octet packets . So , the text in § 8.1.3.9 is probably misleading . 
 I 'm not sure if this makes the text misleading ? The text only says that " a message should be sent and received as a single packet without network - layer fragmentation , if possible . " It may not be possible ... there 's also this sentence : " When used with transports supporting this functionality and running over IP version 4 , the Do n't Fragment bit will be set . " - consider the first half of the sentence : the functionality is constrained to being offered only over transports that provide this precise functionality . 
 I think the text is literally correct , but misleading in that it implies a level of actionability that does n't appear to be in evidence . Unless you have a means to know path MTU , you ca n't adjust your message length to avoid fragmentation or drop , so what good does this do other than result in drops vs. path fragmentation in IPv4 ? This will have zero effect on IPv6 , for instance . 
 I 'm confused about the confusion . What is being asked ? 
 I think I 'm asking for an example of where this property would make a difference to the wire image , other than in the DF - set case on IPv4 where intermediate hops will drop rather than fragment . 
 I think that this is really mainly about DF / IPv4 . But , if you think of a protocol like SCTP which stuffs messages into packets , this protocol could theoretically decide that message X should not be placed such that the first half of it goes into packet 1 and the next half into packet 2 , but that packet 1 should just be shorter and the whole message X should go into packet 2 instead . This is transport - layer fragmentation , not network - layer fragmentation , though . Perhaps " network - layer " should be removed from the text ? This should be safe to do as long as we do n't make any promises . 
 I do n't think we should conflate transport segmentation of data with network - layer fragmentation . These have different purposes . A source host still has the choice to fragment at the network - layer to the PMTU , by the way , even when DF is set - as in IPv6 . Protocols like STUN might use this to control which packets are sent with fragmentation at the sender to the PMTU , and which carry control packets to probe for a larger PMTU . 
 Sure the host can at the network layer anyway ; we 're not giving any guarantees against that . Fine not to conflate - but then the semantics of the text in § 8.1.3.9 really only translates into : " in case of IPv4 , DF=1 " . I think this is fine - it seems  wants more , but why ? Or should the text more bluntly say " IPv4 DF=1 " perhaps ? 
  , that 's basically what I 'm arguing . The only lever TAPS has is over intermediate hop behavior on IPv4 , reducing the whole property to " sets DF=1 on IPv4 " . I also agree with  re : segmentation vs. fragmentation . Do we need text re : segmentation for protocols like SCTP and QUIC ? 
 The minset part for the transport layer thing is called " request not to bundle messages " ; the minset appendix currently identifies that the " No Fragmentation " message property conflates this with network layer fragmentation . I suggest that I 'll fix this , by : the " No Fragmentation " text a little bit , just to more bluntly state that this is really only about IPv4 DF a Message Property that has just the transport - layer " request not to bundle messages " semantics . That should do the trick , I believe . 
 Should n't the default value for every message property basically be " inherit " , i.e. , from the connection ? : This is a bit awkwardly worded . If this is supported for both reliable and unreliable transports ( unclear ? ) , then : For reliable transports , this means that this message will not be delivered to the application until all previous ordered messages on the connection are delivered . For unreliable transports , this means that any message prior to this one in ordering but received subsequently will not be delivered to the application . 
 Multiple things here . Default : interesting idea , I tend to say " yes " . About § 8.1.3.3 : This is meant to support both reliable and unreliable transports - why this unclear ( why would n't it support both ) ? IIRC this was me , borrowing the wording from SCTP which also covers both of these cases ( reliable and unreliable ) . I like your description ( at least the one for reliable transports ) , but I think it 's good to be explicit about the relationship to the Send Action . How about this , maybe simpler to read and still generic : 
 be preserved on delivery via Receive < events for all Messages ... ? 
 We got us a deal ! :-) Seriously , this is better and clearer , thanks ! Will fix 
 Seeing the number of this issue , it 's clear to me that you chose the wrong issue when you wrote " For the love of Satan " . 
 Just a note regarding : you said that the default for every message property should basically be " inherit " ; checking them carefully one by one showed me that this is only a reasonable decision for three of them : Ordered , Reliable Data Transfer ( Message ) and Message Capacity Profile Override . E.g. , a default of using less than a full checksum does n't and probably should n't exist anywhere . Any default other than " False " for " Final " ( last Message of the connection ) really does n't make a lot of sense ( only the application would know that it has only one Message to send ) . ... and so forth . 
 You are technically correct , which is the best kind of correct . I basically meant that message properties that are used to override the same property at the connection level should default to " inherit " . 
 Looks like these issues have been addressed in this PR
Paragraph (version A):
If true, it specifies that the receiver-side transport protocol stack
only delivers the Message to the receiving application after any
existing previous ordered Message that was passed to the same
Connection via the Send Action.
Paragraph (version B):
The order in which Messages were submitted for transmission via the
Send Action will be preserved on delivery via Receive<> events for
all Messages on a Connection that have this Message Property set to
true.
Paragraph (version A):
This property specifies that a message should be sent and received as
a single packet without network-layer fragmentation, if possible.
Attempts to send a message with this property set to a size greater
than the transport's current estimate of its maximum packet size
("singularTransmissionMsgMaxLen") will result in a "SendError".  When
used with transports supporting this functionality and running over
IP version 4, the Don't Fragment bit will be set.
Paragraph (version B):
This property specifies that a message should be sent and received as
a single packet without network-layer fragmentation, if possible.
This only takes effect when the transport uses a network layer that
supports this functionality.  When it does take effect, setting this
property to true will cause the Don't Fragment bit to be set in the
IP header, and attempts to send a message with this property set to a
size greater than the transport's current estimate of its maximum
packet size ("singularTransmissionMsgMaxLen") will result in a
"SendError".
Paragraph (version B):
When set to true, this property requests the network layer at the
sending endpoint to not fragment the packets generated by the
transport layer.  When running over IPv4, setting this property to
true will also cause the Don't Fragment bit to be set in the IP
header.  When this property is set, an attempt to send a message size
greater than the transport's current estimate of its maximum packet
size (singularTransmissionMsgMaxLen) will result in a SendError.
This only takes effect when the transport and network layer support
this functionality.