headers
Phelan, Tom | 5 Oct 2010 20:55

Re: Review in WGLC for draft-ietf-dccp-udpencap-02.txt.

Hi Colin,

I agree with your points below.

Tom P.

> -----Original Message-----
> From: Colin Perkins [mailto:csp <at> csperkins.org]
> Sent: Thursday, September 02, 2010 9:36 AM
> To: Gorry Fairhurst
> Cc: 'dccp' working group; Phelan, Tom
> Subject: Re: [dccp] Review in WGLC for
draft-ietf-dccp-udpencap-02.txt.
> 
> On 1 Sep 2010, at 09:17, Gorry Fairhurst wrote:
> ...
> >>> - I see the value of the IANA-specified destination port for a
> >>> client server app using a NAPT, where the NAPT changes only the
> >>> src port as it leaves the client, and does this differently for
> >>> each sender address behind the NAPT. What is the expected port
> >>> usage at the receiver? Does it listen on the IANA port bound to
> >>> any source port? Can you say more here?
> >>>
> >> [TomP] So section 3.1 says:
> >>    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-UDP packets (normally both are the default port
> >> to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phelan, Tom | 5 Oct 2010 21:32

Re: [udp-encap rev2] discussion/comments

Hi Gerrit,

See inline...

Tom P.

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On Behalf
Of
> Gerrit Renker
> Sent: Friday, September 03, 2010 6:52 AM
> To: dccp <at> ietf.org
> Subject: [dccp] [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.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Phelan, Tom | 5 Oct 2010 21:41

Re: WGLC for dccp-udpencap

Hi Eddie,

Thanks for the comments.  I am in general agreement.  See inline for
specifics.

Tom P.

> -----Original Message-----
> From: dccp-bounces <at> ietf.org [mailto:dccp-bounces <at> ietf.org] On Behalf
Of
> Eddie Kohler
> Sent: Monday, September 20, 2010 12:45 PM
> To: dccp <at> ietf.org
> Subject: Re: [dccp] WGLC for dccp-udpencap
> 
> Hello all,
> 
> I understand that WGLC for this draft has concluded, but in case
comments
> are
> useful, here are several.  I strongly approve of the document; it is a
> clean
> and useful spec and a good advance on prior versions, whether or not
these
> comments are addressed.  The only technical comment has to do with
> demultiplexing; this is important to address.
> 
> * Ports (section 3.1): I agree with those who have commented about the
> oddity
> of "normally both [souce & destination ports] are the default port to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi Sarolahti | 7 Oct 2010 11:55
Picon
Picon
Favicon
Gravatar

Re: [udp-encap rev2] discussion/comments

Hi,

I'm picking a selection of the Gerrit's comments for discussion below...

I'd appreciate prompt responses, so that we can soon be able to determine if we have common understanding
about the draft, and then move forward.

On Oct 5, 2010, at 10:32 PM, Phelan, Tom wrote:

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

Maybe it would be useful to explain in 3.3 a bit more why this approach was chosen, as Gorry suggested in an
earlier mail. Trying to remember the months-old discussion this, I guess the thinking was:

* UDP checksum is needed, to avoid problems caused by possible header corruption
* Since UDP checksum covers the packet, DCCP checksum is redundant and adds complexity especially with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lentvorski | 8 Oct 2010 10:19

Re: [udp-encap rev2] discussion/comments

On 10/5/10 12:32 PM, Phelan, Tom wrote:

> [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.

I hope I'm missing something, but ...

I'm *very* against usage-context sensitive protocol definitions.

Why should my DCCP stack need to know that it got wrapped in UDP 
somewhere along the line?

If somebody wants to only generate one checksum, it is better that they 
punt the UDP checksum.

Besides, my (admittedly old) copy of Stevens indicates that UDP 
checksums are optional.  Therefore, any random system routing the UDP 
packets can legally smash that checksum, no?

In addition, on an embedded system, I have to carry the code around to 
generate both a UDP checksum *and* a DCCP checksum if I have a DCCP 
stack in order to comply with this encap.  If the DCCP checksum is 
extant, I can punt the UDP checksum code.

That's not being very nice to the people running small systems.  So, for 
example, if I want to run DCCP on a system with lwIP, I'm going to have 
to go find the SO_NO_CHECK option in lwIP to enable UDP checksums, kick 
it on, recompile *lwIP* (and reprogram my RTOS or similar), eat the code 
space, and redeploy my *OS*--all just for DCCP.  That's not going to win
(Continue reading)

Permalink | Reply | 10 comments |
headers
Lars Eggert | 8 Oct 2010 10:29
Picon
Gravatar

Re: [udp-encap rev2] discussion/comments

Hi,

On 2010-10-8, at 11:19, Andrew Lentvorski wrote:
> Besides, my (admittedly old) copy of Stevens indicates that UDP 
> checksums are optional.

they are optional for IPv4 but (currently) mandatory for IPv6. (Just a data point.)

Lars
Attachment (smime.p7s): application/pkcs7-signature, 3815 bytes
Permalink | Reply | 0 comments |
headers
L.Wood | 8 Oct 2010 10:54
Picon
Favicon

Re: [udp-encap rev2] discussion/comments

Andrew,

a few points:

- turning off the UDP checksum (which also acts as a necessary demultiplexing at-the-right-endpoint
check) has repeatedly proven to be a very bad idea. Subtle NFS corruption etc. See the end-to-end papers.
Saying 'well, the higher layers will obviously check their work in this case' hasn't worked out so well in practice.

- That UDP encap overhead is trivial, even on smaller systems. Leaving out TCP - big code space win. Removing
UDP as well and giving up going through many firewalls/NATs - not so great a tradeoff for the smaller space
saved. (I've worked with endhosts that only speak UDP.)

- that UDP can now compute a checksum only on its headers, using a redundant length field to indicate
checksum coverage length. It's called UDP-Lite - this would carry DCCP without having to checksum the
payload twice. Unfortunately, Lite was eventually given a different protocol number, rather than being
a simple upgrade to UDP, because pretty much all existing implementations relied on the 'wrong' UDP
length field and preferred it over the IP length field, so the redundant field wasn't really redundant
after all.

So you can argue for DCCP over UDP-Lite as more efficient from a checksum coverage computation viewpoint,
in that both DCCP and UDP-Lite can protect (checksum) just their headers, and leave payload checking to
the application. But UDP-Lite has the same problems with NAT and firewalls that DCCP does, as it's an
unusual protocol number... (And Lite's pass-errored-stuff-to-application focus is pretty useless
over any MAC layer checking its own payloads against channel errors, e.g. Ethernet's CRC32c frame check.)

I'm really looking forward to reading a possible specification for the UDP-Lite in UDP encap, where
handwaving will be used to justify turning off the outer UDP checksum for IPv4!

L.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gorry Fairhurst | 8 Oct 2010 11:48
Picon
Picon

Re: [udp-encap rev2] discussion/comments

See comments in line...

On 08/10/2010 09:54, L.Wood <at> surrey.ac.uk wrote:
> Andrew,
>
> a few points:
>
> - turning off the UDP checksum (which also acts as a necessary demultiplexing
 > at-the-right-endpoint check) has repeatedly proven to be a very bad 
idea.
 > Subtle NFS corruption etc. See the end-to-end papers. Saying 'well,
 > the  higher layers will obviously check their work in this case'
 > hasn't worked out so well in practice.
 >
I support mandating the checksum for transports. Although I agree this 
has implications for lightweight systems and this we should always be 
mindful about.

> - That UDP encap overhead is trivial, even on smaller systems.
 > Leaving out TCP - big code space win. Removing UDP as well and giving up
 > going through many firewalls/NATs - not so great a tradeoff for the 
smaller
 > space saved. (I've worked with endhosts that only speak UDP.)
>
Agree with Lloyd.

We could have mandated an inner DCCP checksum for IPv4 and a UDP 
checksum for IPv6 (already mandated for all end-to-end IPv6 transports). 
There would be differences then between v4 and v6 which seems to me to 
be a poor side-effect. But I do not think *IS* the issue the WG were
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phelan, Tom | 8 Oct 2010 16:25

Re: [udp-encap rev2] discussion/comments

Hi Andrew,

See inline...

Tom P.

> -----Original Message-----
> From: Andrew Lentvorski [mailto:bsder <at> allcaps.org]
> Sent: Friday, October 08, 2010 4:19 AM
> To: Phelan, Tom
> Cc: Gerrit Renker; dccp <at> ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
> 
> On 10/5/10 12:32 PM, Phelan, Tom wrote:
> 
> > [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.
> 
> I hope I'm missing something, but ...
> 
> I'm *very* against usage-context sensitive protocol definitions.
> 
> Why should my DCCP stack need to know that it got wrapped in UDP
> somewhere along the line?
> 
> If somebody wants to only generate one checksum, it is better that
they
(Continue reading)

Permalink | Reply | 3 comments |
headers
Phelan, Tom | 8 Oct 2010 16:29

Re: [udp-encap rev2] discussion/comments

Hi Lloyd,

I'm pretty much in line with what you say here.  See inline for
details...

Tom P.

> -----Original Message-----
> From: L.Wood <at> surrey.ac.uk [mailto:L.Wood <at> surrey.ac.uk]
> Sent: Friday, October 08, 2010 4:55 AM
> To: bsder <at> allcaps.org
> Cc: L.Wood <at> surrey.ac.uk; Phelan, Tom; gerrit <at> erg.abdn.ac.uk;
dccp <at> ietf.org
> Subject: Re: [dccp] [udp-encap rev2] discussion/comments
> 
> Andrew,
> 
> a few points:
> 
> - turning off the UDP checksum (which also acts as a necessary
> demultiplexing at-the-right-endpoint check) has repeatedly proven to
be a
> very bad idea. Subtle NFS corruption etc. See the end-to-end papers.
> Saying 'well, the higher layers will obviously check their work in
this
> case' hasn't worked out so well in practice.
> 
[TomP] Yes, and I've committed to adding "UDP checksum of zero is
interpreted as invalid checksum" to the next revision.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane