On 13/12/2016 09:13, Michael Welzl wrote:
Hi,
This direction definitely makes sense to me, too. I see some tension here, though - on
the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering
right. On the other hand, applications tend to want to know a message size that doesn't
get fragmented along an IPv4 path (as identified by the authors of
draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services).
Raising the abstraction level is fine, but I think Joe's suggestion below
misses something.
In an earlier email, Joe wrote about these two sizes:
***
1) the size of the message that CAN be delivered at all
2) the size of the message that can be delivered without network-layer
fragmentation
***
and stated that 2) should not be exposed.
So, in the proposal below, "largest transmission size" is 1) from above, and sending it
would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE.
So this is how the application would then do its own form of PMTUD.
Given that we don't know which protocol we're running over, probing strategies
that involve common MTU sizes (like using the table in section 7.1 of RFC1191)
can't work. So it's not the world's most efficient PMTUD that applications will
be using, to eventually find the value of 2).
A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which
would have less overhead than requiring applications to do their own PMTUD. => If we have to
"go dirty" anyway, which we already do by exposing the binary "native transmission
desired", why not offer the value of 2) as well?
In other words: how is this boolean better than offering 2) ?
Cheers,
Michael
On 12 Dec 2016, at 21:53, Gorry (erg)<[email protected]> wrote:
This is fine - it looks a like what I pointed to in the DCCP spec. But
specifically, I agree you don't need the DF flag visible - if you have a way
to convey the info needed to set the flag at the transport (and anything else
appropriate -as you note). I am all in favour of such appropriate abstraction.
Gorry
On 12 Dec 2016, at 19:09, Joe Touch<[email protected]> wrote:
On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:
IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.
How does the App handle probes for path MTU then in UDP?
Gorry
I think there needs to be two parts to the API:
- largest transmission size
- native transmission desired (true/false)
If the app says "YES" to native transmission size, then that would suggest that
UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not
only set DF=1, but also not source fragment.
I.e., I don't think it's the app's job to know how to explicitly control a mechanism two
layers down, and DF isn't really what you want anyway. DF isn't the same as "don't
source fragment".
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
So I'd like to return to RFCs that have been through part of this
discussion before,
(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.
(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.
(3) Apps need to be allowed to fragment datagrams more than MPS - This
is not expected as the default, the stack needs to be told.
(4) Apps need to be allowed to not allow datagram fragmentation - The
stack needs to be told. You could do this by using the DF semantics
(i.e., don't source fragment a DF-marked packet). Thinking more, this
seems the easiest.
Sorry, if this goes over what I said before, but I think we should first
explore the approaches that have already been put forward in RFCs
(alebit these were not RFCs about UDP).
Gorry
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
