Subject: [Tsvwg] Application Scenarios where PR-SCTP reduces "junk data" on the net

From: Phillip Conrad <[email-masked]>
Date: Fri, 04 Apr 2003 12:08:49 -0500

Dear Colleagues:

As I understand it, (and I might have it wrong)  Mark's concern is that
PR-SCTP might encourage senders to put information on the wire that is
"not very useful"... .what we might call "junk data".    After all, if one is
willing to "give up" on some message,  how important could it have been
in the first place?  Thus, the argument  might go, it is a waste of network
resources to have put that data on the wire in the first place.

I may be putting words in Mark's mouth, so Mark, if that is NOT your argument,
feel free to speak up and correct me.

But if that is the argument, then I think a concept that may be helpful is
to consider the "time varying value of information".   That is, information 
can be very valuable at one point in time, and less valuable at another 
point in time.      That is key idea behind the idea of "timed reliability".   Thus, by
having a transport service that allows us to give up on packets after their 
utility has decreased, we can actually acheive the result of _less_ "junk 
data" going on the wire.

At 09:28 AM 4/4/2003 -0500, Mark Allman wrote:
>Another class of problems is whether the transport provides an
>incentive for the app to send lots of data that may accomplish no
>useful work.  I am not sure if PR-SCTP does this or not.  But, thus
>far, nobody has convinced me that it does not.

Mark, if you are not certain that PR-SCTP does this, I  think rather the burden of proof is on you to show a scenario that PR-SCTP _does_ create such an incentive. 
I think that if you can make that case, we can really have a useful discussion. 

Without a coherent argument to that effect, your technical argument against PR-SCTP seems to be that "it _might_ create an incentive to send junk data, though I can't yet produce the scenario in which that is true".   This doesn't seem to be a very strong technical argument.    

On the other hand, I'd like to present a couple of scenarios, where I think there is a convincing case that PR-SCTP actually achieves the opposite.. that is, to "reduce" the amount of "junk data" flowing on the network.

(Scenario 1): Consider a "situational awareness" application operating over
a wireless IP network.    In a situational awareness application, mobile units
(mounted on vehicles or wearable computers) send periodic status updates
to planners that need to put together a coherent picture of "who is where"
and "how everyone is doing".    Military applications are probably obvious,
 but if you prefer a non-military purpose, consider tracking emergency
vehicles (rescue, fire personnel, gas and electrical repair workers, etc.)
in a disaster situation (e.g. the "big earthquake").

In such a network, packet loss due to both congestion, noise, and link and
router failure may be significant, so it is important to concentrate the 
resources of the network on the most crucial information.    If the application
generates status update messages every 2 seconds, then it might make
sense to put an  "expiration date" on such messages of 3-5 seconds, 
so that if there is a transient network outage of, say 20 seconds... 
not long enough to drop the SCTP association, but long enough to 
create a backlog of update messages, the sender can skip over
the retransmission of some stale messages and get the more timely 
data out the door.

Now, in this application, it is NOT the case that the transmission of any 
of this information is "wasteful" when it is first submitted to the transport 
service... at least not in the usual case of low packet loss.   In that case, the 
constant updates would flow to the receiver in a timely fashion, and give 
a second by second  picture of where each unit in the overall picture is 
located, a picture that may be crucial to saving lives.

However, once the network gets into trouble, and we get into the situation 
where due to a transient outage, a bunch of messages are sitting in the 
transport send  buffer of some unit, and those messages at the head of 
the transmit queue are NOT the most crucial information to transmit at 
that point in time (because they are  stale) PR-SCTP allows
the sender to skip over the information that has now _become_ stale, and 
put the _more_ useful (i.e., more timely) status information on the wire.

(Application 2:)  My understanding is that in 
certain problem  domains that are outside my main area of expertise 
(e.g. signalling transport, ip  storage) there are certain legacy protocols 
that it is desirable now, because of the  ubiquity of IP-based
technology, to place on top of IP networks.  

(Since my knowledge of sigtran and ip storage is very limited, 
I hope those who are more expert in these areas can either confirm
or correct my simplified explanations below.) 

Because it is desired for these protocols to benefit from the congestion 
control, flow control, and retransmission  mechanisms available
in protocols such as TCP and SCTP, these legacy protocols are generally 
implemented on top of TCP and/or SCTP.

However, a problem occurs because many of these protocols
have built into them, legacy retransmission timers of their own.  In some 
cases, these retransmission timers might be, for example, fixed values 
that are an order  of magnitude larger than typical initial RTOs that would 
result from TCP or  SCTP.    (say, for sake of
argument, 5 seconds), and certainly larger than the retransmission that 
might result from a duplicate ack triggered fast retransmit.

However, sometimes, if the RTO gets backed off, the TCP or SCTP RTO might 
be larger than the application layer protocols own RTO.  Now we have 
retransmission occurring  at two different layers, which is an undesirable situation.

Now there are two ways of addressing this probably immediately occur to the 
reader, neither of which is very satisfactory in the real world, as I 
understand it.

One answer to this would be to "fix the application layer protocol" to 
either turn off the retransmissions at this layer.    However, as a 
practical matter, my understanding is that the application layer protocols 
in question are "deeply embedded" in signalling transport and storage 
systems, and that while is "might be nice" to be able to do this, it is 
simply not feasible.

Another approach, is to apply the end-to-end argument, and run these over a 
completely best-effort transport, and rely exclusively on the 
retransmission built into the application layer protocol.    A problem here 
is that the application layer protocol's retransmission strategies don't 
adapt well to the underlying network, not in the way that the 
retransmissions in TCP and SCTP adapt.   (There may be other reasons as 
well that this is not feasible... I'll rely on my colleagues to fill in the 
gaps)

The alternative approach is to use the timed-reliability service provided 
by PR-SCTP to indicate that messages that will be retransmitted by the 
upper layer after, for example, 5 seconds, should be abandonded by the 
transport layer once that 5 seconds has elapsed.   Again, this results in 
an actual _reduction_ in "junk data", i.e. a redundant retransmission of a 
particular message X, which in the absence of the PR-SCTP timed reliabilty 
service, ends up appearing more than once in the reliable data stream.

Therefore, the bottom line is that PR-SCTP helps to keep redundant data,
or data that has become stale off the network.    None of this data was
"junk data" when it was first transmitted, which seems to be one of the
fears or doubts that is being thrown at PR-SCTP.

Regards,
Phill

-- Phillip Conrad, Asst Professor, CIS Dept. Temple University
-- Philadelphia PA 19122    [email-masked]

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

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Apr 2003 21:13:11 +0200

Dear all,

one of the main usage scenarios for SCTP is SIGTRAN. The SS7
protocols being transported can not be changed and run their
own timers, ISUP for example.

Looking at this example the following happens:

The ISUP sender sends an ISUP message, starts a timer and
waits for an ISUP answer. If the timer is stopped if the
answer arrives and another message will be send.

But if the answer does not arrive before the timer runs
off ISUP brings down the call by sending a NEW message.
Now it makes no sense for the SCTP layer to retransmit the
first message. It would be better to discard that message and
only deal with the new message.

Assuming that this happens during congestion you are sending
2 messages in case of SCTP and only one in case of PR-SCTP,
because you are not continuing to retransmit the now useless
first message.

You can say that we should change the upper layer, but the intention
of the SIGTRAN WG is exactly the opposite: provide a way of SS7 over
IP WITHOUT changing the SS7 protocols.

This usage scenario was already considered during the work on RFC 2960,
therefore you find a lifetime parameter in the send call description.
The mechanisms in the protocol however, did not make it.

So I think the discussion should not only be on potential ways of
misuse, but also on the scenarions where such a mechanism can be
really helpful. SIGTRAN, in my opinion, is one.

Best regards
Michael

On Friday, Apr 4, 2003, at 19:08 Europe/Berlin, Phillip Conrad wrote:

> Mark, if you are not certain that PR-SCTP does this, I  think rather 
> the burden of proof is on you to show a scenario that PR-SCTP _does_ 
> create such an incentive.
> Without a coherent argument to that effect, your technical argument 
> against PR-SCTP seems to be that "it _might_ create an incentive to 
> send junk data, though I can't yet produce the scenario in which that 
> is true".   This doesn't seem to be a very strong technical argument.
>
> On the other hand, I'd like to present a couple of scenarios, where I 
> think there is a convincing case that PR-SCTP actually achieves the 
> opposite.. that is, to "reduce" the amount of "junk data" flowing on 
> the network.
>