[Tsvwg] Re: [rdma] a proposal for a different No-Data-Touch framer for TCP
"Julian Satran" <Julian_Satran@il.ibm.com> Tue, 12 February 2002 07:11 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05307 for <tsvwg-archive@odin.ietf.org>; Tue, 12 Feb 2002 02:11:45 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA05118 for tsvwg-archive@odin.ietf.org; Tue, 12 Feb 2002 02:11:45 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04905; Tue, 12 Feb 2002 02:00:52 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04820 for <tsvwg@optimus.ietf.org>; Tue, 12 Feb 2002 02:00:48 -0500 (EST)
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28522 for <tsvwg@ietf.org>; Tue, 12 Feb 2002 02:00:47 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA85972; Tue, 12 Feb 2002 08:00:12 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1C71jD63976; Tue, 12 Feb 2002 08:01:46 +0100
To: Stephen Bailey <steph@cs.uchicago.edu>
Cc: John Hufferd <hufferd@us.ibm.com>, rdma@yahoogroups.com, tsvwg@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001
From: Julian Satran <Julian_Satran@il.ibm.com>
Message-ID: <OFA76FE5DC.23742C0E-ONC2256B5E.00255476@telaviv.ibm.com>
Date: Tue, 12 Feb 2002 09:01:42 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/02/2002 09:01:46, Serialize complete at 12/02/2002 09:01:46
Content-Type: multipart/alternative; boundary="=_alternative 0025FC68C2256B5E_="
Subject: [Tsvwg] Re: [rdma] a proposal for a different No-Data-Touch framer for TCP
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: tsvwg@ietf.org
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 <steph@cs.uchicago.edu> 12-02-02 00:41 To: "John Hufferd" <hufferd@us.ibm.com> cc: tsvwg@ietf.org, rdma@yahoogroups.com 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: rdma-unsubscribe@egroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- [Tsvwg] a proposal for a different No-Data-Touch … Julian Satran
- RE: [Tsvwg] a proposal for a different No-Data-To… Douglas Otis
- [Tsvwg] RE: [rdma] a proposal for a different No-… Julian Satran
- [Tsvwg] RE: [rdma] a proposal for a different No-… Culley, Paul
- [Tsvwg] RE: [rdma] a proposal for a different No-… Julian Satran
- Re: [Tsvwg] RE: [rdma] a proposal for a different… Lloyd Wood
- [Tsvwg] RE: [rdma] a proposal for a different No-… Julian Satran
- [Tsvwg] Re: [rdma] a proposal for a different No-… Stephen Bailey
- Re: [Tsvwg] RE: [rdma] a proposal for a different… Julian Satran
- [Tsvwg] Re: [rdma] a proposal for a different No-… Julian Satran
- [Tsvwg] Re: [rdma] a proposal for a different No-… Stephen Bailey
- [Tsvwg] Re: [rdma] a proposal for a different No-… John Hufferd
- [Tsvwg] Re: [rdma] a proposal for a different No-… Julian Satran
- [Tsvwg] Re: [rdma] a proposal for a different No-… John Hufferd
- [Tsvwg] Re: [rdma] a proposal for a different No-… John Hufferd
- [Tsvwg] Re: [rdma] a proposal for a different No-… Julian Satran
- [Tsvwg] Re: [rdma] a proposal for a different No-… Stephen Bailey
- RE: [Tsvwg] a proposal for a different No-Data-To… Douglas Otis
- [Tsvwg] Re: [rdma] a proposal for a different No-… John Hufferd
- [Tsvwg] Re: [rdma] a proposal for a different No-… Julian Satran
- RE: [Tsvwg] a proposal for a different No-Data-To… Douglas Otis
- [Tsvwg] Re: [rdma] a proposal for a different No-… Stephen Bailey
- [Tsvwg] Re: [rdma] a proposal for a different No-… Stephen Bailey