Re: transport protocols

[julian_satran@il.ibm.com]

Rod,

Thanks for your note. Obviously we went through this exercise too and
decided for TCP.
I still have the lingering feeling that we did not get through thoroughly
enough with the T/TCP option.
As it is specified today it is sort of clumsy and not very easy to
implement or to assist in hardware.
However there might be other venues for reaching the same goal - some
related to the RDMA option suggested by Costa and others somewhat different
and more far-reaching with a similar effect.
Will you participate in a working group. will your former colleagues from
Quantum?

Regards,
Julo

Rod Van Meter <rdv@Network-Alchemy.COM> on 18/03/2000 03:56:06

Please respond to rdv@Network-Alchemy.COM

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  transport protocols




Sorry to be so late getting in on this conversation.  There was a
discussion of transport protocols a couple of weeks ago, and I wanted
to contribute my $0.02.

When I was at Quantum, we investigated heavily a number of transport
protocols for possible use over IP:

* FC classes 2 & 3
* TCP
* T/TCP
* XTP
* VMTP
* ST
* lightweight reliability over UDP

I no longer have my notes (they stayed at Quantum), but if memory
serves:

* FC 2 & 3: forget it.  Too dependent on a reliable lower layer.  All
  2 really gets you is faster notification of errors -- you still fail
  out to app-level recovery on dropped packets.

* TCP: the best choice.  The problem is efficiently multiplexing
  multiple commands and finding message boundaries -- issues the TCP
  option draft here addressed.

* T/TCP: I like it.  There are apparently some security concerns.  For
  me the show-stopper, though, is that it's designed for
  single-threaded RPC.  A T/TCP connection starts, does its thing,
  shuts down, then is ready for the next one.  If you want two
  concurrent I/Os, you need multiple T/TCP streams.

* XTP: another good option, with a few advantages over TCP (simplicity
  was an XTP goal, partially reached), but not compelling enough.
  Inadequate congestion control; by the time you add it, you're
  probably close to TCP in complexity.  Not firewall friendly?

* VMTP: a little long in the tooth -- would need a serious
  update. Rate-based flow control not useful over today's Internet
  infrastructure, could still be made to work in a LAN.  Forwarded
  RPCs (command to node A, response from node B) is quite intriguing
  for more complex storage systems, but not really needed for SCSI
  over IP.  Not firewall friendly.

* ST: a nice, lightweight protocol, but I'm concerned about a)
  assumptions about a reliable link layer, b) latency sensitivity, c)
  congestion control.  Probably fine in a LAN, not useful in a WAN.


I've got a long list of references on the above, plus more, if
anyone's interested.

          --Rod