> On 09 Dec 2016, at 16:18, Joe Touch <to...@isi.edu> wrote: > > > > On 12/9/2016 12:09 AM, Michael Welzl wrote: >>> 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. > > To figure out 2), the transport layer needs to know the unfragmented > link MTU, the size of all of the network headers (including options), > and the sizes of its own headers and options. > > It's also sometimes assumes that the transport can control the "DF" bit > (for IPv4).
Yes - but that hardly sounds worse to me than requiring the application programmer to do this protocol-specific calculation by hand... > However, this all breaks down if the app makes the wrong choice because > the net can (will, and should) source fragment if it gets a message that > turns out to be too big for one fragment anyway. > >> Not a big deal - and maybe some systems offer a function to give you the >> size of a message that won't be fragmented. > > Remember that - at best - you're optimizing for the next layer down > only. You can't know whether that net layer message is link fragmented > (e.g., as in ATM) or tunnel fragmented (as needs to be required or this > whole MTU concept breaks down). Sure - but that's something end systems just can't see. It's information up to and including the IP layer that should be correctly handed over up the stack, inside the host, with all the caveats this information comes with. >> However: this calculation is transport protocol dependent, which we really >> don't want to have in TAPS. > > If you want to fix this, you need to change the API to the net layer to > provide immediate feedback. When transport hands a segment to network, > it has to get a "call failed" if the message is too big - and we really > do need transport layers to be able to pick between "too big for > non-fragmented net layer" and "too big for the net layer even with frag". > > Merely handing info to the transport layer might not be enough, esp. > when net layer option lengths change. True if you want to cleanly fix it across the RFC-specified stack, but that's beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does that make sense? Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
