Please send presentations

Everyone who used slides in the RDDP meeting in San
Francisco - please send me a copy of your slides if
you have not already done so.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

RDDP DRAFT San Francisco Minutes

Thanks to Allyn for taking notes.  Send
corrections to me and/or the list please.

Thanks,
--David

RDDP WG Meeting Minutes **DRAFT**
56th IETF
March 17 & 20 2003
------------------

-- TCP Mapping Requirements (David Black)

This is a reminder from the WG chair in combination with the Area Directors
of what is expected of the RDDP WG's TCP mapping work.  

(1) The "proof" requirement that two communicating stacks can't get confused
about the format of communication applies to the entire RDDP protocol stack
running over TCP, not just the issue of whether a modified vs. unmodified
TCP
is being used.  32 bits of zeroes (first marker) to distinguish what is
going
on is not enough, 128 bits randomly generated for the connection is enough
(sufficient, but may be more than needed).  Relying on ULP to do this is
considerably weaker than solving the problem in RDDP.  Negotiation is not
required - a declaration mechanism like the SCTP adaption indication
exchange
is sufficient (no additional round trip is required).

(2) The nfsv4 WG is starting work on application of RDDP to NFSv4.  NFSv4's

Option or mandatory CRC in MPA

Hi,

It seems to me that one significant items holding up RDDP and
specifically MPA, is whether CRC should be optional or mandatory.

At the last IETF David said he would be uncomfortable requiring CRC
protection if a key current client protocol (NFS) is not going to
require the protection when not running on RDDP.  The primary argument
for this is to allow RDDP to cross the transition hurdle more easily
by not punishing software clients.

A majority of implementors want CRC, so clearly many implementations
will support it. There's incentive to implement it, and the penalty in
hardware implementations is negligable.

Implementations that do CRC can generate always and check optionally,
which is easy.

Rather than waiting for NFSv4 to settle the argument, it seems we
could push ahead with a reserved spot in the payload, and negotiable
checking.

Steph

Re: Option or mandatory CRC in MPA

At 07:41 PM 4/7/2003 -0400, Stephen Bailey wrote:
>Hi,
>
>It seems to me that one significant items holding up RDDP and
>specifically MPA, is whether CRC should be optional or mandatory.
>
>At the last IETF David said he would be uncomfortable requiring CRC
>protection if a key current client protocol (NFS) is not going to
>require the protection when not running on RDDP.  The primary argument
>for this is to allow RDDP to cross the transition hurdle more easily
>by not punishing software clients.
>
>A majority of implementors want CRC, so clearly many implementations
>will support it. There's incentive to implement it, and the penalty in
>hardware implementations is negligable.
>
>Implementations that do CRC can generate always and check optionally,
>which is easy.
>
>Rather than waiting for NFSv4 to settle the argument, it seems we
>could push ahead with a reserved spot in the payload, and negotiable
>checking.

In some discussions after the meeting with people in NFSv4, it seemed they 
may be fine with RDDP doing the CRC and letting it be optional at their 
layer.  Agree that NFSv4 workgroup needs to make a recommendation here but 
it is not clear to me that having it required is a major issue at all.  The 
only issue raised was why do it in both layers?   If NFSv4 can make it 
optional similar to how iSCSI can make digests optional then this can be 
resolved as a ULP issue allowing the RDDP implementations to be simplified 

Re: Option or mandatory CRC in MPA

I see some issues in doing the CRC checking as a negotiable feature 
at the MPA level.

Apart from the optionality aspect, I don't quite see how ULP-level
CRC negotiation (such as for iSCSI) can harmoniously work with
an MPA-level negotiation of the same.  There's no issue when it's
negotiated to "No".  But when it's negotiated to "Yes" at the iSCSI-level,
as an example, iSCSI wants to generate and check it - not delegate 
the checking/generation part to MPA even if MPA could optionally
do it.  I suspect this issue is not unique to one ULP - other comments,
particularly from NFS folks, would help here.

AFAICT, the only clean solution is to have the ULP always negotiate 
the usage to "No" (with the knowledge that the transport substrate is
doing it), and have the MPA layer always generate/check CRC.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm <at> rose.hp.com

----- Original Message ----- 
From: "Stephen Bailey" <steph <at> cs.uchicago.edu>
To: <rddp <at> ietf.org>
Sent: Monday, April 07, 2003 4:41 PM
Subject: [rddp] Option or mandatory CRC in MPA

RE: Option or mandatory CRC in MPA

The argument for making the CRC optional
in the RDDP over TCP mapping is the following.

  A.  A large percentage of usage will be on
      highly reliable private networks where
      the TCP checksum is more that sufficient
      the achieve the desired level or reliability.

  B.  Optimizing the performance of software 
      implementations is important, and computing
      an unneeded CRC is too high a price to pay
      for avoiding the need to negotiate an option.

The input from NFS is important because it takes
into account years of field experience.  If they
determine that for most all usage, even on private
networks, the TCP checksum is NOT adequate, then
I would regard that as a refutation of point A.
If they determine that for a large enough percentage
of implementations the TCP checksum IS adequate,
then I would regard that as support of point A.

Regarding point B, if one envisions that all 
implementations of interest are hardware customized
for RDDP, then the point does not carry much weight.
However, I would argue that this may be too narrow
a view for the IETF to take.

Re: Option or mandatory CRC in MPA

NFS can protect its data with an RPCSEC_GSS checksum, though
it's somewhat expensive to do in the host stack, so it's not
commonly used.

Instead, most NFS mounts today rely on the TCP checksum and
link CRC to protect data payload.

I doubt that many in the NFS community are completely
comfortable relying on the TCP checksum.  If RDDP provides
a 32 bit CRC that's implemented in hardware, then I'm sure
NFS would use it.

But given that NFS is already widely used over regular TCP,
I'm not sure there's enough support to make an RDDP CRC mandatory,
and a performance hurdle for host stack RDDP implementations.

	Brent

Mallikarjun C. wrote:
> I see some issues in doing the CRC checking as a negotiable feature 
> at the MPA level.
> 
> Apart from the optionality aspect, I don't quite see how ULP-level
> CRC negotiation (such as for iSCSI) can harmoniously work with
> an MPA-level negotiation of the same.  There's no issue when it's
> negotiated to "No".  But when it's negotiated to "Yes" at the iSCSI-level,
> as an example, iSCSI wants to generate and check it - not delegate 
> the checking/generation part to MPA even if MPA could optionally
> do it.  I suspect this issue is not unique to one ULP - other comments,

RE: Option or mandatory CRC in MPA

Re: Option or mandatory CRC in MPA

At 02:18 PM 4/8/2003 -0700, Brent Callaghan wrote:

>NFS can protect its data with an RPCSEC_GSS checksum, though
>it's somewhat expensive to do in the host stack, so it's not
>commonly used.
>
>Instead, most NFS mounts today rely on the TCP checksum and
>link CRC to protect data payload.
>
>I doubt that many in the NFS community are completely
>comfortable relying on the TCP checksum.  If RDDP provides
>a 32 bit CRC that's implemented in hardware, then I'm sure
>NFS would use it.
>
>But given that NFS is already widely used over regular TCP,
>I'm not sure there's enough support to make an RDDP CRC mandatory,
>and a performance hurdle for host stack RDDP implementations.

- The hardware cost is viewed as rather trivial - easier to always 
implement than to have optional.

- Data integrity is a major issue for customers these days.  Having the 
added CRC protection is critical as illustrated by various past discussions 
on the IPS reflector.

- If I recall, doesn't SCTP require a mandatory CRC?  If that is the case, 
wouldn't it be best to have a single "method" be used by all protocols to 
allow ULPs to migrate between the two with minimum functional deltas where 
possible thus mandatory CRC?

Mike

>         Brent
>
>
>Mallikarjun C. wrote:
>>I see some issues in doing the CRC checking as a negotiable feature at 
>>the MPA level.
>>Apart from the optionality aspect, I don't quite see how ULP-level
>>CRC negotiation (such as for iSCSI) can harmoniously work with
>>an MPA-level negotiation of the same.  There's no issue when it's
>>negotiated to "No".  But when it's negotiated to "Yes" at the iSCSI-level,
>>as an example, iSCSI wants to generate and check it - not delegate the 
>>checking/generation part to MPA even if MPA could optionally
>>do it.  I suspect this issue is not unique to one ULP - other comments,
>>particularly from NFS folks, would help here.
>>AFAICT, the only clean solution is to have the ULP always negotiate the 
>>usage to "No" (with the knowledge that the transport substrate is
>>doing it), and have the MPA layer always generate/check CRC.
>>--
>>Mallikarjun
>>Mallikarjun Chadalapaka
>>Networked Storage Architecture
>>Network Storage Solutions
>>Hewlett-Packard MS 5668 Roseville CA 95747
>>cbm <at> rose.hp.com
>>
>>----- Original Message ----- From: "Stephen Bailey" <steph <at> cs.uchicago.edu>
>>To: <rddp <at> ietf.org>
>>Sent: Monday, April 07, 2003 4:41 PM
>>Subject: [rddp] Option or mandatory CRC in MPA
>>
>>
>>>Hi,
>>>
>>>It seems to me that one significant items holding up RDDP and
>>>specifically MPA, is whether CRC should be optional or mandatory.
>>>
>>>At the last IETF David said he would be uncomfortable requiring CRC
>>>protection if a key current client protocol (NFS) is not going to
>>>require the protection when not running on RDDP.  The primary argument
>>>for this is to allow RDDP to cross the transition hurdle more easily
>>>by not punishing software clients.
>>>
>>>A majority of implementors want CRC, so clearly many implementations
>>>will support it. There's incentive to implement it, and the penalty in
>>>hardware implementations is negligable.
>>>
>>>Implementations that do CRC can generate always and check optionally,
>>>which is easy.
>>>
>>>Rather than waiting for NFSv4 to settle the argument, it seems we
>>>could push ahead with a reserved spot in the payload, and negotiable
>>>checking.
>>>
>>>Steph
>>>_______________________________________________
>>>rddp mailing list
>>>rddp <at> ietf.org
>>>https://www1.ietf.org/mailman/listinfo/rddp
>>>
>>
>>_______________________________________________
>>rddp mailing list
>>rddp <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/rddp
>
>
>_______________________________________________
>rddp mailing list
>rddp <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/rddp

RE: Option or mandatory CRC in MPA