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

[Michael Tuexen <[e-mail]>]

On 12 May 2014, at 18:24, Joe Touch <[e-mail]> wrote:

> It might be useful to see the updated document at this point.
OK, I resubmitted the document.
> 
> I think the bottom line is the conclusion point below - this doc needs to be careful about what it requires/assumes from other layers, and if it's implementation-dependent, present the approach as "SHOULD, where implementations permit" and address what to do when this is not the case.
I agree with this high level point. I think we can reach that.
Please have a look at the updated document and provide feedback where this goal is not met yet.

Best regards
Michael
> 
> Joe
> 
> On 5/11/2014 2:45 PM, Michael Tuexen wrote:
>> On 18 Apr 2014, at 18:35, Joe Touch <[e-mail]> wrote:
>> 
>>> Cutting down a bit...
>> Thanks a lot, sorry for the delay. See me comments in-line.
>> 
>> Best regards
>> Michael
>>> 
>>> On 4/18/2014 4:39 AM, Michael Tuexen wrote:
>>> ...
>>>>>> 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.
>>> 
>>> How would an implementer know what to do per se? If they built this using userland SCTP, which they could AFAICT, they might not know.
>>> 
>>> IMO, that means you should say something more like:
>>> 
>>> 	- if you know, it can be at either layer
>>> 	- one layer MUST do it
>> Based on discussions, my current text reads :
>> 
>> 4.  General Considerations
>> 
>>    An implementation of SCTP over DTLS MUST implement and use a path
>>    maximum transmission unit (MTU) discovery method that functions
>>    without ICMP to provide SCTP/DTLS with an MTU estimate.  An
>>    implementation of "Packetization Layer Path MTU Discovery" [RFC4821]
>>    either in SCTP or DTLS is RECOMMENDED.
>> 
>> Doesn't this address your comment?
>> 
>> Please note that
>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08
>> states that the PMTUD is done by SCTP when SCTP over DTLS is used
>> for data channels.
>> 
>> Maybe I should resubmit my current version such that we have the
>> same document to discuss? There have been some changes based on
>> discussions... What do you think? This would not imply that
>> I don't want to address the still open points, just to make the
>> discussion easier.
>>> 
>>>>>> 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
>>> 
>>> That's far too vague to qualify as a "method" that you can tie to a MUST, IMO. I would expect that your doc ought to give the needed details, "inspired" by 4821.
>> By repeating the text of RFC 4821?
>>> 
>>>>> 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.
>>> 
>>> You might need a little more (not sure; I'll let the SCTP folks decide). I just don't know if that's enough detail to qualify as a standards requirement.
>> I think that is enough...
>>> 
>>>>> ---
>>>>> 
>>>>>   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?
>>> 
>>> As noted above:
>>> 
>>> a) say "do X or Y, but you MUST do one of these"
>>> 
>>> b) give the details a little more of how to do things in either case.
>> Hmm. I'm not sure what is missing compared to
>> https://tools.ietf.org/html/rfc4821#section-10.2
>> and
>> https://tools.ietf.org/html/rfc4821#section-10.4
>>> 
>>> ...
>>>>>> 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?
>>> 
>>> That's a really bad compression algorithm. A reasonable one should leave things alone (with no overhead) if it can't make things better.
>> Hmm. Possible. But
>> http://tools.ietf.org/html/rfc5246#section-6.2.2
>> contains in the second paragraph:
>> Compression must be lossless and may not increase the content length
>> by more than 1024 bytes.
>> So at least at the specification level, the above is explicitly covered.
>>>>>> * 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.
>>> 
>>> PMTUD is supposed to tell you when a segment of a given size at a given layer *can get there*. If it gets there, then the MTU is valid.
>> I agree.
>>> 
>>> E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte payloads either.
>> I agree. But I don't get the point...
>>> 
>>> ...
>>>>>> 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...
>>> 
>>> Then you can't require it in a standards doc.
>> Hmm. Then we can't deal with PMTUD at all... I would like to tell people what to
>> do if the implementation allows it...
>>> 
>>> Joe
>>> 
>> 
>