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

[Joe Touch <[e-mail]>]

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.

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.

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

FWIW, 4820 doesn't update SCTP either; this is more like "if you do 
probes, this is the mechanism by which to do it".


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

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

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

Joe