Subject: [Tsvwg] PR-SCTP

From: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2003 10:09:10 -0500

All:

I would like once again to bring up PR-SCTP for discussion...

So far I have received several comments on the document and
am preparing changes based on them. One unresolved
issue is Mark Allmans comments on "junk" data.

Mark and I agree that we have a fundamental difference of opinion
on this...  :-0

I don't think a transport protocol should police the data that
an application sends over it... even if there are hints that
are given saying "you can abandon this data if after some
amount of time you can't get it through". To me this seems to
improve chances of getting out of congestion faster since it
may not be the case that the application as anything else
to say for a while.. and even if it does.. overall you are
reducing the load on the network by the data that you removed
(since classic SCTP would retransmit it until it was sent
  on through).

Mark feels that the parameters given could be used in some
way to enforce on the app that it not use this feature to
much... (Mark jump in and correct me if I mis-state things)...
no matter if it is an abuser (for example sending multiple
copies of data to speed things up) or a valid application.. junk
data is junk data... If you do it to much you should in
some way be penalized... aka make the data reliable or
reset the connection....

Do others feel the same as Mark? Should a transport police
the types of data being sent? ... I guess this falls in
with some of Reiner's work as well (on FEC related use
of the cwnd).. My opinion is obvious :> I am against
this...

Along with the above I would like to get other feedback... I
would like to get this document moved on to last-call possibly
after incorporating all of the comments.. to date...

What does everyone think???

Thanks

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

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

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Apr 2003 08:59:14 -0700 (PDT)

OK, let me show how poorly I understand the issue.

If an application gives clues to transport that something isn't
as interesting as something else, how is this different from
per-packet priority marking?

My first take is that I'm not sure how transports know something
is junk, in the general case. I'm actually interested in
understanding more clearly what the axes of "interesting" look
like. I think I'd like to understand this better, before
providing local-optimal feedback.

My understanding of Randall's concept is "deadline discard" - if
you don't deliver this in 800 ms, don't bother? 

My understanding of Reiner's concept is "reduce retransmission
latency by retransmitting" - if you have unACKed data and don't
have anything else new to send, send the old data again?

What are the other concepts that people are thinking about?

Spencer

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Apr 2003 10:06:31 -0600

Randall,

I am against transports policing junk also.

What other comments are you talking about?  (I only
saw the ladders that Mark started...)

I don't see any problems with the latest draft.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 23 Apr 2003 11:33:07 -0500

>of the cwnd).. My opinion is obvious :> I am against

Even if you agree that the transport layer should prevent
or at least discourage abuse of network bandwidth by the
application layer, it would not be PR-SCTP specific. Or even
SCTP specific for that matter.

PR-SCTP can never guarantee that payload will *not* be
delivered. Even if you cancel it, the receiving side
might still get the data before the cancellation.

If there is a real concern for transports encouraging junk
data, I would suggest a better target being congestion
control itself. It encourages a "use it or lose it"
mentality concerning bandwidth -- a problem not found
with explicit rate control. I'm not advocating any specific
solution -- but at least its a real problem.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Wed, 23 Apr 2003 12:50:35 -0400

My last two notes on this subject from a couple week back stand as
my opinion.  I will not repeat them.  But, I would be interested in
others opinions (especially those we have no heard).  

But, a clarification...

> Mark and I agree that we have a fundamental difference of opinion

Indeed.

> some way be penalized... aka make the data reliable or

Note that "junk data" is maybe not the best way to describe it (even
though I, no doubt, started that).  We can determine data that was
sent, dropped (with good probability) and not retransmitted using
PR-SCTP.  That data **accomplished no useful work and used scarce
network resources**.  (I see this as a pretty non-controversial
opinion.  Do we have agreement on it (i.e., only what I have written
in this paragraph)?)

And, then there is the question of what to do about data being sent
that does not accomplish useful work.

Also, I want to stress that I offered that **excessive** amounts of
data transmitted without accomplishing useful work should be curbed.
I never said it was a reason not to do PR-SCTP.

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: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2003 11:54:09 -0500

I believe there are actually four (two off-line and one
at the TSV meeting)...

1) The current document uses the term "drop" .. this to some
    in TSV is confusing.. aka a router will "drop" a packet due
    to congestion. Instead the term "abandon" aka the user decides
    to "abandon" a packet.. is being substituted for "drop"

2) There was a typo in the document the word "parameter" is miss-spelled

3) Allison wanted a clearification in the service model presented in the
    document that an application cannot change the lifetime of a
    message after it was sent. This is implied in some places but not
    spelled out... It was also due to some poor wording choices in
    the document as to who is evalutating ... etc:

    So the following clearifications are put in (note the line numbers
    are against my xml file..not the draft)...

887c896
      The sender MAY evaluate the lifetime of messages at anytime.
---
      The sending SCTP MAY evaluate the lifetime of messages at anytime.
891a901,904
TR6)
     The sending application MUST NOT change the lifetime parameter
     once the message is passed to the sending SCTP.

900c913
<     implementor flexibility to evaluate lifetime at any other convenient
---
 >     SCTP implementor flexibility to evaluate lifetime at any other 
convenien

4) Comments at the tsv were made that it was not clear that
    normal cwnd adjustments should be made when timers go off
    even if you decide to abandon a chunk..  So a new F5) will
    be added that specifies:

        If a decision to "abandon" a chunk is made based on a
        retransmission decision (e.g T3-Timeout or Fast Retransmit)
        the appropriate congestion adjustment as specified in RFC2960
        MUST be made before any FORWARD TSN chunk is sent.

These are all I have.. unless others pop up :->

R

---

From: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2003 11:59:03 -0500

>>Mark and I agree that we have a fundamental difference of opinion
we surely agree here :>

> though I, no doubt, started that). 

It might be nice to have a better term.. but I did not want to
muddy the water by changing terms :-0

  We can determine data that was
> opinion.  Do we have agreement on it (i.e., only what I have written

Well, Caitlin actually had a good point.. just because you abandon a
chunk does NOT mean it did not get delivered... so it COULD have done
some useful work... you the sender just do not know if it got there
at all (in a timely manner where it was used) or not.... it may
have... with a ACK loss making you think it did not.. or it may
NOT have and then the above would have been true... But I guess
your "good probability" qualification may be saying this :>

> I never said it was a reason not to do PR-SCTP.

Thanks for the clearification.. I too would like to hear what
others think..

R

---

From: Mark Allman <[email-masked]>
Date: Wed, 23 Apr 2003 13:03:00 -0400

> > We can determine data that was sent, dropped (with good
> > probability) and not retransmitted using PR-SCTP.  That data
> > **accomplished no useful work and used scarce network
> > resources**.  (I see this as a pretty non-controversial opinion.
> > Do we have agreement on it (i.e., only what I have written in
> > this paragraph)?)
> 

Yes, that was my intent.

allman

---

From: Randall Stewart <[email-masked]>
Date: Wed, 23 Apr 2003 14:15:06 -0500

Laurent:

Thanks for your response.. I am copying the list (hope thats
ok) .. maybe you forgot to do the reply-all think :>

R

Laurent Glaude wrote:
> Randall,
> 
> I support your view that the transport layer should not police the data 
> that an application sends over it. I do not believe that PR-SCTP 
> provides an incentive to send "junk data".
> 
> -Laurent
> 
> Randall Stewart wrote:
> 
>> All:
>>

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 23 Apr 2003 15:33:35 -0400

Mark ... A comment or two ... Michael Ramalho

>opinion.  Do we have agreement on it (i.e., only what I have written

Yes, I'd agree with the "**" sentence as it stands. However, it is - in
my view - an artful sentence that clouds the issue. (Hey Mark .. don't
get bent out of shape ... I meant this as a compliment ... not everyone
can write like a sentence that :-) ).

The application *did not know a priori* it was using scarce resources - this
became apparent only "after the fact".

Then the application, *given the choice of getting more current data now
rather than getting old data .. then the new data* chose the latter. And
note the latter actually reduced the congestion by the entropy of the
chunk that became "abandoned" (Randall's new descriptive term).

>that does not accomplish useful work.

Obviously, if you knew that a priori ... you would not have sent it!

There are many applications with the property that they monitor
changing parameters. These applications usually send at regular
intervals ... and, in the absence of congestion, would like data
at all the time intervals the data is sent.

PR-SCTP "timed reliability" provides another mechanism for the
application to chose what gets abandoned in the hope that: 1)
it will get more recent data sooner (because it is not behind the
now stale data) and 2) it actually will reduce the congestion
episode by *not* injecting the (now more stale) data into the
network (i.e., by *saving network resources* when you really
need them saved ... during congestion episodes).

I suggested in my earlier posts that I believed this is close to
optimum behavior during congestion episodes (i.e., without a priori
information) ... and you did not refute or challenge that claim.

So I am at a loss to address your concern lacking either:
1) "a priori knowledge on congestion" or
2) a "garbage/relevance" gauge that the transport could use to
determine "excessive/bad/junk/redundant" data.

>data transmitted without accomplishing useful work should be curbed.

I agree that this should be discouraged ... I just don't know
how to enforce/police at the transport level.

>I never said it was a reason not to do PR-SCTP.

Good to hear that.

>allman

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.941.708.4650
Cell: +1.941.544.2844

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 23 Apr 2003 20:00:17 -0500

> per-packet priority marking?

To be more precise, the app is not saying that the data is less
interesting. Rather, in the case of PR-SCTP, the apps is simply saying
that *this piece of data is equally interesting/important as any other
at this moment, but it will become less useful after x seconds*

For this reason, I wouldn't call it "junk data". Maybe better to call it
"time sensitive data".

-Qiaobing

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Apr 2003 19:26:06 -0700 (PDT)

OK, that actually helped in Randall's case - I was thinking
about a linear decay, but see that Randall is talking about a
right-angle decay...

I think my question still applies in Reiner's case (the sender
knows that the data could very well have gotten there the first
time, but would rather retransmit than sit idly and wait for a
timer to pop).

Spencer

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 23 Apr 2003 20:41:32 -0600

Spencer,

Regardless of where you attempt to police FEC or excessive
retransmissions, the application can simply retransmit one
layer up and avoid whatever measures are taken at the lower
layer.

IMO Only a measure that penalizes an application for sending
data would thwart FEC (at the cost of bulk data transfer).

I don't believe that this is a PR-SCTP gating issue at all.
I think it is a general issue outside the scope of PR-SCTP.
I also don't think that PR-SCTP should be delayed in advancing
while disussing this more general question.

My 2 cents.

--brian

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 23 Apr 2003 20:35:56 -0700 (PDT)

> data would thwart FEC (at the cost of bulk data transfer).

Are there only sticks, and no carrots? We've had better luck
getting people to deploy using carrots (congestion avoidance,
HTTP/1.1, CIDR ...)

> while disussing this more general question.

Agreed.

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 24 Apr 2003 11:09:41 +0200

Dear all,

I am under the impression that the "discussion" started
by Mark is a "pseudo"-discussion, more for the sake of
having a discussion than making a point.

Suppose three degrees of freedom (as transport protocol): 
	1.TCP, 
	2.plain SCTP, 
	3.PR-SCTP.
For an application that wants to transmit all data reliably,
it will be able to choose from either of the three, and
in the case of PR-SCTP specify an infinite lifetime, i.e.
reliable delivery, of all data (essentially the same as plain
SCTP). Of course, the application may profit from SCTP multi-homing,
especially in the case where congestion occurs, and retransmission
go along a different, otherwise idle path.

Now, things become interesting for applications that make use
of the unreliable delivery feature, and specify a lifetime
for data to be sent. 
Will this be an incentive for applications to sent more data ?
The applications cannot be sure that the data is NOT sent
over the wire, a priori, so any data submitted to the transport
PR-SCTP may or may not be sent, and therefore may, in the worst 
case *for the application*, hurt the application's congestion 
window. I don't think this is an incentive for applications
to send "junk" data (or data that better not be sent).

As retransmissions are more likely to occur in situations
where the network experiences congestion, PR-SCTP may relieve
this congestion compared to plain SCTP or TCP, where TCP will 
insist on retransmitting the data to the same transport
address. Plain SCTP may do the same (in case associations are
single-homed), and will still put more load on the network
than PR-SCTP (in case associations are multi-homed and use distinct
phiysical paths).

So, is PR-SCTP a bad thing ? I do not think so, for the 
above reasons. It will relieve the network over the long run.

My 2 cents.

Andreas

- -- 
Dipl.-Ing. Andreas Jungmaier              
Computer Networking Technology Group     
University of Duisburg-Essen                       
http://www.exp-math.uni-essen.de/~ajung   
My PGP Key-ID: D3824AC0             

My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 4AC0

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 25 Apr 2003 11:15:54 -0500

On 4/23/03, Spencer Dawkins wrote:

>If an application gives clues to transport that something
>isn't as interesting as something else, how is this
>different from per-packet priority marking?

Actually PR-SCTP is very different from per-packet priority
marking in several important ways:

-- Per-packet priority marking could be used by network
   elements to drop packets themselves. PR-SCTP only
   drops packets in the sending service, and only drops
   retransmissions.
   
-- Because drops are done by the sending service, the
   set of packets dropped can be done in a service sensitive
   fashion and based upon dynamic information not available
   at the time the packet was originally sent.
   
While at first glance it might seem preferable to allow the
network elements forced to drop packets in the face of
congenstion to be given hints on which packets to drop.
But to be effective, such hints would have to be available
on *most* of the packets going through the element.

PR-SCTP is effective in optimizing an applications response
to network congestion, no matter how many or how few other
competing users are employing the same or similiar
algorithms. Keep in mind that the purpose of dropping
a packet for retransmission will typically be to avoid
holding up more critical data that would otherwise be
behind the retransmitted data.

The sending PR-SCTP service can also consider many factors
in determining which data to abandon retransmission of, not
all of which could be translated to a per-packet priority:

-- When the data must be received to be useful. The primary
   example of this is being streaming media delivery.
   
-- What portion of a useful work unit the dropped data was.
   For example, it makes more sense to retransmit one packet
   that will complete 17 other packets that made it, rather
   than to retransmit a packet that was part of a message
   that had been totally lost.
   
-- The importance of the data to the receiver. Many lossy 
   encoding schemes can employ a pyramid encoding, where
   a few data chunks can give a crude picture, and later
   chunks refine the quality of the image. Obviously 
   there would be little need to retransmit the refining
   chunks in preference to the base chunks.
   
In all likelihood, PR-SCTP services will only support a
comibniation of SCTP message integrity and a timed
expiration. But the draft is quite explicit that the sending
service is free to provide other value added services, and
free to evolve them over time.

So PR-SCTP can be implemented by any two peers, and the
"drop selection" algorithm can be refined by the sending
service at any time.

A packet-priority scheme would sit around for a long time
before network elements actually implemented it, and once
implemented it would be frozen.

So I would say that PR-SCTP is quite a bit friendlier to
both the network and application than packet priority
marking.

Caitlin Bestler

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 25 Apr 2003 14:01:41 -0600

Caitlin,

>    drops packets in the sending service, and only drops

Correct me if I'm wrong, but is not a PR-SCTP implementation
also allowed drop packets that have exipired before they are
transmitted for the first time (i.e due to congestion)?

--brian

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 25 Apr 2003 15:16:37 -0500

On 4/25/03, Brian F. G. Bidulock wrote:

>Correct me if I'm wrong, but is not a PR-SCTP
>implementation also allowed drop packets that have
>exipired before they are transmitted for the first time
>(i.e due to congestion)?

It's after a TSN has been assigned. So it would depend on
when the implementation assigned TSNs. But you are correct
that theoretically a service *could* assign a TSN and then
drop it before sending it even once.

Caitlin Bestler

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 25 Apr 2003 13:19:51 -0700 (PDT)

Dear Caitlin,

I think I knew most of this, but it's a REALLY good summary!
Thanks for the clear explanation. 

Spencer

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 25 Apr 2003 14:20:09 -0600

Caitlin,

Section 4.1 of draft-stewart-tsvwg-prsctp-03.txt says:

    TR3) Before assigning a TSN to any message, the SCTP send MUST
       evaluate the lifetime of that message.  If it is expired, the SCTP
       sender MUST NOT assign a TSN to that message, but instead SHOULD
       issue a notification to the upper layer and drop the mssage.

So, I suppose it is wrong to say that only retransmissions are
dropped.  Even transmissions will be dropped *before* assigning a TSN.

--brian