[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] Why did congestion happen at all? Re: why did CC happen at all?

On 8/31/2014 16:36, Miles Fidelman wrote:
> Detlef Bosau wrote:
>> Am 31.08.2014 um 20:46 schrieb Miles Fidelman:
>>>>> /  There are dozens of all days life examples where resources must be
>>>> />/  allocated or assigned, we have well proven algorithms for these
>>>> />/  purposes. E.g. in Germany, you can travel by car from Flensburg to
>>>> />/  F?ssen. And there is no need for probing, no need for dropped
>>>> cars and
>>>> />/  car corruption is considered an accident./
>>> is simply bogus.  You DON'T "have well proven algorithms for  these
>>> purposes."
>> Neither is congestion control for the internet "proven".
> But nobody has said it is.  You're the one who asserted that there are
> algorithms from other sources (ARPANET, German traffic engineering) that
> solve analogous problems,  that all the research on congestion control
> is bogus, and all that we have to do is apply those algorithms.
>>> No.  It didn't.  As several of us who were there, have told you. The
>>> documentation is also pretty easy to find - try googling "BBN Report
>>> 1822," "imp-to-imp protocol", and, "ARPANET 1822L" for starters.
>> Then documentation work like this one here
>> http://www.cs.utexas.edu/users/chris/think/ARPANET/Technical_Tour/sidi_flow.shtml
>> is wrong.
> I have no idea whether that document is accurate or not, or what it's
> based on.  If there's a conflict with primary source material - which is
> what Dave Walden and I both pointed to; or the memories of folks who
> built the ARPANET (as several commentators here are) - then, yes, it's
> wrong.
>> However, honestly, I'm a bit frustrated and a bit tired.
> As am I, and I expect others, by statements like this:
>> Both, "bandwidth" and "flow control" have a propper, well defined
>> technical meaning, in both cases this was forged by our CS rabulistic.
> I expect quite a few people are also personally insulted, if not royally
> ticked off.
>> And more than once, I saw arguments replaced by loudness - and you might
>> believe it or not; I personally prefer the very decent tone, I want to
>> conduct scientific research - and we are neither at Sotheby's nor at a
>> "Tupperware Party".
>> As you see in the quoted pages (and I had a look at some of the protocol
>> standards, I would not write on this one if I had not reflected those
>> matters during the past ten years) the ARPAnet had a flow control
>> mechanism.
>> And the only reason why we dropped flow control in RFC 791 (as you see,
>> I prefer rationales over yelling) was the possibility of head of line
>> blocking, when we do flow control per line. As you see on
>> http://www.cs.utexas.edu/users/chris/think/ARPANET/Technical_Tour/sidi_flow.shtml
>> the ARPANET provided per flow wise flow control for up to 8 flows.
>> Do you agree here?
> Yes - ARPANET had a flow control mechanism.  It also had congestion
> control mechanisms.  They were different.
> No - Neither were particularly appropriate for a datagram oriented
> catenet.  And the design decisions that went into the current net have
> been stated, repeatedly, by several folks who had hands on the code.  Me
> - I was an observer, I did system architecture for the Defense Data
> Network, which evolved from the ARPANET - I saw a lot of this first hand.
>> So, actually, there WAS a flow wise flow control - and hence one could
>> overcome head of line blocking problems.
>> So there actually WAS the possibilty for a
>> - per flow
>> - per hop
>> flow control.
>> And now I would really appreciate compelling reasons why this was
>> abandoned!
> See above, and previous messages.  Beyond that, they weren't abandoned,
> they never applied in the first place.
>> (As you might notice, I'm reviewing the related work for my own research
>> here. Did you?)
>> And when I sound harsh here: Personally, I'm a very decent person. Even
>> the tone in some universities is much too harsh for me, there are always
>> some few "loudspeakers" you shout and yell there insights everywhere and
>> shout down any question.
>> When I ask questions here, I do this because I did not find compelling
>> answers in more than ten years OF EXTREMELY HARD WORK.
> No - you're making wildly wrong and unfounded assertions, and casting
> character aspersions at an entire R&D community, and folks who've been
> working very hard at this for 45 years.
>> This particularly includes not only to attend lessons given by some
>> narcissistic professors but reading many of the original papers
>> (including those by VJ, Little, Shannon) carefully, line by line and
>> several times.
>> And yes, I repeat my statement: You can travel by car from Flensburg to
>> F?ssen, WITHOUT probing and WITHOUT congestion loss, and obviously
>> without evem a university education.
> I note that you're NOT saying "without CONGESTION."  People get stuck in
> traffic, have accidents, and so forth.  It's still congestion, the
> symptoms are different.
>> So there must be something in our networking world, which is different
>> from that real world, and therefore, I ask questions.
> Yes... packets are virtual things - what matters is that a copy gets
> through, not the original bits.  Dropping and retransmitting is a viable
> option for dealing with congestion.  Doesn't work as well with people or
> vehicles. (On the other hand, with merchandise, stores are overstocked
> all the time, and throw stuff away.  Again, an optimization strategy.).

I have concluded that this thread has been highjacked by trolls (high 
maintenance troll, but trolls none the less.

On my way to the spam-filter maintenance screen, let me just say a 
couple of things, for what ever they might be worth.

One of the most offensive things I have heard in a while is that some 
would accuse me of regarding the value of my unique and irreplaceable 
children as equal to an intrinsically valueless and infinitely 
replaceable bit of somebody's Angry Birds game.

It is amazing to me (a non-participant) that the present state of 
internet traffic handling was achieved (apparently) through the 
application  of inane and irrelevant similes and metaphors; and blatant 
disrespect for the participants in the discussions.

The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.