See also in-line comments from me (this has opened some new questions on
the text).
Phelan, Tom wrote:
Hi Pasi,
Thanks for the careful reading and comments. See inline...
Tom P.
-----Original Message-----
From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx]
Sent: Monday, January 14, 2008 2:33 AM
To: dccp@xxxxxxxx
Subject: WGLC comments for draft-ietf-dccp-dtls-04
Hi,
1) Section 3 says "Multiple DTLS records MAY be sent in one DCCP-Data
packet, as long as the resulting packet is within the Path Maximum
Transfer Unit (PMTU) currently in force, if the Don't Fragment (DF)
bit is being used, or within the current DCCP maximum packet size if
the DF bit is not being used (see section 3.5 for more information on
PMTU Discovery)"
This sentence may not be fully correct, depending on what exactly
is meant by "the PMTU currently in force". RFC 4821 distinguishes
between the PMTU used for normal data packets, and the packet
size used for probe packets (which are larger than the current PMTU,
and in case of IPv4, have the DF bit set).
[Tom P.] So it should say "(PMTU) currently in force [for normal data
packets]" (inserted text in the brackets)?
Please see my question at end.
2) Section 3.5, "A DTLS over DCCP implementation MAY use the
DCCP-managed value for PMTU and not perform PMTU Discovery on its
own."
Well... although skipping some parts of PMTU Discovery may be
possible, I think it would be an extremely bad idea to ignore this
PMTU Discovery related part from RFC 4347: "DTLS implementations
SHOULD back off handshake packet size during the retransmit backoff
described in Section 4.2.4." I think this should be mentioned
explicitly.
[Tom P.] OK.
>
Fine with me too, if DTLS wishes to be more conservative than other DCCP
applications, that's no problem.
3) Section 3.5, "DTLS implementations also sometimes allow
applications to control the use of the DF bit (when running over
IPv4)." This sentence should probably continue "or the use of
fragmentation extension headers (when running over IPv6)"?
[Tom P.] OK.
>
OK with me too, but note that sending bigger than MPS in either IPv4 or
IPv6 using DCCP REQUIRES an API option in DCCP - by default, DCCP will
not send any datagram that exceeds MPS, and hence requires fragmentation.
4) Section 3.2 says "DTLS server implementations MAY choose to respond
to a ClientHello message received in a DCCP-Request packet with a
HelloVerifyRequest message, if denial of service countermeasures are
to be used, or a ServerHelloDone message otherwise, in the
DCCP-Response packet."
This text gives the impression that the server replies to ClientHello
with ServerHelloDone; this isn't correct. It replies with a bunch of
handshake messages (ServerHello, Certificate, ServerKeyExchange,
CertificateRequest, ServerHelloDone; some of which are optional in
some cases).
[Tom P.] Oops! I meant ServerHello. I'll fix.
5) Section 3.4 says "It could conceivably contain multiple DTLS
sessions, in series or even in parallel, while simultaneously
transferring non- DTLS data. In practice this could be difficult to
demultiplex at the application/DTLS level and support for this is
likely to be rare to nonexistent. [RFC4347] does not specifically
exclude multiple DTLS sessions simultaneously sharing the same
underlying transport."
RFC 4347 does require that the transport must be able to do the
multiplexing, as DTLS cannot do it. Since DCCP doesn't contain any
field which could be used for multiplexing, and DTLS records are
encrypted, the claim "it could be difficult" is misleading -- it
simply isn't possible to have multiple simultaneous DTLS sessions
(without inserting some kind of application multiplexing layer between
DCCP and DTLS). (Having DTLS and non-DTLS data may be possible,
though.)
I would suggest rephrasing this along the lines "A DCCP connection
has no knowledge of the type of application data it is transferring.
>>
- We should be careful here, since Service Codes do something at a
connection level.
- I'd prefer "DCCP cannot differentiate different types of application
data sent over a DCCP Connection"
If the application performs appropriate multiplexing, a DCCP
connection
could conceivably contain both DTLS and non-DTLS data in parallel.
However, [RFC4347] cannot multiplex simultaneous DTLS sessions (as
DTLS
records do not contain any kind of association identifier), and thus
running multiple parallel DTLS sessions over a single DCCP connection
is not possible."
[Tom P.] OK (thanks for the wording :-)).
6) Editorial nit: Section 6.1, reference RFC4347 is missing the second
author's name.
[Tom P.] Thanks.
Best regards,
Pasi
-----
If DTLS wants to probe, just to be absolutely sure the path supports it,
that's fine with DCCP. So, can I check my understanding here:
* DTLS SHOULD discover the DCCP MPS (as per RFC4340).
* DTLS MAY probe BELOW the MPS (to ensure the integrity of the path).
* DTLS could attempt to probe ABOVE MPS and
(i) By default DCCP will refuse to send these packets at the API (but
could I guess use them to trigger a PMTUD probe by DCCP or even use some
of them as a probe - not considered by anyone as far as I know). DTLS
will anyway discover this limit.
(ii) DTLS could request via the API that the datagram is permitted to be
fragmented by the end host. If DTLS REALLY wants to send large packets
it could using this method. This does not seem helpful for PMTUD (but
could I guess DCCP use them to trigger a PMTUD probe by DCCP or even use
them as a probe).
* DTLS SHOULD signal via the DCCP API to increase the MPS when needed.
This will create a PMTUD trigger - always less than the CCMPS (e.g.
sending a larger DCCP-Sync packet to update PMTUD, when allowed by the
PMTUD algorithm).
Therefore, I interpret this as DTLS would be bound to conform to DCCP's
view of whether a "probe" was allowed to be sent at this time. DTLS can
NOT independently probe for capacity above the DCCP MPS value in some
un-coordinated way (e.g. when DCCP is also probing using DCCP-SYNC packets).
DCCP stacks that do not yet support PMTUD have no way of increasing MPS.
I'd argue that insuch implementations DTLS should not probe above the MPS.
To me, it is not correct to suggest that the probes are an ALTERNATIVE
to DCCP doing this.
Thoughts?
Gorry
