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

[Joe Touch <[e-mail]>]

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

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