From rddp-bounces@ietf.org Mon Jan 01 12:54:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1RMY-0003NT-Ra; Mon, 01 Jan 2007 12:54:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1RMX-0003N6-9B for rddp@ietf.org; Mon, 01 Jan 2007 12:54:17 -0500 Received: from mail.ttlc.net ([66.94.32.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1RMR-0001YN-LU for rddp@ietf.org; Mon, 01 Jan 2007 12:54:17 -0500 Received: from i6000bbr [24.128.204.154] by mail.ttlc.net with ESMTP (SMTPD-9.04) id AAC04904; Mon, 01 Jan 2007 12:54:08 -0500 From: "bbr" To: "RDDP" Date: Mon, 1 Jan 2007 12:54:00 -0500 Organization: Lamprey Networks MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcctzdDTirwnSp1vR52r5QXuo/KWGA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <200701011254837.SM05976@i6000bbr> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Subject: [rddp] Proper understanding of X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bbr@lampreynetworks.com List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1963363504==" Errors-To: rddp-bounces@ietf.org This is a multi-part message in MIME format. --===============1963363504== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C72DA3.E85F7E40" This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C72DA3.E85F7E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I'm looking at the changes in MPA from draft 02 (against which the conformance suite was written) to draft 08. I would like to understand how to take the following text from page 25 (clause 6). "To detect the start of the FPDU unambiguously one of the following MUST be used: 1: In an ordered TCP stream, the ULPDU Length field in the current FPDU when FPDU has a valid CRC, can be used to identify the beginning of the next FPDU. 2: For optimized MPA/TCP receivers that support out of order reception of FPDUs (see section 4.3 MPA Markers on page 15) a Marker can always be used to locate the beginning of an FPDU (in FPDUs with valid CRCs). Since the location of the Marker is known in the octet stream (sequence number space), the Marker can always be found. 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP receiver can find following contiguous FPDUs by using the ULPDU Length fields (from FPDUs with valid CRCs) to establish the next FPDU boundary." Question: Is an implementation allowed to use the marker, as described below, to "unambiguously" detect the start of a FPDU? Condition under which marker was received: 1. Markers being used (negotiated on) 2. Large FPDU being sent which consumes three TCP segments (not desired but allowed) 3. Second TCP segment lost 4. Marker located in third TCP segment Issue: In item two above it would appear that the implementation would have to validate the FPDU in which the marker is received (perform CRC check) before it can use it. However, since a portion of the FPDU is missing this would not be possible to do. Therefore a conformant device MUST NOT use this marker to detect the start of the FPDU. Is this the correct understanding of this requirement? Barry Reinhold (603) 868-8411 bbr@lampreynetworks.com ------=_NextPart_000_003D_01C72DA3.E85F7E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

I’m looking at the changes in MPA from draft 02 (against which the conformance suite was written) to draft 08. I would = like to understand how to take the following text from page 25 (clause = 6).

“To detect the start of the FPDU = unambiguously one of the following

MUST be used:

1: In an ordered TCP stream, the ULPDU Length = field in the current

FPDU when FPDU has a valid CRC, can be used = to identify the

beginning of the next FPDU. =

2: For optimized MPA/TCP receivers that = support out of order

reception of FPDUs (see section 4.3 MPA = Markers on page 15) a

Marker can always be used to locate the = beginning of an FPDU (in

FPDUs with valid CRCs). Since the location of = the Marker is

known in the octet stream (sequence number = space), the Marker can

always be found. =

3: Having found an FPDU by means of a Marker, = an optimized MPA/TCP

receiver can find following contiguous FPDUs = by using the ULPDU

Length fields (from FPDUs with valid CRCs) to establish the next

FPDU boundary.” =

Question: Is an implementation allowed to use = the marker, as described below, to “unambiguously” detect the = start of a FPDU?

Condition under which marker was = received:

1. = Markers being used (negotiated = on)

2. = Large FPDU being sent which = consumes three TCP segments (not desired but = allowed)

3. = Second TCP segment = lost

4. = Marker located in third TCP = segment

Issue: In item two above it would appear that = the implementation would have to validate the FPDU in which the marker is = received (perform CRC check) before it can use it. However, since a portion of the FPDU is = missing this would not be possible to do. Therefore a conformant device MUST NOT = use this marker to detect the start of the = FPDU.

Is this the correct understanding of this = requirement?

Barry Reinhold

(603) 868-8411

bbr@lampreynetworks.com<= /o:p>

------=_NextPart_000_003D_01C72DA3.E85F7E40-- --===============1963363504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1963363504==-- From rddp-bounces@ietf.org Tue Jan 02 10:25:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lVs-0005bk-0q; Tue, 02 Jan 2007 10:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lVr-0005bd-4l for rddp@ietf.org; Tue, 02 Jan 2007 10:25:15 -0500 Received: from mail.ttlc.net ([66.94.32.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1lVm-0005TR-PY for rddp@ietf.org; Tue, 02 Jan 2007 10:25:15 -0500 Received: from i6000bbr [70.90.99.65] by mail.ttlc.net with ESMTP (SMTPD-9.04) id A94D056C; Tue, 02 Jan 2007 10:25:01 -0500 From: "bbr" To: "'Mike Seufert'" Subject: RE: [rddp] Proper understanding of Date: Tue, 2 Jan 2007 10:24:53 -0500 Organization: Lamprey Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Accuf2X6rDpvgoYWQC+Msx66hTe66AAAMCew In-Reply-To: <459A749E.1070200@neterion.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070102102574.SM06064@i6000bbr> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'RDDP' X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bbr@lampreynetworks.com List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org Thanks Mike, I understand you to be in agreement that the conformant device MUST NOT use the marker received in the 3rd segment. BTW - I am unclear as to why the buffer only has to be 512B, wouldn't it need to be large enough to cover whatever size the FPDU might be? What is gained by catching the next marker? -----Original Message----- From: Mike Seufert [mailto:mike.seufert@neterion.com] Sent: Tuesday, January 02, 2007 10:05 AM To: bbr@lampreynetworks.com Cc: RDDP Subject: Re: [rddp] Proper understanding of Barry, In the situation you described, the receiver could not use the marker information in the 3rd segment until the 2nd segment had also arrived. This means the receiver must be prepared to do some amount of (per-session) buffering. Fortunately the amount of this buffering is small since the marker period is only 512B. Mike Seufert www.neterion.com bbr wrote: > > Folks, > > I'm looking at the changes in MPA from draft 02 (against which the > conformance suite was written) to draft 08. I would like to understand > how to take the following text from page 25 (clause 6). > > "To detect the start of the FPDU unambiguously one of the following > > MUST be used: > > 1: In an ordered TCP stream, the ULPDU Length field in the current > > FPDU when FPDU has a valid CRC, can be used to identify the > > beginning of the next FPDU. > > 2: For optimized MPA/TCP receivers that support out of order > > reception of FPDUs (see section 4.3 MPA Markers on page 15) a > > Marker can always be used to locate the beginning of an FPDU (in > > FPDUs with valid CRCs). Since the location of the Marker is > > known in the octet stream (sequence number space), the Marker can > > always be found. > > 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP > > receiver can find following contiguous FPDUs by using the ULPDU > > Length fields (from FPDUs with valid CRCs) to establish the next > > FPDU boundary." > > Question: Is an implementation allowed to use the marker, as described > below, to "unambiguously" detect the start of a FPDU? > > Condition under which marker was received: > > 1. Markers being used (negotiated on) > > 2. Large FPDU being sent which consumes three TCP segments (not > desired but allowed) > > 3. Second TCP segment lost > > 4. Marker located in third TCP segment > > Issue: In item two above it would appear that the implementation would > have to validate the FPDU in which the marker is received (perform CRC > check) before it can use it. However, since a portion of the FPDU is > missing this would not be possible to do. Therefore a conformant > device MUST NOT use this marker to detect the start of the FPDU. > > Is this the correct understanding of this requirement? > > Barry Reinhold > > (603) 868-8411 > > bbr@lampreynetworks.com > > ------------------------------------------------------------------------ > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Jan 02 11:46:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mmQ-0001jj-5z; Tue, 02 Jan 2007 11:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mmO-0001jc-Lx for rddp@ietf.org; Tue, 02 Jan 2007 11:46:24 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mmN-0004Ur-A2 for rddp@ietf.org; Tue, 02 Jan 2007 11:46:24 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Tue, 02 Jan 2007 08:46:05 -0800 X-Server-Uuid: D7CB97D3-6392-476F-BE46-AB3D6F515C9A Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 891932AF; Tue, 2 Jan 2007 08:46:05 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6496F2AE; Tue, 2 Jan 2007 08:46:05 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ESF67537; Tue, 2 Jan 2007 08:45:59 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id EEE5F20501; Tue, 2 Jan 2007 08:45:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] Proper understanding of Date: Tue, 2 Jan 2007 08:45:55 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1E1270D@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <200701011254837.SM05976@i6000bbr> Thread-Topic: [rddp] Proper understanding of Thread-Index: AcctzdDTirwnSp1vR52r5QXuo/KWGAAvsqqw From: "Caitlin Bestler" To: bbr@lampreynetworks.com, "RDDP" X-WSS-ID: 698453C73EK14953928-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org bbr wrote: > Folks, >=20 >=20 >=20 > I'm looking at the changes in MPA from draft 02 (against > which the conformance suite was written) to draft 08. I would > like to understand how to take the following text from page 25 > (clause 6).=20 >=20 >=20 >=20 > "To detect the start of the FPDU unambiguously one of the following >=20 > MUST be used: >=20 > 1: In an ordered TCP stream, the ULPDU Length field in the current >=20 > FPDU when FPDU has a valid CRC, can be used to identify the >=20 > beginning of the next FPDU. >=20 > 2: For optimized MPA/TCP receivers that support out of order >=20 > reception of FPDUs (see section 4.3 MPA Markers on page 15) a >=20 > Marker can always be used to locate the beginning of an FPDU (in >=20 > FPDUs with valid CRCs). Since the location of the Marker is >=20 > known in the octet stream (sequence number space), the Marker can >=20 > always be found. >=20 > 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP >=20 > receiver can find following contiguous FPDUs by using the ULPDU >=20 > Length fields (from FPDUs with valid CRCs) to establish the next >=20 > FPDU boundary." >=20 >=20 >=20 > Question: Is an implementation allowed to use the marker, as > described below, to "unambiguously" detect the start of a FPDU? >=20 >=20 >=20 > Condition under which marker was received: >=20 >=20 >=20 > 1. Markers being used (negotiated on) >=20 > 2. Large FPDU being sent which consumes three TCP segments (not > desired but allowed)=20 >=20 > 3. Second TCP segment lost >=20 > 4. Marker located in third TCP segment >=20 >=20 >=20 > Issue: In item two above it would appear that the > implementation would have to validate the FPDU in which the > marker is received (perform CRC check) before it can use it. > However, since a portion of the FPDU is missing this would > not be possible to do. Therefore a conformant device MUST NOT > use this marker to detect the start of the FPDU. >=20 >=20 >=20 > Is this the correct understanding of this requirement? >=20 >=20 The probable FPDU is not complete, therefore a conformant receiver MUST NOT provide the DDP Segment to the DDP layer. Whether the MPA receiver "used" the marker in the third segment in an attempt to validate the FPDU is irrelevant, since no action would result from merely testing the hypothesis. It would still conclude that the FPDU was no ready for delivery to the DDP layer. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Jan 15 10:04:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TNM-0002rS-52; Mon, 15 Jan 2007 10:03:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1mvr-0006j1-96 for rddp@ietf.org; Tue, 02 Jan 2007 11:56:11 -0500 Received: from barracuda.s2io.com ([72.1.205.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1mvp-00062F-8x for rddp@ietf.org; Tue, 02 Jan 2007 11:56:11 -0500 X-ASG-Debug-ID: 1167756966-9962-7-0 X-Barracuda-URL: http://72.1.205.138:8000/cgi-bin/mark.cgi X-ASG-Whitelist: Client Received: from carlsberg.s2io.com (unknown [142.46.210.147]) by barracuda.s2io.com (Spam Firewall) with ESMTP id 8D59F201BA38; Tue, 2 Jan 2007 11:56:06 -0500 (EST) Received: from [10.16.5.27] (beck [10.16.5.27]) by carlsberg.s2io.com (8.12.9/8.12.9) with ESMTP id l02Gu2Qx024709; Tue, 2 Jan 2007 11:56:02 -0500 (EST) Message-ID: <459A8EA1.2080401@neterion.com> Date: Tue, 02 Jan 2007 11:56:01 -0500 From: Mike Seufert User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: bbr@lampreynetworks.com X-ASG-Orig-Subj: Re: [rddp] Proper understanding of Subject: Re: [rddp] Proper understanding of References: <20070102102574.SM06064@i6000bbr> In-Reply-To: <20070102102574.SM06064@i6000bbr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by Barracuda Spam Firewall at s2io.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Mon, 15 Jan 2007 10:03:51 -0500 Cc: 'RDDP' X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org Barry, The receiver can't use the marker in the 3rd segment - until the second segment arrives. Until this second segment arrives, the 3rd segment is buffered (or dropped if the receiver doesn't support out-of-order receipt.) Once the second segment does arrive, then the FPDU CRC32C can be computed. The receiver uses its per-session state knowledge of where it left off after the first segment and its per-session knowledge of where the markers are to compute where the end of the FPDU - and the CRC32C field - is. After validating the CRC32C, it can then trust the contents of any embedded markers - including the one in the 3rd segment - to confirm its determination of where the fpdu header is. Only at this point does the receiver have enough confidence in the header's placement information to be able to dma the fpdu payload into host memory. I didn't mean to imply that the Rx buffering is limited to 512B. You're right that the Rx must be prepared to buffer up segments until it has a full FPDU to act on. This max size is ~64KB since the ULPDU length field is 16b wide. Note that the actual buffering amount could be somewhat greater than 64KB since the length field does not account for the MPA overhead itself (length, markers, pad, crc). Lastly, this whole discussion only applies to the (hopefully uncommon!) case where the FPDU doesn't fit into a single segment. The common, high-performance case is one where an entire FPDU arrives in a single TCP segment. Mike Seufert www.neterion.com bbr wrote: > Thanks Mike, > > I understand you to be in agreement that the conformant device MUST NOT use > the marker received in the 3rd segment. > > BTW - I am unclear as to why the buffer only has to be 512B, wouldn't it > need to be large enough to cover whatever size the FPDU might be? What is > gained by catching the next marker? > > -----Original Message----- > From: Mike Seufert [mailto:mike.seufert@neterion.com] > Sent: Tuesday, January 02, 2007 10:05 AM > To: bbr@lampreynetworks.com > Cc: RDDP > Subject: Re: [rddp] Proper understanding of > > Barry, > > In the situation you described, the receiver could not use the marker > information in the 3rd segment until the 2nd segment had also arrived. > This means the receiver must be prepared to do some amount of > (per-session) buffering. Fortunately the amount of this buffering is > small since the marker period is only 512B. > > Mike Seufert > www.neterion.com > > bbr wrote: > >> Folks, >> >> I'm looking at the changes in MPA from draft 02 (against which the >> conformance suite was written) to draft 08. I would like to understand >> how to take the following text from page 25 (clause 6). >> >> "To detect the start of the FPDU unambiguously one of the following >> >> MUST be used: >> >> 1: In an ordered TCP stream, the ULPDU Length field in the current >> >> FPDU when FPDU has a valid CRC, can be used to identify the >> >> beginning of the next FPDU. >> >> 2: For optimized MPA/TCP receivers that support out of order >> >> reception of FPDUs (see section 4.3 MPA Markers on page 15) a >> >> Marker can always be used to locate the beginning of an FPDU (in >> >> FPDUs with valid CRCs). Since the location of the Marker is >> >> known in the octet stream (sequence number space), the Marker can >> >> always be found. >> >> 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP >> >> receiver can find following contiguous FPDUs by using the ULPDU >> >> Length fields (from FPDUs with valid CRCs) to establish the next >> >> FPDU boundary." >> >> Question: Is an implementation allowed to use the marker, as described >> below, to "unambiguously" detect the start of a FPDU? >> >> Condition under which marker was received: >> >> 1. Markers being used (negotiated on) >> >> 2. Large FPDU being sent which consumes three TCP segments (not >> desired but allowed) >> >> 3. Second TCP segment lost >> >> 4. Marker located in third TCP segment >> >> Issue: In item two above it would appear that the implementation would >> have to validate the FPDU in which the marker is received (perform CRC >> check) before it can use it. However, since a portion of the FPDU is >> missing this would not be possible to do. Therefore a conformant >> device MUST NOT use this marker to detect the start of the FPDU. >> >> Is this the correct understanding of this requirement? >> >> Barry Reinhold >> >> (603) 868-8411 >> >> bbr@lampreynetworks.com >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rddp mailing list >> rddp@ietf.org >> https://www1.ietf.org/mailman/listinfo/rddp >> >> > > > > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Jan 15 10:04:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TNM-0002rM-0L; Mon, 15 Jan 2007 10:03:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1lCZ-0002yE-Ne for rddp@ietf.org; Tue, 02 Jan 2007 10:05:19 -0500 Received: from barracuda.s2io.com ([72.1.205.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1lCX-0000f1-O1 for rddp@ietf.org; Tue, 02 Jan 2007 10:05:19 -0500 X-ASG-Debug-ID: 1167750306-3764-22-0 X-Barracuda-URL: http://72.1.205.138:8000/cgi-bin/mark.cgi X-ASG-Whitelist: Client Received: from carlsberg.s2io.com (unknown [142.46.210.147]) by barracuda.s2io.com (Spam Firewall) with ESMTP id 2035B20051FA; Tue, 2 Jan 2007 10:05:06 -0500 (EST) Received: from [10.16.5.27] (beck [10.16.5.27]) by carlsberg.s2io.com (8.12.9/8.12.9) with ESMTP id l02F53Qx008144; Tue, 2 Jan 2007 10:05:03 -0500 (EST) Message-ID: <459A749E.1070200@neterion.com> Date: Tue, 02 Jan 2007 10:05:02 -0500 From: Mike Seufert User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: bbr@lampreynetworks.com X-ASG-Orig-Subj: Re: [rddp] Proper understanding of Subject: Re: [rddp] Proper understanding of References: <200701011254837.SM05976@i6000bbr> In-Reply-To: <200701011254837.SM05976@i6000bbr> Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by Barracuda Spam Firewall at s2io.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Mon, 15 Jan 2007 10:03:51 -0500 Cc: RDDP X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org Barry, In the situation you described, the receiver could not use the marker=20 information in the 3rd segment until the 2nd segment had also arrived. This means the receiver must be prepared to do some amount of=20 (per-session) buffering. Fortunately the amount of this buffering is=20 small since the marker period is only 512B. Mike Seufert www.neterion.com bbr wrote: > > Folks, > > I=92m looking at the changes in MPA from draft 02 (against which the=20 > conformance suite was written) to draft 08. I would like to understand=20 > how to take the following text from page 25 (clause 6). > > =93To detect the start of the FPDU unambiguously one of the following > > MUST be used: > > 1: In an ordered TCP stream, the ULPDU Length field in the current > > FPDU when FPDU has a valid CRC, can be used to identify the > > beginning of the next FPDU. > > 2: For optimized MPA/TCP receivers that support out of order > > reception of FPDUs (see section 4.3 MPA Markers on page 15) a > > Marker can always be used to locate the beginning of an FPDU (in > > FPDUs with valid CRCs). Since the location of the Marker is > > known in the octet stream (sequence number space), the Marker can > > always be found. > > 3: Having found an FPDU by means of a Marker, an optimized MPA/TCP > > receiver can find following contiguous FPDUs by using the ULPDU > > Length fields (from FPDUs with valid CRCs) to establish the next > > FPDU boundary.=94 > > Question: Is an implementation allowed to use the marker, as described=20 > below, to =93unambiguously=94 detect the start of a FPDU? > > Condition under which marker was received: > > 1. Markers being used (negotiated on) > > 2. Large FPDU being sent which consumes three TCP segments (not=20 > desired but allowed) > > 3. Second TCP segment lost > > 4. Marker located in third TCP segment > > Issue: In item two above it would appear that the implementation would=20 > have to validate the FPDU in which the marker is received (perform CRC=20 > check) before it can use it. However, since a portion of the FPDU is=20 > missing this would not be possible to do. Therefore a conformant=20 > device MUST NOT use this marker to detect the start of the FPDU. > > Is this the correct understanding of this requirement? > > Barry Reinhold > > (603) 868-8411 > > bbr@lampreynetworks.com > > -----------------------------------------------------------------------= - > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > =20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Jan 15 10:16:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TZQ-0001FR-EU; Mon, 15 Jan 2007 10:16:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TZP-0001FM-Kl for rddp@ietf.org; Mon, 15 Jan 2007 10:16:23 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6TZN-0003WF-5v for rddp@ietf.org; Mon, 15 Jan 2007 10:16:23 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0FFGI3c013366; Mon, 15 Jan 2007 10:16:18 -0500 (EST) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0FFGEwa011697; Mon, 15 Jan 2007 10:16:17 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 10:16:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jan 2007 10:16:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Messages from Mike Seufert Thread-Index: Acc4uBbx8hVVV9kBSEmygRN4W4GB9Q== To: X-OriginalArrivalTime: 15 Jan 2007 15:16:12.0010 (UTC) FILETIME=[17578CA0:01C738B8] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.15.64933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mike.seufert@neterion.com Subject: [rddp] Messages from Mike Seufert X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org These were delayed in the IETF's spam trap, due to the fact that I was on vacation. I apologize for the delay in forwarding the messages out of the spam trap to the RDDP mailing list. Just a reminder - if you are not a subscriber to this mailing list, you should expect any messages sent to the list to be held by the spam trap for at least a day or over the weekend. Actual traffic on this list is fairly light (especially compared to the volume of spam that the spam trap catches), and a digest option is available to avoid being inundated by a burst of activity, so the best bet for anyone interested to the list is to subscribe. Thanks, --David (rddp WG chair and mailing list admin) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Jan 29 20:14:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhZR-0000vt-0N; Mon, 29 Jan 2007 20:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhZP-0000sH-90 for rddp@ietf.org; Mon, 29 Jan 2007 20:13:59 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhZO-00055q-1C for rddp@ietf.org; Mon, 29 Jan 2007 20:13:59 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U1Dt7t000172 for ; Mon, 29 Jan 2007 20:13:55 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U1Dkbo009636 for ; Mon, 29 Jan 2007 20:13:55 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 20:13:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jan 2007 20:13:53 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No RDDP meeting in Prague Thread-Index: AcdEC+g5IzieXvNnRDyr6gEq/Vd5xw== To: X-OriginalArrivalTime: 30 Jan 2007 01:13:54.0267 (UTC) FILETIME=[E8B232B0:01C7440B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.29.164932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [rddp] No RDDP meeting in Prague X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rddp-bounces@ietf.org The RDDP working group will not meet in Prague. Since all of the WG's drafts have been approved by the IESG for RFC publication, the WG is unlikely to meet again. If additional issues arise in the documents, they will be resolved on the mailing list. Thanks, --David (rddp WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Jan 30 02:48:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnit-000542-W2; Tue, 30 Jan 2007 02:48:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnis-00053q-1H; Tue, 30 Jan 2007 02:48:10 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBniq-0000EL-HF; Tue, 30 Jan 2007 02:48:09 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0U7jEmh001735; Tue, 30 Jan 2007 09:45:22 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 09:47:36 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Jan 2007 09:47:36 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3A695748-CC7D-4B99-915A-EC36CCBC6DBD@nokia.com> Cc: From: Lars Eggert Subject: Re: [rddp] No RDDP meeting in Prague Date: Tue, 30 Jan 2007 09:47:47 +0200 To: "ext rddp-bounces@ietf.org" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jan 2007 07:47:36.0774 (UTC) FILETIME=[E8CEB660:01C74442] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100070514==" Errors-To: rddp-bounces@ietf.org --===============2100070514== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-42-710023010; protocol="application/pkcs7-signature" --Apple-Mail-42-710023010 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-30, at 3:13, ext rddp-bounces@ietf.org wrote: > The RDDP working group will not meet in Prague. Since > all of the WG's drafts have been approved by the IESG > for RFC publication, the WG is unlikely to meet again. > If additional issues arise in the documents, they will > be resolved on the mailing list. FYI, the current plan is to close the WG and declare victory after the documents have been published, to safeguard against the (unlikely) event that any changes will need to be made during the publication process that would require WG consensus. Lars --Apple-Mail-42-710023010 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzAwNzQ3NDhaMCMGCSqGSIb3DQEJBDEWBBR4JvBQBLu3yLUH C6MzPcIhGXpzajCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEARbHUVZCo1av8FuDIiZdTmDQFc5DPE1+vWdVw2rtzN5NkS3zFAN87 uUolaqG8KSgOPTtCCudqF5Age+4evqJ9onNrOixoFVNeHy/32XUaZ+gq39zUPuH2ks4tQRqZoiV+ wnNzJ9AdlQ41ukXlcZaQNfBxSMo5Hj+4vM66mSYh3Hs74HmyQ7sz0ZASSkIwnjv2CRd8NHqyA0Kd 0GLWw44GcPYp4zZb1J4cvrpWRtWeD4DjKzXoKQng0KbrkX+pVjsjOT2wwK3jw6qWllg7aWUrw81F nYw9sfRsL5ni3yWAnXN1zWK5Mv7AQkgCrqEXANAcIrEf6i1UIHBmjzWGkLqRdQAAAAAAAA== --Apple-Mail-42-710023010-- --===============2100070514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============2100070514==--