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

From: Michael Tuexen <[email-masked]>
Date: Tue, 8 Apr 2014 16:06:38 +0200

On 07 Mar 2014, at 20:46, Michael Tuexen <[email-masked]> wrote:

Hi Joe,

thank you for your review. Please find my comments in-line.

Best regards
Michael

> WGLC comments from Joe.
> 
> Best regards
> Michael
> 
> Begin forwarded message:
> 
>> From: Joe Touch <[email-masked]>
>> Subject: Re: Fwd: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
>> Date: 6 Mar 2014 23:55:24 GMT
>> To: Michael Tuexen <[email-masked]>
>> Cc: Gorry Fairhurst <[email-masked]>, Randall Stewart <[email-masked]>, Randell Jesup <[email-masked]>, Salvatore Loreto <[email-masked]>
>> 
>> Hi, Michael,
>> 
>> On 2/7/2014 7:55 AM, Michael Tuexen wrote:
>>> Hi Joe,
>>> 
>>> Gorry suggested that you might be interested in reviewing the SCTP over DTLS
>>> ID, since you are interested in transport tunnels. So would it be possible
>>> for you to review the document (it is pretty short)? I would appreciate your
>>> review very much!
>> ...
>>>> 	Filename        : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
>> 
>> Comments below. Feel free to post/forward as usual; please cc me if you do, so I can track any followups if needed.
>> 
>> Joe
>> 
>> -----
>> 
>> 1 - I'm not a fan of "stacked headers"; section 1 should have something to say before you jump into 1.1
Agreed. Actually the abbreviations are almost useless and the terminology can
also be removed. Therefore, section 1 will only contain the overview.
>> 
>> 1.1 - This section should more clearly explain the need for DTLS encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with security. That's implied right now, and should be explicit.
>> 
>> Why doesn't the entirety of this document not boil down to "run SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that description then mean you can then omit section 3?
One of the important points of RFC 6951 is how to deal with the UDP port numbers.
These need to be handled in a specific way as described in RFC 6951. This does
not apply here. This document describes how to run SCTP over a connections
oriented protocol without providing SCTP with any information about IP addresses
and UDP port numbers. You might run DTLS over TCP or HTTP or whatever.
So I added at the end of the Overview:

<t>Please note that the procedures defined in <xref target='RFC6951'/> 
for dealing with the UDP port numbers do not apply here.
When using the encapsulation defined in this document, SCTP is agnostic
about the protocols used below DTLS.</t>

>> 
>> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 doesn't say "sent down to UDP". But, as noted, this section isn't needed.
Replaced by:
When an SCTP packet is provided to the DTLS layer, ...
>> 
>> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS v1.2 or higher [RFC6341]."  T
A similar comment was already made resulting in the following text:

The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The support of future versions of DTLS is RECOMMENDED if defined.

Is that acceptable?
>> 
>> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it).
I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520.
What we want to avoid, is that user data is used as probe packets.
>> 
>> I'm not sure what the issue with probe packets is, but why is this a MUST, rather than just the statement "Probe packets are supported using existing DTLS extensions [RFC6520]"? Again, do you care if there are other DTLS methods for doing this?
We do care that RFC 4821 is used with probe packet not being user messages.
So RFC 6520 provides one way. Other might be possible in the future.

So what about
For probe packets, the extension defined in <xref target='RFC6520'/> can be used.
>> 
>> The Path MTU paragraph is already addressed in RFC6951 - why add it here?
Because RFC 6951 doesn't apply here.
>> 
>> The doc should explain why you care about disabling DTLS compression.
Hmmm. It is stated:
SCTP performs segmentation and reassembly based on the path MTU.
If DTLS performs compression, which limit should SCTP use knowing that
it fits into the packet.
And if SCTP performs the path MTU discovery (as in the case of RTCWeb),
than it can't detect the the message size of the outgoing packet.
>> 
>> The last sentence seems like it should be MUST NOT.
No. How can you send probe packets if you can't send packets larger than
the current PMTU.
>> 
>> I.e., overall, it seems like you get what you need with a simpler first sentence, and the last two only.
I don't think so. This document is independent from the UDP encaps one...
>> 
>> 5 - same stacked header problem
Right. Fixed. I added:
<t>This section describes the usage of the base protocol and the applicability
of various SCTP extensions. Since SCTP is agnostic about the protocols being
used below DTLS, explicit IP addresses MUST NOT be using in the SCTP control
chunks. As a consequence, the SCTP associations are single homed.</t>
> 
>> 
>> 5.1 - odd wording on first sentence. seems like you want to say "This doc defines SCTP [RFC4960] in DTLS 1.2."
I just want to make clear which specification is used for SCTP. So what about:
<xref target='RFC4960'/> specifies SCTP.
Is that better?
>> 
>> The issue here is, IMO, more that DTLS is connectionless *vs UDP* (the comparison is more direct).
Correct. I changed the wording to:

However, the following restrictions are necessary to reflect that the lower layer
is DTLS instead of IPv4 and IPv6 and that SCTP doesn't deal with the IP
addresses or the transport protocol used below DTLS:

Does that address you issue?
>> 
>> I would not suggest using abbreviated terminology; you refer to associations only in one place. Why make it hard to understand that you mean "SCTP associations"?
Agreed. Using SCTP association here.
>> 
>> The last bullet in this list is redundant; it's already covered in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you should refer to RFC6951 as normative and describe this as a superset of that.
Again. I don't see RFC 6951 applying here.
>> 
>> 5.2 - redundant with RFC6951 AFAICT
See above.
>> 
>> 5.3 - why not put all the "no explicit addresses in band" somewhere, and include both this and other uses of addresses as examples?
Makes sense. I added corresponding text to the section introduction as given above.
>> -----

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Apr 2014 11:46:25 -0700

Hi, Michael,

Feedback below. Hopefully useful.

> One of the important points of RFC 6951 is how to deal with the UDP port numbers.

The abstract of RFC 6951 seems to indicate otherwise:

    ...In particular, it does not provide mechanisms
    to determine whether UDP encapsulation is being used by the peer, nor
    the mechanisms for determining which remote UDP port number can be
    used.  These functions are out of scope for this document.

There's an API for configuring the port number being used, but it 
doesn't seem to matter what port number is actually used (though 9899 is 
the default, as per Section 7).

> and UDP port numbers.

I can't see why Section 6.1 wouldn't apply equally well here, though. 
Even when you run over DTLS you still need to pick a transport port 
number, no?

> You might run DTLS over TCP or HTTP or whatever.

OK.

> The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The support of future versions of DTLS is RECOMMENDED if defined.

Yup.

> I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520.

That's correct; it doesn't -- it leaves PMTU discovery to the 
application (Sec 4.1.1.1).

> What we want to avoid, is that user data is used as probe packets.

If that's true, you need to motivate it rather than just declaring so.

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)

> So RFC 6520 provides one way. Other might be possible in the future.

Then update the doc in the future; if this is standards-track (and it 
appears to be intended for that), you should state the MUST of 6520 and 
leave any future extensions for future authors of an update IMO.

> For probe packets, the extension defined in <xref target='RFC6520'/> can be used.

MUST, IMO.

> Because RFC 6951 doesn't apply here.

Again, I think it really does. You're just adding another layer (DTLS), 
but ultimately there are two layers you need to be concerned about - 
DTLS and UDP.

> If DTLS performs compression, which limit should SCTP use knowing that

The uncompressed size.

Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC 
doesn't mention MTUD. VJ's compression mentions the interaction, but 
allows it.

> than it can't detect the the message size of the outgoing packet.

Sure it can; it measures from the size of the packets sent (compressed), 
though.

> No. How can you send probe packets if you can't send packets larger than

How can you do PMTU discovery if IP fragments the packets (which you 
mention in the next sentence)? You need to more carefully discuss how 
probe packets are generated and avoid outgoing fragmentation (as well as 
on-path fragmentation). And it would apply only to probes.

That's an interaction a layer below DTLS, but you need to address it 
here too.

> I don't think so. This document is independent from the UDP encaps one...

I don't see how you can discuss things like MTU discovery and be 
independent of any transport discussion at all.

> chunks. As a consequence, the SCTP associations are single homed.</t>

Introductory headers shouldn't include requirements. IMO, leave that 
address requirement for a subsection; the header paragraph should setup 
the subsections only.

Further, this sounds like something that ought to be mentioned in the 
asbtract and intro - it might severely limit the utility of the approach.

> <xref target='RFC4960'/> specifies SCTP.

Not really; maybe you wan to say:

This document uses SCTP [RFC4960] with the following restrictions, which 
are required to reflect...

> is DTLS instead of IPv4 and IPv6

or UDP over IP as per RFC6951

> and that SCTP doesn't deal with the IP

IMO, it's more that it *can't* deal with addresses that far down.

> Agreed. Using SCTP association here.

AOK.

> Again. I don't see RFC 6951 applying here.

See above; I think it is really relevant, and odd to present this 
approach as completely distinct from that RFC.

> Makes sense. I added corresponding text to the section introduction as given above.

Sure.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 8 Apr 2014 21:56:45 +0200

Hi Joe,

thanks for the feedback. It is very useful and will improve the document.

See my comments/response in-line.

Best regards
Michael
> There's an API for configuring the port number being used, but it doesn't seem to matter what port number is actually used (though 9899 is the default, as per Section 7).
I was not clear enough and maybe the cited text is also not very clear.
Let me be more precisely:

RFC 6951 does not provide a mechanism to figure out if the initiator should use
UDP encapsulation or not. And RFC 6951 does not provide a mechanism to figure
out which UDP port number to use for the initial packet.

However, RFC 6951 does tell you that an SCTP stack has one local UDP encapsulation
port number and needs to store per path for each association a remote UDP encapsulation
port number. See
http://tools.ietf.org/html/rfc6951#section-5.1
RFC 6951 also tells you how to update the remote encapsulation port
number when a packet is received. See
http://tools.ietf.org/html/rfc6951#section-5.4

Therefore the SCTP stack has to manage the UDP port numbers being used. This
is an important part of the UDP encapsulation. Since this is not used when
using DTLS, there is a major difference between the documents.
> I can't see why Section 6.1 wouldn't apply equally well here, though. Even when you run over DTLS you still need to pick a transport port number, no?
Yes, but this is not managed by the SCTP stack. This is managed by the DTLS layer.
And I don't think DTLS can deal with UDP port number changes during the communication
as SCTP can. SCTP/UDP as described in RFC 6951 can survive that a NAT box changes
the port number mapping, SCTP/DTLS can't...
> That's correct; it doesn't -- it leaves PMTU discovery to the application (Sec 4.1.1.1).
Which is SCTP, in this case... One of the options allowed. So are you suggesting just to require
that SCTP the PMTU discovery and take out the option that DTLS does it? I'm fine with that change,
especially because this is exactly what RTCWeb does.
> If that's true, you need to motivate it rather than just declaring so.
OK. What about adding:
User messages SHOULD NOT be used as probe packets, because during probing
this results in potential packet loss which increases due to the necessary
retransmissions the delay of the user message transfer.
> 
> 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?
> Then update the doc in the future; if this is standards-track (and it appears to be intended for that), you should state the MUST of 6520 and leave any future extensions for future authors of an update IMO.
> 
>> So what about
Hmm. This means that the current text is OK:
For probe packets, the extension defined in [RFC6520] MUST be used.

However, it depends on taking out the "DTLS does the PMTUD" option...
> Again, I think it really does. You're just adding another layer (DTLS), but ultimately there are two layers you need to be concerned about - DTLS and UDP.
And as explained above: SCTP, when used over DTLS, does not deal with UDP port numbers at all,
however, SCTP, when used over UDP, does...
> Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC doesn't mention MTUD. VJ's compression mentions the interaction, but allows it.
What I don't understand: SCTP send a probe packet of size M, it gets compressed to size m, m is the PMTU,
so it makes it to the peer, and PMTUD concludes that the path MTU >= M.
Now SCTP fragments a user message to size M, however, this time he compressed packet has size m' with
m' > m. The packet is larger than the PMTU and this is really bad...
So how can this work with compression being enabled?
> Sure it can; it measures from the size of the packets sent (compressed), though.
But this size is only known by the DTLS layer and is useless to SCTP, since
it must fragment the messages such that the compressed message would fit.
How could SCTP know?
> How can you do PMTU discovery if IP fragments the packets (which you mention in the next sentence)? You need to more carefully discuss how probe packets are generated and avoid outgoing fragmentation (as well as on-path fragmentation). And it would apply only to probes.
Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit.
The only crucial point is that the DTLS layer allows the SCTP to do this. This requires:
* the DTLS layer to pass this information through
* the lower layer of DTLS to provide a way to control the DF bit.
> 
> That's an interaction a layer below DTLS, but you need to address it here too.
Yes. The current document (not yet submitted) contains (based on a discussion at the
IETF meeting):

   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 Don't Fragment (DF) bit set.  If controlling the DF bit is not
   possible, for example due to implementation restrictions, a save
   value for the path MTU has to be used by the SCTP stack.

> I don't see how you can discuss things like MTU discovery and be independent of any transport discussion at all.
> 
>>>> 
> Introductory headers shouldn't include requirements. IMO, leave that address requirement for a subsection; the header paragraph should setup the subsections only.
OK. So just:

  This section describes the usage of the base protocol and the
  applicability of various SCTP extensions. 
> 
> Further, this sounds like something that ought to be mentioned in the asbtract and intro - it might severely limit the utility of the approach.
OK. Added:

Using encapsulation method described in this document, SCTP is agnostic
about the protocols being used below DTLS, explicit IP addresses can not
be used in the SCTP control chunks. As a consequence, the SCTP associations
are single homed.

to the abstract and the overview contains already:

> This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect...
OK. So it read now:

<t>This document uses SCTP <xref target='RFC4960'/> with the following
restrictions, which are required to reflect that the lower layer
is DTLS instead of IPv4 and IPv6 and that SCTP doesn't deal with the IP

> or UDP over IP as per RFC6951
No. RFC 6951 supports multihoming, RFC 6951 does support UDP port number mapping changes...
> IMO, it's more that it *can't* deal with addresses that far down.
It depends... At least it is not the way intended by this ID...
> See above; I think it is really relevant, and odd to present this approach as completely distinct from that RFC.
I think it is important to understand the relation... Taking my explanation above into account,
do you still think this is the same?

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Apr 2014 13:24:14 -0700

Following up on only the points needed...

On 4/8/2014 12:56 PM, Michael Tuexen wrote:
...
> using DTLS, there is a major difference between the documents.

There's a difference, but it's not what I'd consider "major" (it could 
easily be stated as "do that RFC, except for Sections X and Y").

> the port number mapping, SCTP/DTLS can't...

Fair enough, but that's just one section, and easily explained as to why 
it doesn't apply.

...
> Which is SCTP, in this case... One of the options allowed.

SCTP does RFC1191 only (PMTUD).

> So are you suggesting just to require

I'm wondering why you want to make a specific recommendation as to how 
to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have 
a reason, IMO include it and justify it.

> retransmissions the delay of the user message transfer.

I don't see why this protocol needs to say that, esp. when RFC4821 
doesn't. SCTP isn't a low-latency transport protocol anyway.

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

> However, it depends on taking out the "DTLS does the PMTUD" option...

That's the issue. If you really depend on DTLS support for probe 
packets, then MUST is fine; otherwise, it's unnecessary.

> however, SCTP, when used over UDP, does...

But again, port numbers are just one part of that other document. You 
could import the rest of that document by reference and exclude the port 
number issues.

> What I don't understand: SCTP send a probe packet of size M, it gets compressed to size m, m is the PMTU,

SCTP never sends probes. Either the app does, or DTLS does.

> so it makes it to the peer, and PMTUD concludes that the path MTU >= M.

The path MTU would be m - compression doesn't affect the fact that the 
path supported a message (compressed or not) of actual size m.

> m' > m. The packet is larger than the PMTU and this is really bad...

The packet size would be m' (the uncompressed size I was referring to 
above), and that's what you compare to the actual path MTU.

> So how can this work with compression being enabled?

See above. You measure what you see through the path, and compare it to 
the uncompressed size of the packet. Compression helps performance, but 
should not be considered as a way to increase effective path MTU.

> it must fragment the messages such that the compressed message would fit.

If that's the case, then you have problems with DTLS-layer discovery too.

> Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit.

When SCTP runs over IP directly. It won't work when SCTP runs over UDP 
or SCTP over X.

> * the lower layer of DTLS to provide a way to control the DF bit.

But that doesn't appear to be a feature of DTLS AFAICT.

>     the Don't Fragment (DF) bit set.

This adds a requirement to DTLS that doesn't appear to currently exist; 
that means this extension isn't necessarily compatible with currently 
compliant DTLS implementations.

>     ...If controlling the DF bit is not

safe?

>     value for the path MTU has to be used by the SCTP stack.

Presuming you mean 'safe', there's no such value AFAICT.

...
> do you still think this is the same?

Yes. You've explained a few places that are useful to separate, but the 
rest is relevant.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 8 Apr 2014 23:54:15 +0200

> Following up on only the points needed...
Thanks... See inline...
> There's a difference, but it's not what I'd consider "major" (it could easily be stated as "do that RFC, except for Sections X and Y").
Well, when implementing it, it is the major part. Adding/Removing the the UDP header is the minor part.
Without the UDP port number handling, I think there wouldn't be a real need for an RFC, since
the header manipulation is pretty obvious to do.
> Fair enough, but that's just one section, and easily explained as to why it doesn't apply.
> 
> ...
That is why the text explicitly requires RFC4821 for PMTU in SCTP.
> I'm wondering why you want to make a specific recommendation as to how to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have a reason, IMO include it and justify it.
The text leaves it open, which layer does it. The RTCWeb spec make it clear when used in the RTCWeb context.
In general, I'm open and this is what the text currently says.
However, we need a way of doing it
* without relying on ICMP, since we can't verify the contents
* without affecting the user data transmission with probe packet loss
That is why we want an RFC4821 based algorithm. Either in DTLS or SCTP.
> I don't see why this protocol needs to say that, esp. when RFC4821 doesn't. SCTP isn't a low-latency transport protocol anyway.
But we don't want to add timeouts just because we do PMTU discovery when it is not needed...
> 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).
> That's the issue. If you really depend on DTLS support for probe packets, then MUST is fine; otherwise, it's unnecessary.
We can just specify that PLMTUD is done at the SCTP layer. That would simplify things.
> But again, port numbers are just one part of that other document. You could import the rest of that document by reference and exclude the port number issues.
For me (having both implemented) gives the impression of a similarity, which isn't there...
ICMP feedback, for example: In SCTP/UDP it might be able to process incoming ICMP packets,
since I might be able to verify the SCTP port numbers and the verification tag. With SCTP/DTLS
I can't, since the information is encrypted...
> SCTP never sends probes. Either the app does, or DTLS does.
When SCTP does PLMTUD, it sends probe packets. These would be packets containing HEARTBEAT chunks
bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820)
> The path MTU would be m - compression doesn't affect the fact that the path supported a message (compressed or not) of actual size m.
> 
> The packet size would be m' (the uncompressed size I was referring to above), and that's what you compare to the actual path MTU.
> 
> See above. You measure what you see through the path, and compare it to the uncompressed size of the packet. Compression helps performance, but should not be considered as a way to increase effective path MTU.
But whenever SCTP sends down a packet, it is compressed. So it has no way of finding the
packet size. 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''. That is why
PMTUD does work with compression.  
> If that's the case, then you have problems with DTLS-layer discovery too.
No. The DTLS overhead is constant (if you don't use compression). So DTLS could
provide a size for which packets would fit into the PMTU.
> When SCTP runs over IP directly. It won't work when SCTP runs over UDP or SCTP over X.
It does. At least in the FreeBSD based implementation. SCTP controls the DF bit...
> But that doesn't appear to be a feature of DTLS AFAICT.
It is nothing the protocol has to provide, it is a feature provided by the
implementation or not...
> This adds a requirement to DTLS that doesn't appear to currently exist; that means this extension isn't necessarily compatible with currently compliant DTLS implementations.
Right. However, the limiting factor is not the DTLS stack, but the UDP interface...
> Presuming you mean 'safe', there's no such value AFAICT.
Formally correct. Well, RTCWeb has decided on such values: 1280 bytes for IPv6
and 1200 bytes for IPv4 (both at the IP layer). 

> Yes. You've explained a few places that are useful to separate, but the rest is relevant.
> 
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Apr 2014 09:56:03 -0700

On 4/8/2014 2:54 PM, Michael Tuexen wrote:
...
> 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.

> That is why we want an RFC4821 based algorithm. Either in DTLS or SCTP.

There doesn't appear to be such an algorithm required in SCTP; it would 
be either in DTLS or the user application.

If it's in DTLS, I'm not sure how SCTP would get the MTU information, 
though.

> But we don't want to add timeouts just because we do PMTU discovery when it is not needed...

Timeouts are already there - they're just retransmissions in SCTP.

My concern is whether/how users can know the PMTU if they aren't the 
ones sending the probes.

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

(b) required at SCTP has the same problem

(b) for DTLS has the issue of how SCTP finds out the MTU from DTLS.

However you intend to handle this needs to be specific, justified, and 
cite an existing mechanism that's complete or you need to introduce the 
needed components here.

...
> bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820)

RFC4820 says that RFC4821 descibes how to use the pad chunk for PLMTUD, 
but there's no RFC I can locate that actually describes this as an 
extension to SCTP.

> packet size.

Isn't there a length field telling you the uncompressed size, and a 
length parameter to the next layer that indicates the compressed size?

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

> That is why

Are you sure you meant that? That's what I was saying, but you seem to 
be saying the opposite.

> provide a size for which packets would fit into the PMTU.

But DTLS packets can be fragmented at the IP layer; that's already a 
warning in the DTLS doc.

> It does. At least in the FreeBSD based implementation. SCTP controls the DF bit...

But do you have any indication this will work with another layer of 
indirection? I.e., SCTP->DTLS->transport->IP

> It is nothing the protocol has to provide, it is a feature provided by the

This may be a red-herring for this discussion, but the API provided to 
the next layer is absolutely part of the spec of a protocol. The IETF's 
position on this was incorrect (and hopefully has changed).

Implementation issues are things like the argument order and specific 
data types (e.g., whether to use u8 or u16 for a range of 0..255)..

> Right. However, the limiting factor is not the DTLS stack, but the UDP interface...

Wouldn't it also be the DTLS interface (to SCTP) too?

> and 1200 bytes for IPv4 (both at the IP layer).

You should refer to those then, IMO.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 9 Apr 2014 21:13:13 +0200

On 09 Apr 2014, at 18:56, Joe Touch <[email-masked]> wrote:

> 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?
> There doesn't appear to be such an algorithm required in SCTP; it would be either in DTLS or the user application.
In my view RFC 4821 describes such an algorithm. That is why I'm requiring support of
this method.
> 
> If it's in DTLS, I'm not sure how SCTP would get the MTU information, though.
> 
Yes.
> 
> 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
> (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.
We have only to require that the SCTP implementation support the mechanism described in
RFC4821.
> (b) for DTLS has the issue of how SCTP finds out the MTU from DTLS.
There can be an API for requesting the MTU minus the DTLS relevant overhead...
> 
> However you intend to handle this needs to be specific, justified, and cite an existing mechanism that's complete or you need to introduce the needed components here.
Why is 4821 not enough?
> RFC4820 says that RFC4821 descibes how to use the pad chunk for PLMTUD, but there's no RFC I can locate that actually describes this as an extension to SCTP.
For my understanding, this is done in
http://tools.ietf.org/html/rfc4821#section-10.2
> Isn't there a length field telling you the uncompressed size, and a length parameter to the next layer that indicates the compressed size?
> 
> 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?
> 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.
> But DTLS packets can be fragmented at the IP layer; that's already a warning in the DTLS doc.
We want to avoid IP level fragmentation. That is why we want to do PLPMTUD.
> 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...
> This may be a red-herring for this discussion, but the API provided to the next layer is absolutely part of the spec of a protocol. The IETF's position on this was incorrect (and hopefully has changed).
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...
> 
> Implementation issues are things like the argument order and specific data types (e.g., whether to use u8 or u16 for a range of 0..255)..
> 
That can simply be changed by the people implementing this stack, since it is in userland.
Accessing the UDP stack (without special privileges) requires OS support. This can't
be changed that simple by people using this stack.
> You should refer to those then, IMO.
I can... No problem, but I think the value for IPv4 might be dependent on the
usage. The 1200 bytes comes from the RTCWeb WG, and are stated in that specification.

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Apr 2014 14:36:15 -0700

Hi, Martin,

On 4/9/2014 12:13 PM, Michael Tuexen wrote:
...
> 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.

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

> 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

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

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

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

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

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 17 Apr 2014 22:54:39 +0200

> RFC4821 doesn't update SCTP -- it doesn't update anything.
Right.
> 
> 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.
> 
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. 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?
> 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.
The user of SCTP doesn't need to know. SCTP fragments the user 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".
Correct. I want the SCTP/DTLS to mandate that this is the way you need to do it (in this case).
> It talks about how SCTP should generate probes; it doesn't provide the rest of what would be needed to update SCTP.
> 
> 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).
Normally the user is not interested in it, since SCTP does fragmentation and reassembly.
However, if the user wants to know it, it can use
http://tools.ietf.org/html/rfc6458#section-8.2.2
> 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.
What I don't understand:
* A compressed message can be larger than the original uncompressed. So it won't fit.
* If SCTP sends the probe packets, doesn't this mean that the probe packets
  must bypass compression?
> 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.
> 
> ...
> Hmm. That may render this entire document irrelevant then; you can't know what you're building SCTP to run over in that case.
I don't think we can define a DTLS API in TSVWG... At least this is not in the scope
of this document.

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Apr 2014 16:20:37 -0700

Hi, Michael,

On 4/17/2014 1:54 PM, Michael Tuexen wrote:
> as defined in this document, you MUST use the PLMTUD.

At the DTLS layer.

> So this document

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.

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.

---

    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.

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

OK; I think I have it now. I was thrown off by Section 4.

> Correct. I want the SCTP/DTLS to mandate that this is the way you need to do it (in this case).

See above; there's ambiguity that needs to be resolved.

> http://tools.ietf.org/html/rfc6458#section-8.2.2

Right - I was confused by Sec 4.

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

> * If SCTP sends the probe packets, doesn't this mean that the probe packets

At the SCTP layer; SCTP can't force lower layers to bypass compression.

However, again, I was confused by Sec 4.

> I don't think we can define a DTLS API in TSVWG... At least this is not in the scope

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.

Joe

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 18 Apr 2014 13:39:10 +0200

>> as defined in this document, you MUST use the PLMTUD.
Either at the DTLS layer or at the SCTP layer.
> 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
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
>   described in [RFC6520] MUST be used.
OK. I'm fine with that text.
> 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?
> 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?
> 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.
> 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...

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Apr 2014 09:35:53 -0700

Cutting down a bit...

On 4/18/2014 4:39 AM, Michael Tuexen wrote:
...
> 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

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

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

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

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

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

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

Then you can't require it in a standards doc.

Joe