[ih] Loss as a congestion signal [internet-history Digest, Vol 84, Issue 4]

[Detlef Bosau]

Am 21.05.2014 22:02, schrieb Brian E Carpenter:

> and congestion-prone segments, TCP doesn't work so well. (See
> http://www.ietf.org/proceedings/87/slides/slides-87-nwcrg-4.pdf for
> example.) Brian 

Oh yeah. I'm afraid this could end up in a flame war.................


I just remember the thread about hop by hop flow control. And of course,
this is the same discussion.

I once read in Tanenbaums book on computer networks and multicast, when
two professors in Berkeley chat, this is of no interest for the rest of
the world. (Obviously, Andrew's system model did not consider the
NSA.)(Which is not interested in any phone talk in Germany at all, but
in contrast to German people who start yawning in those cases, they are
eager to listen "Madame The Nought".)

Back to the issue. Of course it can well make sense to do error
correction at the transport layer, particularly when retransmissions on
demand aren't feasible or too expensive, refer e.g. to the TETRYS work
by E. Lochin et al.

However, both, retransmission and error correction as well are annoying
for the rest of the world, both require resources which are not
available for others any more.

In my view, it is one of our central fallacies that we intertwined error
_correction_, error _recovery_ and congestion detection.
These are completely different issues and should be carefully distinguished.

In addition, we see packet loss as an indication for congestion.

Neither packet loss is a reliable congestion indicator (it may be due to
congestion or due to corruption as well),
neither this is delay, wich can be due to local recovery, due to varying
channel codings or line coding, due to varying acess times.

When in a chain of 100 hops and links the last link is lossy, so a
packet cannot be delivered, it is not always the best solution
- to retransmit it locally,
- to retransmit it end to end, if the link is lossy, the packet will be
corrupted anyway, no matter whether it was sent end to end or locally,
- to change the path,
...
...

Hence,  a packet traveling from source to sink may encounter quite a lot
of different scenarios. And I'm (in contrast to the community) not
convinced that a whole TCP flow may be controlled only by actions at the
end points.

I think, we should strongly review our strict "end to end view" here.

Detlef


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