Subject: Re: [Tsvwg] pr-sctp

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

Mark, I agree that this explanation is a lot more clear than your previous ones.    However I still don't think you have made your case, or at least, your case isn't clear to me.  (If it is clear to others, please help me understand it.)

More comments below...

At 11:59 AM 4/4/2003 -0500, Mark Allman wrote:
>
>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...
>
>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.

You note that there is a disincentive to sending junk data in regular TCP/SCTP (i.e. spending buffer space, cwnd, etc.).  But you imply that this disincentive is NOT present with PR-SCTP.    That's where I think we have a difference in understanding, becuase I claim that the same disincentives to send junk data apply equally to PR-SCTP.  Specifically, I note that: 

* Every chunk you send with PR-SCTP consumes rwnd and cwnd space.    

* PR-SCTP does NOT result in putting any more data on the network than if you did NOT have PR-SCTP.  It is only a question of "which" data goes on the network.

Look at it another way: TCP-friendliness enforces that each transport sender gets some "share" of the bandwidth on the network.   How a given application chooses to use that share is up to that application.  PR-SCTP gives the application more flexibility in how it chooses how to use that share... meaning that it can make decisions on the fly about diverting some of that share from a message that is already in the sequence number space to a new message that is not yet in the sequence number space.

I don't see how that creates an incentive to send junk data.  I'm not saying with 100% certainty that it isn't there, but the more we talk about it, the less worried I get.   Maybe there is an argument that I just haven't seen or understood yet.

Now in response to your comments about "circling the wagons"...   see below. :-)

>At 12:57 PM 4/4/2003 -0500, Mark Allman wrote:
>>I should re-phrase... I think there *is* an incentive for apps to
>>pollute the network with junk data caused by PR-SCTP.  What I am not
>>sure of, yet, is how much we should really care about it.  I.e., how
>>big of a deal is it?  But, I *would advocate* understanding it
>>before sending it out and then waiting for the paper (from Stefan
>>Savage, no doubt!) on how to game SCTP for fun and profit.  (And, I
>>have been somewhat disappointed thus far because I see some folk
>>"circling the wagons" to "protect" SCTP rather than trying to help
>>figure out if this is a real issue or it is just me being paranoid
>>(which is a fine result, BTW).  (My guess - without reading your
>>note - is that you have not done that.))

I don't know if it was deliberate or accidental, but your last phrase is marvelously
ambiguous..  do you mean that your guess is that I have not "circled the wagons", or your guess is that I have not "help[ed] to figure out if this is a real issue"?   (You can leave
this ambiguous if you like... :-) ).

Well, in any case, a accusation that the PR-SCTP advocates are "circling the wagons" sounds a bit light an invitation to up the rhetoric a little bit, but  Mark, since I consider you a friend, I'm not gonna take the bait.    Well, what the heck, maybe I will, trusting that you'll see this as a friendly jab rather than an invitation to a flame war.

I don't think we are circling the wagons at all.  I think we are trying honestly to understand what your fear is that PR-SCTP creates an incentive to send junk data... which, if it could be argued convincingly, would be a reason to pause and reflect.       But so, far, if you'll forgive me for saying so, your criticism that PR-SCTP creates an incentive to send junk data without a clear explanation of how that occurs feels a little bit  like a "fear uncertainty doubt" attack.    That's why I sent my much longer note with some specific application scenarios where I think I've made a case that PR-SCTP does just the opposite: it helps applications _reduce_ junk data on the net.    

The bottom line is that if you are being TCP-friendly, you have a "share" of the network resources.    How you use it is up to you.  If you waste your share, that's your own funeral, because TCP-friendliness limits your impact on others.

How much worse would it be if (in the absence of PR-SCTP) you had to open, for example, two separate connections: say, (1) a TCP or SCTP connection/association for the reliable data, and (2) a TCP-friendly UDP flow, or at somepoint in the future, a DCCP connection for the other data.

Now you have to implement your own reliability on top of connection flow (2) and further, you have increased your share of the bandwidth by having two tcp-friendly flows rather than one.    Seems like a lot more waste to me.  

(Obligatory concession: yes, I know that if we all implemented an end point congestion manager type solution, that last point would be invalidated.   Seems unlikely though.) 

Thanks,
Phill 

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

---

From: Phillip Conrad <[email-masked]>
Date: Sat, 05 Apr 2003 00:43:21 -0500

I want to apologize to Mark Allman for inadvertently responding to a private note on the open list.

This was an honest mistake on my part; Mark's note was a response to mine, and so had [tsvwg] in the subject line.   I mistakenly concluded that it was an on-list reply; I should have looked more carefully at the header before responding.

Sincerely,
Phill Conrad

---

From: Mark Allman <[email-masked]>
Date: Mon, 07 Apr 2003 00:24:56 -0400

> This was an honest mistake on my part; Mark's note was a response
> to mine, and so had [tsvwg] in the subject line.  I mistakenly
> concluded that it was an on-list reply; I should have looked more
> carefully at the header before responding.

Thank you, sir.

allman

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