RE: legality of interleaving untagged message segments

This looks like WG rough consensus that interleaving
of untagged message segments at the sender MUST NOT be
done.  Send any objections to this to the list.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Michael Krause
> Sent: Tuesday, May 18, 2004 2:34 PM
> To: [email protected]
> Subject: Re: [rddp] legality of interleaving untagged message segments
> 
> 
> At 11:24 PM 5/17/2004, Caitlin Bestler wrote:
> 
> >Michael Krause said:
> > >
> > > Within a given LLP stream, you are correct that the 
> optimization benefits
> > > may be minimal if I/O device is somewhat "distant" (read 
> as relatively
> > > high
> > > latency) from the memory controller.  However, as we see 
> the industry move
> > > towards PCI Express (PCIe) and with the potential to create more
> > > integrated
> > > memory controller chipsets, there may be greater benefit over time
> > > (especially with some architectures moving to be more 
> NUMA oriented).
> > >
> > > Given this may take time to occur and validate, would you 
> be willing to
> > > make this a SHOULD NOT instead of a MUST NOT thus 
> allowing leeway for
> > > future development while providing strong guidance that 
> such interleaving
> > > is strongly discouraged?
> > >
> > > Mike
> > >
> >
> >There is already a SHOULD that segment SHOULD be submitted 
> in ascending
> >order. So no further SHOULD clause is required.
> >
> >Or for that matter useful.
> >
> >  A "SHOULD NOT 'X'" clause does not truly allow the 
> receiver to optimize on
> >the assumption that senders will not do X. It just 
> discourages testing of
> >'X',
> >so in a sense it's worse than doing nothing. Receivers are 
> not free to
> >optimize,
> >and senders are discouraged from whatever optimization there 
> might be.
> >
> >My assumption is that the MUST NOT I am proposing will not 
> preclude any
> >achievable optimization on the sender side.  If that 
> assumption is correct
> >then benefit to the receiver is clearly preferable. But if 
> anyone had an
> >algorithm that really would optimize across message 
> boundaries and gain
> >actual benefits from it then the tradeoff is indeed more complex.
> >
> >The benefit at the receiver side, for an implementation that 
> defers placement
> >processing of DDP segments until they can be processed in 
> order, is that
> >there would be at most one active untagged buffer per DDP 
> Stream. This
> >is a major benefit, which I believe outweighs the 
> theoretical benefits that
> >some unidentified sender algorithm *might* achieve in the future.
> >
> >Of course I am willing to be convinced to the contrary if 
> someone were to
> >present a contemplated optimization that this restriction 
> would interfere
> >with.
> >Or for that matter, even assert that they are researching 
> such an algorithm
> >that they are unwilling to disclose.
> 
> I willing to make this a MUST NOT and address this in a 
> future version of 
> the spec should the optimizations be publicized.
> 
> Mike 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>