Date: Fri, 17 Aug 2001 09:01:51 -0700
From: Arvola Chan <>
I agree that if intermediate MSHs do not perform duplicate
elimination, then achieving end-to-end reliable messaging is
easy. I also agree that simpler is better. Do you see a real
adavantage in retaining the use of intermediate Acks?
With the two-layer approach, it's easy to do acks, duplicate
elimination, etc. hop-to-hop if you want to, although it's entirely
optional. Is there a real advantage? For each hop, the less reliable
the hop, the more advantage. If a hop is less reliable
(statistically) than some threshold, then the extra costs of doing
acks and retransmits and duplicate elimination are more than offset by
the savings of not having to do the whole end-to-end trip multiple
times.
I find it cumbersome for the sending MSH to deal with two sets of
retry parameters, one for the next MSH, the other for the
destination MSH.
With the two-layer approach (and using reliability in the lower
layer), each protocol implementation only deals with one set of retry
parameters. (The MSH pretty much corresponds to what I called the
HLPI in my previous mail.) Each end party runs both the HLPI and the
LLPI, and each has its own retry parameters, but they don't know about
each other.
CPA's currently don't work with intermediaries. The retry and
retryInterval parameters to intermediaries can only be configured
through proprietary means. I guess I am in favor of doing away with
intermediate Acks altogether, or at least until they can be
specified through CPA's.
So, you might ask me, is there both a high-layer CPA and a low-layer
CPA? Certainly there's a high-layer CPA, which is basically the CPA
we have now. I think it would be good if we could avoid the need for
a low-layer CPA (mainly to reduce the administrative burden of
creating and distributing low-layer CPA's all over the place). The IP
protocol gets away without anything like a CPA, and so does TCP. The
LLP does not need to be cognizant of a lot of the interesting stuff
that the CPA deals with, and so I think that an LLP connection would
need relatively few parameters, and they could be negotiated
dynamically.
I agree. Now I see the advantage of XMLDSIG which allows the
exclusion of certain elements from the signature.
That's a good thing about XMLDSIG, but with the two-layer approach I
don't think it's needed. The HTPI constructs its HLP message, signs
and/or encrypts the whole thing, and passes it into the LLP. The LLP
sees it as an opaque octet array. All the stuff that you don't want
signed is in the LLP headers, and all the stuff that you do want
signed is in the HLP headers and payload. So you don't need to use
the "sign some but not all" stuff, so everyting is simpler.
-- Dan
