> On Oct 15, 2018, at 11:41 AM, Templin (US), Fred L > <[email protected]> wrote: > >> It would be interesting to see the reall world case where >> fragmentation can do better or as good (either in goodput or >> performance), but I'm doubtful that exists. > > One of the applications I am referring to works over space links where there > are long delays, but no congestion and hence little/no IP packet/fragment > loss. > This is a case of a long, fat network (LFN) and because there is significant > delay > (reliable) UDP is used instead of TCP.
So the issue isn't fragmentation, it is the ability to carry streams of packets. Fragmentation becomes a way to create and consume streams of packets. If the space-based application is the one I'm thinking of (SCPS), the fundamental reasons it doesn't use TCP is because of the RTT when setting up a session, and the number of RTTs that have to happen before a session develops a reasonable estimate of channel capacity. It operates as command/telemetry - the sending application sends a sequence of enumerated packets, the receiving application reports what it receives, and the sending application retransmits the subset that didn't make it through. I find myself thinking of RFCs 2525 and 2760. What I know about such applications tells me that you *have* to have an estimate of channel capacity and the ability to, in essence, have an open and operational channel when you need it - such as sending a burst of segments from Pluto to Earth without session set-up or capacity estimation, and very probably operating in a command/telemetry model in the application. I have no problem with space-based protocols or applications. However, at some point I wonder whether the tail is wagging the dog, so to speak. To make these applications work, NASA and others modify the protocols or substitute entirely new ones. If the protocol specification is a point of departure, I don't see any reason that space-based applications can't say "unlike our terrestrial counterparts, we do use fragmentation and reassembly".
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
