Subject: [rddp] Marker Progress?

From: [email-masked]
Date: Wed, 16 Apr 2003 15:28:24 -0400

> > > I do take exception that we mandate an option that essentially
> > > diminishes or precludes a flow-through design
> >
> > Could we see "valid engineering justification" for the latter statement,
> > especially the "precludes" assertion?  Keep in mind that the "option"
> > under discussion allows a receiver who benefits from markers 
> > to require their use.
> 
> You are correct, the "preclude" assertion does not apply if 
> we get to the point that markers are mandatory to 
> implement/optional to use at all receivers (are you putting 
> your WG Chair hat on?).

Not exactly, and not yet.  Here's the proposal that was floated to
start this thread:

	One alternate possibility would be to make marker usage optional,
	but put control of this "option" entirely in the hands of
	the receiver - senders MUST implement both markers and not-markers,
	receivers MUST implement one OR the other, and each receiver
	gets to pick which one is used as the benefits of markers are
	primarily on the receiver side.

See Jeff Mogul's email for a long explanation of why something like
this has a better chance of making progress than the "MUST always
use markers" and "markers are completely OPTIONAL" positions.

> However, this means that markers are 
> mandatory to implement at the transmitter also, which seems 
> to be where the argument for the most marker pain has 
> manifested itself for those that are opposed to markers.

Yes.  This now puts responsibility for the transmitter consequences
on the receiver.  Receiver implementers who believe that there are
no significant transmitter consequences can implement receivers that
always require markers.  Receiver implementers who are concerned about
transmitter consequences can choose to support not using markers.
OTOH, we could go on arguing about this for the next 6 months ...

> Once implemented, is there sufficient delta to a) warrant an 
> option and b) operate the connection in an asymmetric mode? I 
> apologize in advance for slipping into "commercial merits 
> diatribe" but options cost real money once the ink is dry on 
> the spec. I like to reserve their use/cost for things that 
> are to the left of the decimal point, rather than the right. 

This is an unfortunate example of the "vehemence of opposition
to options" that is causing delay.

For asymmetric mode, consider that some all-software "client"
implementations might be more willing to put in the markers to
help out the receiving "server" if the "client" didn't have to
go to the pointless additional trouble of stripping markers from
the data returned by the server.  Consider that the "client"
might be a small portable device like a PDA or mobile phone.

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: "Somesh Gupta" <[email-masked]>
Date: Wed, 16 Apr 2003 12:57:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, April 16, 2003 12:28 PM
> To: [email-masked]; [email-masked]
> Subject: [rddp] Marker Progress?
> 
> 

  Or the low end server using an embedded processor (with a
  smaller I and D cache than a P-4) and (or without) a 
  partial or TCP offload NIC may not want to see markers.
  People have indicated that they don't believe there will
  be RDMA based storage servers without hardware acceleration,
  but that is probably more a function of protocol design
  than whether someone will do it or not, or whether there
  is a place in the market for that or not.