[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
Hi Brian,
Thanks for the comments. See inline ...
Tom P.
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Thursday, November 20, 2003 11:05 AM
> To: 'Phelan, Tom'; 'Jonathan Rosenberg'
> Cc: 'dccp@ietf.org'; 'avt@ietf.org'; 'mmusic@ietf.org'
> Subject: 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.
Would you prefer to be forced unnecessarily into packet loss and a lower
encoding rate by greedy TCP applications? Or do you have another solution?
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.
I must admit that my initial reactions to suggestions like this were very
similar to yours. I encourage you to look at the draft for more detail on
the issues that convinced me otherwise.
>
> 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