Hi Gorry, See inline (this is getting long, but be sure to get to the end, that's where the controversy is :-))... Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Monday, December 03, 2007 6:31 PM > To: Phelan, Tom > Cc: 'dccp' working group > Subject: Re: Close-read of DTLS - questions on latest revision. > > 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. [Tom P.] Webster says, "concert (noun) -- agreement in design or plan. 'In concert' -- together, as in <acting in concert with others>". I suppose this could be an Americanism, but it sounds pretty British to me. > > >> - 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." [Tom P.] Agreed, but the case that's causing us problems is when we've changed from the default and are using fragmentation. > > > 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 [Tom P.] ^^^^^^^^^ well, less than or equal > (MPS) (e.g. determined by Path MTU Discovery). The Congestion Control [Tom P.] ^^^^^^^^^^^^^^^^^^ not always > 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 [Tom P.] ^^^^^^^^^^^ current PMTU > 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." [Tom P.] I'll think about this a bit, but I feel we're going down the path of trying to improve the clarity of the DCCP specification, and I don't think that's the correct thing to do here. For example, as far as I can tell from searching CCID2 and 3, they don't specify what the CCMPS is, and DCCP doesn't specify what it is when the CCID hasn't stepped up. I don't think we should fix that here. I think the important points to make for DTLS over DCCP are: 1) As with UDP, it's possible to send DTLS records that are bigger than the PMTU (by not setting the DF bit, although DCCP implementations are not required to support this). 2) When you do this, don't blindly assume that the maximum record size is 64K-1 or any other fixed value. 3) Under no circumstances can the DTLS record size be bigger than the DCCP MPS. > > > >> ---------- > >> 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. > > > >
