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 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?
~ 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?.
---
~ 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
