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

["Barry Reinhold" <bbr at lampreynetworks.com>]

-----Original Message-----
From: Caitlin Bestler [mailto:caitlinb at siliquent.com] 
Sent: Monday, December 20, 2004 4:15 PM
To: Jim Pinkerton; Barry Reinhold; iwarp-tech at iol.unh.edu; RDDP
Subject: RE: [rddp] Conformance test design issue with exposed MULPDU

 

> -----Original Message-----
> From: Jim Pinkerton [mailto:jpink at windows.microsoft.com] 
> Sent: Monday, December 20, 2004 11:51 AM
> To: Caitlin Bestler; Barry Reinhold; iwarp-tech at iol.unh.edu; 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".

I don't think I have an issue with this, the tests are designed to allow
the DUT to see whatever events cause the MULPDU change to take place
before the data to be sent is submitted to the RDMA interface of the
DUT.

After reviewing RFC 1122 I am no longer convinced that I can change the
EMSS through the advertised window as RFC 1122 clearly links the EMSS to
a default value or the value set at connection startup via TCP MSS
option. Not using the TCP MSS option results in use of the default, not
a value based on the largest seen window.

Thus the only way to change the EMSS within the context of a live
connection is by changing the PMTU. However, path discovery is not
something I anticipate many implementation supporting. I will probe the
list to see what the situation is. 



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