[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: [udp-encap rev2] discussion/comments



Hi Gerrit,

See inline...

Tom P.

> -----Original Message-----
> From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
Of
> Gerrit Renker
> Sent: Friday, September 03, 2010 6:52 AM
> To: dccp@xxxxxxxx
> Subject:  [udp-encap rev2] discussion/comments
> 
> Please find below the transcript of a discussion I sent to Gorry
regarding
> revision 2 of the udp-encap draft.
> 
> As per Gorry's comments, I may have missed parts of the discussion, so
> please
> ignore or correct where I am erring.
> 
> The main point I did not understand is whether the aim is to
>  * encapsulate DCCP as a user-space protocol or
>  * encapsulate DCCP as an in-kernel protocol?
> 
[TomP] The main point is neither, or rather the main point is orthogonal
to these issues.  The main point is to allow DCCP to pass through
existing NAT devices.

> If the latter is the main aim, then it would be great not to make
changes
> to
> the encapsulated data (DCCP header + DCCP payload), since this would
> require
> a separate implementation for generating the DCCP-UDP payload data.
> 
> Even if the DCCP checksum should break as a result of NAT-ing some of
the
> IP adresses - the DCCP checksum can easily be recomputed at the UDP
> endpoint.
> 
[TomP] I am very against doing the checksum calculation twice, once for
UDP and then again for DCCP.  In my opinion, implementations should know
which encapsulation is being used.

> 
> General questions and remarks
> =============================
>   a. It would be good to specify how UDP ICMP errors are translated
into
> DCCP
>      semantics, in particular the "administratively prohibited"
variants
> of
>      Destination Unreachable (RFC 1122, 3.2.2.1), and how these
options
> are
>      to be passed on to UDP.
> 
> GF>  Agree, something is needed to specify at the sender to say the
> procedure for generating errors
> and processing then at the receiver.
> 
[TomP] I'll look into this for the next version.

>   b. Are network-layer options (e.g. setting TOS) which may be set
with
> DCCP-STD
>      simply to be transferred to DCCP-UDP (same question for PMTUD -
is
> the
>      DCCP-UDP MTU the same the UDP_MTU - 8 ?).
> 
[TomP] I believe this is already covered in the draft (sections 3.4 and
3.5).  As to how implementations will choose to do this (as you suggest
or some other mechanism), I don't thinks that's the business of this
draft.

>   c. Why does there need to be an IANA-assigned default port for DCCP
>      encapsulation? The benefit of a well-known for current-generation
NAT
> boxes
>      is not clear (it would not help NAT traversal). For
future-generation
> NAT
>      boxes might give the wrong impression to implementors that
DCCP-UDP
> is the
>      only feasible way of supporting DCCP.
>      For out-of-band signalling SDP has already been specified by the
> document.
> 
[TomP] For applications that don't use a rendezvous protocol such as
SDP, a default port is very useful.  That it might be changed along the
way doesn't change the initial need.

> GF>  This is debatable - I can see pros and cons, at the moment I'd
favour
> using
> a well known port. The document should say WHY the method is chosen.
> 
[TomP] I think that such as statement is not necessary.

>   d. The document specifies that both endpoints shall be listening on
the
> given
>      UDP port, while DCCP distinguishes active and passive
(client/server)
> parts
>      of the connection. I wonder whether it is necessary or would be
good
> to
>      inform about which side is the active one in the SDP protocol,
since
> how
>      shall the endpoint otherwise know what to do with the UDP tunnel?
If
> both
>      endpoints listen, nothing happens, if both connect there is
> simultaneous
>      open (discussed in RFC 5596).
> 
[TomP] You seem to be confusing the UDP aspects with the DCCP aspects
here.  The DCCP server listens, and the DCCP client initiates on DCCP
ports, but both server and client listen on UDP ports.

> GF>  This, to me, refers to both stacks at the hosts, rather than per-
> socket connection
> endpoints. I agree the wording should better.
> 
[TomP] The wording where?
> 
>   e. I can see no point for the extra rule that DCCP packets contained
in
> UDP
>      encapsulation should not have their own checksums. First it
alters
> and
>      restricts the use of DCCP so that encapsulated DCCP behaves
> differently
>      from unencapsulated DCCP. Second, it makes the specification more
> complicated,
>      by adding exceptions. Furthermore, the Internet checksum is cheap
to
> compute,
>      the other endpoint is known (and hence pseudo-header is already
> implicit).
>      The restriction of not being able to use partial checksums limits
> usability
>      if e.g. DCCP-UDP is employed on a path where on the "last mile"
> partial
>      checksums are of interest (e.g. wireless links). It is also
> conceivable
>      that there may be a "tunneling server" which transparently wraps
DCCP
> in UDP;
>      for such mode of operation it could simply just prepend the 8
bytes
> of header,
>      checksum the resulting packet, no need to alter its payload. The
> peering
>      endpoint would strip off the UDP header and could forward the
> enclosed DCCP
>      datagram without having to peek into the packet in order to
recompute
> the
>      checksum. Hence the recommendation is to keep DCCP as originally
> specified
>      in DCCP, and to not introduce extra checksumming rules.
> 
[TomP] I don't agree.  Introducing an in-the-network tunneling server
complicates things (how do you ensure it's on the path?  Build it into
the NAT?  But then why not build in real DCCP support?), and therefore
will never be built.

Maybe someone might choose to implement DCCP-UDP as a bump-in-the-stack
model.  Well, then that implementation can zero the DCCP checksum on the
outbound side and recomputed it on the inbound side, instead of forcing
more integrated implementations to calculate the checksum twice.

> GF>  This comes from the NAT behaviour where the module modifies the
IP
> (and port
> values for NAPT) of the outer headers. The encaps document doesn't say
how
> this works, and I expect a NAPT would re-write the "emphemeral" port
> anyway.
> So, I am guessing the encaps receiver should bind to ANY src port and
the
> standard DCCP_UDP dst port by default. The document should say WHY the
> method was chosen.
> 
[TomP] I'm not seeing the relationship of this to what's immediately
above.

> Abstract
> --------
>   * the term 'alternative' encapsulation is a bit misleading, since
there
> is
>     alternative, both DCCP-STD and DCCP-UDP are encapsulated in IPv4/6
> headers;
>   * it would be clearer to refer to the technique as something like
"DCCP-
> in-UDP"
>   * "without modification of those middleboxes"
>     =>  suggest e.g. 'modification of their software stacks' since
> "middleboxes"
>        otherwise is repeated in the same sentence
> 
[TomP] I think the abstract is pretty clear.

> 1. Introduction
> ---------------
>   * 'According to [RFC 4340], DCCP packets are directly encapsulated
...'
>     =>  this is clear from the definition of transport protocol, could
be
> omitted
> 
> GF>  I disagree: This was instead in the last review, to make clear
the
> NORMAL
> behaviour was standard RFC 4340 encaps.
> 
[TomP] I agree with Gorry.

>   * 'For convenience, the [RFC 4340] encapsulation (updated by [RFC
> 5596])'
>     =>  as above, perhaps one could refer to RFC 4340 as "native
> packetization of
>        DCCP within IP" or something similar;
[TomP] I find that very clumsy.

>     =>  the remark that RFC 4340 is updated by RFC 5596 is not
relevant,
> referencing
>        it would only make sense if there were discussion comparing the
> pros and cons
>        of the two approaches, which does not seem to be the aim of
this
> specification.
>        Since this document introduces a fix for current-generation NAT
> devices, it
>        could e.g. be said that current generation NAT devices also do
not
> support
>        RFC 5596 (hopefully Linux will soon), or the RFC reference
could be
> dropped.
> 
> >  I recommended adding this: The rationale was we need to be able to
> transition
> firewalls AND NATs and the same behaviour can not be expected at all
> middleboxes.
> Therefore, I argued that the encaps MUST support both RFC 4340 and the
> extension
> in 5596 to allow it to operate in the wild, especially with multiple
> NATs/Firewalls.
> 
[TomP] I think that this should be kept.  The capabilities of 5596 are
supported by DCCP-UDP.

>   * "The DCCP-UDP encapsulation specified here supports all of the
> features
>     contained in DCCP-STD except for partial checksums."
>     =>  Please see (e) above, it would be best not to introduce new
> assumptions
>        about DCCP and support the checksum by treating the
encapsulated
> packet
>        as opaque payload data of UDP. This would not restrict
application
> scenarios
>        ("sorry you can't use partial checksums because we are
tunneling
> you").
> 
> GF>  The intention was to allow applications to use the same partial-
> checksum code,
> but they wouldn't get benefit with UDP encaps. If they were to use
UDP-
> Lite encaps
> they would, but that is a corner case...
> 
[TomP] DCCP-UDP supports the semantics of partial checksums, but not the
function, as the UDP checksum covers the whole packet.  I think the
statement stands.
> 
> 3. DCCP-UDP
> -----------
>   * "(default port awaiting IANA action)"
>     sorry I don't understand why it is necessary to define a default
port?
>   * "The basic format of a DCCP-UDP packet is"
>     =>  Drawing could perhaps be simplified by referring from 'DCCP
> Generic
>        Header' downwards simply as "DCCP packet, possibly with header
> options,
>        as specified in RFC 4340, section 5".
> 
[TomP] Possibly, but I like the resemblance to the drawing in 4340.

>   * section 3.1, "(normally both are the default port to be assigned
by
> IANA)"
>     =>  meaning that 'Source Port' == 'Dest Port'?
>     =>  again, please, I don't understand why a default port is
required?
> 
[TomP] We've covered why the default port.  I suggest changing
"(normally both are the" to "(often both are initially the".

>   * Checksum:
>     - the specification (reference) of the UDP pseudo-header is
missing;
[TomP] RFC 0768 has already been referred to.  I can add another
reference here.

>     - as per (e) above it is better not to introduce assumptions about
the
>       contained payload, which would also simplify the specification,
i.e.
>       * checksums are to be used and computed as specified in RFC
4340,
>       * the DCCP pseudo-header uses the DCCP port numbers and the UDP
>         endpoint IP addresses (i.e. from the point of DCCP the
> encapsulating
>         UDP header does not exist);
>       * the DCCP-UDPv4 checksum computation then proceeds according to
>         RFC 768 with the UDP checksum field set to zero and using as
>         UDP length the length of the contained DCCP packet including
the
>         DCCP header and DCCP header options;
>       * the DCCP-UDPv6 checksum computation uses the pseudo-header
>         from RFC 2460, 8.1 with the Upper-Layer packet length set to
the
>         length of the contained DCCP packet including the DCCP header
and
>         options.
> 
[TomP] I don't agree with this (as covered before).

>   * section 3.2 could be omitted, since this is already specified in
>     RFC 4340 and as far as I understand the inner DCCP packet
semantics
>     are opaque for the purpose of NAT traversal;
> 
[TomP] We still the paragraph of text that's in the section.  I think it
doesn't hurt to repeat the diagrams and set the context for that
paragraph.

>   * section 3.3, checksum computation
>     - as per (e) above, this section could be omitted
>     - with regard to checksum validity it could be simplified by
>       referring validate DCCP-UDP packets according to RFC 768, with
>       the restriction that the checksum MUST NOT be disabled (zero
csum)
>     - (The term 'DCCP-NAT' has not been introduced in this document.)
> 
[TomP] I disagree.

>   * section 3.3.1
>     - s/Chesksums/Checksums/
[TomP] I'll fix the typo.

>     - same comment as per (e), section could be omitted
[TomP] I disagree.

> 
>   * section 3.5
>     - would be good to clarify the use of UDP fragmentation:
>       UDP implementations support fragmentation, UDPv6 in addition
> supports
>       jumbograms (RFC 2675), hence need clarification whether to
>       a) bump the maximum inner MTU of DCCP to exploit the limits of
UDP
> or
>       b) completely disallow fragmentation of DCCP-UDP packets (since
> possibly
>          not supported by hardware)
>     - how shall section 14 of RFC 4340 be interpreted in this context:
>       * is DCCP's MPS simply the UDP PMTU minus 8?
>       * apply RFC 5405 for UDP MTU fallback values?
> 
[TomP] I think that 4340 section 14 (including 14.2) covers these
issues.

>   * section 3.6
>     I don't understand the purpose of specifying the service code of
an
>     encapsulated protocol. Service code and encapsulation seem not
> related,
>     a connection could have any service-code value and still need UDP
>     encapsulation, but why not leaving this transparent to DCCP?
>     In particular, if assuming a "DCCP tunnelling service" or a type
of
>     overlay network, it would be difficult to alter the contained
service
>     code. Also, like the checksums, this again introduces new
assumptions
>     into DCCP and complicates the specification. My personal view is
to
>     allow DCCP to pick whatever service code is appropriate for the
type
>     of service used, and not to add additional rules restricting this
use
>     because the protocol ends up being "tunneled".
> 
[TomP] I think you mean section 3.7.  I believe the section says pretty
much what you say above.

> 
> 5. Signaling the Use of DCCP-UDP
> --------------------------------
>   * "listening for DCCP-UDP connections on the indicated UDP port (if
>     udp-port-num is included)
>     -->  suggest to make the use of `udp-port-num' mandatory ('MUST')
and
>         not to require an IANA-assigned well-known port
> 
[TomP] I disagree.

> GF>  Don't agree.
> 
> 7. IANA Considerations
> ----------------------
>   * same comment as earlier, perhaps I am missing something, but I
fail
>     to see the need for a default well-known port for DCCP
encapsulation
> 




[Kernel List]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]     [Linux Resources]

Powered by Linux