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

From: Michael Tuexen <[email-masked]>
Date: Sun, 11 May 2014 23:45:07 +0200

On 18 Apr 2014, at 18:35, Joe Touch <[email-masked]> 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

---

From: Joe Touch <[email-masked]>
Date: Mon, 12 May 2014 09:24:19 -0700

It might be useful to see the updated document at this point.

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.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 13 May 2014 11:05:13 +0200

> 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