While TCP/IP takes care of lossless and ordered sending of messages, they can still get reordered on the receiver side by the thread pool sending up received messages concurrently. UNICAST3 makes sure that unicast messages are delivered in per sender FIFO order. See  for details.
FRAG3 creates messages fragments that are never bigger than the max_credits size in MFC/UFC and the max_bundle_size in the transport. *If* you set max_bundle_size to the largest message you ever send, remove UFC and FRAG3 and have TCP as transport, then that might probablywork as well... However, as messages are stored in retransmission tables, which are purged only when all members have received them, it is probably better to have smaller-sized messages. Granted, not really relevant for unicast messages.
Thanks for the answer.
So for TCP would it be possible to have ordering of messages without paying additional overhead of acks produced by UNICAST3 that are used to implement lossless transport?