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

[Joe Touch <[e-mail]>]

Cutting down a bit...

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

>>> 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.

>> 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.

>> ---
>>
>>    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.

...
>>> 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.

>>> * 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.

E.g., PMTUD won't tell you that ATM has 53-byte cells with 48-byte 
payloads either.

...
>>> 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.

Joe