Subject: [rddp] Markers and Software

From: [email-masked]
Date: Mon, 24 Feb 2003 12:16:03 -0500

> Depending upon the software stack implementation, the insertion of markers

> can be accomplished at the same time one is copying / calculating the 
> checksum for the packet thus it is relatively isolated within the 
> stack.   This was verified by examination of various OSV  offerings 
> including active support by multiple OSVs who stated this was not an issue

> after they had examined their implementations to validate the proposal and

> its cost of implementation.

That is software, but not an unmodified existing stack, which is of
importance here, in contrast to the environment in which the MPA draft
was originally developed.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Michael Krause <[email-masked]>
Date: Mon, 24 Feb 2003 09:39:42 -0800

>was originally developed.

I think we need to keep in mind that there is rarely any such thing as a 
pure layered network stack implementation in practice.  Most software 
implementations today use a variety of techniques to provide performance 
boosts to their solution offerings and do so while maintaining 
interoperability. Some simple ones that come to mind are:
         - Copy and checksum when crossing the user-kernel boundary
         - Buffer cache (file system) accelerations for network accessed 
objects
         - Checksum off-load
         - TCP large send (send a single large message to a NIC and have it 
segment accordingly).

If the various OSV want to isolate this functionality as they currently do 
today and they want to add in MPA through similar means, no one will be 
able to tell the difference from the wire protocol perspective and they 
will interoperate just fine as well as perform better than those that do 
not take these types of steps.  If an OSV wants to have a well-layered 
implementation, then it can do so without changing its TCP 
implementation.  The layer above TCP (e.g. Sockets) simply performs the 
marker insertion (transparent to the application) prior to handing the 
packet to the TCP layer which treats it as a standard byte stream for 
transmission purposes.  The performance impacts can be mitigated for those 
that want to implement a higher performing solution with some intelligence 
such as utilizing various techniques they may have already in place.

We should also keep in mind that negotiating attributes is generally more 
disruptive to an OSV / network stack implementation than having a single 
method for accomplishing a task - a key reason for having a fixed marker 
interval.

In general, I have not seen a strong case made for having variable marker 
intervals or necessarily an implementation concern being raised by various 
OSVs (the OS we provide within my company do not have an issue with the 
current proposal) w.r.t. complexity, performance, etc.

Mike

---

From: [email-masked]
Date: Mon, 24 Feb 2003 13:10:25 -0500

> pure layered network stack implementation in practice.  

[ ... large snip ...]

> current proposal) w.r.t. complexity, performance, etc.

That is based on the incorrect assumption that the only interesting
software implementations are by Operating Systems Vendors who will
change their stacks to do the implementation.  Not only is that a
bad assumption, but it does not comport with the current WG rough
consensus of the WG that support for at least client implementations
on existing unmodified stacks is important.  It's ok not to optimize
for unmodified existing stacks, but the design cannot deliberately
ignore them in the above fashion.

Thanks,
--David

---

From: Michael Krause <[email-masked]>
Date: Mon, 24 Feb 2003 11:04:40 -0800

>ignore them in the above fashion.

I did not state that either clients or storage are being ignored nor did I 
state that the only interesting implementations are by OSV who will change 
their stacks.  I only stated that the one can implement without changing 
that stack and that a more optimal implementation can be done by providing 
minor changes.  This isn't apple vs. oranges but illustrates my point that 
there are many shades of implementation and mileage will vary 
accordingly.  Does the architecture need to be permuted to accommodate 
every implementation or can it strike a good balance - I assert that their 
is a good balance in today's drafts for all solutions and I have not seen 
anything substantial to the contrary.

Mike