Subject: Re: [tcpm] "TCP Multipath" with shim6

From: Scott Leibrand <[email-masked]>
Date: Fri, 31 Mar 2006 17:18:50 -0500 (EST)

On 03/31/06 at 1:59pm -0800, Joe Touch <[email-masked]> wrote:

> > Can anyone think of any problems with this approach?
>
> You seem to have listed more than enough above. ;-)

Heh.

On 03/31/06 at 2:07pm -0800, Caitlin Bestler <[email-masked]> wrote:

> Joe Touch wrote:
>
> > Hacking TCP to provide something SCTP - or even BXXP over
> > separate TCP connections - would provide seems like a poor
> > way to justify the need for Shim6.
>
> More generally, any attempt to hack TCP to provide something
> SCTP like is inherently an interim strategy to work around
> middlebox shortcomings.

Wouldn't it also be a way to get around the shortcoming that most
operating systems don't support SCTP?  Of course, most TCP/IP stacks don't
support shim6 either, so we'll have to see which gets widespread support
(particularly in Windows) first...

> As long as you are playing that game, IPv4 support and NAT compatibility
> is essential.

Point taken.  IPv4 support is on the roadmap for shim6, but not NAT (yet).

> If you are dealing with how the network SHOULD work then you SHOULD use
> SCTP and write a shim to pack byte streams into chunk streams (assuming
> your application was truly byte-stream oriented in the first place, if
> it was already truly message oriented then the shift to SCTP is even
> simpler).

Yeah.  My background is in Network Operations and only recently
Engineering, so my focus is to try to come up with solutions that can be
unilaterally implemented and interoperate with the existing userbase.  I
agree that SCTP is better suited to multipath than TCP (although TCP+shim6
is close, it's a few years behind).  Perhaps I should focus on SCTP for
now, and keep this idea in my back pocket in case shim6 gets more
widespread adoption than SCTP...

-Scott

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 31 Mar 2006 14:07:40 -0800

More generally, any attempt to hack TCP to provide something
SCTP like is inherently an interim strategy to work around
middlebox shortcomings. As long as you are playing that game,
IPv4 support and NAT compatability is essential. If you are
dealing with how the network SHOULD work then you SHOULD use
SCTP and write a shim to pack byte streams into chunk streams
(assuming your application was truly byte-stream oriented in
the first place, if it was already truly message oriented then
the shift to SCTP is even simpler).

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Mar 2006 14:41:03 -0800

> (particularly in Windows) first...

That's the problem. You can't address the lack of SCTP deployment by
introducing a new lack of TCP-multipath deployment ;-)

Alternately, just call SCTP "TCP-multipath" and you're basically done,
right?

> Point taken.  IPv4 support is on the roadmap for shim6, but not NAT (yet).

I'm not sure I agree with the issue of NATs; NATs are a moving target
that wants to be taken seriously but also wants to silently violate
whatever architectural principles it wants for its own benefit. It's
impossible to design systems to work with that - it just ends up 'mutual
escalation'.

> widespread adoption than SCTP...

The key question is what shim6 provides and for whom. Right now, we have
competing solutions - shim6, HIP, SCTP - granted, at different layers,
but still similar w.r.t. multihoming. The big question is how many
solutions do we need or want?

Joe

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 31 Mar 2006 21:50:03 -0500 (EST)

> introducing a new lack of TCP-multipath deployment ;-)

More precisely, the lack of shim6 deployment.  Because if the recipient
doesn't support TCP-multipath, that's OK.  He can still *receive*
multipath (and not even know it, except that "it's faster") if he supports
shim6.  As a new layer 3 protocol, shim6 adoption may be easier than
getting enough applications changed to call SCTP instead of TCP to make a
difference.

> Alternately, just call SCTP "TCP-multipath" and you're basically done,

No, because for that to work, both sides have to use SCTP *instead* of
TCP.  For TCP+shim6 multipath, OS's just have to be updated to be shim6
compatible.  IMO it's easier to add shim6 to a TCP/IP stack, and just have
it sitting there ready to spring into action upon receipt of a shim6 I1
message, than to try to convince every application developer out there of
the benefits to rewriting their application (or the socket calls) to try
SCTP first, and if that fails try TCP.

> solutions do we need or want?

Well, the reason we need or want multiple solutions is not so that they'll
all get implemented on your grandmother's PC, but rather so that they can
compete for early adopters, and you have a greater likelihood that at
least one of them might prove useful enough to get widespread adoption.
Put another way, different protocols were designed for different niche
uses, and while they may be architecturally similar, in the real world of
getting them to work well enough for people to actually use them, the fact
that they operate at different layers, or have other subtle differences,
can be the difference between viable for widespread use and a niche
protocol which can never improve the Internet experience for your grandma
(or your precocious nephew with a server farm in his basement).

-Scott