On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:
> ...
>>>
>>> (1) I think we need a parameter returned to the App that is
>>> equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is
>>> useful to know how many bytes the app can send with reasonable
>>> chance of unfragmented delivery.
All we can know is whether it is unfragmented at the next layer down.
>>
>>> (2) It's helpful for Apps to be able to retrieve the upper size
>>> allowed with potential fragmentation - that could be useful in
>>> determinine probe sizes for an application. Apps should know the
>>> hard limt, In DCCP this is called the current congestion control
>>> maximum packet size (CCMPS), the largest permitted by the stack
>>> using the current congestion control method. That's bound to be less
>>> than or equal to what is permitted for the local Interface MTU. This
>>> limit lets the App also take into consideration other size
>>> constraints in the stack below the API.
>>
Again, next layer down only. We're generally talking about existing
transports that try to pass the link MTU up through network and
transport transparently, but that need not be the case. Keep in mind
that the link MTU for ATM AAL5 isn't 48B, it's 9K - i.e., it is the
message that the link will deliver intact, not the native link size.
...
> (3) Apps need to be able to ask the stack to try hard to send
> datagrams larger than the current MPS -
I disagree.
The app should see two values from transport:
A) how big a message can you deliver at all?
B) how big a message can you deliver "natively"?
Any probing happens between those two values.
> This is not expected as the default, the stack needs to be told to
> enable this use of source/router fragmentation and send IPv4 datagrams
> with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very
> small).
I disagree.
DF=0 is a network flag that should never be exposed to the app. Even if
it is, this wouldn't be the control the app really wants. The app would
want to prevent source fragmentation. DF=0 applies to IPv4 only and only
affects *on path* fragmentation.
But that's not the transport's job.
Consider this:
- transport has max and native message sizes
- network has max and native message sizes
- link has max and native message sizes
Every layer has these. Sometimes they're the same (when a layer doesn't
support frag/ressembly , e.g., UDP, Ethernet), sometimes they're not
(IP, TCP). Somtimes they're unlimited (TCP has no max message size, AFAICT).
> (4) Apps need to be able to ask the stack to send datagrams larger
> than the current MPS, but NOT if this results in source fragmentation.
Apps can control only transport fragmentation. They can't and shouldn't
see or control network or link fragmentation UNLESS transport lets that
pass through as a transport behavior.
> Such packets need to be sent with DF=1. - This is not expected as the
> default, the stack needs to be told to enable this - for UDP it would
> be needed to perform PMTUD. That's I think what has been just called
> "native transmission desired ".
The issue is that this is an interaction between the app and transport.
It has nothing to do with the network or link layers - unless the
transport wants it to. It's up to the transport to decide whether to try
to "pass through" the native network size. It's up to the network layer
to decide whether to "pass through" the native link size.
E.g., for IPv6, the lowest values to the answers above are:
A) 1500B, including IP header and options
B) 1280B, including IP header and options
That necessarily means that IPv6 over IPv6 cannot truthfully answer (B)
- it HAS to require the lower IPv6 to fragment and reassemble. Otherwise
it would be reporting a value that would make it no longer compliant
with RFC2460.
So we need to be careful about this - there really aren't 4 values here.
There are only two - the max and "native" *as reported by* the next
layer down.
There never has been and never can be a way that an app can solely
manage PMTUD to match network *unless* the transport passes that
information through. There never has been and never can be a way an app
can match to a link layer native MTU (otherwise, we'd be spinning MTUs
down to 48B for ATM).
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
