Hi, Gorry,
Let me see of I can explain my viewpoint.
I'll start by noting that there's a difference between "what transports
currently do" and what they "should" do. I agree with you that current
transports do have access to network MTUs and DF control, but don't
always pass all that to the user.
Here's what I think is currently required:
1122 indicates the interface between IP and transport as indicating the
max send and receive transport sizes - but for IPv6 that would be 1500 -
IPheaders, not 1280 - IP headers or even 1500 or 1280.
1122 also indicates that the transport - not the application - gets to
set DF in the SEND call to IP.
However, there does not appear to be any provision to limit source
fragmentation between transport and IP, nor any requirement for UDP to
pass that control to the app.
----
So 1122 is consistent with my view that:
- the application sees a transport MSS (I'm not sure whether to call
that max or native yet...)
- the transport sees the max network MSS (i.e., allowing source
fragmentation), not the native network MSS
I don't understand why 1122 requires transport control over DF, but UDP
is not required to pass that control to the user.
---
My conclusion is that the app-transport API *should* be required to give
the user control over whether to use the max or native transport MSS,
just as the transport-API should be required to give the transport
control over whether to use the max or native network MSS, and so forth
for the network-link API.
However, none of that implies that the user ever will be able to match
the link MTU. There's always the possibility that one of these layers
decides to never report a true native size, e.g., ATM (as a link layer)
never reports 48 to IP.
This means that apps can't ever really force a probe of much of
anything, too. Only transports can.
(FWIW, when I say that UDP doesn't support fragmentation, I mean that
UDP doesn't have UDP fragmentation. The fragmentation is at the IP
layer; UDP is ignorant of it).
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
