dccp@ietf.org
[Top] [All Lists]

Re: [dccp] Comments on :draft-ietf-dccp-udpencap-01.txt

Subject: Re: [dccp] Comments on :draft-ietf-dccp-udpencap-01.txt
From: "Phelan, Tom"
Date: Fri, 25 Jun 2010 11:24:22 -0400
Hi Gorry,

Thanks for the comments -- see inline...

Tom P.

> -----Original Message-----
> From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
Of
> Gorry Fairhurst
> Sent: Thursday, June 24, 2010 8:55 PM
> To: dccp@xxxxxxxx
> Cc: Gorry
> Subject: [dccp] Comments on :draft-ietf-dccp-udpencap-01.txt
> 
> I have a few comments on rev -01 of the above draft,
> 
> Best wishes,
> 
> Gorry
> 
> ----
> Section 1.
> 
> I hesitate to use the words "This is the long-term objective for
DCCP",
> since this can be seen as a euphemism for "never". I'd suggest we
don't
> actually need to promote this view by using the words "long-term".
> 
[Tom P.] This was originally written when 5597 was just a gleam in
Remi's eyes and probably needs more major surgery.  How about replacing
the two paragraphs starting with "In order for" with this:

[RFC5597] specifies how DCCP should be handled by NAT devices, but there
is a significant installed base of NAT devices that do not support
[RFC5597].  In the short term, it would be useful to have an
encapsulation for DCCP that is compatible with the installed base that
supports [RFC4787] but does not support [RFC5597].  This document
specifies that encapsulation, which is referred to as DCCP-UDP.  For
convenience, the [RFC4340] encapsulation is referred to as DCCP-STD.

> ----
> Section 1.
> 
> Is there merit in the introduction pointing to RFC 5596 when
describing
> the goals for DCCP NAT traversal?
> 
[Tom P.] I like the idea but I'm having trouble seeing how to include it
without making it seem like an arbitrary interjection -- it's one of the
many features of DCCP, albeit one that's important to NAT traversal, but
any way I think of phrasing it seems like arbitrarily mentioning one
supported feature.

> ----
> Section 1.
> 
> I'm not sure I understand the standards language here:
>    "Also,
>     support for ECN might be impractical for some implementations.
Those
>     implementations MAY choose to not support ECN."
> 
> - If this is "impractical" whatever that means, then they can choose
not
> to? This seems odd, and seems to contradict later
> 
> - I would much prefer "Implementations SHOULD support ECN (see section
> 3.4)."
> 
[Tom P.] I think this sentence can be removed from section 1.

> ----
> Section 2.
> 
> Checksum: 16 bits
> 
> - I think the checksum field MUST be non-zero, if you over-riding the
> DCCP checksum function, as per RFC 5405.
> 
[Tom P.] I think you mean section 3 here, and I agree.  Although I think
the place to mention that is in section 3.3 DCCP-UDP Checksum
Procedures.

> ----
> Section 3.2
> 
> "   For DCCP-UDP, all generic header fields except for Checksum
function
>     as specified in [RFC4340]."
> 
> I think this could be better reworded:
> "All generic header fields, except for the Checksum field have the
same
> meaning as specified in [RFC4340]"
> 
> It could also be useful to say: "(including the update specified in
RFC
> 5596)."
> 
[Tom P.] OK

> ----
> 3.3.1.  Minimum Checksum Coverage Feature
> 
> - I agree with not including special support for DCCP partial checksum
> support. If you wanted to do this, you should have encapsulated in
> UDP-Lite. It would be nice to think NATs will support UDP-Lite, but my
> guess is that NATs are just as likely to natively support DCCP, If
this
> does happen to prove wrong we can redefine UDP-Lite encaps for DCCP!
> 
> That said, I do not see why we need to also mandate this:
> 
>    "A DCCP-UDP
>     implementation MUST NOT send a "Change R(Minimum Checksum
Coverage,
>     value)" with any "value" other than 0, and MUST answer all "Change
>     R(Minimum Checksum Coverage, value)" with "Confirm L(Minimum
Checksum
>     Coverage, 0)"."
> 
> It is allowable for apps to call the API and say they are willing to
set
> less checksum coverage, even if the links on the way do not support
this
> as a special treatment. I'd argue that it's equally OK to negotiate to
> use this, even though they happen to routed over a tunnel that will
> discard all types of corruption. To me, this seems better to encourage
> use of the function, so that when we go Native it can still be used (I
> dislike the idea of different features for different transports).
> 
[Tom P.] I put this in because I was uncomfortable with false
advertising, but I see your point.  This section can be eliminated.

> ----
> 3.4 Explicit Congestion Notification
> 
> "(e.g., user-space implementations using the
>     socket interface)."
> 
> - I guess this is a comment on Windows? - I'd rather not go there, we
> have Linux stacks we have "used" where we set ECN on sockets. I'd
> suggest we don't imply it has to be so, and say:
> 
[Tom P.] Well, Windows and Linux are not the only operating systems out
there.  Android, for example, doesn't support ECN via (the java
equivalent of) sockets.

> "(e.g., a user-space implementation that uses a socket interface that
> does not support ECN)."
> 
[Tom P.] But I do see your point.  I suggest we eliminate talk of
practicality and replace the last paragraph with:

Implementations that do not support ECN MUST follow the procedures in
DCCP-STD section 12.1 for implementations that are not ECN capable.

> -----
> Section 3.7
> 
> "   There is one Service Code registry and one DCCP port registry and
>     they apply to all combinations of encapsulation and IP version. "
> - I think was OK when the work started, but the proposed changes to
> ports and services registry (about to be WGLC'ed in TSVWG) would make
> this out of date.
> 
> I suggest:
> "   There is one Service Code registry and one DCCP port registration
> that applies to all combinations of encapsulation and IP version. "
> 
> - It may be helpful to cite RFC 5595 (since service codes are
sometimes
> :-) alien to non-DCCP people).
> 
[Tom P.] OK

> -----
> Section 3.7
> 
> I agree with the IANA instruction not to register variegates per
encaps.
> 
> I'd however much prefer that we were to omit this last phrase:
>    "Since
>     the port registry supports multiple applications registering the
same
>     port (as long as the Service Codes are different), other
applications
>     MAY register on the same port, but those registrations are also
>     applicable to all combinations of encapsulation and IP version."
> - this would avoid ambiguity for the updated IANA procedure, since the
> new procedure calls out how IANA should handle this in the TSVWG
draft.
> 
> 
[Tom P.] OK

> -----

<Prev in Thread] Current Thread [Next in Thread>