-IP-tunnel
(or even GRE) and rely on decap at the endpoints...
Does DCCP have any applications using it?
Note that I am NOT expressing a preference for any particular draft here. We
should not follow either approach.
Lloyd Wood
http://sat-net.com/L.Wood
ling complex protocols that still
won't be used? Pointless.
> The functionality could be as well be integrated into the IP stack, but
> that would be somewhat more challenging.
...and won't happen.
L.
>
> regards,
> Jukka
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
... so there's no need to tunnel
these over UDP to get through NAT.
actual applications running on an actual end-user computer with a TCP/IP stack,
please.
On 26 Apr 2010, at 23:49, Brian F. G. Bidulock wrote:
> L.Wood,
>
> Hmmm. SIGTRAN requires SCTP. SIGTRAN is widely
-variant screwdrivers.
And there was consensus that the OSI protocols would be useful and a lot of
workgroups were formed. So?
(Approach to follow? Neither)
Lloyd Wood
http://sat-net.com/L.Wood
From: Michael Welzl [mich...@ifi.uio.no]
Sent: 27 April 2010
t this approach is stuck with, I think.
Lloyd Wood
http://sat-net.com/L.Wood
From: Fred Baker [f...@cisco.com]
Sent: 27 April 2010 10:55
To: Lars Eggert
Cc: bidul...@openss7.org; dccp@ietf.org; tsv-a...@ietf.org; tsvwg list; Wood L
Dr (Electronic Eng)
complicated way to do UDP
tunnelling instead of just doing UDP tunnelling won't change that.
Lloyd Wood
http://sat-net.com/L.Wood
From: Michael Welzl [mich...@ifi.uio.no]
Sent: 27 April 2010 12:08
To: Wood L Dr (Electronic Eng)
Cc: dccp@ietf.org; tsv
te what is being done here with a
> particular weird encap, as well as the original ports on the interior packet,
> is something that this approach is stuck with, I think.
>
> Lloyd Wood
> http://sat-net.com/L.Wood
>
> From: Fred Baker
e?
>
> All this effort to save a few bytes tunnelling complex protocols that still
> won't be used? Pointless.
>
>> The functionality could be as well be integrated into the IP stack,
>> but that would be somewhat more challenging.
>
> ...and won't happen.
The SCTP/UDP encapsulation is implemented in FreeBSD and part of the SCTP
kernel implementation for Mac OS X.
Best regards
Michael
>
> L.
>
>>
>> regards,
>> Jukka
>
> Lloyd Wood
> l.w...@surrey.ac.uk
> http://sat-net.com/L.Wood
>
>
>
>
n
> > headers and pseudo-header' to decrease the computational overhead -
> > that should be a fixed value.
> >
> > Using a UDP (or lite) port to indicate what is being done here with
> > a particular weird encap, as well as the original ports on the
> > in
a unique loopback address with each different connection and state becomes very
straightforward...)
Lloyd Wood
http://sat-net.com/L.Wood
From: Phelan, Tom [tphe...@sonusnet.com]
Sent: 28 April 2010 14:36
To: Wood L Dr (Electronic Eng); aco...@optonl
do matter.
>>
>> Thanks,
>> Lars
>>
>> PS: I'm pushing on this topic, because UDP encapsulation is the last
>> remaining work item in the DCCP working group before it can close...
>
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
so there's no need to tunnel these over UDP to get through NAT.
>>
>> actual applications running on an actual end-user computer with a
>> TCP/IP stack, please.
>>
>> On 26 Apr 2010, at 23:49, Brian F. G. Bidulock wrote:
>>
>>> L.Wood,
>>&g
cation for the UDP-Lite
in UDP encap, where handwaving will be used to justify turning off the outer
UDP checksum for IPv4!
L.
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
On 8 Oct 2010, at 09:19, Andrew Lentvorski wrote:
> On 10/5/10 12:32 PM, Phelan, Tom wrote:
>
>>
need
> to think about that a little more.
Some reading may help, but the RFCs and most textbooks aren't very good at
explaining decisions behind design choices. That leaves Stevens vol. 1,
which doesn't contain lessons illustrated by modern transport protocol
examples - and isn't bothered by NATs.
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
> what is the status of draft-ietf-dccp-udpencap?
deader than dccp itself, I believe.
Oh. It's still not dead?
-Original Message-
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Pasi
Sarolahti
Sent: 29 November 2010 14:00
To: dccp@ietf.org group
Subject: Re: [dccp] status of draft-ietf-dccp-udpencap
Hi all,
People must have been wondering about t
Um, the U in UDP stands for User. As in, userspace.
A kernel implementation of this hack? It would need users first.
-Original Message-
From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf Of Eddie
Kohler
Sent: 10 January 2011 15:12
To: Pasi Sarolahti
Cc: go...@erg.abdn.
As an actual native English speaker on this thread, I would
use 'cannot' for 'cannot obtain', as it indicates an
impossibility, never a choice, but stay with 'can not' in
the other cases. I cannot live forever; I don't get the choice.
I can not care about this silly thread, but I choose to post
reg
idiomatic text should be avoided in technical writing.
> -Original Message-
> From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On
> Behalf Of Eddie Kohler
> Sent: 04 March 2011 15:27
> To: Gerrit Renker
> Cc: dccp@ietf.org group
> Subject: Re: [dccp] AD review: draft-ietf-dccp-
could keep it as it is, the
>>> suggestion confuses me:
>>>> can is a verb, not the negation, cannot is spoken language, the
>>>> document is written text. I actually replace everywhere I
>>> see this the
>>>> other way around, since I read somewhere that cannot in
>>> written text
>>>> is not considered good style. If you can give a rule for
>>> the above, I
>>>> am willing to be educated on the matter.
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
his time or
> not. (I am guessing the RFC Editor will change it later anyway.)
>
> Lars
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
tid=655717
> Can we please focus on the technical discussion and not at grammar nit fixing?
of DCCP? What's the point?
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood
CCP deployment to get to widespread
TFRC use is unlikely to happen. How best to get widespread adoption of TFRC
itself?
Lloyd Wood
l.w...@surrey.ac.uk
http://sat-net.com/L.Wood/
> -Original Message-
> From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On
> Behalf Of Mich
what matters, while widespread DCCP
>> deployment for applications to rely on appears to me to be a lost cause even
>> with the kludging to make DCCP run over UDP.
>>
>> It's an algorithm deployment issue, not a protocol deployment issue. The
>> goal i
24 matches
Mail list logo
