Subject: RE: [tcpm] TCPx2

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 8 May 2006 11:57:03 -0700

[email-masked] wrote:
>> Agreed, but as I read the proposal it has the same impediments to
>> deployment as SCTP without any of the additional features.
>> 
>> Is there any reason why the network elements that do not support SCTP
>> will support TCPx2?
> 
> People use TCP?
> 
> allman

But they don't use TCPx2.

Any middlebox firmware developer can still refuse to add a
single line of firmware to support TCPx2 and they cite the
fact that nobody is using it as justification.

Applying the *same* PNAT logic used for TCP and UDP
for SCTP would be also be a very similar change.
But it doesn't make the cut because nobody uses it,
and nobody uses it because...

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 15:10:44 -0400

> Any middlebox firmware developer can still refuse to add a single line
> of firmware to support TCPx2 and they cite the fact that nobody is
> using it as justification.
> 
> Applying the *same* PNAT logic used for TCP and UDP for SCTP would be
> also be a very similar change.  But it doesn't make the cut because
> nobody uses it, and nobody uses it because...

First, you're missing the (admittedly pithy) point.  It's an easy change
to NATs to make x2, DCCP, SCTP, whatever work.  TCP is widely used.
SCTP is not.  If we standardized x2 then we'd be migrating, not building
From zero.  You asked if there was a reason and my own opinion is that
the difference is in the massive use of TCP that could be a base for
x2.  SCTP does not have the base.  (And, note, that I am not trying to
disparage SCTP here.  I am just noting what I see as a practical
difference.) 

Second, I think this entire line of wondering is sort of ridiculous.  If
we block on what some network element (or even all current "network
elements") will block then we'll never do anything.

allman