Well, not sure what wastes CPU cycles, since the checksums need to be
(re)computed in any UDP tunneling scheme?
Our implementation is a separate process to make deployment easier (no
need for support from OS provider), but you could integrate the
computing into your stack and maybe save a few cycles.
Jukka
On 04/13/2010 06:26 PM, Phelan, Tom wrote:
Oh, I understand now. So this just wastes CPU cycles to get
transparency?
-----Original Message-----
From: Jukka Manner [mailto:jukka.manner@xxxxxx]
Sent: Tuesday, April 13, 2010 10:46 AM
To: Phelan, Tom
Cc: Colin Perkins; DCCP working group
Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt
No, because the outer UDP checksum protects the tunneled part, right?
Jukka
On 04/13/2010 05:28 PM, Phelan, Tom wrote:
Hi Jukka,
Are you saying that the receiving GUT recalculates the DCCP
checksum?
But the only effect that would have is to make any errors introduced
on
the way undetectable.
Tom P.
-----Original Message-----
From: Jukka Manner [mailto:jukka.manner@xxxxxx]
Sent: Tuesday, April 13, 2010 12:58 AM
To: Phelan, Tom
Cc: Colin Perkins; DCCP working group
Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt
Yes, that's right. Except that GUT itself recalculates the checksum
before the packet hits the DCCP receiver. Thus, the
UDP-encapsulated
DCCP flow never needs to do anything - it never even sees that GUT
was
there.
regards,
Jukka
On 12.4.2010 23:17, Phelan, Tom wrote:
Hi Jukka,
Well, I guess one of us misunderstands something, because it looks
to me
like GUT doesn't work. Taking your example in section 3.3 of the
draft:
We start out with a DCCP packet encapsulated in IP as:
Dest addr (DA): B
Src addr (SA): A
DCCP Ports : E and F (I assume that's what your notation
means)
DCCP checksum calculated over contents of DCCP packet and IP
pseudo header with DA/SA = B/A
This packet gets GUT'd as:
DA: B
SA: A
UDP Ports: E and GUT
DCCP packet unchanged
This packet gets NAT'd as:
DA: B
SA: C
UDP Ports: P and GUT
DCCP Packet unchanged
This packet arrives at the remote host and gets un-GUT'd as:
DA: B
SA: C (!)
DCCP packet unchanged
And this packet fails DCCP checksum because the Source Address (C)
is
different now than when the checksum was calculated initially
(with
SA =
A).
What am I missing?
Tom P.
-----Original Message-----
From: Jukka Manner [mailto:jukka.manner@xxxxxx]
Sent: Monday, April 12, 2010 3:21 PM
To: Phelan, Tom
Cc: Colin Perkins; DCCP working group
Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt
DCCP wouldn't need to care about checksums if we had a generic
encapsulation scheme, such as the one we have been discussing on
the
TSV
list, the Generic UDP Tunneling scheme GUT.
Jukka
On 04/12/2010 06:05 PM, Phelan, Tom wrote:
Hi All,
OK, I'll accept the apparent consensus and make the DCCP header
the
same
format in both encapsulations. Note that a DCCP implementation
is
still
going to need to know whether this came in with UDP encap or STD
encap
-- the checksum processing needs to be different at least.
Tom P.
-----Original Message-----
From: Colin Perkins [mailto:csp@xxxxxxxxxxxxx]
Sent: Sunday, April 11, 2010 5:55 AM
To: Phelan, Tom
Cc: Pasi Sarolahti; DCCP working group
Subject: Re: I-D Action:draft-ietf-dccp-udpencap-00.txt
On 7 Apr 2010, at 15:14, Phelan, Tom wrote:
-----Original Message-----
From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx]
Sent: Thursday, February 18, 2010 5:54 PM
To: DCCP working group
Cc: Phelan, Tom
Subject: Fwd: I-D
Action:draft-ietf-dccp-udpencap-00.txt
...
* worth considering a straight UDP encapsulation that does
not
adjust
the position and order of the fields.
-- Gorry / 2009-11-20
[Tom P.] Worth considering, but since there are already two
implementations of the existing encapsulation I'm going to
resist
this.
We're early enough in the life of DCCP that I'd prefer we get
this
right, than preserve running code that has minimal deployment.
--
Colin Perkins
http://csperkins.org/
--
Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481
Aalto University Mobile: +358+(0)50+5112973
Department of Communications Fax: +358+(0)9+470 22474
and Networking (Comnet) Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@xxxxxx
Finland www.netlab.hut.fi/~jmanner/
--
Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481
Aalto University Mobile: +358+(0)50+5112973
Department of Communications Fax: +358+(0)9+470 22474
and Networking (Comnet) Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@xxxxxx
Finland www.netlab.hut.fi/~jmanner/
--
Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481
Aalto University Mobile: +358+(0)50+5112973
Department of Communications Fax: +358+(0)9+470 22474
and Networking (Comnet) Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@xxxxxx
Finland www.netlab.hut.fi/~jmanner/
