[e2e] TFRC vs UDP

[Cannara]

The problem with all of these "The transport does what the network should do"
bandaids is that they're just that.  Combine dealing with congestion at the
wrong layer, in naive ways, with the traditional lack of standards review and
source control, and that's given us our wonderfully insecure, spam-ridden
Internet.  What we have today is barely a networking existence proof, after
spending many millions of taxpayers' $, over about 30 years for certain
'researchers' and their grad students to write papers, convene around the
world and 'invent' rather than engineer protocols.  This is not meant as a
criticism of DCCP, TFRC, etc., just a commentary on the vast difference
between a subsidized, poorly-managed, self-involved, bureaucracy-stunted
Internet and something elegant, economical, efficient and worthy of general
pride, like Ethernet quickly became as has remained.  :]

The just out "E2E Vision" draft says this, perhaps inadvertently, by
suggesting that we need a "vision" for data communications for the next "10-15
years".  Well, yes, we needed it 10-15 years ago, when serious protocol R&D
was stopped -- without properly addressing 'minor' details, like congestion,
or even node addressing.  The Vision doc also exhibits the Internet
bureaucracy's traditional NIH approach, as in:

"The older members of the data communications research community spent some of
their formative years in the time when data communications was being
revolutionized by the creation of a new paradigm: packet switching. While
packet switching is now an accepted, indeed, lauded way to think about data
communications, into the early 1980s it was still a radical idea and into the
1990s required periodic justification."

leading newer readers to think the Internet folks invented packet switching.
This self-serving comment isn't even approrpiate in a "vision" document, but
it reflects the tradition of maintaining ignorance that any bureaucracy
depends on to avoid scrutiny.  After all, TCP/IP folks then apparently never
even knew what a MAC was, because the IMPs on their Unix boxes somehow used
phone lines to get to other IMPs on other Unix boxes.  They apparently didn't
even understand why they should have lauded things like Ethernet, Znet,
CromemcoNet, CorvusNet, XNS, SNA, yadda, yadda, which in the '70s depended not
on the public dole from DARPA, but real corporate investment in efficient
networking systems.  Though not being a great IBM fan, I do have to admit to
knowing no one who ever hacked an SNA network, but someone probably did
something, once, and it was likely harder that getting Sendmail to execute
remote code.

What a "Vision" doc could say, to be more trustable than a Carl Rove memo, is
maybe:  "Today's Internet has demonstrated that open, international network
communication, at will, is a realizable goal.  Unfortunately, lack of proper
engineering attention to certain areas has also exposed shortsightedness on
the part of its designers.  For example, a mistaken trust in human nature has
left our Internet and all its users exposed to extremely serious issues:
insecurity, denial of service, unwanted traffic, lack of efficiency, economic
barriers, all manner of traditional scams, and even heightened potential for
identity loss.  The vision for the Internet now should be to move beyond its
existence-proof phase and into the realm of a safe, reliable, economical and
responsible utility."

Anyway, it's interesting and encouraging that we at least have some folks
concerned about the future.  I hope rocking the boat is on their agenda.

Alex

"Phelan, Tom" wrote:
> 
> Hi Syed,
> 
> DCCP includes TFRC as one of its congestion control algorithms, and there has been quite a bit of discussion in the group of the impact of TFRC on streaming media applications.  The DCCP User Guide contains an extensive discussion of the issue.  Unfortunately, it's timed out of the drafts archive as we work out the future course of the guide, but it's available at http://www.phelan-4.com/dccp/draft-ietf-dccp-user-guide-02.txt.
> 
> Tom Phelan
> 
> > -----Original Message-----
> > From: end2end-interest-bounces at postel.org
> > [mailto:end2end-interest-bounces at postel.org]On Behalf Of Syed Faisal
> > Hasan
> > Sent: Thursday, March 31, 2005 8:37 AM
> > To: gdc at iki.fi
> > Cc: end2end-interest at postel.org
> > Subject: Re: [e2e] TFRC vs UDP
> >
> >
> > Hi Dado,
> >
> >
> > >Syed Faisal Hasan wrote:
> > >>
> > >>To whom it may concern,
> > >>
> > >>TFRC was designed for use by the Continuous Media (CM)
> > applications. But
> > >>why will a CM application which is performing well using
> > UDP, use TFRC if
> > >>there is performance gap (more latency, less number of
> > packets transmitted
> > >>in the same time, high rate fluctuations in the beginning)
> > betwen UDP and
> > >>TFRC ? May be thats the reason we haven't seen any
> > applicatons using TFRC.
> > >>On the other hand there is no (I haven't found) research
> > which analyzes
> > >>the performance difference between UDP and TFRC. It is
> > clear that TFRC
> > >>will not perform exactly like UDP ( due to TFRC's
> > friendliness with TCP),
> > >>but how much can we expect from TFRC?
> > >
> > >
> > >Hi Syed,
> > >
> > >the motivation is that although your application would work
> > fine and you (a
> > >single person in a society) would have a good welfare using
> > UDP, it is your
> > >fellow citizens that would potentially suffer from your actions. The
> > >network resource should be distributed fairly - whatever it
> > means. If we
> > >all started to disregard other users, the network might stop working
> > >properly - equivalent to anarchy in a society. Mechanisms
> > are needed to
> > >guarantee fair distribution of the resource. TFRC attempts
> > to provide
> > >mechanisms to distribute the bandwidth resource in the same
> > way TCP does.
> > >
> > >I think performance issues depend more on competing TCP
> > flows and the
> > >network than on the TFRC control algorithm.
> >
> > I understand what you are talking about. But I want to know
> > the performance
> > difference of
> > UDP and TFRC in the same scenario. Is there any published
> > research on this?
> >
> > Faisal