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

From: "Barron, Dwight" <[email-masked]>
Date: Wed, 28 May 2003 17:14:45 -0500

wrstuden wrote:

> Ah! My appologies.
> 
> I think though that I agree with Caitlin here, that if we are 
> going to let
> some ULPs take advantage of not computing CRCs, we should do 
> it both for
> calculating and comparing. We should get the full umpf.
> 
> Also, I'm not sure if we can really get away without 
> "negotiation" (well,
> expression of preferences). While Caitlin and I are disagreeing about
> where the admin fits in the scheme of things, I agree with 
> her that there
> will be some ULPs that will really not want the other side to 
> ignore CRCs.
> Say in the case where I have a lot of open buffers for you to 
> send to, I
> wamt to make sure that you check the CRCs to make sure that you get my
> STags & such right.

Given the desire to mask latency with multiple outstanding requests, wouldn't 
this description apply to just about any ULP that would be architected for RDDP?
Or conversely, would you propose that ULP designers purposely constrain the number
of advertised buffers just to "optimize" for the case where CRCs were turned off? 

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

---

From: [email-masked]
Date: Thu, 29 May 2003 01:20:40 +0000 (UTC)

On Wed, 28 May 2003, Barron, Dwight wrote:

> Given the desire to mask latency with multiple outstanding requests,
> wouldn't this description apply to just about any ULP that would be
> architected for RDDP? Or conversely, would you propose that ULP
> designers purposely constrain the number of advertised buffers just to
> "optimize" for the case where CRCs were turned off?

Neither.

I think that ULPs should assume it has a CRC-quality connection. If CRCs
are being ignored, it is because the system admin(s) determined that the
connection will have CRC32C-quality protection.

If ULPs assume anything else, we will be in for a royal mess.

Take care,

Bill