Phelan, Tom wrote:
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."?
The word Concert confuses me a little.
- 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.
Yes and "Fragmentation SHOULD NOT be the default."
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 :-).
I'd assume a value based on the default of 576 or 1280.
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);
I think CCMPS is just the payload, i.e. MPS for a specific CCID.
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.
>
I was wondering if for CCID-4 the CCMPS was going to be small(ish).
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.
Agree, *could* define future CCIDs that vary the CCMPS...
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."
Much improved. Is this any use:
DCCP normally restricts packets to be less than the Maximum Packet Size
(MPS) (e.g. determined by Path MTU Discovery). The Congestion Control
MPS (CCMPS) [RFC4340] specifies the largest MPS that may be used with a
specific congestion control ID (CCID). This may be fixed for a
Congestion Control ID, or could vary as a function of the current
congestion control state.
A DCCP implementation may permit applications to send datagrams larger
than the current MPS (permitting fragmentation), but smaller than the
CCMPS. When this is allowed, DTLS implementations SHOULD control the use
of the DF bit by DCCP in concert with the application's indications.
When the DF bit is not set, and DCCP packets can be fragmented, the
CCMPS may be less than the 65,535 bytes normally used in UDP.
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.
OK
-------------
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."
That's better.
