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
