Subject: [rddp] Some Marker Comments

From: [email-masked]
Date: Wed, 22 Jan 2003 16:22:39 -0500

With WG chair hat off:

On optional markers, Dwight Barron says:

> The impact of this form optionality is that every implementor
> has to implement both options (on and off) and QA four permutations
> (mine on, your's on; mine on, your's off, etc.) to insure true
> interoperability. This seems a rather high price to pay today
> for something that may happen five years hence.

Two and a fraction should be closer to the mark because
both the on-off and off-on scenarios should turn into off-off
in short order as the connection gets going.  Recall that we
need a mechanism to ensure that the two TCP endpoints aren't
confused about the content of the bytestream, and the on-off
and off-on scenarios both look like confusion.  The count would
go back to four if markers were independently optional in each
direction, but seems like something that one could "just say no"
to, provided that we had markers that were reasonable for software
to cope with (IMHO, MPA's current 512-byte fixed interval isn't).

On iSCSI markers, Jim Williams asks:

> Anyone have feedback on how iSCSI markers are
> doing with respect to market acceptance?  Too soon,
> I know, but this may be an indicator of how
> RDDP markers will fare as there is a
> similarity in the cost/benefit (assuming that
> RDDP, like iSCSI, does not mandate alignment).

I believe "not widely implemented" is a summary, possibly
optimistic.

Also, a while back, Jim commented:

> 5.  Some method needs to be created for a sender
>     to notify the receiver of ability to align.
>     There are strong arguments that this should
>     be done at the transport, not the RDDP layer.
>     (i.e. a new TCP option on the SYN segment).

IMHO (WG chair hat still off), the odds of a new TCP
option for this purpose getting through tsvwg are close
to zero (I've been involved in somewhat analogous attempts,
and my ears are still ringing ...).  It would be better
to pursue an inband notification mechanism that could also
satisfy the "ensure no confusion about bytestream contents"
requirement.  Getting that design and the underlying rationale,
weaknesses, tradeoffs, etc. are worked out and well-described
in an Internet-Draft ought to be done before considering
whether the result makes a sufficient case for a new TCP
option.

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: Thu, 23 Jan 2003 10:37:41 -0600

On 1/22/03, [email-masked] wrote:

>provided that we had markers that were reasonable for
>software to cope with (IMHO, MPA's current 512-byte fixed
>interval isn't).

I do not see any undue burden on a software solution from
markers, at whatever interval, unless the software makes the
misktake of physically assembling the DDP Segment in a
consecutive sequence of memory bytes.

The first step is to identify the DDP segment. With markers
embedded, the identified location consists of portions of
one or more received IP datagrams. If you want to be even
more nitty gritty, that is generally within one more
received Ethernet Frames (but there are exceptions).

The DDP implementation has to do two things with the
received DDP segment: interpret the DDP header and place the
DDP contents. Both can be accomplished with a scatter/gather
list. Unless you attempt to interpret the DDP header while
it is has a marker imbedded in the middle of it there really
isnt' that much of a problem for the software.

A hardware implementation could apply the same algorithm,
but has the additional options, such as mapping around the
markers or identifying an incoming Ethernet Frame as being
part of an MPA connection "on the fly" and compressing the
markers during the act of receiving the data. It cannot
cut-thru place the data, because the port number and header
will not be known to be correct until the entire TCP segment
is recieved, but it can "pre-digest" the incoming TCP
segment on the presumption that the only way it will be kept
is if it is indeed part of an MPA connection.

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