RE: 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: [email protected] [mailto:[email protected]] On 
> Behalf Of Barry Reinhold
> Sent: Monday, December 20, 2004 6:17 AM
> To: [email protected]
> 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
> [email protected]
> (603) 868-8411
>  
> 
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>