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

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 13 Feb 2002 14:16:10 -0500

> I see it clearly.  However, this seems to be a case where we can't
> have everything.  If we want to touch the data we can have a
> synchronization technique which can also be used to determine PDU
> alignment (COWS).  If we don't want to touch the data, we can have PDU
> alignment (TUF or NDT) OR synchronization (FIM), but not both.

Not to muddy the waters, but isn't an "aligning FIM" possible
(not that anyone would want to do it), where ULP PDUs (possibly
chunked) are aligned into TCP segments allowing direct placement
of each TCP segment payload, and with FIM to allow location of
subsequent ULP PDUs after a packet drop?

Jim

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

---

From: "WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 13 Feb 2002 11:17:04 -0800

The flexibility to synchronize independent of transport segment alignment
would seem
to come at the costs of a significant increase in receiver complexity in
managing the
reconstruction of ULP DDP PDUs across transport segments, and of additional
buffer memory. The ability to directly place individual incoming transport
segments,
while not necessarily providing greater throughput, is a simple, low
meta-data, 
and low buffer-memory approach.
 
Jim

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, February 11, 2002 11:02 PM
To: Stephen Bailey
Cc: John Hufferd; [email-masked]; [email-masked]
Subject: Re: [rdma] a proposal for a different No-Data-Touch framer for TCP

Steph, 

You fail to see that a good synchronization scheme should work with or
without a TCP alignment scheme. 
If the instream alignment can be infered by the ULP the so it can by a
generic DDP. Alignment can somewhat improve performance 
but it is not mandatory neither for a generic nor for a protocol specific
placement scheme.  In other words - steering every TCP packet is the
ultimate effectivenss but not necessarily the only steering scheme.  An IP
steering scheme would work unchanged on every transport. 

Regards, 
Julo 

	Stephen Bailey <[email-masked]> 

12-02-02 00:41 

        To:        "John Hufferd" <[email-masked]> 
        cc:        [email-masked], [email-masked] 
        Subject:        Re: [rdma] a proposal for a different No-Data-Touch
framer for TCP 

John,

Thanks for the exhausting analysis.

As Paul points out, you do not want to scan the received segment to
recover synchronization with either of these techniques, since it's
too risky.  The TUF draft specifically makes this point.  Basically,
you get one event per segment.  However, if you want to be really
pessemistic you could say the stream IS segmented into tiny frames
that almost result in scanning.

The TUF draft also says that the use of a TUF-derived PDU containment
property should be discontinued after repeated failure of PDU
containment.  Given Julian's repeated statements that TUF should be
analyzed against an infinite stream, I can conclude that the draft
does not make this point strongly or clearly enough.

The TUF assumption is that there are two distinct, quasi-stable
scenarios: segmentation is preserved or it is not.  Obviously if
segmentation is not preserved, there's no point in trying to use the
PDU containment property because it will never hold.  If a receiver
detect that the PDU containment property does not hold for longer than
would represent a transient condition like PMTU change, it gives up
and stops using it.

Julian's argument that TUF needs to be analyzed against an infinite
stream is a straw man.  You can pick the threshold at which a TUF
receiver gives up to be any number that makes you comfortable (10e6
packets, 10e4, whatever).

I'm not clear on how your analysis incorporates worst case data
pattern distribution assumptions.  There is a ULP running inside the
framing protocol, and if we assume the ULP is efficient, MOST of the
data IT carries is actually controlled by the user of the ULP.  This
user data can just as well be a `search and destroy' sequence that
tries every `eye catcher' in a well-formed context.  This technique
boils down to a blind search for a 32-bit integer, and there's the
additional probability of hitting any particular element of the blind
search pattern (basically like your ex and ey).  Julian's extra 64
bits (salt & digest) are not doing anything for you in this case.
It's as simple as the probability of the resegmented stream hitting
the correct 32-bit number.

Thanks again for your work on this.

Steph

> Steph, Julian,
> The following is an attempt to determine the probability of a false
> positive, both with the TUF approach as defined in
> draft-ietf-tsvwg-tcp-ulp-frame-01.txt, and the semi draft that Julian
> proposed.
> 

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Do you need to encrypt all your online transactions? Find
the perfect solution in this FREE Guide from VeriSign.
http://us.click.yahoo.com/vCuuSA/UdiDAA/yigFAA/W6uqlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email-masked]

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=221000.1882886.3382503.1261774/D=egroupweb/S=17057010
14:HM/A=965714/R=0/O=1/I=brandr-promo-flowersale-alerts-lrecm/*http://shoppi
ng.yahoo.com/promotions/flowers/index.html> 	
 
<http://us.adserver.yahoo.com/l?M=221000.1882886.3382503.1261774/D=egroupmai
l/S=1705701014:HM/A=965714/rand=391276857> 	

To unsubscribe from this group, send an email to:
[email-masked]

Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service.

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 13 Feb 2002 22:40:37 +0200

For non-generic hardware DDP and alignment are not synomins.
Neither are they necessarily for generic hardware.

Julo

"WENDT,JIM (HP-Roseville,ex1)" <[email-masked]>
13-02-02 21:17

        To:     Julian Satran/Haifa/IBM@IBMIL, Stephen Bailey <[email-masked]>
        cc:     John Hufferd/San Jose/IBM@IBMUS, [email-masked], [email-masked]
        Subject:        RE: [rdma] a proposal for a different No-Data-Touch framer for TC       P

reconstruction of ULP DDP PDUs across transport segments, and of 
additional
 
Jim
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, February 11, 2002 11:02 PM
To: Stephen Bailey
Cc: John Hufferd; [email-masked]; [email-masked]
Subject: Re: [rdma] a proposal for a different No-Data-Touch framer for TCP

Steph, 

Regards, 
Julo 

        To:        "John Hufferd" <[email-masked]> 
        cc:        [email-masked], [email-masked] 
        Subject:        Re: [rdma] a proposal for a different 
No-Data-Touch framer for TCP 

John,

Steph

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 

Yahoo! Groups Sponsor

ADVERTISEMENT

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.