Subject: RE: [Tsvwg] RE: [rddp] I-D ACTION: draft-williams-iwarp-ift-00.txt

From: "Uri Elzur" <[email-masked]>
Date: Mon, 18 Nov 2002 15:59:10 -0800

There is a problem with the basic premise here: in case the sender doesn't offer alignment of DDP with TCP or a middle box has changes that segmentation, the receiver can no longer find the DDP header with the "header CRC". It will have to first put the whole TCP stream in order. When this is done, what is the value of the "header CRC"? you might as well just have CRC cover the whole DDP.

Another note, if the receiver was able to locate the first part of the DDP message with the "header CRC" and even desires to place that portion of the DDP header, then it must keep state for each such partially placed DDP segment. This is additional state not required by MPA.

thx

Uri

-----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Tuesday, October 22, 2002 11:49 AM
To: 'Culley, Paul'
Cc: [email-masked]'; [email-masked]'
Subject: [Tsvwg] RE: [rddp] I-D ACTION:draft-williams-iwarp-ift-00.txt

Regarding separation of header and payload CRCs:

Paul Culley wrote:

> It was observed that a NIC must buffer the entire packet before it 
> can be used in any way if the Ethernet CRC and IP/TCP checksums are 
> checked before use.  Most NICs have macros that check this stuff 
> before any layer 4 or higher processing is started. The NIC 
> vendors found that adding CRC on the whole packet to this scheme 
> offered no disadvantage over separate CRCs.  They would not be 
> able to do a "flow-through" design anyway.

Thanks for your response, Paul.

I agree that if DDP PDUs are always aligned with TCP PDUs, then
the CRC can be checked before any layer 4 processing is done.
If, however, DDP PDUs are not necessarily aligned, then layer 4
processing must be done first to determine where the CRC computation
begins and ends, and fetch the starting seed if a partial CRC has
already been computed.  When the payload is split between two
TCP segments, placement of the beginning of the payload will
ideally begin before the end of the payload and 
associated CRC has been received.

So the critical question is should we rely on the remote end
to always align DDP PDUs to TCP PDUs?  TCP does not by default
do this.  Certainly TCP implementation can be easily modified
to do this.  

I am not arguing that TCP implementations should or should not
be so modified.  However the addition of a second CRC is 
relatively low incremental cost even if the remote TCP does
alignment, and it is a big win if the remote TCP does not
do alignment.  It seems desirable not to be dependent on
the remote end supporting a modified TCP implementation,
especially when the cost of avoiding this dependency is low.

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

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

---

From: "Uri Elzur" <[email-masked]>
Date: Mon, 18 Nov 2002 20:35:34 -0800

there is a difference of opinions as to the goals and implementation complexity. 

The higher the network speed and the longer the control loop the more buffer memory is consumed for out of order. several people have commented about the need to deal with o-o-o.
Dealing with o-o-o allows more implementation option on the NIC and app level while restricting ALL implementation to in-order forces all to one way. Note that an algorithm that deals with o-o-o allow one to implement in-order only. not true for the other way around.

Complexity - one example: CRC on a limited number of bytes located some place in a received frame requires special handling of the data with delicate start/stop CRC that is smack in the middle of moving 10G or faster data. I don't see how this is easy.

Uri

-----Original Message-----
From: Williams, Jim [mailto:[email-masked]]
Sent: Monday, November 18, 2002 7:08 PM
To: [email-masked]; [email-masked]
Subject: [rddp] RE: [Tsvwg] RE:I-D ACTION:
draft-williams-iwarp-ift-00.txt

> From: Uri Elzur [mailto:[email-masked]]
> Sent: Monday, November 18, 2002 6:59 PM
> To: Williams, Jim; Caitlin Bestler; [email-masked]; [email-masked]
> Subject: RE: [Tsvwg] RE:I-D ACTION:draft-williams-iwarp-ift-00.txt
> 
> 
> >on 10/28/02, Jim Williams wrote:
> >
> >I believe an important objective in the protocol design
> >should be avoiding the need to re-assemble split
> >DDP segments.  This is an important motivating factor for
> >a separate header CRC.
> >
> >The idea is that the first part of the split DDP segment can
> >be placed without the need to reassemble it.  When the
> >second part of the split segment arrives, payload CRC
> >computation resumes where it left off on the first part.
> >All that needs to be saved in the interim are the header
> >info and the CRC seed.
> 
> One key issue that is glossed over, is how does the receiver 
> find the beginning of the first or second part of that split 
> DDP segment? In presence of middle box or TCP sender that 
> provides no alignment to DDP, this can be any place in the 
> received TCP segment. The draft suggests that IFT targets 
> in-order only ("Assuming in order processing of received TCP data, 
>    this is fully sufficient to define the DDP PDU 
> boundaries"). How does it deal with out-of-order? Does it 
> suggest to drop it? Buffer it?

IFT does not need to deal with out of order segments because
TCP delivers them in order.  The combined TCP/IFT implementation
of course must buffer out of order segments until the gap 
is filled.  However the vast majority of segments arrive in
order.

> hence, the IFT algorithm requires the receiver to: 
> 
> a. find the beginning of the IFT in the received TCP segment and 
> b. Dealing with the following cases: a partial "DDP header", 
> complete DDP header reception, complete DDP header with part 
> of the data and complete DDP header with complete data.
> c. run CRC on a selected number of bytes located anywhere in 
> that segment  
> d. Run a separate CRC on the data portion of the segment
> e. Keep state for the case partial segment has been received

This sounds about right, and is not problematic.

MPA assumes alignment.  With guaranteed alignment, a single
CRC makes some sense.  IFT does not assume alignment (as
standard TCP doesn'r provide it) so a separate header CRC
makes sense.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp