iADT revised proposal posted (T10/08-469r4)

[Kevin D Butt]

Formatted message: <A HREF="r0805306_f.htm">HTML-formatted message</A>

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 at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Paul Suhler" <Paul.Suhler at Quantum.Com> 
Sent by: owner-t10 at t10.org
05/30/2008 09:35 AM
To
<t10 at 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 at 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.