One piece of potentially important information:
PMTUD and PLMTUD are intended to avoid the need for on-path
fragmentation. That's why there is control only over the DF bit, not
source fragmentation.
AFAICT, this points to a (AFAICT) a problem with IPv6 PMTUD as described
in RFC1981. That doc clai
Hi, Gorry,
Let me see of I can explain my viewpoint.
I'll start by noting that there's a difference between "what transports
currently do" and what they "should" do. I agree with you that current
transports do have access to network MTUs and DF control, but don't
always pass all that to the user.
It seems we can not find a common basis here. See below:
On 14/12/2016 01:23, Joe Touch wrote:
On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:
...
(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 m
On 12/13/2016 5:34 AM, Gorry Fairhurst wrote:
> ...
>>>
>>> (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.
All
On 13/12/2016 12:53, Michael Welzl wrote:
On 13 Dec 2016, at 11:05, Gorry Fairhurst wrote:
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 lay
> On 13 Dec 2016, at 11:05, Gorry Fairhurst wrote:
>
> 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 ot
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
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 iden
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 abs
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 U
On 12/12/2016 18:50, Joe Touch wrote:
On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:
So what does that mean: that the API should contain a "don't
fragment" flag from the application?
Definitely.
The use of DF in a datagram protocol is per-datagram decision -
depending on what the app needs
On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:
>>
>> So what does that mean: that the API should contain a "don't
>> fragment" flag from the application?
>>
> Definitely.
>
> The use of DF in a datagram protocol is per-datagram decision -
> depending on what the app needs to happen.
>
> gorry
IMO
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 wrote:
>>
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 12/9/2016 8:12 AM
> 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 handled arbitrary sized
user me
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 wrote:
>>> On 09 De
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
> 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: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: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 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 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: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 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: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 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 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 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
> 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 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 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-
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 tunn
Not quoite answering this question, but for DCCP this is clearly also a
transport understanding of the maxmium datagram size, as in RFC 4340:
"A DCCP implementation MUST maintain the maximum packet size (MPS)
allowed for each active DCCP session."
and
"The MPS reported to the application SHOUL
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_INTERFACE_MTU function a network-layer
function that indicates
34 matches
Mail list logo
