Subject: comments on PacketWay

From: [email-masked] (Greg Chesson)
Date: Sun, 16 Nov 1997 19:15:11 -0800

Colleagues,

I oppose advancing the proposed PacketWay protocol as described in the
document draft-ietf-pktway-protocol-eep-spec-02.txt to draft standard
status for reasons outlined below.

Greg Chesson

1. There are plausible alternatives to Packetway. Either IPv4 (minus SAR),
   or IPv6 seem to be roughly equivalent to Packetway and perhaps better.
   Since many SAN implementations will provide IP support as a matter
   of course, there seems to be no need for an alternative that provides
   no distinct advantage.

2. Rapid advancement of SAN technology suggests that a standard
   for SAN-to-SAN communication is premature, assuming that something other
   than IP is actually needed - something that has yet to be proven.  
   A standard at this time would probably not incorporate or export features 
   of developing SANs or fully meet the needs of SAN-to-SAN communication. 

3. Some SANs in development have capabilities that exceed those exportable 
   by PacketWay (or IP).  The main examples are flow
   control and error control at the physical layer.  Inability to export
   this capability between cooperating SANs could lead to ATM-like
   congestion within the routers.

4. The draft document claims: "PacketWay has learned many lessons from
   IP, but has been heavily optimized for high performance SANS, while
   IP is the protocol of choice for WANS."

   I don't see how PacketWay is an improvement over IP as claimed.
   In particular the numerous optional fields and variable-length
   headers of PacketWay lead to overhead in header-processing.  This is a 
   problem corrected in IPv6, but not PacketWay.  The 23-bit addresses are
   cited as an improvement over IP addressing, but are still impractical
   for cheap and high-speed table lookups.  High-speed IP implementations
   with hardware support treat IP options almost as an error-case; 
   i.e. option processing takes a slower path.  However, some of the
   PacketWay options seem to be required in a conforming implementation.

5. The technical content of the draft leaves much to be desired.
   Here are some issues:

	1. There are many options and optional fields in the eep protocol.
	   Which ones are required of a conforming implementation?

	2. What subset of the set of options is the minimum required
	   subset to guarantee interoperability?

	3. There are 4 forms of addressing plus codes for more.
	   Is a conforming implementation expected to implement all of them?

	4. How would one end-system figure out the magic set of options
	   to use when talking to another end point?  There seem to be
	   no negotiations of any kind in the protocol.  In fact there
	   seem to be no end-to-end exchanges of any kind defined
	   in the document suggesting that "PacketWay Message Formats"
	   might be a more appropriate title.

	5. There is both a 2-byte packet type field and an optional 
	   2-byte extention to the type field.  Wouldn't it be preferable,
	   especially in a new design that aims to improve upon IP,
	   to have a single type field that is deemed adequate?
	   Throw in a 32-bit type field and be done with it.
	   Or declare a type field and a sub-type field.
	   (Or simply adopt a form of IPv6.)

	6. The introduction contains several duplicated sentences: e.g.
	   "Most modern SANs have much in common, etc" in the second
	   paragraph appears again in the third paragraph.  There are
	   other similar examples suggesting that not enough people have
	   been reading the document.

	7. The introduction observes that a 9,000 processor
	   system is not expected to be assigned 9,000 IP addresses.
	   Perhaps so, but 9.000 addresses of some kind will be assigned.
	   A form of IP using 16-bits of the IP address would be perfectly 
	   adequate.

	8. On page 3 near the bottom is a paragraph that discusses
	   some possible methods for configuring half-routers without
	   providing any guidelines on how multiple implementations
	   might work together.  A successful standard for interworking 
	   SANs will have to be specific on the details.

	9. In section 1b: "PktWay supports resource discovery, by name
	   or capabilities."  Forgive me, but I couldn't find an algorithm
	   for this in the document.

       10. On page 5 there is a note in section 1c to the effect that
	   the term "address" should be interpreted as a PacketWay
	   address throughout the document.  That's fine, but shouldn't
	   a statement like that be located in section 3 where the other
	   conventions of the document are listed?

       11. Trailers are interesting and have long been a source of
	   religious ferver.  I like the idea and have implemented
	   trailers several times in both hardware and software.
	   I find that trailer designs which require padding calculations
	   and which may also have variable length or options, as with PktWay,
	   add considerable overhead if processed in software or firmware.
	   Efficient implementations usually need some hardware support
	   which may not always be available.  But when hardware support
	   is available, it seems much simpler to have a fixed-length
	   trailer that occupies the final N bytes of its transmission unit.
	   In the cell-based transmission systems used for some SANs, 
	   it is often simplest to dedicate a final cell to an aligned 
	   trailer implementation.  PacketWay does not provide these options,
	   and seems to provide too many other trailer options.

       12. PacketWay states a goal of operating on multiple types of SAN.
	   In this sense it is similar to many other protocols.
	   For every other protocol, one can find encapsulation standards
	   for each target environment.  Examles are usually found
	   in RFCs such as "IP over Fibre Channel", or "IP over ATM",
	   and so on.  It would be reassuring to see what PacketWay
	   over ABC and XYZ would look like along with examples of how
	   the translation from the ABC encapsulation to the XYZ
	   encapsulation would work.