[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
To me, this is just nonsense.
I can't imagine anyone deploying such a solution.
This is forcing the problem to fit the solution, and it's not
the right way to go. If you want it to work, the protocol
has to take the characteristics of the flows as they are, and not
as you would like them to be. Real time media, streaming or realtime,
is either constant bit rate, or pretty close to it. That's how it
works. Our challenge is to make the protocols work with this data,
not change the data, especially silly ideas like doubling the bandwidth.
We make video telephones. They nominally send 4 megabits. Would
you like us to double that, under any circumstances?
I thought not.
Brian
> -----Original Message-----
> From: Phelan, Tom [mailto:tphelan@sonusnet.com]
> Sent: Thursday, November 20, 2003 10:36 AM
> To: 'Jonathan Rosenberg'
> Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org'
> Subject: [AVT] RE: [MMUSIC] DCCP Media Guide
>
>
> Hi Jonathan,
>
> Thanks for the comments. The actual proposal is to send up
> to double the
> nominal transmit rate when there's available bandwidth, and
> to reduce the
> rate as necessary if there isn't enough bandwidth. This
> doubling is to
> allow fair sharing of the chokepoint bandwidth (between DCCP
> media apps and
> TCP apps), and to avoid what appears to me to be the
> potential for bullying
> from TCP applications that want to suck up all the bandwidth
> they can. It
> doesn't preclude using low-rate codecs, or mean that the
> access link must
> support the double rate for the connection to function well.
>
> This recommendation was meant for best-effort environments,
> where the voice
> traffic receives no special treatment, and must compete with
> TCP apps for
> network resources. I can see how this would require a
> network that gave
> special treatment to voice packets to provision double the
> capacity, though.
>
> This fairness problem is difficult. All of the research I'm
> familiar with
> approaches it from the direction of other apps being fair to
> TCP. I'm not
> aware of any other methods for ensuring that non-TCP apps get
> their fair
> share when competing with TCP. If you (or anyone else) knows
> of something
> I'd appreciate the pointer.
>
> Tom P.
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, November 20, 2003 2:32 AM
> > To: Phelan, Tom
> > Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org'
> > Subject: Re: [MMUSIC] DCCP Media Guide
> >
> >
> > Tom,
> >
> > I don't think this solution will be acceptable to many of
> the network
> > providers of interactive voip services. Many of them are
> insistent on
> > using low rate codecs, like g.723, in order to reduce the costs of
> > capacity in their networks. Doubling the rate would defeat
> > the purpose
> > of using these low rate codecs in the first place.
> >
> > -Jonathan R.
> >
> > Phelan, Tom wrote:
> >
> >
> > > Comments will be appreciated. In particular, I make the
> > suggestion that
> > > media apps should transmit at up to twice their nominal
> > maximum rate, when
> > > DCCP allows it, in order to provide protection from competing TCP
> > > applications. I know that the first time I heard someone
> > make a similar
> > > suggestion I was horrified, but as I developed the issues
> > it seemed to be
> > > necessary. Reactions to this will be appreciated.
> > >
> > > Tom P.
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > mmusic@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > Chief Technology Officer Parsippany, NJ
> 07054-2711
> > dynamicsoft
> > jdrosen@dynamicsoft.com FAX: (973) 952-5050
> > http://www.jdrosen.net PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
>
_______________________________________________
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