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

From: "Shah, Hemal" <[email-masked]>
Date: Tue, 19 Nov 2002 07:23:54 -0800

I agree with Uri on designing with o-o-o placement allows one to implement
in-order placement but not the other way around. Also, when we have
self-describing DDP Segments, why do we restrict it to in-order placement
only?
With each DDP Segment self-describing from the placement perspective, the
goal should be to enable placement of each DDP Segment independent of its
arrival order (in-order or out-of-order).

Hemal

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

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

> -----Original Message-----
> 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

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