Draft: draft-ietf-taps-interface

Commentary: Alternate fix for fragmentation / segmentation prohibited in a single message property , per discussion . Merge only one of these . :) 
 Discussion on identified that we probably want a Message ( and/or Connection ) property that forces  on for IPv4 ( and , I guess , ensures that datagram sends on IPv6 below MTU will fail , by disabling sender fragmentation , as well ) . 
 This should also prevent IPv4 sender fragmentation . It 's possible to generate IPv4 fragments from the stack with the DF set . I think the property should default to do this , and I 'd suggest " ALLOW Network Fragementation " as a suggested name . 
 This has to be a Message Property , however , we expect programmers to typically set this property on a Connection or Preconnection ( as default for all messages ) . 
 so you say " network fragmentation " . This excludes fragmentation in the host , which we may also want to control if we want to send unfragmented PMTU - sized packets . On the other hand , if this includes fragmentation in the host , your suggested default will always fail for TCP when I send messages PMTU , yet in case of a TCP - like service I really do n't want to care about this . = My suggestion would be to just to drop the word " network " and ( alas ) NOT make forbid - fragmentation the default . it has to be a Message Property , yes . But what makes you say that you 'd expect programmers to typically set this on a Connection or a Preconnection ? 
 the only use case to set this on a per - message basis I can image is PMTU discovery and I hope this is usually done by the transport system implementaion 
 I agree with you but do n't see the relationship with setting that on a Connection or Preconnection . 
 Agreed to the general point that this is a useful property ! To the discussion of where it goes , I agree with We had discussed letting defaults for Messages be set connection - wide for convenience , so I think the point is that this would commonly be set as a convenient default , rather than having the application set it over and over . 
 After reading again , I get the feeling we actually need two properties : Allow Fragmentation for the Messages passed to the transport service . Allow IP level Fragmentation for the Packets generated by the transport protocol . Now it becomes ugly : For UDP , both are equivalent . For TCP / QUIC , the former set to false means that sending a message should fail if the exceeds the PMTU after passing the framer . This also implies that a message should be sent within a single packet . For TCP / QUIC , the latter set to false means that the transport system should set the DF flag for v4 and disable local fragmentation for v6 , but the transport protocol can still split a message into multiple packets . While the former definitely works as discussed so far , I have no idea what should happen if the latter is set to false on a message but the former is set to true … 
 Not sure about QUIC , but what you say here about TCP is n't right : none of this should matter to TCP , you ca n't control DF with it and the PMTU should n't be visible to the application . 
 More on philsbln 's note above : I 'm putting TCP aside , and assuming he 's right about QUIC : 1 ) The former set to false , but the latter to true : " a message should be sent within a single packet " - but then we want to be able to allow network - layer fragmentation ? That seems strange to me . 2 ) The latter set to false , but the former to true : so here we want the DF flag , but it 's still ok to split messages across multiple packets . Again , that seems strange to me . = I struggle to see a use case for any of these combinations . My proposal would be to have only one boolean property that controls both IP- and transport - level fragmentation ( allowing or forbidding both ) . 
 while I was writing , I also came to think that this should be a single message context property whose implementation was context - dependent made more sense . I 'm happy to rework along these lines . 
 I may have confused people - but I too think it is OK to express this as one property . I think there are subtle differences , but such details are not important to TAPS . ( Any app needing finer control will likely need to control more than this ) . 
 this alternative is in 
 Very nice ! Thanks a lot for doing this !
Paragraph (version B):
This property specifies that a message should be sent and received as
a single packet without transport-layer segmentation or network-layer
fragmentation.  Attempts to send a message with this property set
with a size greater to the transport's current estimate of its
maximum transmission segment size 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.