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

From: "Julian Satran" <[email-masked]>
Date: Thu, 7 Feb 2002 04:08:22 +0200

Martin,

I am glad you like it.
The salt is a random number (a RN generator generates a new one at every
PDU). That is why it is hard to guess.
PDU headers are not random enough. It is essential that it is random and
different in every frame.
For iSCSI this comes a bit late but for a "generalized framing" I think
that this is a good solution with a very low price tag.

Thanks,
Julo

                    "Martin, Nick"                                                           
                    <Nick.Martin@C       To:     Julian Satran/Haifa/IBM@IBMIL               
                    OMPAQ.com>           cc:                                                 
                                         Subject:     RE: [rdma] a proposal for a different  
                    06-02-02 02:42        No-Data-Touch framer for TCP                       

Julian,

I *really* like this proposal.

Here is what I think I understand about the NDT framing draft
(un-optimized).  The two ends would agree upon a unique 32-bit value to be
used as the framing pattern.  The next 32 bits are random, and the next
32-bits are a digest.  This effectively defines 2**32 sets each containing
2**32 valid 96-bit frame markers.  Each connection will use markers from
one of the 2**32 sets.  If a secret value is added, there become 2**64 sets
each containing 2**32 valid 96-bit frame markers.  Entities other than the
intended recipient are less likely to know whether the digest is correct.
However, with each frame beginning with the same framing pattern, and a
published standard for how to compute the digest, it still seems fairly
easy to synthesize the "secret" on a long living connection.

I like NDT (optimized) for iSCSI framing.  Except for the salt and shared
secret, this version looks equivalent to having each iSCSI PDU header start
with a framing pattern, and including that pattern in the header digest.
If someone asked me how to do framing for iSCSI, that is what I would have
done.  [Start of PDU marker without salt or secret, turn on digests].  It
is simple and obvious how to do this in either software or hardware, with
or without turning your network stack inside out. [I have had difficulty
understanding why all the more complex proposals were desired.]  As you
point out, statistically the 32-bit framing pattern alone, even if required
to be on a frame boundary, can easily be fooled into making a mistake.
However, with ULP (iSCSI) digests enabled, the probability of an undetected
mistake is much lower.  [I would say acceptable.]  Given that digests are
enabled, I believe the probability of an undetected mistake with the 32-bit
framing pattern included in the digest is about the same as with the
framing pattern excluded from the digest.  Just adding the framing pattern
to iSCSI requires only 32-bits per PDU.  Adding the framing pattern and
salt is only 64-bits.

For an iSCSI software implementation on top of an unmodified [Operating
System Vendor provided] TCP stack, I can not take advantage of out of order
placement and also may not be able to detect TCP/IP packet boundaries.
When discarding a PDU header with a bad digest possibly followed by data of
un-trusted length, I would like to be able to quickly recover/confirm the
next PDU boundary using a framing marker and a digest, rather than
computing the iSCSI digest at each succeeding 4 byte boundary.  [I would
*not* like to have to generate, nor to locate and discard, framing markers
in the middle of otherwise perfectly good PDUs.]

I have a couple of questions about the salt.  Are there any rules for
generating it?  If the rest of the ULP PDU header is included in the
digest, would this not be as effective as the salt?  When a shared secret
or other data value not transmitted with the PDU is included in the digest
calculation, is this as effective as adding salt, so that explicit salt
would not be needed?  If the secret and/or the ULP header can replace the
salt, the frame markers overhead shrinks another 32-bits.

I also appreciate that the un-optimized version of the NDT framer can
easily and efficiently be inserted above or below almost any other protocol
layer by hardware or software.  On the outbound side, it does not need to
be told the length of the next ULP PDU.  It only needs to know when a PDU
boundary (either beginning, ending, or both) has been reached.

Thanks,
Nick

P.S. I did not copy this message the reflector.  You are free to do what
you please with it.
 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Saturday, February 02, 2002 3:49 AM
 To: [email-masked]; [email-masked]
 Subject: [rdma] a proposal for a different No-Data-Touch framer for TCP

 Dear Colleagues:

 I've recently submitted a draft including a different "No-Data-Touch"(NDT)
 framer.
 Unlike the current proposed NDT framer that has a "mistake" probability
 that increases asymptotically (to 1) with the stream length the framer I
 am suggesting has a very low and constant mistake probability and is thus
 safe to use even in the absence of alignment or in the presence of
 re-segmentation.

 It does not contain the standard RFC2026 reference not as an indication of
 patent - I have no  patent on it and I do not know about the existence of
 one (nor did I search thoroughly) - but rather as a sign of discomfort for
 it to be used without me being asked about it.

 Until it apperas you can find it also at:

 http://www.haifa.il.ibm.com/satran/ips/draft-satran-NDT-Framing-00.pdf

 http://www.haifa.il.ibm.com/satran/ips/draft-satran-NDT-Framing-00.txt

 Julo
                                   
       Yahoo! Groups Sponsor       

           ADVERTISEMENT           

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

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

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

---

From: "Culley, Paul" <[email-masked]>
Date: Thu, 7 Feb 2002 08:06:45 -0600

I am having a hard time understanding the advantage of the "salt", as
opposed to a longer framing key.  Both would seem to have the same
probability of false recognition.  Neither protects against the extreme
case where an application places a valid frame within the ULP data (I
assume that the application knows the frame key, adds its own salt, that
it can generate a CRC etc.).

I also presume that reasonable implementations will chose the framing
key randomly, perhaps with a bit of selectivity, like not using values
with leading zeros etc.

Also, do you have a probability of false recognition that you are
shooting for?  How does it compare to the probability of other types of
false negative errors associated with TCP with a PDU CRC?

For example, has anyone looked at what happens if a (lightly protected)
TCP sequence number is corrupted, possibly while a packet is also
dropped?

Given a few other rules around out of order placement which also improve
the odds, I personally feel like this issue is being over designed.
Rules like:
 1) don't actively search for frames, unless it appears on a segment
boundary, wait for previous segments to arrive so the correct boundary
can be calculated.  (resegmenting middle boxes kill out of order
placement).
 2) don't place unless its in the TCP RWIN
 3) ULP checks should still be made, and failures could cause the
implementation to drop/wait until framing can be assured. (bigger layer
violation, for more paranoid designers).

Paul R. Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 8:08 PM
To: Martin, Nick
Cc: [email-masked]; [email-masked]
Subject: RE: [rdma] a proposal for a different No-Data-Touch framer for
TCP

Martin,

I am glad you like it.

Thanks,
Julo

                    "Martin, Nick"

                    <Nick.Martin@C       To:     Julian
Satran/Haifa/IBM@IBMIL               
                    OMPAQ.com>           cc:

                                         Subject:     RE: [rdma] a
proposal for a different  

Julian,

Here is what I think I understand about the NDT framing draft
(un-optimized).  The two ends would agree upon a unique 32-bit value to
be
used as the framing pattern.  The next 32 bits are random, and the next
32-bits are a digest.  This effectively defines 2**32 sets each
containing
2**32 valid 96-bit frame markers.  Each connection will use markers from
one of the 2**32 sets.  If a secret value is added, there become 2**64
sets
each containing 2**32 valid 96-bit frame markers.  Entities other than
the
intended recipient are less likely to know whether the digest is
correct.
However, with each frame beginning with the same framing pattern, and a
published standard for how to compute the digest, it still seems fairly
easy to synthesize the "secret" on a long living connection.

I like NDT (optimized) for iSCSI framing.  Except for the salt and
shared
secret, this version looks equivalent to having each iSCSI PDU header
start
with a framing pattern, and including that pattern in the header digest.
If someone asked me how to do framing for iSCSI, that is what I would
have
done.  [Start of PDU marker without salt or secret, turn on digests].
It
is simple and obvious how to do this in either software or hardware,
with
or without turning your network stack inside out. [I have had difficulty
understanding why all the more complex proposals were desired.]  As you
point out, statistically the 32-bit framing pattern alone, even if
required
to be on a frame boundary, can easily be fooled into making a mistake.
However, with ULP (iSCSI) digests enabled, the probability of an
undetected
mistake is much lower.  [I would say acceptable.]  Given that digests
are
enabled, I believe the probability of an undetected mistake with the
32-bit
framing pattern included in the digest is about the same as with the
framing pattern excluded from the digest.  Just adding the framing
pattern
to iSCSI requires only 32-bits per PDU.  Adding the framing pattern and
salt is only 64-bits.

For an iSCSI software implementation on top of an unmodified [Operating
System Vendor provided] TCP stack, I can not take advantage of out of
order
placement and also may not be able to detect TCP/IP packet boundaries.
When discarding a PDU header with a bad digest possibly followed by data
of
un-trusted length, I would like to be able to quickly recover/confirm
the
next PDU boundary using a framing marker and a digest, rather than
computing the iSCSI digest at each succeeding 4 byte boundary.  [I would
*not* like to have to generate, nor to locate and discard, framing
markers
in the middle of otherwise perfectly good PDUs.]

I have a couple of questions about the salt.  Are there any rules for
generating it?  If the rest of the ULP PDU header is included in the
digest, would this not be as effective as the salt?  When a shared
secret
or other data value not transmitted with the PDU is included in the
digest
calculation, is this as effective as adding salt, so that explicit salt
would not be needed?  If the secret and/or the ULP header can replace
the
salt, the frame markers overhead shrinks another 32-bits.

I also appreciate that the un-optimized version of the NDT framer can
easily and efficiently be inserted above or below almost any other
protocol
layer by hardware or software.  On the outbound side, it does not need
to
be told the length of the next ULP PDU.  It only needs to know when a
PDU
boundary (either beginning, ending, or both) has been reached.

Thanks,
Nick

 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Saturday, February 02, 2002 3:49 AM
 To: [email-masked]; [email-masked]
 Subject: [rdma] a proposal for a different No-Data-Touch framer for TCP

 Dear Colleagues:

 I've recently submitted a draft including a different
"No-Data-Touch"(NDT)
 framer.
 Unlike the current proposed NDT framer that has a "mistake" probability
 that increases asymptotically (to 1) with the stream length the framer
I
 am suggesting has a very low and constant mistake probability and is
thus
 safe to use even in the absence of alignment or in the presence of
 re-segmentation.

 It does not contain the standard RFC2026 reference not as an indication
of
 patent - I have no  patent on it and I do not know about the existence
of
 one (nor did I search thoroughly) - but rather as a sign of discomfort
for
 it to be used without me being asked about it.

 Julo
                                   
       Yahoo! Groups Sponsor       

           ADVERTISEMENT           

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Tiny Wireless Camera under $80!
Order Now! FREE VCR Commander!
Click Here - Only 1 Day Left!
http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/W6uqlB/TM
---------------------------------------------------------------------~->

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

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 7 Feb 2002 22:21:35 +0200

And in addition even if the frame key is random  it does not change for the
life of the stream - and that makes it impractical.

Julo

                    "Culley, Paul"                                                           
                    <paul.culley@c       To:     Julian Satran/Haifa/IBM@IBMIL               
                    ompaq.com>           cc:     <[email-masked]>, <[email-masked]>    
                                         Subject:     RE: [rdma] a proposal for a different  
                    07-02-02 16:06        No-Data-Touch framer for TCP                       

Paul R. Culley
Compaq Sr. Fellow
281-514-5543

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 8:08 PM
To: Martin, Nick
Cc: [email-masked]; [email-masked]
Subject: RE: [rdma] a proposal for a different No-Data-Touch framer for
TCP

Martin,

I am glad you like it.

Thanks,
Julo

                    "Martin, Nick"

                                         Subject:     RE: [rdma] a
proposal for a different

Julian,

Thanks,
Nick

 -----Original Message-----
 From: Julian Satran [mailto:[email-masked]]
 Sent: Saturday, February 02, 2002 3:49 AM
 To: [email-masked]; [email-masked]
 Subject: [rdma] a proposal for a different No-Data-Touch framer for TCP

 Dear Colleagues:

 Julo

       Yahoo! Groups Sponsor

           ADVERTISEMENT

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Secure all your Web servers now - with a proven 5-part
strategy. The FREE Server Security Guide shows you how.
http://us.click.yahoo.com/iWSNbC/VdiDAA/yigFAA/W6uqlB/TM
---------------------------------------------------------------------~->

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

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 8 Feb 2002 02:58:29 +0200

yes - except that unlike a dictionary builder I do not attempt to guarantee
that it is an "only once" word :-)  julo

                    Lloyd Wood                                                                
                    <[email-masked]       To:     Julian Satran/Haifa/IBM@IBMIL               
                    rey.ac.uk>            cc:     tsvwg <[email-masked]>, rdma                
                                           <[email-masked]>                             
                    07-02-02 22:54        Subject:     Re: [Tsvwg] RE: [rdma] a proposal for  
                    Please respond         a different No-Data-Touch framer for TCP           
                    to Lloyd Wood                                                             

On Thu, 7 Feb 2002, Julian Satran wrote:

> The salt is a random number that is changing on every PDU.

you mean a nonce?

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 10 Feb 2002 21:22:22 +0200

Leonid,

The probability is not 0 - that is true. But for the form used in the ULP 
framing draft it is in theory 1 and that is unacceptable.
The new proposal is aimed at macing it a very low (acceptable number) - 
equivalent with the probability of an undetected error by a CRC (in fact 
substantially less).

As for directing DDP traffic to a specific port that is an interesting 
idea (although not related to the issue at hand).
Even in a separate ring you are still faced with the same probability as 
long as the stream is infinite. The gain that you can obtain is the 
coexistence of DDP streams with "non-steered" streams and you pay by 
maintaining a more complex stack.

Julo

"Leonid Grossman" <[email-masked]>
09-02-02 19:22

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

Julian - either proposal has a non-zero probability to mistaken TCP
payload in non-DDP frame for a valid framing (and potentially cause 
a data corruption).
I'm deciding whether to put some framing and DDP on TCP support in our
upcoming 10GigE NIC ASIC, and to me it looks like a simpler and 
arguably more reliable way to recognize DDP frames would be to just 
use a dedicated port number for DDP.
For outgoing frames, DDP shim can replace application port number 
with DDP port number, and store the original port in iWARP/DDPP 
header somewhere.
On receive, NIC hardware would use DDP port number to recognize DDP
traffic and steer it into a separate receive ring (with protocol and
DDPP headers separated into pre-allocated buffers); 
then the hardware would verify iWAPR/DDPP header, do map tag into
physical address of the locked DDP buffers and DMA DDP payload.
SDP shim on receive would steer the traffic based upon the original 
port number.
Anyway, identifying DDP traffic in TCP header rather than in TCP payload 
looks like a better approach.

Any comments?

Thanks in advance,
Leonid Grossman
Software Engineering
S2IO Technologies
Cupertino, California

> The mathematics behind the proposal are simple. You have two random 
> numbers "against" a finite-length PDU.
> In you original proposal you have single random number (the marker) 
> against a quasi infinite stream. The chance to miss is 1.
> With any decent digest (e.g. a CRC) you have a small (2**-64) chance to 
> miss per PDU word (for every new PDU you have a new pattern). All the 
> tricks like alignment etc do not decrease the cardinality of stream - 
> i.e., it is still infinite and then a constant framer is no good.
> The cost of the new scheme is also tolerable.

---

From: "John Hufferd" <[email-masked]>
Date: Sun, 10 Feb 2002 17:22:35 -0800

Step, Julian,
While looking at the calculations in fresh light, I think I spotted an
error that gave Julian's ESC approach, to high a probability.  That is I
multiplied both ex and ey by 361.  I think I should have only multiplied
one by that value.

"ey" should have been left at 2.3e-10  and the resulting total probability
(ex * ey) should have been 1.934e-19

This would mean that the probability of a False Positive, given a
segmentation occurred, to be 1.934e-19 for ESC and the current TUF value
would still be 1.962e-17.

That would mean that if the CRC was part of the PDU, then the probability
would be even less, and yet only use 2 extra words would be used in the
framing header.

It seems clear however, if three words of header are used with TUF, vrs
normal ESC, that the value probability of a false positive with the 3 word
TUF at 4.557e-27 is  a lot better then the 1.934e-19 in the normal 3 word
header of ESC.

 .
.
 .
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]
---------------------- Forwarded by John Hufferd/San Jose/IBM on 02/10/2002
04:52 PM ---------------------------

John Hufferd
02/09/2002 05:05 PM

To:    Stephen Bailey <[email-masked]>, Julian
       Satran/Haifa/IBM@IBMIL
cc:    [email-masked]
From:  John Hufferd/San Jose/IBM@IBMUS
Subject:    Re: [rdma] a proposal for a different No-Data-Touch framer for
       TCP  (Document link: John Hufferd)

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.

Since we are only interested in the case of False Positives given a
re-segmentation occurs, I think it is possible to determine which of the
two approaches is less risky.

Here are the two layouts:

Current TUF has a 64 bit header at the beginning of Segment:
1. Length of 16 bits (Must match up with the physical length of the
segment)
2. Key  48 bits (Key Randomly Chosen by ULP,  -- Known by sender and
receiver, and changed as some undefined interval, if at all)

Julian's Eye-catcher-Salt-CRC approach (which I will call ESC) is 96 bits
1. Eye-catcher - 32 bits (Chosen by the ULP,  could also be chosen like the
Key in TUF, known by both sides)
2. Random number - 32 bits (Generated by ULP, unique to this PDU only)
3. CRC  - 32 bits (Generated by ULP based on 1. & 2.)

Lets first examine the ESC.

Once the Eye-catcher is determined, the Random number is chosen and the CRC
is computed, but to the Framer this is just string of bits passed from the
ULP.  The Receiving Framer (deFramer?) does not know the actual magic
string of bits which it should look for within the incoming payload.
Therefore it needs to do a computation at the start of each segment to make
sure the approprate string is received.

Given any beginning Eye-catcher, randomly chosen or not, there are a number
of 64 bit strings which can be interpreted as a valid salt and CRC.  That
is, for every 32 bit Salt, there is a valid 32 bit CRC.  Therefore, there
is as many valid 64-bit strings, which can follow the Eye-catcher as there
are unique 32-bit Salt numbers.  This means, there are (2**32) valid 8 byte
strings that can follow the Eye-catcher.

So in the case of ESC we have:

 The probability "ex" that a 32-bit Random Eye-catcher (or Key) is
"incorrectly" (do to re-segmentation) located at the beginning of a segment
, and the probability "ey" that one of the 2**32 valid 8 byte strings will
follow that Eye-catcher.  I think that makes it the total probability equal
to:
ex times  ey.

We have "ex" equal to the probability of the Eye-catcher occurring in any
word times the number of chances that might happen.  This means the
probability of any 32 bit value occurring  is 1/(2**32) times 361  where
361 is the number of possible segment points that could have been made in a
1460 byte payload (with a total of 3 header words and one byte of data).
Therefore:

ex = (1/2**32) times 361
ex = 2.3e-10 * 361
or
ex = 8.41e-8

The value of "ey" is equal to the probability that one of the 2**32 valid 8
byte strings will follow the Eye-catcher.  This is 1/2**32 times the number
of chances.  In this case the number of chances equals the number of
possible segment points that could have been made in a 1460 byte payload
(with a total of 3 header words and one byte of data), which is 361.
Therefore:

ey = 2.3e-10 * 361
or
ey = 8.41e-8

Therefore with ESC  we have the total probability of false positive of:

ex*ey = 8.41e-8 * 8.41e-8
or
ex*ey = 7.06 e-15

Now we will examine  the case of the current TUF proposal:

We have a probability "tx" that a 48-bit Random Key (or Eye-catcher) is
"incorrectly" (do to re-segmentation) located at + 2 bytes from the
beginning of a segment , and the probably "ty" that a 16 bit field
preceding it, will be a valid length of the current Segment.

I think that probability is equal to  tx  times  ty.

Now "ty" has 1 chance of occurring in 2**16 -10 (there must be at lease 8
bytes of TUF header + one byte of data, and zero is not valid so subtract
10 from the number of valid lengths)
ty = 1/((2**16)-10)
ty = 1/65526
ty = 1.526e-5

"tx" is the probability of a specific 48 bit string occurring at +2 bytes
into each possible segmentation point.  This is the probability of the
string occurring times the number of possible chances it has to occur.
Since there can be at most 365 TCP payload words in a normal Ethernet Frame
((1500-20-20)/4 =1460/4 = 365 words) then that means there are 365-3 or 362
possible segment point, which could leave at least a 2 word header and 1
byte of data.
Therefore:
tx = (1/2**48) times 362
tx = ((3.55e-15) * 362
tx = 1.286e-12).

Therefore with Current TUF we have the total probability of false positive
of:

tx*ty = 1.286e-12 * 1.526e-5
or
tx =  1.962e-17

Therefore, based on the calculations above, I believe that the Current TUF
approach offers a lower probability of False positive then does the
straight version of ESC.

But remember, Current TUF has a 64 bit header and ESC has a 96 bit header.
If we were to extend the TUF proposal to 96 bits the calculation would look
like:

ty = 1.526e-5 (Same as before)

AND,

tx =l (1/2**80) * 361
tx = 8.27e-25 * 361
tx = 2.986e-22

and
tx * ty = 2.986e-22 * 1.526e-5
tx * ty = 4.557e-27

However, ECS can also use a PDU header as part of the total salt.  The PDU
is not a fully random set of bits, but it does also reduce the probability
of False Positive a great deal more.  (I will let someone else compute that
probability.) The current probability of a false positive with a TUF's two
word header is 1.962e-17, but I think it is safe to guess that the ECS when
factoring in a PDU, would lower its probability a great deal lower then
7.06 e-15 (probably lower then current TUF), and it would then only need a
two word header like TUF.

Summary:
If you compare Current TUF (which has 2 word headers) to ECS (which has 3
word headers) you have a lower probability of False Positives with TUF.  If
you compare Current TUF with ECS that uses the CRC with the Header of the
PDU (so ECS only has a 2 byte Header) there is reason to believe that ECS
would have the lower probability of false positive.

So the questions should be: is  1.962e-17 a low enough probability of false
positives that we can get on with the Framing per the current TUFs
proposal?  Or do we need to add a third word to TUFs, or use the ECS with
PDU CRC.

 .
.
 .
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Stephen Bailey <[email-masked]> on 02/09/2002 08:35:17 AM

To:    Julian Satran/Haifa/IBM@IBMIL
cc:    [email-masked], [email-masked]
Subject:    Re: [rdma] a proposal for a different No-Data-Touch framer for
       TCP

For a proper safety analysis, you can not assume that the the contents
of the the stream (or the PDU) are randomly distributed.  You have to
assume the stream has worst-case contents.  Defining `worst case' is
the hard part.

Steph

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Sponsored by VeriSign - The Value of Trust
Pinpoint the right security solution for your company - FREE
Guide from industry leader VeriSign gives you all the facts.
http://us.click.yahoo.com/pCuuSA/WdiDAA/yigFAA/W6uqlB/TM
---------------------------------------------------------------------~->

---

From: "John Hufferd" <[email-masked]>
Date: Sun, 10 Feb 2002 17:26:09 -0800

Julian,
I do not think any of that matters, since you are not trying to determine
the probability of a False Negative.  Only the probability of a False
Positive at the beginning of a frame, given a re-segmentation, is the
issue.

 .
.
 .
John L. Hufferd

Julian Satran/Haifa/IBM@IBMIL on 02/10/2002 11:22:22 AM

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

Leonid,

As for directing DDP traffic to a specific port that is an interesting idea
(although not related to the issue at hand).
Even in a separate ring you are still faced with the same probability as
long as the stream is infinite. The gain that you can obtain is the
coexistence of DDP streams with "non-steered" streams and you pay by
maintaining a more complex stack.

Julo

     "Leonid Grossman"                                                     
     <[email-masked]>                 To:                               
                                 <[email-masked]>               
     09-02-02 19:22                      cc:                               
                                         Subject:        Re: [rdma] a      
                                 proposal for a different No-Data-Touch    
                                 framer for TCP                            

Any comments?

Thanks in advance,
Leonid Grossman
Software Engineering
S2IO Technologies
Cupertino, California

                                                                            
                               Yahoo! Groups Sponsor                        

                                       ADVERTISEMENT

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 11 Feb 2002 19:39:58 +0200

John - it is all about false positive.

Julo

John Hufferd@IBMUS
11-02-02 03:26

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     "Leonid Grossman" <[email-masked]>, [email-masked], 
[email-masked]
        From:   John Hufferd/San Jose/IBM@IBMUS
        Subject:        Re: [rdma] a proposal for a different No-Data-Touch framer for TCP

Julian,

 .
.
 .
John L. Hufferd

Leonid, 

Julo 

09-02-02 19:22 

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

Any comments?

Thanks in advance,
Leonid Grossman
Software Engineering
S2IO Technologies
Cupertino, California

Yahoo! Groups Sponsor

ADVERTISEMENT