Hi Gorry, Thanks for the comments. See inline... Tom P. > 1) > /DTLS implementations SHOULD control the use of the DF-bit in concert/ > ^^^^^^^^^^^ > - "in concert", is not clear to me. [Tom P.] How about, "DTLS over DCCP implementations SHOULD control the use of the DF bit by DCCP in concert with the application's indications."? > - If DCCP implements PMTUD, then the MPS can increase, and DTLS SHOULD > learn of this directly via the API, but MAY choose to probe instead or > as well. As I understand, the DCCP API will anyway refuse to send a > packet larger than the MPS and will return an error to DTLS. [Tom P.] I'm confused. And after rereading RFC 4340, I can see why. For most of the discussion in section 14, Maximum Packet Size, PMTU and MPS are effectively the same (well, MPS is PMTU minus expected IP and DCCP header sizes), but during all of this discussion it's assumed that the DF bit is set. When the DF bit is not set, there's no mention of what MPS is, but DCCP MAY allow "packets larger than PMTU, but not larger than CCMPS". And, "(Packets larger than CCMPS MUST be rejected in any case [DF set or not])". It's interesting to have a requirement in a parenthetical comment :-). A reasonable interpretation of this seems to me to be (if you implement the MAY condition above): MPS = (DF set) ? (min(PMTU, CCMPS) - header) : (CCMPS - header); If you don't do the MAY: MPS = min(PMTU, CCMPS) - header; Either way, the MPS is always dependent on the CCMPS, although it's probably rare for the CCMPS to be less than the PMTU. See point 4 for some text that tries to resolve all of this. > ---------- > 2) > /Note that even when the DF bit is not used/ > ^^^^^^^^^^^ > - This should be /is not set/ [Tom P.] OK. > - This is just IPv4 (yes?), let's say that. [Tom P.] OK. But is it really needed? There's no DF bit in IPv6... > ---------- > 3) > /the maximum size of a DCCP packet/ > ^ > Please insert /(the current MPS [RFC4340])/ [Tom P.] See below. > ---------- > 4) > / depends on factors such as the congestion control state/ > - Does it? I do not think it does, for currently defined CCIDs, although > I guess there is nothing to stop the application from varying the packet > size in response to congestion, or even defining a CCID that changes MPS. [Tom P.] For currently defined CCIDs, I believe you're correct. But there doesn't seem to be anything in 4340 that prohibits future CCIDs from varying the CCMPS due to congestion conditions. The idea of this sentence is to get across the concept that MPS in DCCP is not the fixed 64K-1 of UDP; it can vary from connection to connection and even within a single connection. How about this to replace the last paragraph in 3.5: "DTLS implementations also normally allow applications to control the use of the DF bit (when running over IPv4). DTLS over DCCP implementations SHOULD control the use of the DF bit by DCCP in concert with the application's indications. Note that the DCCP maximum packet size (MPS in [RFC4340]) is bounded by the current congestion control state (congestion control maximum packet size, CCMPS in [RFC4340]). Even when the DF bit is not set and DCCP packets may then be fragmented, the MPS may be less than the 65,535 bytes normally used in UDP. It is also possible for the DCCP CCMPS, and thus the MPS, to vary over time as congestion conditions change. DTLS over DCCP implementations MUST NOT use a DTLS record size that is greater than the DCCP MPS currently in force." > ---------- > 5) (as above) > /as congestion conditions change/ > - As the network path, or the network path properties change. [Tom P.] Changes in network path can change the PMTU, but I don't think they can directly change the MPS for fragmentable packets. See new text above. > ------------- > 6) SC > There is also one statement in the last line pf 3.6, that reads "these > applications MUST use one Service Code". > > - This seems like a truism, there *is* only one SC a socket could use. I > think though you need to say which SC, that is I would suggest: > "these applications MUST use a Service Code that is appropriate to a > session that does not use DTLS" [Tom P.] You're correct that this is really a truism, not a requirement, but I don't know what the difference is between an SC that is "appropriate to a session that does not use DTLS" and one that is appropriate to a session that uses DTLS, so I don't think we can use that text. How about: "Since there is no way to change the Service Code for a connection after it is established, these applications will use one Service Code."
