Subject: RE: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL"

From: "Uri Elzur" <[email-masked]>
Date: Thu, 5 Dec 2002 17:21:14 -0800

DDP/MPA actually does work with "network" as-is. True it requires deployment on both ends. 
SCTP may also require endpoints and boxes in the infrastructure changed

Uri
-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 5:00 PM
To: Caitlin Bestler
Cc: Williams, Jim; [email-masked]'; [email-masked]'
Subject: Re: [Tsvwg] Re: [rddp] "DO IT RIGHT", or "DON'T DO IT AT ALL"

Caitlin Bestler wrote:
> The goal for DDP over TCP has always been twofold:
> 
> - to allow DDP to work the way it was intended to work.
> 
> - to allow DDP to work with the IP networks as they are,
>   without any adverse effect on any middleboxes, or
>   any dependency on network architecture.
>   
> I would maintain that however messy MPA might be, it meets
> both of these objectives.
> 
> SCTP is indeed a superior protocol to MPA/TCP for DDP, as it
> is for many applications.
> 
> Realistically, however, if DDP relied solely upon SCTP it
> would *not* meet the objective to work with IP networks *as
> they are*. There are too many environments where middleboxes
> have no SCTP capability, or at least no SCTP ability that
> has been enabled.

Good. But then DDP doesn't work with networks as they are either. It has 
to be installed on both ends.

I.e., as I've said before, this is a new transport protocol. Call it 
that. Pick another number. 6 is taken.

Joe

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Dec 2002 17:44:15 -0800

> SCTP may also require endpoints and boxes in the infrastructure changed

SCTP clearly requires endpoint changes.

How does it require changes from boxes in the middle? More than DDP/MPA? 
It would be useful to clarify this point.

Joe

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 5 Dec 2002 19:55:50 -0600

On 12/5/02, Joe Touch wrote:

>How does it require changes from boxes in the middle? More
>than DDP/MPA? It would be useful to clarify this point.
>

Most firewalls do not have port specific control of SCTP
associations. Ditto for load-balancers and NATs.

By contrast they support MPA/TCP because it *IS* fully
compliant TCP traffic. In fact, within the network it is
impossible to *prove* that a TCP connection is in MPA mode.
(You can prove that it is NOT, but not that it is).

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Dec 2002 20:44:55 -0800

> associations. Ditto for load-balancers and NATs.

By that logic all new protocols should be embedded over HTTP, which 
works through most firewalls.

> (You can prove that it is NOT, but not that it is).

All that proves is that the traffic is compliant. It still remains that 
the endpoint semantics are not.

Joe

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 6 Dec 2002 11:31:06 -0600

On 12/5/02, Joe Touch wrote:

>>>How does it require changes from boxes in the middle?
>>>More than DDP/MPA? It would be useful to clarify this
>>>point.
>>>
>By that logic all new protocols should be embedded over
>HTTP, which works through most firewalls.
>

There is a big difference.

One is circumventing security, the other is facilitating it.

Hiding a new service under port 80 is hiding information
from the firewall administrator.

Using an existing transport allows the firewall
administrator to use their existing tools to control a new
application. From the network administrator's viewpoint, an
RDMA enabled application is exactly like  any other
application. The same tools can be used to control
distribution of connections, throttle new connections, limit
aggregate bandwidth, monitor and control the source of
external clients, etc.

If a new RDMA-optimized transport were defined ("IB over
IP"), then none of these tools would be available until
their vendors upgraded.

Sticking with existing transports is not a sleazy trick to
evade the oversight of network administrators, rather it is
avoiding creating unncessary new work for them.

Caitlin Bestler

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Dec 2002 10:02:38 -0800

> from the firewall administrator.

Hiding a new protocol under protocol 6 is hiding information as well.

> aggregate bandwidth, monitor and control the source of

By that logic, all TCP-friendly apps should have protocol 6. Perhaps 
there's need for a flag in the IP layer that says "TCP friendly", but 
the protocol ID field is already taken for other purposes.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 12 Dec 2002 09:14:37 -0500

> avoiding creating unncessary new work for them.

I'd vote for "sleazy trick" myself.  It is nice that you are
thinking of firewall admins needs -- but, I think Joe is right and
the bottom line is that the reason you want to use TCP and not SCTP
for DDP and the reason my IM client uses our HTTP proxy are the
same.  That is, they are rational responses to getting traffic
through firewalls/middleboxes.  I can understand the rational, and
can even sympathize with it on a good day.  But, I still think both
of these examples are architecturally broken.  Both of these tactics
hide one thing in another and obfuscate what is really going
on.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/