Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt

[Michael Tuexen <[e-mail]>]

On 18 Apr 2014, at 01:20, Joe Touch <[e-mail]> wrote:

> Hi, Michael,
> 
> On 4/17/2014 1:54 PM, Michael Tuexen wrote:
>> On 09 Apr 2014, at 23:36, Joe Touch <[e-mail]> wrote:
>> 
>>> Hi, Martin,
>>> 
>>> On 4/9/2014 12:13 PM, Michael Tuexen wrote:
>>> ...
>>>>>>> SCTP does RFC1191 only (PMTUD).
>>>>>> 
>>>>>> That is why the text explicitly requires RFC4821 for PMTU in SCTP.
>>>>> 
>>>>> RFC4821 talks about how SCTP *can* use the PAD chunk to do so, while avoiding retransmission if anything is lost - but I can't find anything that says that SCTP actually does this.
>>>> I read
>>>> http://tools.ietf.org/html/rfc4821#section-10.2
>>>> in way that is describes a method for doing PLMTUD with probe packets. It used the term RECOMMENDED, so
>>>> it is more strict than *can*. Or am I missing something?
>>> 
>>> RFC4821 doesn't update SCTP -- it doesn't update anything.
> >
>> Right.
>>> 
>>> I read that as "if SCTP generates probes, it SHOULD generate them using the PAD chunk attached to a min-len HB", and, later, "it MAY" do something like TCP does.
>>> 
>>> It doesn't mandate that SCTP do probes at all - or PLMTUD at all - though.
> >
>> That is why we write in this document that when you run SCTP over DTLS
>> as defined in this document, you MUST use the PLMTUD.
> 
> At the DTLS layer.
Either at the DTLS layer or at the SCTP layer.
> 
>> So this document
>> mandates what to do, it refers to other specs how to do it, but the
>> other documents don't mandate it.
>> Isn't that a valid way of doing it?
> 
> The way you describe it in Sec 4 is (emphasis mine):
> 
>   If path MTU discovery is performed by the *DTLS* layer, the method
>   described in [RFC4821] MUST be used.
> 
> But RFC4821 doesn't talk about DTLS. That's what's confusing me. It only talks about SCTP, and gives two methods - one using pads and one at the user level (like TCP).
> 
>   For probe packets, the
>   extension defined in [RFC6520] MUST be used.
> 
> Now you're back to talking about DTLS.
Have a look at
https://tools.ietf.org/html/rfc4821#section-10.4
Since DTLS is running on top of UDP, it qualifies as an
application in the sense of that section, I think.
In the second paragraph it talks about packets similar
to SCTP HB plus PAD. This is exactly what is described in
https://tools.ietf.org/html/rfc6520#section-4
> 
> I think what you might want to say is that:
> 
>   If path MTU discovery is performed by the DTLS layer, the method
>   described in [RFC4821] as for SCTP using a PAD in the extension
>   described in [RFC6520] MUST be used.
OK. I'm fine with that text.
> 
> ---
> 
>   If path MTU discovery is performed by the *SCTP* layer and IPv4 is used
>   as the network layer protocol, the DTLS implementation MUST allow the
>   DTLS user to enforce that the corresponding IPv4 packet is sent with
>   the DF bit set.
> 
> Now I don't know where to do discovery - in DTLS or SCTP. That's not a mandate; that's two alternatives.
Since it is "performed by the SCTP layer", SCTP is sending the probe packets. It usea
the ones defined in http://tools.ietf.org/html/rfc4820. However, the requirement for
the DTLS layer is to expose the control of the DF bit.
Any suggestion how to make that clearer?
> 
>>> ...
>>>>> My concern is whether/how users can know the PMTU if they aren't the ones sending the probes.
>>>> 
>>>> Because the probes are sent by SCTP as described in RFC 4821. RFC 4820 defined the probes:
>>>> http://tools.ietf.org/html/rfc4820
>>> 
>>> That means that SCTP knows the PMTU, so it can send data
>>> fragmented to conform to the path; that doesn't mean the user ever
>>> knows it. SCTP goes to lengths to bundle multiple user messages
>>> into one chunk or to split chunks across messages.
>> 
>> The user of SCTP doesn't need to know. SCTP fragments the user messages.
> 
> OK; I think I have it now. I was thrown off by Section 4.
> 
>>> FWIW, 4820 doesn't update SCTP either; this is more like "if you do probes, this is the mechanism by which to do it".
> >
>> Correct. I want the SCTP/DTLS to mandate that this is the way you need to do it (in this case).
> 
> See above; there's ambiguity that needs to be resolved.
> 
>>>>>>>>> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD?
>>>>>>>>> 
>>>>>>>>> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec)
>>>>>>>> Again: What about just requesting SCTP to do the PMTU here?
>>>>>>> 
>>>>>>> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?)
>>>>>> What are you suggesting:
>>>>>> (a) Simplify the ID by requiring to do PLMTUD at the SCTP layer
>>>>>> (b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let
>>>>>>     the decision be specified in the corresponding document describing
>>>>>>     the particular use case.
>>>>>> 
>>>>>> I'm for simplicity and would vote for (a).
>>>>> 
>>>>> (a) requires a standards-track RFC that indicates how this is done, which I can't find (there may be one; I don't track SCTP at that level of detail).
>>>> 
>>>> What am I missing: I think RFC4821 describes such an algorithm and it is standards track.
>>> 
>>> It talks about how SCTP should generate probes; it doesn't provide the rest of what would be needed to update SCTP.
>>> 
>>>> We have only to require that the SCTP implementation support the mechanism described in
>>>> RFC4821.
>>> 
>>> AFAICT, that description alone would not be sufficient. At a minimum, it fails to describe how SCTP would indicate the PMTU to the user (which SCTP doesn't otherwise do, AFAICT).
> >
>> Normally the user is not interested in it, since SCTP does fragmentation and reassembly.
>> However, if the user wants to know it, it can use
>> http://tools.ietf.org/html/rfc6458#section-8.2.2
> 
> Right - I was confused by Sec 4.
> 
>>> ...
>>>>>> I think the problem is that two packet of uncompressed sizes M' and M'' with
>>>>>> M' > M'' can result in compressed sizes m' and m'' with m' < m''.
>>>>> 
>>>>> Yes, that's why you would want to use the compressed size as the indicator of the path MTU.
>>>> 
>>>> OK. But does SCTP know what size it needs to use as the fragmentation limit such that
>>>> after compression of that fragment it does fit?
>>> 
>>> That's where thinking about compression gets into trouble with PMTUs.
>>> 
>>> Think of it this way:
>>> 
>>> 	- the PMTU is the size of message the net supports
>>> 
>>> 	- compression makes transmission more efficient
>>> 
>>> 	- compression IS NEVER a way to get a larger single
>>> 	message across a net than the PMTU can support
>>> 
>>> THat's why SCTP doesn't need to know what size to use as a frag limit so that "after compression" it will fit; if it doesn't fit *before* compression, it doesn't fit.
> >
>> What I don't understand:
>> * A compressed message can be larger than the original uncompressed. So it won't fit.
> 
> Then your compression is broken. A compressed message should never be larger than uncompressed - ever.
Really? If you present some random data, the compression won't give you anything (there
is no redundancy). Some compression algorithms add an overhead. So the compressed message would
be larger. Or am I wrong?
> 
>> * If SCTP sends the probe packets, doesn't this mean that the probe packets
>>   must bypass compression?
> 
> At the SCTP layer; SCTP can't force lower layers to bypass compression.
Correct.
So assume SCTP send probe packets and the padding is constant data. So it is highly
compressible. Wouldn't SCTP then conclude that you can send a large message without
fragmentation? If SCTP takes that as the PMTU, it would fragment user messages for
that boundary, compression might not be as efficient and you would need IP fragmentation.
> 
> However, again, I was confused by Sec 4.
> 
>>>>>> That is why
>>>>>> PMTUD does work with compression.
>>>>> 
>>>>> Are you sure you meant that? That's what I was saying, but you seem to be saying the opposite.
>>>> 
>>>> Yes, sorry. Mistake on my side. I meant that is why PLMTUD does not work with compression.
>>> 
>>> It can; there's nothing about that in the PLMTUD doc.
>>> 
>>> ...
>>>>> But do you have any indication this will work with another layer of indirection? I.e., SCTP->DTLS->transport->IP
>>>> 
>>>> Depends on the OS. Some OSes allow to control the DF bit others don't. Getting this through DTLS
>>>> is simple to implement...
>>> 
>>> It's not an implementation issue; it's a protocol issue. If it's not a service provided by the protocol (in its logical API), then it might not exist, and thus you can't rely on it.
>>> 
>>> ...
>>>> I really appreciate that API are becoming important... Having worked for a long time on the socket API for SCTP.
>>>> However, there is currently no API specified for DTLS...
>>> 
>>> Hmm. That may render this entire document irrelevant then; you can't know what you're building SCTP to run over in that case.
> >
>> I don't think we can define a DTLS API in TSVWG... At least this is not in the scope
>> of this document.
> 
> Sure, but then you're stuck with SCTP only assuming it can interact with DTLS as if it were a DTLS user. DTLS users can't set DF.
Why? It depends on the implementation of DTLS...

Best regards
Michael
> 
> Joe
>