Hi Pasi, See inline... Tom P. > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx] > Sent: Thursday, October 07, 2010 5:55 AM > To: Phelan, Tom > Cc: Gerrit Renker; dccp@xxxxxxxx > Subject: Re: [udp-encap rev2] discussion/comments > > 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. > [TomP] OK, I'll add some text on the rationale with regard to checksums. Hopefully this won't just open another can of worms :-). > >> 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? > [TomP] I'll look into this and send something to the list. > >> 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?) > [TomP] I'm not sure that 4340 has anything to say about the sections of TOS besides ECN, or about IP options. I'll look into it. Sorry about the section confusion :-(. > 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 :-) > [TomP] OK. > >> 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.) > [TomP] OK, I'll incorporate something along the lines of your suggestion. > >> * '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. > [TomP] I thought Gerrit was saying to change DCCP-STD to "native packetization of DCCP within IP" in all uses. If it's just clearing up that paragraph I have no problem doing that. > >> * 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. > [TomP] OK > >> * 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 > [TomP] Yes. > >> * 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. > [TomP] OK, I'll look into what can be done without completely repeating 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. > [TomP] I'll look into cleaning this up. > - Pasi
