On 1 Jan 2011, at 11:50, Gorry Fairhurst wrote: > It's approaching a time when we need to decide as a WG what goes into the > next rev. of the draft: > > ~ Could the procedure for DCCP checksums be further simplified by requiring > (MUST) this to be set to zero when encapsulated within a (DCCP-)UDP header? - > this would reduce the checksum processing overhead to that of only UDP. > > ~ Following the WGLC there was debate on the 4/6-Tuple and how this would > work with different UDP and DCCP port values. As I see it, the current > proposal is to eliminate the 6-Tuple text and use only the outer UDP ports > for demultiplexing.
If I understand what's proposed correctly, I don't think this would be a good idea. The ability to have a well-known UDP port on which tunnelled DCCP connections can be accepted seems important to me; as does the ability to run a server accessible via UDP and native DCCP listening on the same port, also accessible via tunnelled DCCP. Neither of these are possible if we use only the outer UDP ports. > ~ If we adopt the above, there has also been a proposal to remove the DCCP > ports prior to encaps. This is a topic we have visited as a WG in the past. > I've seen recent comments supporting this and comments against this. Is it > viable to remove the DCCP ports field, and is this desirable or not - > comments welcome? (see also note on DCCP Checksum being zero) - How far do > people wish to go (if at all) in removing unused fields? See above. I don't think this is desirable. > ~ If we allow the the well-known UDP-assigned port for DCCP (as currently > proposed), then it seems this would rely on out-of-band information or the SC > to identify the intended DCCP service. This has less utility (i.e. there are > only specific cases where this is useful, and it wouldn't work in some NAPT > scenarios), but it currently seems to me to be mostly harmless - can someone > supply suggested text?. Or use the inner DCCP port. > --- > > ~ Known NiTs (to be corrected in next version - thanks to all who noted > these): > > Header: s/Engineeeing/Engineering/ > Abstract: s/This documents also updates/The document also updates/ > > Section 1: "[...] that is compatible with this installed base of NAT/NAPT > devices that supports [RFC4787], but do not support [RFC5597]." > Change to 'devices that support' > Section 1: "The document also provides an updated SDP specification for DCCP, > and, in this respect only, it updates the method in [RFC5762]." > Insert text 'updated SDP specification for DCCP to convey the > encapsulation type and, in this respect only, ...' > > Section 3: "Devices offering or using DCCP services [...] listens on a UDP > port" > ^ - Change to /A device that offers or uses ... > > Section 3.1: "Length: 16 bits > [...] (for DCCP-UDP, the payload is a DCCP-UDP datagram)" > See if this is clearer to say that the payload is a DCCP datagram. > > Section 3.3: s/encapuslated/encapsulated/ > Section 3.3: "Use of UDP-checksum is mandated" => of UDP checksums > > Section 3.4: Typo "teh" > Section 3.4: Typo "A DCCP-UDP implementations" change to implementation > Section 3.4: Typo s/susbequent/subsequent/ > > Section 3.8: Typo "DCP-UDP client" > Section 3.8: "If the DCCP-UDP server binds to this default port" > Repeat "binds to the default port reserved for DCCP-UDP service"? > > Section 3.9: Check: "This section clarifies the usage of DCCP Service Codes > or the registration of > server ports by DCCP-UDP." ==> should this be 'Service Codes and the [...]"? > > Section 4: There is no clear motivation for using a different encapsulation > for higher-layer protocols in DCCP-NAT than in DCCP-STD. Change: The > different encapsulations MUST be the same. > > Section 4: Clarify "If a document does not specify [...] the specified > encapsulation SHALL apply [...]" ==> does this mean that 'DCCP-UDP > encapsulation applies as specified by this document'? > > Section 5.1: Add some words to explain the applicability of the new SDP > attribute. Specifically, it's likely only useful if the offering party is on > the public Internet, or in the same private addressing realm as the answering > party, since otherwise the port advertised is unlikely to be reachable due to > the NAT. > > Section 5.1: the "a=dccp-in-udp:" attribute can be used in a declarative SDP > file, in addition to in offer/answer mode. > Section 5.1: procedures for handling DCCP-STD and/or DCCP-NAT with ICE may > need to be developed, but are left for further work. > > Section 5: Ed Note: There is only one subsection, 'SDP Support for DCCP-UDP'. > Would it make > sense to collapse the single subsection so that there is only a section 5? > > Section 6: s/swent/sent/, s/encapsualted/encapsulated/, > s/conenctions/connections/ > > Section 7: s/occurances/occurrences/ > > Section 8: s/Collin/Colin/, s/Lenvorski/Lentvorski/ > --- > > Gorry > > > On 20/12/2010 15:30, Eddie Kohler wrote: >> If the parsing change were dramatic or expensive I'd be less happy about >> eliding the DCCP ports. But the DCCP ports are just the first 4 bytes of >> the DCCP header, making it very easy to pop ports on for parsing and pop >> them off for encapsulating. >> >> E >> >> >> On 12/20/10 1:50 AM, Pasi Sarolahti wrote: >>> On Dec 15, 2010, at 11:20 PM, Colin Perkins wrote: >>> >>>>> No, they would not. Just as the encapsulated DCCP header checksum is >>>>> ignored, the encapsulated DCCP PORTS would be ignored. The receiver >>>>> would use the ports from UDP. >>>> >>>> In that case, we should just elide the ports from the encapsulated DCCP >>>> header to avoid the confusion, if we're going to do this. >>> >>> I'm also supportive of using UDP ports in the 4-tuple, and ignore the DCCP >>> ports. I wouldn't so much like the idea of defining a different DCCP header >>> for UDP encapsulation, even if it saved a few bytes (just to avoid separate >>> packet parsers). >>> >>> With a shared UDP port at the server, this would mean that the service >>> codes come to good use (which might be worth emphasizing in the text). >>> >>> - Pasi >>> >> >> > -- Colin Perkins http://csperkins.org/
