Hi,
as most of you probably know, there are two different proposals for how to
encapsulate SCTP and DCCP inside UDP.
One approach proposes two protocol-specific encapsulation schemes (described in
draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).
The second approach proposes a generi
On Apr 22, 2010, at 3:50 AM,
wrote:
http://tools.ietf.org/html/draft-ietf-dccp-udpencap-00#section-3.3
section 3.3 of the draft and its use of UDP as UDP-lite -- despite
UDP-lite being given a different protocol number because consensus
was that messing with UDP checksum and length fiel
Hi Lloyd,
I have to object here. :)
On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
The GUT draft and recreating IP packets strikes me as problematic in
implementation, just as much as NATs. I'd rather have a simple IP-in-IP-tunnel
(or even GRE) and rely on decap at the endpoints...
GUT is
On 26 Apr 2010, at 20:07, Jukka Manner wrote:
> Hi Lloyd,
>
> I have to object here. :)
>
> On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
>
>> The GUT draft and recreating IP packets strikes me as problematic in
>> implementation, just as much as NATs. I'd rather have a simple
>> IP-in-IP-t
I don't think that counts as a we-chose-to-use-SCTP end user...
SIGTRAN infrastructure in the telephony providers doesn't go through NAT. ergo,
SCTP's most popular use doesn't need to go through NAT. And DCCP doesn't need
to go through NAT, because no-one uses DCCP... so there's no need to tunne
Hi,
please keep this discussion focused on which approach we should follow for
UDP-encapsulating DCCP and SCTP.
I'm happy Lloyd posted his views. I'm hoping other community members will speak
up as well. If I were asked to characterize current consensus, I'd probably say
"disinterest for eithe
Hi,
Okay, I herewith speak up: yes I want to see UDP encapsulation for
both these protocols
(but right now I'm not sure which one).
Both SCTP and DCCP are useful - if there was no consensus on that,
ever, these
groups would never have been formed, and the protocols would never have
been de
"A bit stupid"?
UDP encapsulation of these protocols can already be done. Tunnelling is not
new. IP packet, UDP header, IP outer header, you're done.
What is not needed or justified is a 'special' encap which requires
documentation, implementation, and then deployment - because lack of deployme
Fred,
advocating removing the interior protocol checksum across header and payload
(and reconstituting/recomputing it afterwards) violates end-to-endidness and
weakens the reliability guarantee. Bad idea. From a checksum perspective, you'd
do better saying 'use UDP lite with a minimal check jus
Hi,
On Apr 27, 2010, at 12:06 PM,
wrote:
"A bit stupid"?
Sorry - I didn't mean to be personal, my point was that this
looks like a self-contradicting (somehow circular) argument.
UDP encapsulation of these protocols can already be done. Tunnelling
is not new. IP packet, UDP header,
They're already deployment failures.
Straightforward UDP tunnelling (encapsulate IP packet in UDP payload, that's
all) is not happening for these protocols.
A custom encapsulation method tailored just to carrying these protocols (in
effect, a pointless addition to each protocol) is not justified
IMHO, what should drive the use or no use of UDP is "the need and use of
UDP functons", rather then "the need to make the SCTP and SCCP more
popular because of using a popular transport". Perhaps I am not reading
right the motivation, but I somehow get that frm the thread - sorry...
Which is to sa
Hi Fred,
I can understand in general your point that things should not be done multiple
times.
So you argue not to have a UDP and SCTP/DCCP checksum and not to duplicate the
port
numbers. I would like to address these suggestions individually:
1. Checksum
SCTP uses a 32-bit CRC32c which is m
On Apr 26, 2010, at 9:07 PM, Jukka Manner wrote:
> Hi Lloyd,
>
> I have to object here. :)
>
> On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
>
>> The GUT draft and recreating IP packets strikes me as problematic in
>> implementation, just as much as NATs. I'd rather have a simple
>> IP-in-IP
On Apr 26, 2010, at 10:34 PM, wrote:
>
> On 26 Apr 2010, at 20:07, Jukka Manner wrote:
>
>> Hi Lloyd,
>>
>> I have to object here. :)
>>
>> On 22.4.2010 13:50, l.w...@surrey.ac.uk wrote:
>>
>>> The GUT draft and recreating IP packets strikes me as problematic in
>>> implementation, just as
But encapsulation methods intended for endhosts wind up in middleboxes.
Look at Cisco's RBSCP and WAAS (and the recently discontinued NCE), which
already rewrite between SCTP and TCP checksums.
Any new encap method blessed by the IETF must be considered for worst-case
middlebox use - where rewr
That's hardly integrated into a shipping IP stack.
FreeBSD may be an SCTP reference implementation, but that's not significant
deployment.
-Original Message-
From: Michael Tüxen [mailto:michael.tue...@lurchi.franken.de]
Sent: 27 April 2010 19:16
To: Wood L Dr (Electronic Eng)
Cc: jukka.
Hi,
the discussion has touched on lots of things related to UDP encaps, but I
haven't seen anything I'd call consensus on the question below. I'd therefore
like to ask folks to specifically state which option they support:
(1) do one SCTP-specific and one DCCP-specific UDP encaps
(2) do one gen
On 5/18/10 12:37 AM, Lars Eggert wrote:
Hi,
the discussion has touched on lots of things related to UDP encaps, but I
haven't seen anything I'd call consensus on the question below. I'd therefore
like to ask folks to specifically state which option they support:
(1) do one SCTP-specific and o
to Android.
Tom P.
> -Original Message-
> From: dccp-boun...@ietf.org [mailto:dccp-boun...@ietf.org] On Behalf
Of
> Andrew Lentvorski
> Sent: Tuesday, May 18, 2010 4:19 AM
> To: Lars Eggert
> Cc: DCCP working group; TSV Area; ts...@ietf.org
> Subject: Re: [dccp] UDP enc
Hi Lars,
Well, I like option 1.
I feel that option 2 is a chimera. The 'G' in the GUT proposal stands
for "generic", but it is not entirely generic. The decapsulation stage
is specific to the encapsulated protocol. The GUT draft gives one decap
rule that is more-or-less suitable for TCP and DC
On May 18, 2010, at 9:37 AM, Lars Eggert wrote:
> Hi,
>
> the discussion has touched on lots of things related to UDP encaps, but I
> haven't seen anything I'd call consensus on the question below. I'd therefore
> like to ask folks to specifically state which option they support:
>
> (1) do on
3. neither
(a solution for 2. already exists. It's called UDP tunnelling.)
On 18 May 2010, at 08:37, Lars Eggert wrote:
> Hi,
>
> the discussion has touched on lots of things related to UDP encaps, but I
> haven't seen anything I'd call consensus on the question below. I'd therefore
> like to
Tom,
At 15:08 18/05/2010, Phelan, Tom wrote:
Hi Lars,
Well, I like option 1.
I feel that option 2 is a chimera. The 'G' in the GUT proposal stands
for "generic", but it is not entirely generic. The decapsulation stage
is specific to the encapsulated protocol. The GUT draft gives one decap
r
Lars,
At 08:37 18/05/2010, Lars Eggert wrote:
Hi,
the discussion has touched on lots of things related to UDP encaps,
but I haven't seen anything I'd call consensus on the question
below. I'd therefore like to ask folks to specifically state which
option they support:
(1) do one SCTP-speci
Hi,
Somewhat obviously, I support
2. a generic solution
since I believe it can be done. GUT is just one design which has a
certain deployment scenario in mind and use cases. But I believe we can
build on GUT and develop it further, or create an alternative general
solution, why not.
At lea
Lars,
I support 3. (Existing tunnelling should suffice.)
--brian
Lars Eggert wrote: (Tue, 18 May 2010 10:37:49)
> Hi,
>
> the discussion has touched on lots of things related to UDP encaps,
> but I haven't seen anything I'd call consensus on the question below.
> I'd
On 5/18/10 4:03 PM, Brian F. G. Bidulock wrote:
Lars,
I support 3. (Existing tunnelling should suffice.)
What is defined as "existing tunnelling"?
How do I get DCCP packets over UDP if I don't have root access to a machine?
I can create DCCP packets at a user level by linking in a user space
Hi,
On 2010-5-18, at 10:37, Eggert Lars (Nokia-NRC/Espoo) wrote:
> (1) do one SCTP-specific and one DCCP-specific UDP encaps
> (2) do one generic UDP encaps that can be used with both
> (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
my current count of folks who stated an opin
At 07:00 AM 5/21/2010, Lars Eggert wrote:
Hi,
On 2010-5-18, at 10:37, Eggert Lars (Nokia-NRC/Espoo) wrote:
> (1) do one SCTP-specific and one DCCP-specific UDP encaps
> (2) do one generic UDP encaps that can be used with both
> (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
Lars,
On 21 May 2010, at 13:00, Lars Eggert wrote:
On 2010-5-18, at 10:37, Eggert Lars (Nokia-NRC/Espoo) wrote:
(1) do one SCTP-specific and one DCCP-specific UDP encaps
(2) do one generic UDP encaps that can be used with both
(3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
Randall,
If you're referring to RBSCP, which is a weak TCP/SCTP PEP that
uses SCTP between tunnel endpoints, then yes, that is available
in SCTP-capable Cisco routers. But it's not in widespread use.
having a large number of IANA PPIDs for SCTP is simply
an indication that SCTP is overspecified.
On May 22, 2010, at 10:18 PM, wrote:
> Randall,
>
> If you're referring to RBSCP, which is a weak TCP/SCTP PEP that
> uses SCTP between tunnel endpoints, then yes, that is available
> in SCTP-capable Cisco routers. But it's not in widespread use.
>
> having a large number of IANA PPIDs for SCT
Lars:
I vote for 1
R
On May 21, 2010, at 5:00 AM, Lars Eggert wrote:
Hi,
On 2010-5-18, at 10:37, Eggert Lars (Nokia-NRC/Espoo) wrote:
(1) do one SCTP-specific and one DCCP-specific UDP encaps
(2) do one generic UDP encaps that can be used with both
(3) do neither (don't do any sort of UDP en
One other side thing to remember is that the
draft as been implemented in FreeBSD/Mac (and its Windoz version).
I will ping Vlad and see if he has done it for linux.. I know
it was on his list...
R
On May 21, 2010, at 12:01 PM, James M. Polk wrote:
At 07:00 AM 5/21/2010, Lars Eggert wrote:
Hi
There are several projects I have worked on that
DO use SCTP internally. Do they run on the big I.. in a way,
they are in routers.
Are they behind NAT's no.. since most NAT's with two exceptions do
not support SCTP.
There are other protocols that I am aware of in Datacenters as well that
have pi
Hi Lars,
I vote for (1), SCTP-specific and DCCP-specific UDP encaps.
Although those specific encaps could be very similar, or in fact
identical at first, there are enough protocol differences to recommend
planning ahead for potential divergence.
At minimum there could be two documents that a
Lars
1)
They may look similar now, but their paths could (will:-) diverge over the
life of the RFC and then it will be easier to evolve them separately.
Tom Petch
- Original Message -
>
> On 5/18/10 12:37 AM, Lars Eggert wrote:
> > Hi,
> >
> > the discussion has touched on lots of thi
Hi,
I see some weak consensus emerging for option #1. Please continue to state your
opinion; I'll close the call Friday.
Thanks,
Lars
On 2010-5-21, at 8:00, Eggert Lars (Nokia-NRC/Espoo) wrote:
> On 2010-5-18, at 10:37, Eggert Lars (Nokia-NRC/Espoo) wrote:
>> (1) do one SCTP-specific and one DC
Hi,
On 2010-5-25, at 17:07, Eggert Lars (Nokia-NRC/Espoo) wrote:
> I see some weak consensus emerging for option #1. Please continue to state
> your opinion; I'll close the call Friday.
I haven't seen any further follow-up, so we do seem to have weak consensus of
going forward with option #1 (d
40 matches
Mail list logo
