[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
- To: "'philippe.gentric@philips.com'" <philippe.gentric@philips.com>, "Phelan, Tom" <tphelan@sonusnet.com>, "'Rosen, Brian'" <Brian.Rosen@marconi.com>
- Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
- From: "Phelan, Tom" <tphelan@sonusnet.com>
- Date: Thu, 20 Nov 2003 13:04:29 -0500
- Cc: "'avt@ietf.org'" <avt@ietf.org>, "'dccp@ietf.org'" <dccp@ietf.org>, "'mmusic@ietf.org'" <mmusic@ietf.org>
- List-help: <mailto:dccp-request@ietf.org?subject=help>
- List-id: Datagram Congestion Control Protocol <dccp.ietf.org>
- List-post: <mailto:dccp@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/dccp>,<mailto:dccp-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/dccp>,<mailto:dccp-request@ietf.org?subject=unsubscribe>
- Sender: dccp-admin@ietf.org
Hi Phillipe,
The situation I'm worried about is a little different than you describe.
Say you have a 10M bps link, over which there's a 4M bps video stream and a
long-lived TCP app. The TCP app will take the remaining 6M bps, and then
push for more, which might cause the video stream to lose packets. The
video stream then drops to 2M bps, and the TCP app expands to 8M bps. This
hardly seems fair.
The video app can protect itself from this by transmitting enough more than
4M bps to buffer itself against the TCP probes. In this case we'd come to a
relatively steady state where both apps are sending roughly 5M bps. This
seems reasonably fair to me, since the TCP app gets what it would get if it
were competing with other TCP apps, and the video app gets to send at its
full rate.
Tom P.
> -----Original Message-----
> From: philippe.gentric@philips.com
> [mailto:philippe.gentric@philips.com]
> Sent: Thursday, November 20, 2003 12:23 PM
> To: Phelan, Tom; 'Rosen, Brian'
> Cc: 'avt@ietf.org'; 'dccp@ietf.org'; 'mmusic@ietf.org'
> Subject: RE: [AVT] RE: [MMUSIC] DCCP Media Guide
>
>
> Brian, all,
>
> It may provide some help in understanding the situation
> to describe your exemple as follows:
>
> * you send video at 4 Mb/s, good.
>
> * it happens that you are competing with (a lot of ) TCP
>
> AND that you want to be fair to it:
>
> * so when that happens you decrease your rate to 2 Mb/s for "a while"
> because otherwise you are not fair.
>
> * but at some moment you will want to come back up to 4 Mb/s right ?
>
> => the point is that the **only way** to know if you "can"
> do that, is to try it....
>
> regards,
>
>
> Philippe Gentric
> Chief Architect
> Philips Software
> philippe.gentric@philips.com
> http://www.software.philips.com
>
>
>
>
>
>
>
>
> To:
> "'Rosen, Brian'" <Brian.Rosen@marconi.com>
>
> cc:
> "'dccp@ietf.org'" <dccp@ietf.org>
>
>
> "'avt@ietf.org'" <avt@ietf.org>
>
>
> "'mmusic@ietf.org'" <mmusic@ietf.org>
>
> "Phelan, Tom" (bcc:
> Philippe Gentric/MP4-SUR/CE/PHILIPS)
>
> <tphelan@sonusnet.com> Subject:
> RE: [AVT] RE: [MMUSIC] DCCP Media Guide
>
>
>
>
> Sent by:
> Classification:
>
> mmusic-admin@ietf.org
>
>
>
>
>
> 20/11/2003 17:47
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> > >
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
_______________________________________________
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