Hi, I'm picking a selection of the Gerrit's comments for discussion below... I'd appreciate prompt responses, so that we can soon be able to determine if we have common understanding about the draft, and then move forward. On Oct 5, 2010, at 10:32 PM, Phelan, Tom wrote: >> If the latter is the main aim, then it would be great not to make > changes >> to >> the encapsulated data (DCCP header + DCCP payload), since this would >> require >> a separate implementation for generating the DCCP-UDP payload data. >> >> Even if the DCCP checksum should break as a result of NAT-ing some of > the >> IP adresses - the DCCP checksum can easily be recomputed at the UDP >> endpoint. >> > [TomP] I am very against doing the checksum calculation twice, once for > UDP and then again for DCCP. In my opinion, implementations should know > which encapsulation is being used. Maybe it would be useful to explain in 3.3 a bit more why this approach was chosen, as Gorry suggested in an earlier mail. Trying to remember the months-old discussion this, I guess the thinking was: * UDP checksum is needed, to avoid problems caused by possible header corruption * Since UDP checksum covers the packet, DCCP checksum is redundant and adds complexity especially with pseudoheaders and assumed NATs along the way (that cannot be assumed to recalculate the encapsulated DCCP checksum) * From this then follows why we don't support partial checksums, which I think is already pretty well said in the following subsection. >> a. It would be good to specify how UDP ICMP errors are translated > into >> DCCP >> semantics, in particular the "administratively prohibited" > variants >> of >> Destination Unreachable (RFC 1122, 3.2.2.1), and how these > options >> are >> to be passed on to UDP. >> >> GF> Agree, something is needed to specify at the sender to say the >> procedure for generating errors >> and processing then at the receiver. >> > [TomP] I'll look into this for the next version. Could we outline the main points already now on the mailing list, so that we have a common understanding what the next version is going to say about this. I'd like to avoid a second WGLC, if possible. Gerrit, Gorry: do you have proposal about what should be said about ICMP errors? >> b. Are network-layer options (e.g. setting TOS) which may be set > with >> DCCP-STD >> simply to be transferred to DCCP-UDP (same question for PMTUD - > is >> the >> DCCP-UDP MTU the same the UDP_MTU - 8 ?). >> > [TomP] I believe this is already covered in the draft (sections 3.4 and > 3.5). As to how implementations will choose to do this (as you suggest > or some other mechanism), I don't thinks that's the business of this > draft. Section 3.4 speaks only about ECN, but that could be extended to clarify that TOS and other IP options are handled as they would be with DCCP-STD (right?) Nit: in 3.4 add a reference to RFC4340, section 12, instead of just saying "DCCP-STD, section 12". The HTML version of the draft doesn't know in its hyperlinks which document is being referred to :-) >> c. Why does there need to be an IANA-assigned default port for DCCP >> encapsulation? The benefit of a well-known for current-generation > NAT >> boxes >> is not clear (it would not help NAT traversal). For > future-generation >> NAT >> boxes might give the wrong impression to implementors that > DCCP-UDP >> is the >> only feasible way of supporting DCCP. >> For out-of-band signalling SDP has already been specified by the >> document. >> > [TomP] For applications that don't use a rendezvous protocol such as > SDP, a default port is very useful. That it might be changed along the > way doesn't change the initial need. > >> GF> This is debatable - I can see pros and cons, at the moment I'd > favour >> using >> a well known port. The document should say WHY the method is chosen. >> > [TomP] I think that such as statement is not necessary. This whole port issue has triggered a few comments, so I think it needs to be clarified. The text in 3.1 could say: * DCCP-UDP implementation binds to well-known UDP port XXX (specified by IANA) for receiving incoming datagrams. It MUST accept datagrams from any UDP source port, because it is possible that a NAPT has changed source port along the way. * DCCP-UDP sender sends datagrams to well-known UDP destination port XXX. It is left for the implementation to choose the UDP source port. (With this draft particularly, it is important to be specific about when we are talking about UDP ports and when we are talking about DCCP ports.) >> * 'For convenience, the [RFC 4340] encapsulation (updated by [RFC >> 5596])' >> => as above, perhaps one could refer to RFC 4340 as "native >> packetization of >> DCCP within IP" or something similar; > [TomP] I find that very clumsy. I agree with Gerrit's point here. Something like "native DCCP over IP is referred to as DCCP-STD" would be clearer than "[RFC4340] encapsulation..." but I'll leave it to you to think about the wording. >> * Checksum: >> - the specification (reference) of the UDP pseudo-header is > missing; > [TomP] RFC 0768 has already been referred to. I can add another > reference here. Yes, it probably clarifies to say that this is as specified in original UDP spec. >> * section 3.3, checksum computation >> - as per (e) above, this section could be omitted >> - with regard to checksum validity it could be simplified by >> referring validate DCCP-UDP packets according to RFC 768, with >> the restriction that the checksum MUST NOT be disabled (zero > csum) >> - (The term 'DCCP-NAT' has not been introduced in this document.) >> > [TomP] I disagree. but note the DCCP-NAT catch >> * section 3.5 >> - would be good to clarify the use of UDP fragmentation: >> UDP implementations support fragmentation, UDPv6 in addition >> supports >> jumbograms (RFC 2675), hence need clarification whether to >> a) bump the maximum inner MTU of DCCP to exploit the limits of > UDP >> or >> b) completely disallow fragmentation of DCCP-UDP packets (since >> possibly >> not supported by hardware) >> - how shall section 14 of RFC 4340 be interpreted in this context: >> * is DCCP's MPS simply the UDP PMTU minus 8? >> * apply RFC 5405 for UDP MTU fallback values? >> > [TomP] I think that 4340 section 14 (including 14.2) covers these > issues. I agree with Gerrit. Section 3.5 is very minimal (one sentence) at the moment. It doesn't hurt to clarify how the MTU handling works, even if it was trivial. This relates to the discussion of the ICMP errors in general. Maybe there we could discuss also the PMTU case. Anyways, I assume the main logic works as specified in RFC 4340. >> * section 3.6 >> I don't understand the purpose of specifying the service code of > an >> encapsulated protocol. Service code and encapsulation seem not >> related, >> a connection could have any service-code value and still need UDP >> encapsulation, but why not leaving this transparent to DCCP? >> In particular, if assuming a "DCCP tunnelling service" or a type > of >> overlay network, it would be difficult to alter the contained > service >> code. Also, like the checksums, this again introduces new > assumptions >> into DCCP and complicates the specification. My personal view is > to >> allow DCCP to pick whatever service code is appropriate for the > type >> of service used, and not to add additional rules restricting this > use >> because the protocol ends up being "tunneled". >> > [TomP] I think you mean section 3.7. I believe the section says pretty > much what you say above. I don't have section 3.7 in my -02 version of the draft. I don't disagree with section 3.6 (that discusses service codes), but maybe it could be clarified and shortened a bit. As I read it, the main point is that DCCP service code allocations and DCCP port allocations are common for DCCP-UDP and DCCP-STD (there are no separate IANA tables for these anyway). Whether an application chooses to not support some combination of these does not seem so relevant to discuss. That's something we cannot affect in any case. - Pasi
