Do we need congestion control in the future Internet?

1The 1st European Teletraffic Seminar (ETS), 15/02/2011 Poznan

High Speed Networks Laboratory

Do we need congestion control in the future Internet?

Sándor Molnár

Department of Telecommunications and Media Informatics

Budapest University of Technology and Economics

Sándor Molnár <[email protected]>

The 1st European Teletraffic Seminar (ETS), 15/02/2011 Poznan 2

Outline

• Motivation

– What is the problem with TCP?

– Go for a clean slate research: forget TCP!

• Living without congestion control

– A solution proposed

– Results investigated

• Conclusions


What is the problem with TCP?

• 35 years of evolution of TCP versions with 20 years of evolution of congestion control– Most of the versions were born by incrementally

tuning the previous version

– The control always has a price: utilization, fairness, etc.

• Lesson learned: to find an universal solution seems to be hopeless– Why? Environment is heterogeneous:

• High speed

• Lossy links


Do We Need Congestion Control?

• Example: wireless

– Packet losses are not due to congestion but due to random channel errors

– Packet losses can be handled at link layer

– No need for TCP

• What if packet loss is really due to congestion?

– The control can be avoided even in this case!


Inspiration

• Forget problematic TCP

• Find alternatives to congestion control

• GENI’s proposal in 2007

“Living Without Congestion Control”


Related research

• R. Kempter, B. Xin and S. K. Kasera, "Towards a Composable Transport Protocol: TCP without Congestion Control", ACM SIGCOMM 2004, Poster Session, August 30-September 3, Portland/Oregon

• B. Raghavan and A. Snoeren, "Decongestion Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006.

• T. Bonald, M. Feuillet and A. Proutiere, "Is the "Law of the Jungle" Sustainable for the Internet?",INFOCOM 2009, Rio de Janeiro, Brazil, 2009.


Proposal

• Every application sends its data as fast as it can

• If there is no congestion in the network

– The best possible solution!

• Otherwise

– By employing efficient erasure coding application data can be restored

• Stop sending when data is reconstructed


Advantages

• Efficiency

– max performance: hosts sends at full rate

– network resources are maximally utilized

• Simplicity

– get rid of the burden of control

– routers can be simplified: no need to buffer all data packets, e.g. bufferless all-optical switches can be used

• Stability

– frequent rate variations caused by traditional congestion control algorithms can be avoided

• Robustness

– greedy sources cannot take control


Challenges

• Packet losses

– use efficient erasure coding

• Fairness of flows

– use selective packet dropping techniques at routers e.g. Approximate Fair Dropping

• Dead packets

– use control channel to inform routers or senders


Do we have efficient erasure codes?

• Reed-Solomon codes (1960)

– encoding/decoding works only for small (N, K)

– code rate must be set before transmission but erasure probability is not known in advance

• Tornado Codes (1997)

– less efficient than RS codes but can be much faster

• Rateless codes

– Luby Transform (1998)

– Raptor codes (2001)


Raptor codes

• Fountain codes

– The source data k can be reconstructed from any subset of the encoding packets (1+ε)k

– Linear time encoding and decoding


Rateless FEC-Based Transmissionk

n

(1+ε)k

c1

c2

cN

cB

r1

r2

rN

Maximal rateAll times

Fair Dropping0

n

k

ε= 5-10%


Rateless FEC – Raptor

• Linear time complexity, software solution

ε= 5-10%• Every packet is useful, (1+ε)k

• Robust operation, heavy congestion


Rateless Goodput

Goodput of flow i)1(

1

i

Bi

N

CG

c1

c2

cN

cB

Fair Dropping

ε= 5-10%

100 MB

100(1+ε) MB


Rateless FEC vs. TCP

• Comparison metric: equivalent redundancy

N

C

T

DG

i

B

i

ii

)1(

1ND

CT

i

Biequ

Goodput of flow i:

• Example:

εmin=5%

εequ=13%

gain=8%

TCP goodput Rateless goodput


Long Scale Data Transfer Results

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

100 300 500 700 1000

Equ

ival

en

t R

ed

un

dan

cy

Bottleneck Link Capacity [Mbit/s]

CUBIC 1BDP CUBIC 0.1BDP CUBIC 0.01BDP

Compound 1BDP Compound 0.1BDP Compound 0.01BDP

1800 seconds, averaged data transfer (equivalent redundancy)


Medium Scale Data Transfer Results

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

100 300 500 700 1000

Equ

ival

en

t R

ed

un

dan

cy




470 megabytes, last download time (equivalent redundancy)


Small Scale Data Transfer Results

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

100 300 500 700 1000

Equ

ival

en

t R

ed

un

dan

cy




1 megabyte, last download time (equivalent redundancy)


10 Gbit Network Scenario (Medium Scale)

0

0,2

0,4

0,6

0,8

1

1000 3000 5000 7000 10000

Equ

ival

en

t R

ed

un

dan

cy

554,86% 456,28% 594,21% 541,20% 404,79%

0%

20%

40%

60%

80%

100%

120%

140%

160%

180%

200%

1000 3000 5000 7000 10000

Rat

e In

cre

ase


CUBIC 0.1BDP CUBIC 0.01BDP CUBIC 0.001BDP

Compound 0.1BDP Compound 0.01BDP Compound 0.001BDP


Rateless FEC-Based Scenario II.

Maximal rateON-OFF sources

Asymptotic results

i

i

B

OFFON

ON

i

OFFON

ON

Bit

OFFON

ONit

GN

C

N

CtGE

tP

)1()1(

))((lim

)(lim

Key Renewal Theorem

k

n

(1+ε)k

c1

c2

cN

cB

r1

r2

rN

Fair Queuing


Conclusion

• Proposed solution outperforms TCP especially in case of high speed and small buffer scenarios

• High potential: all-optical networks

• Ongoing research: testbed implementation

• Several challenges are still needed to be addressed for practical implementation

Date post:	03-Feb-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Do we need congestion control in the future Internet?

Documents