Re: Fujitsu & Savvion proposal

[jacques durand <jacques@savvion.com>]

Sandy:

I am not sure if I understand well your point, though I am glad you see a
"technically elegant implementation path" here... (we always follow this path
anyway :)

So far, the demo outline is quite explicit, as Chris said:
- show that RM  works (once-and-only-once)
- show that the Sliding Windows (SW) really offsets most of the overhead entailed
by the previous RM version (equivalent to window size = 1, or
RMSW(1)), as demoed in Tokyo, which required the serialization
of all round robin trips for receipt.

This serialization, as mentioned in TR&P meeting last July when the initial version
of
the sequence number RM method was first presented, was considered up-front as
unacceptable
for any scalable MSH server (Hub or not). The factors of the corresponding overhead
are known:
- network latency
- intermediate nodes for multi-hop.
- characteristics of the underlying transport protocol
But the weight of these factors is still unknown. The questions we try to answer
are:
- what improvement can we expect by using RMSW(n) over previous RM (RMSW(1)), and
what is the overhead compared to non-RM?
- how sensitive is RMSW to the configuration ? (obviously, we may see much more
improvement
on multi-hop RM than on point-to-point)
- What difference can we expect between multi-hop RM without intermediate acks vs.
with
intermediate acks (V 0.91)? Intermediate acks already offsets some RM overhead
(pipe-line).
Obviously, no intermediate acks is a killer for RMSW(1): can RMSW(n)
without intermediate acks get closer to RMSW(n) with intermediate acks?

These results are expected to  have an impact on the spec content: it is indeed
always desirable to reduce the
number of implementation options particularly at such a low level , as the POC
experience showed
that too many are a constant threat to interoperability.

This demo is an opportunity to create the platform for this testing.
All these aspects will be discussed within the POC meeting, and you are welcome
to participate. Meanwhile, getting more familiar with sliding window techniques
will help,
as this is a major improvement in RM V0.91.


Regards,

Jacques Durand
Savvion


Sandy Klausner wrote:

> Chris:
> I still think that there is a basic issue here of mixing level of processing
> concern. Tangling domain transaction closure with transport closure leads
> one down a path that is inherently not scalable from a practical deployment
> perspective. Proving a reliable messaging mechanism that "works" is a
> required infrastructure ebXML capability. I just don't understand how one
> would practically untangle the domain transaction information from the
> communications transport stream in a generic fashion. The first is a
> background task while the later is a foreground task. The required
> "overhead" for the round robin trip to verify message receipt (unsigned or
> signed) for any particular payload size is a constant due to network
> propagation delay.
>
> I must admit that I have not read the particulars of the Sliding Windows
> approach and perhaps I am reading to much into this proposed capability. If
> the issue is restricted only to avoiding getting tangled up in queued
> incoming message payload traffic, then the approach is well worth pursuing.
> Sandy
>
> > From: christopher ferris <chris.ferris@east.sun.com>
> > Organization: XTC Advanced Development
> > Date: Fri, 26 Jan 2001 07:42:35 -0500
> > To: Sandy Klausner <klausner@coretalk.net>
> > Cc: jacques durand <jacques@savvion.com>, ebxml-poc@lists.ebxml.org,
> > iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> > Subject: Re: Fujitsu & Savvion proposal
> >
> > Sandy,
> >
> > I think that you're missing the point of the demonstration
> > proposal. The "batch" of messages is purely artificial,
> > for purposes of demonstrating that reliable messaging
> > a) works and b) does not impose significant overhead.
> >
> > Indeed, the whole purpose of the demonstration is to
> > dispel *precisely* the myth/comment you cite in the
> > last sentence of your email:
> >
> >> It just seems to me that the TR&P implementation path you are suggesting may
> >> be technically elegant, but introduces a level of complexity that in itself
> >> will have scaling difficulty.
> >
> > Cheers,
> >
> > Chris
> >
> > Sandy Klausner wrote:
> >>
> >> Fujitsu & Savvio:
> >>
> >> I have read your demo draft proposal and question the general technical
> >> solution to this round robin ack performance problem. If the concern here is
> >> transaction throughput, wouldn't it be more practical to declare a singular
> >> message that contains a collection of trade instances and assuring that this
> >> payload has indeed been received intact. The receiver can always return a
> >> message that itself could contain a subset of "rejection trade" instances.
> >> It just seems to me that the TR&P implementation path you are suggesting may
> >> be technically elegant, but introduces a level of complexity that in itself
> >> will have scaling difficulty.
> >>
> >> Sandy Klausner
> >> CoreTalk Corporation
> >> 408.867.1100 O
> >> 408.813.1124 C
> >>
> >>> From: jacques durand <jacques@savvion.com>
> >>> Date: Thu, 25 Jan 2001 20:50:01 -0800
> >>> To: ebxml-poc@lists.ebxml.org
> >>> Cc: jacques@savvion.com, iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> >>> Subject: Fujitsu & Savvion proposal
> >>>
> >>> Here is a demo proposal, focused on the new RM / TRP spec.
> >>> The proposal is intentionally terse on the business scenario side,
> >>> but strong in business *significance*, so that it can accommodate other
> >>> proposals
> >>> that are more architectured around a business scenario, (e.g.
> >>> CommerceOne proposal.)
> >>>
> >>> For your review...
> >>>
> >>> Regards,
> >>>
> >>> jacques Durand
> >>> Savvion
> >>>
> >>
> >>> From: jacques durand <jacques@savvion.com>
> >>> Date: Thu, 25 Jan 2001 20:50:01 -0800
> >>> To: ebxml-poc@lists.ebxml.org
> >>> Cc: jacques@savvion.com, iwasa@fsc.fujitsu.com, shima.masa@jp.fujitsu.com
> >>> Subject: Fujitsu & Savvion proposal
> >>>
> >>> Here is a demo proposal, focused on the new RM / TRP spec.
> >>> The proposal is intentionally terse on the business scenario side,
> >>> but strong in business *significance*, so that it can accommodate other
> >>> proposals
> >>> that are more architectured around a business scenario, (e.g.
> >>> CommerceOne proposal.)
> >>>
> >>> For your review...
> >>>
> >>> Regards,
> >>>
> >>> jacques Durand
> >>> Savvion
> >>>