RE: Conformance test design issue with exposed MULPDU

 

> -----Original Message-----
> From: Jim Pinkerton [mailto:[email protected]] 
> Sent: Monday, December 20, 2004 11:51 AM
> To: Caitlin Bestler; Barry Reinhold; [email protected]; RDDP
> Subject: RE: [rddp] Conformance test design issue with exposed MULPDU
> 
> 
> 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)
> 

But unless you can intercept the DDP to LLP communications, I don't
See how you can design a conformance test.

The DDP layer only segments once, but there is no constraint as to
How early or late the segmentation is done. An implementation could
Segment when requests are submitted, and immediately submit the
Resulting segments to the LLP -- or it could segment "just in time".

A lot depends on the nature of the DDP/LLP interface -- but that
itself is not standardized. It could be a push, pull or hybrid
interface.
The closer to a "just in time" interface the easier it would be to 
see the reaction to the change PMTU.

But if the LLP accepts 2 GB  of segments in advance then lagging
on recognizing the new PMTU until the 2 GB made its way through
the LLP queue would be correct behavior. It's not very desirable,
and an excessive amount of buffering capacity for the LLP to provide,
but it would be legitimate.

The actual interface will more likely resemble a pull than a push,
but implementations will vary in their definition of "just in time".