Subject: RE: [rddp] CRC - rough consensus update

From: "Uri Elzur" <[email-masked]>
Date: Wed, 4 Jun 2003 16:58:49 -0700

Caitlin

Strikes me we're on the same page. However, I don't see a way around
using an API, IF CRC is OPTIONAL.

Let me try to clarify it, using the following scenario: in the case MPA
protocol makes the use of CRC OPTIONAL, in a particular case MPA may
have negotiated the connection to NO CRC. Now the ULP cannot tell how
MPA has  negotiated CRC without a proper API. i.e. I'm not sure the ULP
can query MPA without a proper API (that I also think can not be part of
what RDDP requires or can be guaranteed to be available)

Therefore what will the ULP do? How will a ULP that wants to RELY on
MPA's CRC and NOT have to provide its own error recovery do it?

Uri

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Wednesday, June 04, 2003 2:51 PM
To: Uri Elzur; [email-masked]
Subject: RE: [rddp] CRC - rough consensus update

> Maybe most important comment is that, if CRC is optional in any way, 
> there is no way (or it becomes very hard) for the ULP to know it is 
> there. It takes a mandatory API to make this info avail on every OS to

> every ULP. RDDP has no control over the APIs. It means the ULP has to 
> design its own error detection and correction scheme. This might be 
> the most important motivation to not only have CRC as MUST IMPLEMENT 
> but also MUST USE.

I agree and disagree.

An API that the ULP MUST use to guarantee that CRCs are used is clearly
unacceptable.

However, if there MAY be an API, which IF used MAY suppress CRCs, but if
not available or not used then CRCs MUST be used.

That is acceptable to me.

If you want CRCs used all of the time, simply set the bit so indicating.
In fact we could even agree that "zero" indicates that CRCs are
mandatory, so in fact you have to do nothing. The field must be set with
the same zero that it would have been set with if it had been "reserved
- must be zero".

If we were talking about *anything* that an implementation would have to
*actively* do I would be in full agreement with you.

As it is though, even though I am confident that I would never turn on
this option, the cost of allowing others to have it seems to be as close
to zero as is humanly possible.

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 4 Jun 2003 19:16:21 -0500

On 6/4/03, Uri Elzur wrote:

>Caitlin
>
>Strikes me we're on the same page. However, I don't see a
>way around using an API, IF CRC is OPTIONAL.
>
Agreed. By inclination I am against options. I ended up
convincing myself that this one made sense while trying
to compose a blistering email tearing the rationale for
the option to shreds. I could come up with lots of reasons
why it was far from essential, but not as to how it hurt
anybody (beyond wasting an option bit that might
theoretically have found a use sometime 30 years later).

>Let me try to clarify it, using the following scenario: in
>the case MPA protocol makes the use of CRC OPTIONAL, in a
>particular case MPA may have negotiated the connection to
>NO CRC. Now the ULP cannot tell how MPA has  negotiated
>CRC without a proper API. i.e. I'm not sure the ULP can
>query MPA without a proper API (that I also think can not
>be part of what RDDP requires or can be guaranteed to be
>available)
>
>Therefore what will the ULP do? How will a ULP that wants
>to RELY on MPA's CRC and NOT have to provide its own error
>recovery do it?
>

There have been two criteria proposed:

First, equivalence of result - not method. The ULP does not
truly care *how* the payload is protected (well, at least
it shouldn't). It cares *that* it is protected. An
end-to-end CRC32c is defined to be a "safe harbor", that
is one method is defined which will provide adequate
protection without any further questions asked.

Under the "equivalent protection" override, the CRC is
suppressed for specific paths *only* if the network
administrator can vouch that these paths truly have
equivalent protections.

Personally, I would anticipate that this feature would
be used by all system administrators who are bored and
have absolutely nothing else in their in-basket. ;-)

Second, their MAY be an API that allows a ULP to volunteer
for a lower level of protection. This lower level MUST NOT
be applied unless the ULP actively invokes this API.
Ignorance of such an API MUST leave the higher standard
undisturbed.

With these two rules, any ULP that requires the equivalence
of end-to-end CRC32c protection need do nothing. Any
application designed that does not understand how to
lower the lower-protection API will receive the full
end-to-end CRC32c (or equivalent) protection.

So in the absence of an API to query MPA, the ULP can assume
that it has CRC32c (or equivalent) protection.

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

---

From: [email-masked]
Date: Thu, 5 Jun 2003 00:32:22 +0000 (UTC)

> using an API, IF CRC is OPTIONAL.

The point is we aren't making CRCs "OPTIONAL." Optional means you are free
to turn it on or off.

We've been talking about making it such that the admin MAY indicate that
CRCs can be skipped IF the admin is CONFIDENT that the connection will be
as reliable as if it had the CRC on.

Thus there's a burden on the admin that wants to mark CRCs as ignorable,
which is not there if we use the word, "OPTIONAL."

> MPA's CRC and NOT have to provide its own error recovery do it?

The ULP will do the only thing it can. It will know that regardless of the
CRC setting, it will have a link as reliable as if it has the CRC-32C
verification. Because the only time(s) it is valid for the CRCs to be
neglectable is when other factors known to the admin(s) indicate that the
connection is reliable.

Take care,

Bill