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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Nov 2003 15:27:05 -0500

Phillipe

You have made invalid assumptions:
	1. That audio/video media data rates will be changed dynamically
		as network traffic changes.  This is very unlikely.  It may
		be that you get so much loss that you drop to a lower data
		rate, although I suspect that will be rare.  When you do,
		you will never revert to the higher rate.  This is because
		humans hate to see the change, and minimizing changes is 
		more desirable than keeping average quality higher.

	2. Real Time apps have no interest in being "fair".  They are all
		or nothing. If you admit them to the network, you expect
		the streams to be maintained.  If you can't maintain them,
		don't start them.  They don't want to be fair to TCP, and
they
		don't want to be fair to other RTP.  They just want to send
		data at the rate they were advised to do by signalling.
		They can tolerate some loss.  Misordering=loss.  Duplicates=
		wasted bandwith.  That's a whole lot different from TCP
		traffic.  

I can imagine working on protocols which allowed CBR and "best effort"
traffic to better coexist, but I think it's only possible if the best
effort traffic recognized the presence of the CBR traffic and reacted
appropriately.  Otherwise, you need to use QoS mechanisms to separate
the traffic.

Brian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Thursday, November 20, 2003 12:23 PM
> To: Phelan, Tom; 'Rosen, Brian'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'
> 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
> [email-masked]
> http://www.software.philips.com
> 
> 
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
>                                                    To:   
> "'Rosen, Brian'" <[email-masked]>                    
>                 
>                                                    cc:   
> "[email-masked]'" <[email-masked]>                             
>                 
>                                                     
> "[email-masked]'" <[email-masked]>                               
>                      
>                                                     
> "[email-masked]'" <[email-masked]>                         
>                      
>                "Phelan, Tom"                        (bcc: 
> Philippe Gentric/MP4-SUR/CE/PHILIPS)                          
>                
>                <[email-masked]>              Subject:   
>  RE: [AVT] RE: [MMUSIC] DCCP Media Guide                      
>            
>                                                               
>                                                               
>            
>                Sent by:                            
> Classification:                                               
>                       
>                [email-masked]                          
>                                                               
>            
>                                                               
>                                                               
>            
>                20/11/2003 17:47                               
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> Hi Brian,
> 
> Thanks for the comments.  See inline ...
> 
> Tom P.
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Thursday, November 20, 2003 11:05 AM
> > To: 'Phelan, Tom'; 'Jonathan Rosenberg'
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > 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:[email-masked]]
> > > Sent: Thursday, November 20, 2003 10:36 AM
> > > To: 'Jonathan Rosenberg'
> > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > 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:[email-masked]]
> > > > Sent: Thursday, November 20, 2003 2:32 AM
> > > > To: Phelan, Tom
> > > > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > > > 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
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/mmusic
> > > > >
> > > >
> > > > --
> > > > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > > > Chief Technology Officer                    Parsippany, NJ
> > > 07054-2711
> > > > dynamicsoft
> > > > [email-masked]                     FAX:   
> (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: 
> (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/avt
> > >
> >
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Nov 2003 16:40:06 +0100

Hi Brian,

I don't think that the people working with stability of the network are 
sharing you view due to the implications that your claims results in.

First, if a multi-media application transmitting data over a best-effort 
IP network, i.e. without any QoS guarantees across the whole net that 
its traffic will fit, it can definitely cause congestion collapse if the 
mix becomes most, media, little TCP. Please read 
draft-iab-congestion-01.txt for some discussion on this.

Some comments to your assertions.

> 		more desirable than keeping average quality higher.

First you agree that it is possible to change the rate. Secondly I 
understand that the there are implications on switching rate, i.e. 
quality to often, however there are reasons for switching up when the 
quality gain of a switch if being possible to keep the new rate is clear.

> 		wasted bandwith.  That's a whole lot different from TCP

Yes, I agree that the application has no interest in being fair. However 
using best effort networks requires one to being reasonably fair. If one 
are not, the combination of several of media application can totally 
destroy things for them self.

> appropriately.  Otherwise, you need to use QoS mechanisms to separate

What says that the media traffic is more important that the traffic 
going over TCP?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 23 Nov 2003 13:28:46 -0500

On Fri, 21 Nov 2003 16:40:06 +0100
> draft-iab-congestion-01.txt for some discussion on this.

Dear Magnus;

Yes, I have read this. I also operate networks that are mostly UDP - typically 90%+ of the traffic.
I have never seen true congestive collapse on these networks. Never. 

The typical paper that I have seen that deals with post 1987 congestion collapse
hypotheses a UDP flow that is too large to fit in a end to end "pipe" that is subject to several
bottlenecks, with the second being smaller than the first. The UDP packets clog 
up the first bottleneck,
and are then dropped on the second. Since the packets dropped on the second bottleneck are wasted,
this lowers the goodput of the first bottleneck, in principle to as near zero as you want.

Note that this is very different from the 1987 congestive collapse where congestion causes
the number of retrials and control packets to increase, until they dominate the available 
bandwidth - and this "auto-congestion" causes the link goodput to vanish. This UDP congestion
collapse is _not_ a run-away situation like the original case.

From RFC896 :
-------
Even with the
better adaptive host retransmission algorithms, though, a  sudden
load on the net can cause the round-trip time to rise faster than
the sending hosts measurements of round-trip time can be updated.
Such  a  load  occurs  when  a  new  bulk  transfer,  such a file
transfer, begins and starts filling a large window.   Should  the
round-trip  time  exceed  the maximum retransmission interval for
any host, that host will begin to introduce more and more  copies
of  the same datagrams into the net.  The network is now in seri-
ous trouble.  Eventually all available buffers in  the  switching
nodes  will  be full and packets must be dropped.  The round-trip
time for packets that are delivered is now at its maximum.  Hosts
are  sending  each packet several times, and eventually some copy
of each packet arrives at its destination.   This  is  congestion
collapse.

This condition is stable.  Once the  saturation  point  has  been
reached,  if the algorithm for selecting packets to be dropped is
fair, the network will continue to operate in a  degraded  condi-
tion.   In  this  condition  every  packet  is  being transmitted
several times and throughput is reduced to a  small  fraction  of
normal.   We  have pushed our network into this condition experi-
mentally and observed its stability.  It is possible  for  round-
trip  time to become so large that connections are broken because
the hosts involved time out.
-------

This run-away collapse was what TCP Reno was introduced to fix. 

I have never seen a claim that excess UDP could cause this type of behavior in
the TCP + UDP system using modern TCP algorithms, and frankly regard
use of the term  congestion collapse in the present context as being misleading.

Again, I have never seen anything like this on a network I operate or monitor.
There can, of course, be "congestion events", where the TCP + UDP is overfilling the
available bandwidth. These stop immediately when the offending flows do.

Why is this not a problem in practice ? 

1.) For sources :
 
Because the throughput / goodput definition is arbitrary - it is a global metric, when
a local one would be more appropriate.

Suppose I am running a source network. I can easily arrange for the sum of all of my sources
to be < my link bandwidth. So, my network is always happy, at least outbound.

Let's say that I am sourcing high bit rate video. Let's say that for some reason every viewer
is trying to get these video's through a dial up modem. Now, they will not be happy, and the
vast majority of the outbound packets will be dropped at the user side.  

By definitions such as 

http://www.ietf.org/internet-drafts/draft-iab-congestion-01.txt
Section 3.1

my network is experiencing congestion collapse (most packets going out my links are wasted), even
though locally I can see no signs of it. (My clients may not be happy, and I may want to give
preference to non-dial-up users, but that is a different matter and I would argue out of scope.)

2.) For Sinks :

Because UDP flows (except for DOS attacks) are self regulating. If I try and put 10 Mbps of UDP
through a 30 kbps link, I will stop quickly.

I in fact see this all of the time - and I bet many people on this list have tried to 
watch a video through a connection at home or over a T1 only to realize that the 
packet losses are just too high and stopped the
process. This is clearly not a run-away situation and I would again argue that the use of the term
congestion collapse to describe it is inappropriate.

I of course, fully support the recommendations of draft-iab-congestion-01.txt
and elsewhere to drop UDP sessions or layers in the case of excessive loss, which tends to be set
very high (30% packet loss in the case
of draft-iab-congestion-01.txt, which is long past the point where most media players
will time out and users will leave in my experience).

Since we are not talking about a run-away collapse, then any problems that are not self
regulating can be dealt with administratively - which is common practice, especially
on college campus networks.

So we have

- Something that is not a run-away situation, despite the re-use of terms that may give that
impression and

- Something that exists on real networks and is dealt with routinely already without causing undue
problems.

> First you agree that it is possible to change the rate. Secondly I 

May be possible. There can be real costs in doing this, and it may not
be practical in many cases.

> destroy things for them self.

This is commonly said, but I would argue is routinely shown to be not true in practice.

> What says that the media traffic is more important that the traffic 

The network administrator decides this yeah or nay. Since there is no danger of
a run-away collapse, this is the appropriate level for this decision.

Even for TCP flows, there are all sorts of ways that network admins can and do show
preference, so fairness is something of an illusion there as well. 

It may well be that there are networks (say, mobile IP), where excessive use of UDP could
cause a true congestive collapse (i.e., a run-away of useless traffic). If so, then I would
argue that should be demonstrated clearly, and then be addressed for those networks
specifically. In the absence of this I would be very careful to impose apparently 
innocent conditions which, if actually followed, would kill most real time media distribution over
the Internet.

As I hate to complain without offering alternatives, here is my definition of UDP fairness and how
to achieve it :

UDP flows should not significantly increase the packet loss rate on any link that they transverse.
A UDP flow or flows from an application that 
do significantly increase the packet loss rate on a link MUST either be
dropped or reduced in bandwidth  on that link until the excess packet loss rate on the link is
reduced to an acceptable level.

Of course, averaging times and acceptable loss changes have to be defined - I would suggest
5 RTT's and 1%.

> Magnus Westerlund

Regards
Marshall Eubanks