Paul,

Let me make IBM's position on defining both a UDP and a TCP version very clear. We are opposed to defining both. We need to chose one and stick with the one. If we do not, then the target is free to chose which one it will support. The initiator will then be required to implement both so it can talk to whatever device it attaches to. This is the SCSI way of doing things. In ADT, where the drive is both an initiator and a target and where the library is both an initiator and a target, this means that any device that implements iADT will be required to implement both the UDP version and the TCP version.

As I understood Rod's argument for UDP it was that you could reuse the existing serial ADT implementation and just send it across UDP. This he believes will save implementers effort. This assumes that implementers have implemented that layer of ADT in a manner that has well defined interfaces to the other layers. This is not necessarily true. The other assumption is that if you do UDP you will not have to do TCP in your device. This assumption is also false for the above stated reason. It is also false if the device needs to support any other type of TCP connection. I believe that %100 of the libraries already use TCP connections. I would also submit that many future drives may also support TCP connections. If the hardware exists, there will be demands to add capabilities to utilize that hardware.

My view of using TCP is that TCP is well understood. It is well proven and has much more proving history than does our serial ADT. TCP will likely be required to be used by ADI devices for other capabilities than ADT and as such will be part of the devices anyway. If we use TCP we have built in error recovery that has been proven in a network environment. Our Serial ADT is not. In fact the timeouts being used will need to be adjusted and tested in order to find optimum values. TCP will allow clean delivery of messages. A UDP design will cause many more errors that need to be redriven using our serial ADT recovery procedures. These recovery procedures, while tested in today's implementations, have likely never had the numbers of retries required that will potentially be required in iADT (at least when on an external network).

For these reasons, IBM believes that one and only one of UDP or TCP should be defined. Also, we believe that the smart choice that gives the best growth path for the future is TCP. We are also not convinced that UDP will save design effort or implementation time.

Thanks,

Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/

"Paul Suhler" <Paul.Suhler@Quantum.Com>
Sent by: owner-t10@t10.org

05/30/2008 09:35 AM

To	<t10@t10.org>
cc
Subject	iADT revised proposal posted (T10/08-469r4)

I have uploaded T10/08-469r4, the next revision of the iADT proposal, for discussion at next Wednesday's ADI working group teleconference. A meeting announcement will be forthcoming later today

http://www.t10.org/ftp/t10/document.07/07-469r4.pdf

In this version, I've inserted an "interconnect layer" between the physical layer and ADT link layer. This appears to work while avoiding changes to the link, transport, and SCSI application layer. An "ADT port" is now an abstraction that connects with one other ADT port via an ADT serial, ADT TCP, or ADT UDP interconnect port. At its upper edge, the interconnect layer provides a standard set of protocol services to the ADT port to allow it to connect with another ADT port, send and receive, and disconnect. Operation of each service is defined for each of the three interconnect layer alternative. At its lower edge, the interconnect layer uses hardware connections defined by either the ADT serial bus or the (newly-defined) ADT Ethernet bus.

The ADT Ethernet bus proposes electrical characteristics for optional LED output connections.

Cheers,

Paul
___________________________________
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office: 949.856.7748 | paul.suhler@quantum.com
___________________________________
Disregard the Quantum Corporation confidentiality notice below. The information contained in this transmission is not confidential. Permission is hereby explicitly granted to disclose, copy, and further distribute to any individual(s) or organization(s), without restriction.

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum Corporation. Furthermore, Quantum Corporation is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.