Cristicism of current TCP:
- oscillatory and instable
- AIMD limits sender to acquire only one more packet of bandwidth per RTT
- biased against long RTT flows (e.g. satellite connections need ad hoc methods like proxies)
- congestion notification only implicit through packet loss: no distinction between error and congestion loss, long time until packet loss identified
- Arguments from Control Theory (though more often cited than used ;-)
- Simulation
- Rethinking the transport protocol without requiring backward compatibility
- no per-flow state
- separation of utilization/efficiency and fairness control
- detects misbehaving sources
- provides incentive to both: users & ISPs
- gradual deployment schemes discussed
- new protocol supersedes TCP: eXplicit Control Protocol
- XCP congestion header informs sender about degree of congestion rather than having only 1-bit explicit congestion notification or packet loss
- XCP header includes congestion windows size and RTT (set by sender), gateways can modify the feedback field
- receiver sends XCP header back to sender, sender uses feedback to set new congestion window
- if a gateway sees spare bandwidth or overutilization, it picks a couple of packets randomly and sets their feedback field to compensate (not necessarily in a fair manner): efficiency control
- pairs of flows are picked, the feedback fields are set to take some feedback of the higher-bandwidth flow and give it to the lower bandwidth flow, this will eventually converge to fairness: fairness control
1 comment:
Hey, I like this bullet format!
Post a Comment