[e2e] Answer to Dave Reed Re: Fwd: Re: Question the other way round:
detlef.bosau at web.de
Sat Nov 23 16:04:36 PST 2013
Am 23.11.2013 22:15, schrieb Ted Faber:
> Those systems significantly mitigate the effect of network probes on
> congestion, yes.
Certainly. Nevertheless, network congestion is reality and it is solicited.
Look at the discussion with David Reed and Jon Crowcroft.
Imagine a scenario:
pc 1 ------------------------ TP line -------------------------- pc 2
and perhaps two TCP flows from pc1 to pc2. So, you have two flows
sharing a line. And it would be useful to reasonably share the line.
E.g. by a scheduler. What are we doing instead? We induce network
Wouldn't it make sense to at least discuss alternatives?
> 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.
Is there a possibility to avoid those probes at all?
> 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.
ECN is one of the acronyms with several meanings.
One is "explicit congestion notification" in contrast to "implicit
congestion notification" (packet loss),
the other is "early congestion notification" and includes various
approaches, some of which make sense, while others are more or less
black magic. Years ago, some guys wanted to assess the load of a WiFi
cell by observing transport delay variations.
Of course, delay variations in WiFi may stem from many reasons, amongst
them are noise, congestion, movement......
and afterwards, a wise algorithm has a sixth sense to properly detect
THE very reason. Sometimes, it is a bit annoying to read approaches like
> A router implementing ECN
> just marks a packet that would have been dropped under an early discard
> queueing discipline (e.g., RED).
Yes. And particularly RED is one of the black magic approaches. Some
months ago, I read some work about coddle, which is proposed as some
kind of "self configuring RED". I don't know whether I still remember my
objections from that time, however, I'm not fully convinced.
O.k., IIRC coddle even discards packets under certain circumstances.
The problem with discarded packets is: Each packet discard is a possible
cause for a retransmission. Actually, a congestion collapse is in fact a
retransmission collapse. Hence, induced retransmissions are quite
similar to induced congestion.
> RED discards packets before congestion
> sets in (Random Early Detection) in order to slow down loss-reactive
> flows before the network experiences congestion collapse.
Exactly. So it "emulates" congestion to fend off congestion ;-)
(That's another acronym with multiple interprations. Didn't RED stand
for "random early discard" in some very early papers?)
> 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.
However, IIRC, in coddle, packets are dropped.
> 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.
I don't mind store and forward!
I only ask some nasty questions about congestion ;-)
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
detlef.bosau at web.de http://www.detlef-bosau.de
More information about the end2end-interest