Hi Gorry, On your bottom bit, I agree. A basic principle is that DCCP's view of PMTU is dominant -- that's why the draft says DTLS "MAY choose to use its own PMTU Discovery", but, "MUST NOT use a value greater than the value determined by DCCP". I'll parse this a little more closely to see what new/changed text is necessary in the draft. Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Tuesday, January 15, 2008 12:03 PM > To: Phelan, Tom > Cc: gorry Fairhurst; dccp@xxxxxxxx; Pasi.Eronen@xxxxxxxxx > Subject: Re: WGLC comments for draft-ietf-dccp-dtls-04 > > 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 > > >
