Subject: [NSIS] Message summarisation ("summary refreshes")

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 23 Sep 2003 23:02:19 +0100

dear all,

there is currently an open issue in the framework about which
layer should be responsible for summarisation of refresh messages
(i.e. being able to send a message id rather than a complete
message, like 2961 does). some people have assumed that the
NTLP should provide this as a service, while others have 
felt this would be an overcoupling of state/identifiers between
the two layers.

my feeling is that we should not mandate specific functionality
in the NTLP to do this at this stage, or impose a specific 
function split or inter-layer dependency in the framework. we should
just mention the possibility of doing transparent compression
in the NTLP as a option for later consideration (it's a bit like
'advanced bundling'). since this is always possible, the issue
probably doesn't even need to be discussed in detail.

views?

robert h.

=============================================================

the outline reasoning is as follows:
*) one benefit of summary refreshing is that the receiver doesn't
have to check the incoming message against all stored state to 
see if anything has changed, it just does 'same as last time'.
since the NTLP knows nothing about signalling application state,
achieving this benefit must be an NSLP function.
*) the other benefit of summary refreshes is to get multiple 
messages into a single network layer packet (saving network and
interrupt processing load in the receiver). this is basically 
a compression function. now:
- an NSLP can do a good job of compressing a message down
to flow-id + session-id + NSLP-id + NSLP-message-tag (if it
wants to); exactly what this compression means may be 
signalling application dependent (i.e. it may be something
other than bit-transparent compression)
- the NTLP may or may not be able to compress away the remaining
identifiers into a single message tag, depending on the exact 
circumstances (e.g. is the NSLP peer one NSIS hop or one IP hop
away, how much state the remote NTLP is prepared to store and
so on). It isn't clear how much additional benefit this will 
give over the compression can be done at the NSLP, but in any
case, it is just bit-transparent compression which can be done
as a matter of choice in the NTLP design.

the IETF (rohc w.g.) has developed a remarkable set of capabilities
for bit-transparent compression over recent years; IMHO we should
consider using these, if doing more than the NSLPs can becomes 
important (which in fact I doubt will happen soon), rather than
wiring a particular approach into the protocol suite framework.
in the meantime we don't lose anything by ignoring the issue.

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 24 Sep 2003 09:55:30 +0200

Hi Robert

Your proposal regarding the optional/mandatory functionality
in the NTLP is very reasonable and I agree with it.

Best regards,
Georgios