RE: DDP 7.3 - Data Source MUST transmit DDP Messages in order

Michael Krause's replied to my post as follows:

 >> I would request the following:
 >>
 >> - Does the WG agree that the current wording is compatible
 >>   with both interpretations? Or is the latter interpretation
 >>   locked in by some other language the at I overlooked?

 >> - If there is agreement that the current language is at
 >>   least potentially ambiguous, is there any objection to
 >>   adding the clarification that all DDP Segments for a
 >>   DDP Message must be submitted for transmission to the
 >>   LLP before any Segment for a following DDP Message.

 > Implementations should be able to deal with OOO packet delivery and 
being
 > able to target multiple receive buffers if they are posted (shared or 
  exclusive).
 > Given there is no delta in the wire protocol or the expected  
interoperability in
 > this respect, I do not favor trying to tighten how the  transmitter 
is implemented
 > as that is potentially delving into the specific  design options in 
the hardware.
 >
 > Mike

Generally, I am in full agreement. Receivers should be as flexible as 
possible
and senders should be given as much freedom as possible.

But the purpose of that is to allow senders to find potential 
optimizations
in ways that might not have been obvious. For example, mandating that a
message MUST be segmented in a certain way would block a sender from 
optimizing
for a DDP Segment that might have piggy-packed in the same SCTP Packet 
or TCP
Segment that was already partially filled.

But I'm not sure I can see any benefit to the senders of working ahead,
especially when the last segments must be sent in order and when for 
many
ULPs almost all untagged messages will fit in a single segment.

On the receiving side, however, the restriction can be beneficial to an
entire *class* of implementations -- those that ride on top of optimized
TCP solutions.

Since we have made it clear that the receiver does not have to 
pre-commit
receive buffer for untagged messages (as in the class receive queue) we
have implicitly allowed for receivers that must fetch buffers "on 
demand".

Whatever implementation is used, clearly having a limit on the number of
fetched buffers that have not completed will result in a simpler 
problem.

Simplifying the problem is legitimate. Yes it benefits certain 
implementations,
but that is because it simplified the problem.

Admittedly, the proposed restriction is of virtually no benefit to
implementations that process DDP Segments in arrival order. For that
reason it would be wrong to impose any costs on those implementations
for this feature. But there is no impact on out-of-order receivers.

The *only* impact is that it might block hyper-aggressive re-ordering
of unsent pending DDP Segments. Even with this proposed additional
language, such re-ordering is still possible *within* an untagged
message and with tagged segments. In my opinion that is more than
enough slack for potential optimizations (in fact I suspect that
very few implementations are even considering such optimizations).






-- 
Caitlin Bestler - [email protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html