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

2016-12-09 Thread Joe Touch
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

2016-12-09 Thread Michael Tuexen
> 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

2016-12-09 Thread Joe Touch
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

2016-12-09 Thread Michael Tuexen
> 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

2016-12-09 Thread Michael Tuexen
> 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

2016-12-09 Thread Joe Touch
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

2016-12-09 Thread Michael Welzl
> 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

[Taps] Document Action: 'Services provided by IETF transport protocols and congestion control mechanisms' to Informational RFC (draft-ietf-taps-transports-14.txt)

2016-12-09 Thread The IESG
The IESG has approved the following document: - 'Services provided by IETF transport protocols and congestion control mechanisms' (draft-ietf-taps-transports-14.txt) as Informational RFC This document is the product of the Transport Services Working Group. The IESG contact persons are Mirja

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

2016-12-09 Thread Joe Touch
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

2016-12-09 Thread Michael Welzl
> 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