Re: I-D Action:draft-ietf-dccp-udpencap-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux