Subject: RE: [Tsvwg] RE: [rdma] a proposal for a different No-Data-Touch f ramer for TC P

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 15 Feb 2002 17:05:08 -0800

Steph & Pat,
Let's call the new scheme AFIM (Aligning FIM). My thought for AFIM
was that one or more ULP PDUs are aligned with, and packed
into each TCP segment ala TUF's 'ULPDU packing'. Thus, each TCP
segment starts with a new ULP PDU and contains one or more complete
ULP PDUs.

But my initial idea for the re-synchronization markers was to continue
to have the markers occur at a fixed interval in the sequence stream as
in the original FIM. Pat is right that the marker's forward pointer
might point to a ULP PDU that wasn't in the same TCP segment as the
marker. This scheme is no touch (direct placement of each TCP payload)
unless the stream has been resegmented and alignment has been broken,
and a packet drop occurs. I still think this is better than straight
FIM which causes most ULP PDUs to span across TCP segments and requires
more complex processing to reconstruct ULP PDUs before placing them.

Steph's variation, if I understand it, is different in that the FIM
interval is set to the EMSS, the space between each marker contains one
or more complete ULP PDUs followed by padding to fill the EMSS interval,
and TCP segments are constructed such that the FIM markers fall at the
beginning of each TCP segment. I'm not sure what happens across PMTU
changes in this scheme.

Jim

> Pat,
> 
> > I don't understand what you are suggesting.
> 
> Actually, it seems you do understand what he's suggesting, but are not
> buying it :^)
> 
> The way I'd define it, it's not that the ULP PDUs are fixed length,
> but that the framing protocol may add padding within a finite
> interval.  For best transport efficiency, you would need to do what
> TUF calls `ULPDU packing'.  You may end up with more than one ULPDU
> per finite interval.
> 
> It actually seems like it might be a pretty good scheme.  Your finite
> interval would be EMSS, and the segmentation algorithm would be
> similar to the current TUF except to get markers at the beginning of
> segments.
> 
> This might be a new leading candidate.  It's no touch and completely
> safe.  The cost is that you must either do ULPDU packing (the
> unpacking is actually the burdensome part, but I personally never
> thought it was too horrible), or live with inefficient transport of
> small messages.  For bulk data protocols (e.g. storage) the
> overwhelming majority of the data you carry is in large
> (interval-sized) PDUs, so a small loss of transport efficiency for the
> control PDUs won't hurt.
> 
> Alright, you've done it again Jim!  By muddying the waters we clarify
> them :-?
> 
> Steph
> 
> 
> _______________________________________________
> 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: Stephen Bailey <[email-masked]>
Date: Fri, 15 Feb 2002 20:13:10 -0500

> I'm not sure what happens across PMTU changes in this scheme.

As with current TUF, the receiver stumbles along (slow path) for a
little while with uncontained ULPDUs until the sender learns of the
new EMSS, signals the new finite interval, and starts sending with the
new interval.  You'll need a synchronous handshake to do the interval
update signalling (clear the wire, signal the new finite interval,
wait for the ack and then start sending with the new finite interval).

Steph