Re: Why do we need congestion control?

Hi，

 I found two papers which state that with ideal fountain code,there is
generally no congestion collapse.Efficiency remains higher than 90% for
most network topologiesas long as maximum source rates are less than link
capacity by one or two orders of magnitude. Moreover, a simple fair drop
policy enforcing fair sharing at flow level is sufficient to guarantee 100%
efficiency in all cases. I refer to several papers on the congestion
problem when fountain code is used. [1] [2]


[1] Bonald, T., M. Feuillet, et al. (2009). *Is the''Law of the
Jungle''Sustainable for the Internet?* INFOCOM 2009, IEEE

[2] B. Raghavan and A. Snoeren. Decongestion control. In HOTNETS-V,
2006.


2013/3/7 RAMAKRISHNAN, KADANGODE (K. K.) <[email protected]>

> I want to second what Jon and Keshav say with regard to the assistance
> provided by coding, but the limitations that arise in an environment
> without effective congestion control.
>
> We'd explored the benefit of coding (admittedly simple R-S codes) at the
> end-end transport layer to complement TCP, so as to help sustain losses on
> wireless links, in our work on LT-TCP.
> We did see the benefit of coding, to extend the dynamic range of transport
> protocols to tolerate higher loss rates, but only up to a point. Beyond
> that, you see the same results as you would see in an uncontrolled
> environment where losses (and the resulting wasted work) begin to dominate
> the utilization of the resources in the network. That is without paying
> attention to the delays that result from excessive losses that cause the
> receiver to wait to reconstruct a block.  There is still the need for
> reasonable congestion control mechanisms to keep from causing excessive
> losses. And Keshav's point of the unfairness across flows in the short term
> and the eventual result of everyone losing out is certainly important to
> keep in mind.
>
> Finally, I heartily agree with Jon's last point regarding ECN...
>
> --
> K. K. Ramakrishnan                  Email: [email protected]
> AT&T Labs-Research, Rm. A161        Tel: (973)360-8764
> 180 Park Ave, Florham Park, NJ 07932    Fax: (973) 360-8871
>       URL:
> http://www.research.att.com/people/Ramakrishnan_Kadangode_K/index.html
>
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of Jon Crowcroft
> Sent: Wednesday, March 06, 2013 10:03 AM
> To: shun cai
> Cc: [email protected]; [email protected]
> Subject: Re: [e2e] Why do we need congestion control?
>
> ok - i see your point - this is true if your sources have a peak rate they
> can send at
>
> this could be the line rate of their uplink  -
> that would be embarrasingly bad
> (see keshav's followup on escalating costs of coding)
> or the rate they can get data off disk (which could be as bad, but might
> be lower)
> or an application specific rate (e.g. streamed video) for which you're
> suggestion is
> quite reasonable....
>
> but for data sources which are greedy
> (TCP with arbitrarily large files)
> you need a way to tell sources a non wasteful way of sending -
>
> and what is more
> there isn't just one set of sources in one location
> and a set of sinks in one other location
> so the system of senders sending at
> unconstrainted rates on a finite speed net with high speed edges,
> would create multiple bottlenecks,
> which would exponentiate the problem
>
> coding isn't magic - its info theory - if you lose info
> you must add redundency - coding does it pre-emptively
> rather than post-hoc the way ARQ/Retransmit does,
> which saves you time, but in the end, can't defer the inevitable
>
> if you look at digital fountin systems for video
> they pick a likely loss rate, pick a tolerable picture degradation rate
> and use those to derive/choose a code
>
> the assumption is that the losses are capped because most other systems
> are backing off just like TCP - if you break that assumption,
> you'll break the coding parameter choice
>
> anyhow, roll out ECN - much betterer technology:)
> congestion avoidance without keeping queues filled everywhere...
>
>
>
>
>
>