[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide

At 11:47 AM 11/20/2003 -0500, Phelan, Tom wrote:

<snip>


I don't think I'm forcing the problem to fit the solution, just perhaps that
the problem I'm trying to solve is different than you perceive.  The problem
that I'm trying to solve is how can an application that is content with a
maximum bandwidth compete with TCP applications that are insatiably greedy,
in a way that satisfies some concept of fairness in all directions?

The solution that I see is to provide a buffer against TCP probing.  This
would involve sending more data than is nominally necessary.  If the network
has capacity for more than 4M bps, then why shouldn't a media app make use
of it?  A TCP app would.
<snip>

I think this snippet captures the essence of the argument.

An "insatiably greedy" TCP application has an infinite amount of data to
send. And "fairness" in "TCP-land" is ONLY FAIRNESS IN INSTANTANEOUS
BANDWIDTH ALLOCATION (across TCP/DCCP/SCTP connections/associations).

This is historically how TCP has been viewed. But wait ... if you delay
the "infinite amount of data" in the TCP socket .... what bad happens?
Nothing, it just takes longer (from a "work conservation viewpoint") to send
the data. Did TCP suffer? Well ... it got less work per unit time ... but
nothing really bad occurred for the "insatiable TCP" case.

Most real-time data is DELAY SENSITIVE. To real-time data ... it would be
"fair" to delay some of the TCP data during it's bursts (like some video codecs
have when a high-entropy scene change occurs). That is because TCP
can afford to "wait a little longer" to get it's data across. The bursts are usually
bounded in time (a talkspurt, a scene change, etc.) ... and TCP can usually
afford to wait through these bursts. From the real-time application's perspective
they are being "good citizens" by not using bandwidth when they don't
need to (during VAD/silence or no video scene changes). Can't the TCP apps
step aside for a moment and acknowledge their good citizenship?

To be fair ... we really need to re-evaluate the issue of "fairness" capturing more
than just an INSTANTANEOUS BANDWIDTH ALLOCATION dimension. Is it "fair"
to slow down TCP more than present mechanisms allow? For a "insatiably greedy"
TCP connection the answer may be yes. For a TCP session with a reasonably
bounded amount of data the answer maybe no - because there is a linear
relationship with how long the data will take to get to the other side and
the slowdown rate.

This is a really tough problem.

Why this post? Simply because I'd desire each camp to widen their vision
of what is "fair/right/best" from their own myopic point of view. TCP'ers should
try to capture the spirit of Brian's comment ... that "forcing the problem
to fit [TCP's view of] a solution" is not appropriate. And that is, in fact, what
I perceive all the well-intentioned "TCP rate control" crowd to be doing here.

Please widen your perspective of the problem. Then comment. Don't expect
people like Brian to be happy with the "you must fit in to TCPs view of the
world" when most of their real-time applications are already being good
citizens (by not sending "all they can" when they don't have to). Do you
like being further punished because you weren't greedy when you could
have been?

Michael Ramalho


_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info: https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html