> -----Original Message----- > From: Phelan, Tom [mailto:tphelan@xxxxxxxxxxxx] > Sent: Wednesday, April 07, 2010 7:52 AM > To: Dan Wing; Pasi Sarolahti; DCCP working group > Cc: draft-ietf-dccp-udpencap@xxxxxxxxxxxxxx > Subject: RE: dccp-udpencap discussed in TSVWG > > 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. That isn't the best way to look at it. I mean, you will *always* be running DNS over UDP/53, so UDP services aren't eliminated. Rather, I would look at it that once a specific UDP port is being used for DCCP-over-UDP, it is solely used for DCCP-over-UDP. I don't think that is a limitation at all; afterall, that is how IPsec-over-UDP and lots of other tunnel-over-UDP function. However, adding compression to the DCCP-NAT header (to eliminate the DCCP ports) would make DCCP-over-UDP more complex so, for that reason, I would keep it out of scope of your current I-D. Such compression could be done in the future to save 4 bytes. > > 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." Hm. Are you prohibiting the UDP checksum from being 0? > 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. That would help a lot, yes. It makes me nervous, though. > > 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"? sure. You should get an IANA registration for the a=dccp-in-udp (I *think* there is a registry for the "a=" stuff; maybe there isn't...). > > 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. With a NAPT, the source port is can be changed (rewritten) by the NAPT purposefully (all the time, such as to randomize the source port used; or sometimes, because another host behind the same NAPT is already using the same port). We need to support DCCP-over-UDP being used by two hosts behind the same NAPT (imagine in your own house or at Starbucks or a hotel, for example). As it is, it creates an opportunity for two hosts behind the same NAT to simply signal the 'default DCCP-over-UDP port' and get their traffic [RTP or whatever] sent to the other host. Which I guess will drop it unless the DCCP ports match (and occasionally they will - birthday problem). > 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. Ouch. > Again, this is a compromise between my initial version of this > (which allowed explicit signaling of which encapsulations were > supported) and Colin's input. You might want to hand-waive towards SDP Capability Negotiation and towards ICE. -d > > 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 > > > > > > > > >
