[e2e] Answer to Dave Reed Re: Fwd: Re: Question the other way round:
faber at isi.edu
Sat Nov 23 13:15:04 PST 2013
On 11/23/2013 11:10, Detlef Bosau wrote:
> Am 22.11.2013 23:34, schrieb Ted Faber:
>> On 11/22/2013 13:03, Detlef Bosau wrote:
>>> Actually, causing congestion is part of the VJCC congestion handling,
>>> and exactly this is the problem!DecBit,
>> ECN, Vegas, FAST, XCP...
> TCP with ECN does not cause congestion? Vegas does not cause congestion?
Those systems significantly mitigate the effect of network probes on
I took your statement about "VJCC causing congestion" to mean you took
issue with the endpoints slowly opening their windows to probe the
network state and the effect of that probing on network queues and
consequently on other flows. The work I mentioned is part of a large
body of work focused on reducing the effect of such probes. Since I
didn't mention anything that isn't more than a decade old, I didn't
think citations were necessary.
> Why does TCP nead an Explicit Congestion Notification, when there is no
I'm surprised that you're asking these questions, if you're familiar
with the work, but here's an explanation:
Despite the name, ECN is not a "congestion" notification, but data about
queue occupancy along the path a packet took. A router implementing ECN
just marks a packet that would have been dropped under an early discard
queueing discipline (e.g., RED). RED discards packets before congestion
sets in (Random Early Detection) in order to slow down loss-reactive
flows before the network experiences congestion collapse. ECN mitigates
RED's effect on loss rate by making the drops virtual (packets are
marked instead of dropped), informing sources to slow without making
them retransmit the "lost" packet.
Now, you may take the position that any queue occupancy is congestion,
but if so, I think the significant benefits of store and forward routers
argue persuasively against that position.
Unexpected attachment on this mail? See
More information about the end2end-interest