Hi Dan, Good comments -- thanks. See inline... Tom P. PS. Colin, if you're reading this, there are some comments about the SDP that could use your input. > -----Original Message----- > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of > Dan Wing > Sent: Wednesday, April 07, 2010 1:00 AM > To: 'Pasi Sarolahti'; 'DCCP working group' > Cc: draft-ietf-dccp-udpencap@xxxxxxxxxxxxxx > Subject: Re: dccp-udpencap discussed in TSVWG > > > -----Original Message----- > > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On > > Behalf Of Pasi Sarolahti > > Sent: Thursday, March 18, 2010 11:01 AM > > To: DCCP working group > > Subject: dccp-udpencap discussed in TSVWG > > > > Hi, > > > > Even though we do not have a DCCP session in the Anaheim > > meeting, the > > dccp-udpencap draft will be discussed in the TSVWG session. > > TSVWG will > > meet on Monday, March 22 at 13:00, so if you are interested in this > > draft, please consider attending that session. > > > > Now might also be a good time to read the draft, if you haven't done > > so yet. The draft is available at > > http://tools.ietf.org/html/draft-ietf-dccp-udpencap-00 > > Introduction: > > > The introduction should more clearly indicate if DCCP-NAT is intended to > work > with NAPT (as defined in Section 4.1.2 of RFC2663) or not. I believe that > is > the intent; please make the document clearer on that point. > [Tom P.] OK > > OLD: > In order for the [RFC4340] encapsulation to pass through Network > Address Translation (NAT) devices, these devices must be updated to > recognize and properly modify DCCP. This is the long-term objective > for DCCP, and work is underway to specify the necessary operations. > NEW: > In order for the [RFC4340] encapsulation to pass through Network > Address Translation (NAT) devices, these devices must be updated to > recognize and properly modify DCCP, as described in [RFC5597]. > .....................................^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [Tom P.] OK > > > Section 3.1, "UDP Header" > > "Source and Dest(ination) Ports: 16 bits each > > These fields identify the UDP ports on which the source and > destination (respectively) of the packet are listening for > incoming DCCP-NAT packets (normally both are the default port to > be assigned by IANA). Note that they do not identify the DCCP > source and destination ports." > > With a NAPT, due to the UDP port being used by another host, or another > DCCP-NAT instance running on the same host, it is not true that "normally" > the > source and destination ports will be whatever IANA assigns. If anything, > the > parenthetical statement should be almost reversed and say something like > "implementations should be aware that a NAPT may, for various reasons, > assign > a different source UDP port than used by the host sourcing the DCCP-NAT > packets". > [Tom P.] OK > > "Length: 16 bits > > This field is the length of the portion of the UDP datagram, > including the UDP header and the payload (which for DCCP-NAT is > the DCCP-NAT datagram) that is covered by the UDP Checksum." > > Is the "DCCP-NAT datagram" the same as the "Application Data Area" from > the > diagram in section 3? If they are the same, please pick one term; if they > are > different, the I-D needs to explain the difference. I believe it > encompasses > the DCCP-NAT Generic Header, Additional Fields, DCCP Options, and [DCCP?] > Application Data Area. > [Tom P.] Your belief is what I intended. It might be clearer to just remove the parenthetical statement. > > The I-D does not say if the UDP source/destination ports need to agree > with > the DCCP source/destination ports, or what it means if they disagree > (nothing?). Is there a reason there are ports in both places? I presume > it > is so that one DCCP-NAT "tunnel" can be run between two DCCP-NAT hosts, > carrying various different DCCP flows? > [Tom P.] The basic way this works is that the UDP ports indicate the DCCP-over-UDP service and the DCCP ports indicate the DCCP service being used. I thought this was clear but I guess it isn't. I'll try to clear it up. There seems to be this idea circulating that you could eliminate the DCCP ports and use the UDP ports for the DCCP application. Well, you could do this if you didn't want to run UDP services on those ports. I don't think we want to eliminate the ability to run UDP services other than DCCP-over-UDP. > > Section 3.3: > > "If the UDP Checksum field, computed using standard UDP methods except > including only UDP Length bytes of the UDP packet, is invalid, the > packet MUST be dropped." > > I don't understand the phrase "except including only UDP Length bytes of > the > UDP packet". Can that be clarified? > [Tom P.] Normally in UDP the Length field is the length of the entire packet. DCCP-UDP modifies the semantics of the Length field to be the length of the packet that the checksum applies to. So the DCCP-UDP checksum process differs from the standard by "including only UDP Length bytes of the UDP packet." This is explained in the section describing the Length field (in 3.1). Maybe this can be cleared up by explicitly saying in that section that this is a change to standard UDP behavior. > > Section 3.5: > > DCCP-NAT implementations should follow DCCP-STD section 14 with > ^^^^^^ > SHOULD > regard to maximum packet size and Path Maximum Transmission Unit > Discovery (PMTUD). > [Tom P.] OK > > > Section 4: > > In general, the encapsulation of a higher-layer protocol within DCCP > SHOULD be the same in both DCCP-STD and DCCP-NAT. At this time, > encapsulations of DTLS over DCCP, defined in [RFC5238] and RTP over > DCCP, defined in [I-D.ietf-dccp-rtp], have been already defined. The > encapsulations of those protocols in DCCP-NAT SHALL be the same as > specified in those documents. > > Except that, for native DCCP, the encapsulation allows short sequence > numbers -- but that isn't allowed with DCCP-NAT. That should be made > clearer > [Tom P.] OK > > Section 5.1: > > [I-D.ietf-dccp-rtp] defines SDP extensions for signaling RTP over > DCCP connections. Since it predates this document, it does not > define a method for determining the DCCP encapsulation type. > ^^^^^^^^^^^ > signaling > [Tom P.] OK > > Section 5.1: > > This > document updates [I-D.ietf-dccp-rtp] to add a method for determining > the DCCP encapsulation type. > > Then it needs "Updates: ietf-dccp-rtp" in the document header. Which > makes me > notice that DCCP-NAT is Experimental, whereas draft-ietf-dccp-rtp is > standards-track. So, I think you cannot 'update' the standards-track > document. Rather, the extension to SDP needs to, itself, be > experiemental. > [Tom P.] I see your point. Can I replace "updates" with "extends"? > This is Experimental, so the a=dccp-in-udp is probably okay. If it wasn't > experimental, it would probably be better to use the SDP Capabilities > Negotiation stuff from MMUSIC (draft-ietf-mmusic-sdp-capability- > negotiation). > > I would encourage the I-D require the UDP port *always* be provided in the > signaling, and not allow it optionally as currently in the spec. Havoc > will > ensue if the port is not signaled, as implementations will expect/require > the > NAPT to not change port numbers (relying on the NAPT keeping the port the > same), which will break outside of a quiescent lab environment. We had a > similar problem with RTCP port numbers not being signaled (assumed to be > the > RTP port number + 1) which has not worked out well in practice. > [Tom P.] I tend to agree with you on this, but the draft is this way because of input from Colin Perkins, who would prefer that there be no way at all to signal the UDP port. What's in the draft now is a compromise. Colin -- do you have any input? > > > Section 5.1: What happens if the offerer supports DCCP-over-UDP, but the > answerer only supports native DCCP? [Tom P.] Then they can't communicate, and won't know that until they try it. Again, this is a compromise between my initial version of this (which allowed explicit signaling of which encapsulations were supported) and Colin's input. > Also, what happens if both offerer > and > answerer support DCCP-over-UDP, but there isn't a NAT between them (and > they > could have used DCCP for more efficient communication)? It seems adding a > 'for future study' reference to ICE might be helpful if someone decides > they > want to optimize that situation. > [Tom P.] OK > -d > > > >
