Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!aurora!labrea!agate!ucbvax!SPAM.ISTC.SRI.COM!robert
From: robert@SPAM.ISTC.SRI.COM (Robert Allen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PSN 7 End-to-End question.
Message-ID: <8802030045.AA01518@spam.istc.sri.com>
Date: 3 Feb 88 00:45:37 GMT
References: <920@thumper.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70


>> > 1) Best effort systems rely totally on hosts for congestion
>> > management. That is, transport protocols are responsible for
>> > congestion control and congestion avoidance.
>> 
>> Yes, transport protocol behavior is important, but there's no reason why
>> the "best effort" network can't have defense mechanisms that activate
>> only when the network is congested.  For example, the network might
>> normally run in a pure datagram mode, with no network bandwidth wasted
>> on edge-to-edge acknowledgements. However when the network becomes
>> congested, the internal equivalent of "source quench" packets are sent
>> to the entry node, telling it to stop injecting so much traffic into the
>> network. The entry node might translate that into an access protocol
>> message telling the host (or gateway) to slow down, but more importantly
>> the entry node could simply delay or discard additional traffic before
>> it enters the network. Discarding packets is certainly one way to get
>> TCP's attention, but the delaying tactic would be more efficient.

    This is what was on my mind when I asked if the ETE was used for all
    traffic.  If everything is fine and dandy then there shouldn't be a
    need for ETE.  It should only activate when needed, similar to when
    traffic directing cops are only sent out when the stoplights breakdown
    (hmmm, maybe that's sort of poor metaphor, but...).  As originally
    stated, the Arpanet was designed as an open network, where the hosts
    or gateways were assumed not to overuse the network.  Now however that
    can no longer be assumed.  Perhaps indeed some new protocols need
    to be developed that put a chokehold on gateways, instead of trying to
    choke the traffic at an IMP (via ETE, and assuming that the network
    consists of homogeneous hardware and software) or at a host (which is
    obviously a problem currently, since host behavior is very heterogenous).
    Current routing protocols seem to be very weak at load sharing and con-
    gestion control.  Most metrics are are hops, rather than quality metrics.
    cisco gateways have the administrative distance metric, but for the most
    part this field is in its infancy.

>> Question: has anyone looked into techniques for tuning TCP window sizes?
>> Intuitively, I expect that increasing the window size for a TCP-based
>> file transfer would increase throughput until the slowest link in the
>> path saturates. Beyond this point, throughput would remain constant but
>> round trip delay would goes up, unnecessarily increasing delay for other
>> users of the same path. It would be nice to find an algorithm that found
>> and operated at this optimal operating point automatically. Any ideas?

    I wonder about this.  If the situation were ideal it might be the case
    that throughput would remain the same when saturation occurred, however
    in reality wouldn't the increasing load (over and above the sat. level)
    on the IMP be likely to cause congestion problems, perhaps enough
    to back up the series of links to the transmitting host, or more likely,
    to cause enough of a delay to cause TCP to declare the host/network
    unreachable?

    My understanding of the internal structure of the Arpanet is not what
    it should be, so excuse me this question.  Are all Arpanet (internal)
    links pretty much equal in speed (assumedly their MTU size is constant
    since it is all the same hardware)?  If that is the case perhaps your
    model works, but consider this.  With networking becoming the widespread
    thing that it is, is it fair to design protocols which are designed for
    a relatively homogeneous PSN(etwork)?  The Arpanet seems to me to be
    rather unique in its construction and administration.  Networks of the
    future may not rely on a homogeneous core, but may rather be a series
    of smaller networks which provide routes of varying expense or quality
    of service to each other, on a peer rather than superior basis.  In
    fact, isn't it possible that the current problems encountered in the
    Arpanet with loops and backdoor routes messing up the network could be
    considered to be weaknesses of the existing protocols?  This by the way
    really is a question, and not an assertion.

    Comments welcome.

    Robert Allen, robert@spam.istc.sri.com
    415-859-2143 (work phone, days)