|
IMO, 'Customized' and 'closely coupled' reads also as a protocol
layering violation. This raises concerns of architectural and practical
nature. For one, low-cost commodity TCP silicons will come in one shape, and
they better be agnostic to whatever the client(s) are.
I would disagree with the
above. The actual TCP protocol algorithms are a small part of the
challenge
of building
an accelerated NIC. Much
more important are placing data in the correct destination
buffer so that the host need not do any copies, careful design of
interrupt strategy so that host
OS is interrupted only when
absolutely necessary, and
efficient control communications between NIC
and host so as not to cause the NIC or the host to stall
unnecessarily waiting for IO bus
transaction completion. In order to achieve this,
the NIC must understand it detail
the client protocol using TCP, and must to some extent
merge the protocol layers.
I would argue that merging protocol layers in the
implementation is not a "layering violation"
provided that the layered
protocol definition as viewed from the wire is not violated
and interoperability is not broken with layered
implementations.
The implementation space has historically been fragmented over urgent
pointer semantics, I'd hope that we do not raise this entropy with new iSCSI
self-serving flavors.
Alternately, it there is a contribution on
urgent pointer matters that is of general applicability, it could be
submitted as a general purpose amendment to TCP for framing (with the same
general applicability statement that was applied to the RDMA thread). Other
communities (say http 1.x) may add their support.
The counter argument is that the meaning of urgent data is
iSCSI specific and not
general to TCP, and that each TCP client protocol is allowed
to define urgent
data to its own liking. To me the operative question
(which I won't presume to
answer) is whether Matt's proposal is broken by any current
implementations or
could be broken by any reasonable implementations which are in
compliance with
the relevant TCP/IP RFCs.
| 