> 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.
> 2) the size of the message that can be delivered without network-
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 message that CAN be delivered at all
True... I wasn't thinking of that, but yes.
2) the size of the message that c
> 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 message that CAN be delivered at all
>> Tr
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.
>
>
>> 2) the size o
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
> 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 that CAN be delivered at all
>>
On 12/9/2016 8:12 AM, Michael Welzl wrote:
>> 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 siz
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
> 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:
>
> "GET_INTERFACE_MTU: The GET
On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>> 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-tran
> On 9 Dec 2016, at 21:23, Joe Touch wrote:
>
>
>
> On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>>> 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'
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 packet for
>>> chunks." I think this is the best
>>> we can do at that interf
> 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 packet for
chu
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 c
> 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 limit the size of
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 delivery.
>>>
>>> The
16 matches
Mail list logo
