> On 07 Dec 2016, at 20:29, Joe Touch <to...@isi.edu> wrote: > > FYI, there are two different "largest messages" at the transport layer: > > 1) the size of the message that CAN be delivered at all
True... I wasn't thinking of that, but yes. > 2) the size of the message that can be delivered without network-layer > fragmentation (there are no guarantees about link-layer - see ATM or the > recent discussion on tunnel MTUs on INTAREA) > > MTU generally refers to the *link payload*. At that point, transports > have to account for network headers, network options, transport headers, > and transport options too. See RFC6691. > > MSS refers to the transport message size AFAICT. It is *sometimes* tuned > to MTU-headers but not always. > > E.g., for IPv6, link MTU is required to be at least 1280, but the > src-dst transit MTU is required to be at least 1500. So a transport that > wants to match sizes and reduce fragmentation issues would pick > 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust > that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. I conclude: a TAPS system must implement a local function to provide this information, both 1) and 2) above. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
