Subject: [rddp] Conformance test design issue with exposed MULPDU

From: "Barry Reinhold" <[email-masked]>
Date: Mon, 20 Dec 2004 09:16:40 -0500

I am seeking to write a conformance tests that addresses that following
item from DDP clause 3, first item, which states:

"   1.  LLPs MUST expose MULPDU & MULPDU Changes. This is required so 
       that the DDP layer can perform segmentation aligned with the 
       MULPDU and can adapt as MULPDU changes come about. The corner 
       case of how to handle outstanding requests during a MULPDU 
       change is covered by the requirements below.

   2.  In the event of a MULPDU change, DDP MUST NOT be required by the 
       LLP to re-segment DDP Segments that have been previously posted 
       to the LLP. Note that under pathological conditions the LLP may 
       change the advertised MULPDU more frequently than the queue of 
       previously posted DDP Segment transmit requests is flushed. 
       Under this pathological condition, the LLP transmit queue can 
       contain DDP Messages which were posted multiple MULPDU updates 
       previously, thus there may be no correlation between the queued 
       DDP Segment(s) and the LLP's current value of MULPDU. "

In seeking to test the DUT's exposing of MULPDU changes I am currently
assuming that if:

1. There has been no TCP MAXSEG option advertisement,
2. The maximum sized TCP window seen by the DUT is N octets (where N is
not limited by the lower bound of a segment, and is smaller than that
advertised by the DUT)
3. The window size is advertised to the DUT at a time when no RDMA
operation has been requested.

then when a RDMA Send/write operation is requested of the DUT w/ Nish
octets the DUT will send one FPDU in one TCP segment. (Nish implies that
N is selected with an awareness of the need to take into account
headers).

What I am a less sure on is the next step. I would like to know if
people believe that the following is required normative behavior:

Once the DUT has sent the FPDU as outlined above, consuming the N octets
advertised by the test station, the test station advertises a window
smaller that N, uses PULP to queue additional RDMA send/write requests,
and then checks to see that the new FPDUs are such that they fit into
the now smaller TCP segment.

I believe this to be the heart of what the conformance item is
requesting, but I'm not sure how quickly a LLP is supposed to map a
change in the EMSS to the MULPDU and expose it to the ULP.

If this is an invalid test in your mind, is there a delta (in either
time or octet stream space) by which the DUT would have to change the
exposed MULPDU?

Barry Reinhold
Lamprey Networks
[email-masked]
(603) 868-8411

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 20 Dec 2004 08:53:34 -0800

Any specific performance requirements would have to be
in the LLP Requirements of the DDP draft. They are not
there, which I believe represents a deliberate decision
to leave this as a "quality of implemnetation" issue that
does not require standards enforcement.

Keep in mind that in the extreme case, long delays in
reporting changes in the PMTU would effectively degrade
to the same behavior as a non-MPA/DDP aware LLP. For TCP
This would mean non-aligned MPA frames, for SCTP it would
mean IP fragmentation. Neither of which will prevent
Interoperability, merely degrade performance.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Barry Reinhold
> Sent: Monday, December 20, 2004 6:17 AM
> To: [email-masked]
> Cc: RDDP
> Subject: [rddp] Conformance test design issue with exposed MULPDU
> 
> I am seeking to write a conformance tests that addresses that 
> following item from DDP clause 3, first item, which states:
> 
> In seeking to test the DUT's exposing of MULPDU changes I am 
> currently assuming that if:
> 
> 1. There has been no TCP MAXSEG option advertisement, 2. The 
> maximum sized TCP window seen by the DUT is N octets (where N 
> is not limited by the lower bound of a segment, and is 
> smaller than that advertised by the DUT) 3. The window size 
> is advertised to the DUT at a time when no RDMA operation has 
> been requested.
> 
> then when a RDMA Send/write operation is requested of the DUT 
> w/ Nish octets the DUT will send one FPDU in one TCP segment. 
> (Nish implies that N is selected with an awareness of the 
> need to take into account headers).
> 
> What I am a less sure on is the next step. I would like to 
> know if people believe that the following is required 
> normative behavior:
> 
> Once the DUT has sent the FPDU as outlined above, consuming 
> the N octets advertised by the test station, the test station 
> advertises a window smaller that N, uses PULP to queue 
> additional RDMA send/write requests, and then checks to see 
> that the new FPDUs are such that they fit into the now 
> smaller TCP segment.
> 
> I believe this to be the heart of what the conformance item 
> is requesting, but I'm not sure how quickly a LLP is supposed 
> to map a change in the EMSS to the MULPDU and expose it to the ULP.
> 
> If this is an invalid test in your mind, is there a delta (in 
> either time or octet stream space) by which the DUT would 
> have to change the exposed MULPDU?
> 
> 
> 
> 
> 
> Barry Reinhold
> Lamprey Networks
> [email-masked]
> (603) 868-8411
>  
> 
> 
> 
>

---

From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 20 Dec 2004 11:51:15 -0800

I think the tests could even be tougher than that defined below. 

To me the goal of the text was to require a conformant implementation to
enable data transfer whenever the PMTU changes. In terms of testing for
compliance with this intent, the PMTU update could occur at a variety of
points, including:

	1) data sent, but not ACKed
	2) data not sent, still in the RDMAP/DDP/MPA/TCP/SCTP layer 
		(tough to test a specific layer independently, but 
		probably worth a try)
	3) data in the application layer (i.e. connection established, 
		but data not yet posted to RDMAP/DDP/MPA/TCP/SCTP)

I would prefer a test for at least the above three categories. 1) would
require the recipient to be able to explicitly control when the TCP/SCTP
window update occurred (i.e. don't ack the data, change the PMTU
up/down), drop all the data, let the transmitter retransmit, but only
except MTU's that are less than or equal to the revised value). 2) could
be exercised by asking the target to send a very long message (say, 10's
of megabytes on a 1 gig link), sending a PMTU update, and then only
accepting data with a MTU less than or equal to the PMTU (the target
should update the PMTU before the final connection timeout to ensure
forward progress). And finally, 3) is send some data with the old PMTU,
send a PMTU update, and then send some new data, and only accept the new
data if it's MTU is <= the new PMTU value.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Caitlin Bestler
> Sent: Monday, December 20, 2004 8:54 AM
> To: Barry Reinhold; [email-masked]; RDDP
> Subject: RE: [rddp] Conformance test design issue with exposed MULPDU
>