[e2e] Answer to Dave Reed Re: Fwd: Re: Question the other way round:

[Detlef Bosau]

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
congestion.

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
this.
> 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 ;-)
>


-- 
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30  
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de