Subject: Re: [Tsvwg] pr-sctp

From: Mark Allman <[email-masked]>
Date: Fri, 04 Apr 2003 11:59:14 -0500

Michael rightly noted that I wrote a whole lot of ambiguous rubbish
the last time around.  Durned context senssative languages.  So, I
am going to try again...

> If such a service definition existed ... there would be *no need*
> for the application to send N times via APF as you suggest.  We
> then let PR-SCTP (the transport ... not the application) do the
> "accounting" and it will only send once (if successful) the
> majority of the times .... and only sends N times when it was
> actually unsuccessful for [N-1] prior times. Thus this service
> definition would make PR-SCTP have a "N persistence" property.
> 
> This, in my book, is an incentive for the app to behave better
> than sending "N times" in a brute force manner.

No need, but maybe a desire.

Say the app sends the same message to the transport twice.  The
transport then sends both copies out (in two segments).  Now, say
one of these segments gets dropped but the other arrives fine and is
delivered to the receiving app.  By some metrics that offers better
performance than the case when the sending app gives the sending
transport only one copy and lets the transport retransmit as
necessary (which adds an extra ~RTT before the receiving app gets
the data).  If the sender has to waste its own resources (buffer
space, cwnd space, etc.) to retransmit the lost segment (that is now
useless) then I think there is *some* incentive against using such a
brute force method.  If the sender can say "oh, nevermind on that
lost segment" and clean up our own resources then it seems like
there is no incentive not to waste network resources if one wanted
lots of redundancy.

I hope that is a bit more clear.  Sorry for any confusion I caused.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 04 Apr 2003 15:02:28 -0500

At 11:59 AM 4/4/2003 -0500, Mark Allman wrote:

>the data).

Ok. Now I get your point. You are specifically looking at "delay
performance" ... not other "performance metrics".

>If the sender has to waste its own resources (buffer

You have a point if you desire/need redundancy AND delay performance
less than an RTT. Obviously any (partially) reliable transport
protocol can't do that job without being (knowingly) wasteful
(i.e., sending data twice).

I think these applications - by design necessity - need application
layer design (e.g., FEC on voice packets).

But even the vast majority of non-interactive streaming applications
could benefit from an additional playout delay of a few RTTs .... and
use either the "timed reliability" or "N persistence" flavors of PR-SCTP.
For these applications ... let the transport layer use the resources
(buffer space, etc.) profitably and let it discard "stale information".
To do otherwise, the application needs to get as smart as the
average tsvwg'er.

>I hope that is a bit more clear.  Sorry for any confusion I caused.

Got it this time .. thanks.

Michael Ramalho

---

From: Randall Stewart <[email-masked]>
Date: Sun, 06 Apr 2003 15:19:21 -0500

> there is no incentive not to waste network resources if one wanted
Mark:

I think I understand your point but I don't see how PR-SCTP encourages
an application designer to send extra data...

Lets say I send two copies of packet X in the hopes of
getting it through with an application sequence number....

Now what have I done with PR-SCTP ... taken up twice the
amount of cwnd space... each copy eats into how much
I can send.

My problem is I am missing the incentive for this bad behavior
that PR-SCTP provides..

The dis-incentive for this behavior you mention is head of
line blocking (for TCP).. but what is my dis-incentive for unordered
SCTP? The same for PR-SCTP, if I send it twice I eat up twice
my cwnd this is the only dis-incentive that I can see and PR-SCTP
does not change compared to SCTP-unordered....

Am I missing a dis-incentive... or to flip the coin.. an incentive
to send extra non-needed data... I don't see it...

If I really am going to send each 'packet X' twice.. I can do the
same thing with SCTP/Un-ordered, UDP or DCP...

I agree that TCP has the extra dis-incentive of head of line blocking,
but semi-ordered SCTP and unordered SCTP do not have this problem.
For example take away unordered SCTP and I the application designer will
setup 100 streams in SCTP. Send copy 1 of Packet X on stream 0, send the
next copy on stream 1. Then send Packet Y on stream 2 and copy on stream 
3.. etc.

Again.. what is my dis-incentive for the above behavior? I eat up
cwnd of my association.

Even in TCP I can do the above... setup multiple connections and
then not only do I get the ability to replicate everything down the
second connection.. I can also get two sets of cwnd's.

Am I missing something in your side of the bolgna? I just can't find
the incentive for bad behavior over what is already out there...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)