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

["Jim Pinkerton" <jpink at windows.microsoft.com>]

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





> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Caitlin Bestler
> Sent: Monday, December 20, 2004 8:54 AM
> To: Barry Reinhold; iwarp-tech at iol.unh.edu; RDDP
> Subject: RE: [rddp] Conformance test design issue with exposed MULPDU
> 
> 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: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On
> > Behalf Of Barry Reinhold
> > Sent: Monday, December 20, 2004 6:17 AM
> > To: iwarp-tech at iol.unh.edu
> > 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:
> >
> > "   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
> > bbr at lampreynetworks.com
> > (603) 868-8411
> >
> >
> >
> >
> >
> > _______________________________________________
> > rddp mailing list
> > rddp at ietf.org
> > https://www1.ietf.org/mailman/listinfo/rddp
> >
> 
> _______________________________________________
> rddp mailing list
> rddp at ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp