[e2e] Reacting to corruption based loss

Cannara cannara at attglobal.net
Sun Jun 26 21:32:10 PDT 2005


Ok Detlef, then the phrase: "to that degree that a TCP sender may continue to
reckognize any loss as being due to congestion" remains the problem, since TCP
designers assumed loss was due to congestion, thus often slowing down
unnecessarily and, even when loss is due to congestion, often too much. The
problem we have now is that TCP's "congestion control" was never more than a
bandaid, added in the '80s, to protect the burgeoning Internet from the
dreaded "meltdown", as predicted by Metcalfe & others.  The near meltdowns
scared Inet folks mightily.  

As a kludge, making TCP try to manage congestion was never followed up with
protocol research and development to properly sense and distribute congestion
info.  Thus, any loss, is considered congestion, and a typical TCP will be
brought to its knees by a few % packet losses that are simply due to hardware
errors.

Alex

Detlef Bosau wrote:
> 
> Cannara wrote:
> >
> >
> > Now to the question: "Why couldn´t we continue to assume loss free links?"
> 
> O.k, this remark was intendedly somewhat teasing ;-)
> 
> And of course it was thought in a "TCP manner", i.e. the assumption that
> all losses are due to congestion and therefore are treated like
> congestion notifications.
> 
> I´m personally interested in wide area mobile wireless networks ("mobile
> networks") used as access networks to the Internet. In this model,
> the Internet _core_ consists of wirebound networks and mobile networks
> are used as _access_ networks only.
> 
> For this particular case I advocate the use of PEP to make loss
> differentiation for TCP unnecessary.
> 
> So, correctly I should say: In the particular case of using mobile
> wireless networks as access networks to the Internet, we can compensate
> corruption based loss at the access network by the use of PEP/RLP/... to
> that degree that a TCP sender may continue to reckognize any loss as
> being due to congestion.
> 
> Of course, not all protocols are TCP. And of course different protocols
> may require different strategies.
> 
> However, I´m not quite sure whether my position meets the general
> consensus. I´ve earned both, strong support and strong criticism when I
> talked about
> this to colleagues.
> 
> DB
> --
> Detlef Bosau
> Galileistrasse 30
> 70565 Stuttgart
> Mail: detlef.bosau at web.de
> Web: http://www.detlef-bosau.de
> Mobile: +49 172 681 9937


More information about the end2end-interest mailing list