Re: [Taps] MTU / equivalent at the transport layer

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

Re: [Taps] MTU / equivalent at the transport layer

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

Re: [Taps] MTU / equivalent at the transport layer

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

Re: [Taps] MTU / equivalent at the transport layer

On 12/12/2016 1:31 AM, Michael Welzl wrote: > Hi, > > Just trying to understand, so we're not talking past each other. Please note > that I'm not trying to argue in any direction with my comments below, just > asking for clarification: Sure... > >> On 09 Dec 2016, at 18:32, Joe Touch

Re: [Taps] MTU / equivalent at the transport layer

On 12/12/2016 09:31, Michael Welzl wrote: Hi, Just trying to understand, so we're not talking past each other. Please note that I'm not trying to argue in any direction with my comments below, just asking for clarification: On 09 Dec 2016, at 18:32, Joe Touch wrote: On

Re: [Taps] MTU / equivalent at the transport layer

> On 09 Dec 2016, at 23:13, Joe Touch wrote: > > > > On 12/9/2016 1:38 PM, Michael Tuexen wrote: >>> On 9 Dec 2016, at 22:30, Joe Touch wrote: >>> >>> >>> >>> On 12/9/2016 1:26 PM, Michael Tuexen wrote: Not sure what the reassembly limit is... SCTP

Re: [Taps] MTU / equivalent at the transport layer

Hi, Just trying to understand, so we're not talking past each other. Please note that I'm not trying to argue in any direction with my comments below, just asking for clarification: > On 09 Dec 2016, at 18:32, Joe Touch wrote: > > > > On 12/9/2016 8:12 AM, Michael Welzl

Re: [Taps] MTU / equivalent at the transport layer

On 12/9/2016 1:38 PM, Michael Tuexen wrote: >> On 9 Dec 2016, at 22:30, Joe Touch wrote: >> >> >> >> On 12/9/2016 1:26 PM, Michael Tuexen wrote: >>> Not sure what the reassembly limit is... SCTP handled arbitrary sized >>> user messages a the receiver side by using partial

Re: [Taps] MTU / equivalent at the transport layer

> On 9 Dec 2016, at 22:30, Joe Touch wrote: > > > > On 12/9/2016 1:26 PM, Michael Tuexen wrote: >> >> Not sure what the reassembly limit is... SCTP handled arbitrary sized >> user messages a the receiver side by using partial delivery. >> >> The SCTP_MAXSEG allows a user to

Re: [Taps] MTU / equivalent at the transport layer

On 12/9/2016 1:26 PM, Michael Tuexen wrote: > > Not sure what the reassembly limit is... SCTP handled arbitrary sized > user messages a the receiver side by using partial delivery. > > The SCTP_MAXSEG allows a user to limit the size of DATA chunks without > reducing the pmtu. Yes, but that size

Re: [Taps] MTU / equivalent at the transport layer

> On 9 Dec 2016, at 22:12, Joe Touch wrote: > > > > On 12/9/2016 12:28 PM, Michael Tuexen wrote: >>> ... In the API description in https://tools.ietf.org/html/rfc6458 the MTU exposed to the application via the API is "the number of bytes available in an SCTP

Re: [Taps] MTU / equivalent at the transport layer

> On 7 Dec 2016, at 15:54, Michael Welzl wrote: > > Hi all, > > I have a problem with one particular primitive, or lack of it, in UDP, > UDP-Lite and SCTP. It's something I just don't get. > > Consider this text from draft-fairhurst-taps-transports-usage-udp: > >

Re: [Taps] MTU / equivalent at the transport layer

On 12/9/2016 12:56 AM, Michael Welzl wrote: > These things can be achieved by only changing the implementation of > transports to locally provide some more of its internal information to a > system on top; they don't change anything on the wire... FWIW, we really need to stop using that phrase

Re: [Taps] MTU / equivalent at the transport layer

> On 09 Dec 2016, at 16:18, Joe Touch wrote: > > > > On 12/9/2016 12:09 AM, Michael Welzl wrote: >>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>> >>> FYI, there are two different "largest messages" at the transport layer: >>> >>> 1) the size of the message

Re: [Taps] MTU / equivalent at the transport layer

On 12/9/2016 12:09 AM, Michael Welzl wrote: >> On 07 Dec 2016, at 20:29, Joe Touch 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. > >

Re: [Taps] MTU / equivalent at the transport layer

> On 09 Dec 2016, at 09:46, Gorry Fairhurst wrote: > > On 09/12/2016 08:09, Michael Welzl wrote: >>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>> >>> FYI, there are two different "largest messages" at the transport layer: >>> >>> 1) the size of the

Re: [Taps] MTU / equivalent at the transport layer

FYI, there are two different "largest messages" at the transport layer: 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 (there are no guarantees about link-layer - see ATM or the recent discussion on