Subject: [rddp] Marker Consensus Proposal

From: [email-masked]
Date: Fri, 25 Apr 2003 12:41:03 -0400

WG Chair hat firmly in place ...

Looking back on the discussion of markers, I'm going to attempt
to propose a way forward and hope the we can get WG rough consensus
for it.  The core of the proposal is what I originally posted a
couple of weeks ago:

	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.

With the following additions:
- When markers are used, the marker interval MUST be 512 bytes.
- This proposed rough consensus assumes that we will be forced
	to do some sort of setup announcement as part of the
	"proof" requirement, which will provide a place to
	transmit options (and a version number).  Details of
	exactly how this works so that each receiver gets to
	pick what is sent to it are TBD.

This is not going to be the "perfect" answer for everyone, but
it's clear to me that WG rough consensus will not be obtained
for the positions at the end of the spectrum, namely:

- 512 byte markers MUST be used at all times
- Markers are completely optional

Further discussion/advocacy of those positions is probably
not productive.

I believe the above proposal is acceptable for the important
classes of implementations, and is technically sound.

Further comment to the list, please.

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: Caitlin Bestler <[email-masked]>
Date: Fri, 25 Apr 2003 12:15:22 -0500

On 4/25/03, [email-masked] wrote:

>Looking back on the discussion of markers, I'm going to
>attempt to propose a way forward and hope the we can get
>WG rough consensus for it.  The core of the proposal is
>what I originally posted a couple of weeks ago:
>
I concur that this is the best option that a consensus can
form around. Given that the mode-marker will have to exist
anyway (residual grumbles from those like myself who
disagree aside) there is little reason not to accomodate
receivers who will not benefit from the use of markers.

Clearly, generating markers is more work (and network
traffic) than not generating them. And that simply does not
make sense if the receiver indicates it will not use them.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 25 Apr 2003 12:23:27 -0500

On 4/25/03, [email-masked] wrote:

>- This proposed rough consensus assumes that we will be
>forced to do some sort of setup announcement as part of
>the "proof" requirement, which will provide a place to
>exactly how this works so that each receiver gets to pick
>what is sent to it are TBD.

One refinement I would like to see is to allow public
servers that are likely to have many intermittent clients
(such as an RDMA enabled web server) to be ambidexterous.

Specifically, I would propose that the mode information
contain the following flags:

    My preferred reception mode: marker/no-marker.
    My presumption on your mode: marker/no-marker.
    I will match your presumption: true/false.
    
If a peer's presumption is incompatible with the receiver
some action is required to reliably shift mode. This is TBD,
one simple solution is to simply abort the connection and
try again. But that is a seperate discussion.

The above proposal allows two things:

-- When a sender has a priori knowledge of a receivers 
   preferred mode, it can simply start sending. It does
   not have to wait for the peer's mode packet to start.
   
-- It allows a receiver the option of accomodating a
   a peer that made the wrong presumption.
   
Between the two it should be possible to keep the number of
"wrong mode" startup attempts quite minimal. The more
minimal the more acceptable simply closing the connection
and trying again becomes.

Caitlin Bestler