From fred at cisco.com  Wed Jan  1 22:31:20 2014
From: fred at cisco.com (Fred Baker (fred))
Date: Thu, 2 Jan 2014 06:31:20 +0000
Subject: [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines
In-Reply-To: <201312151857.rBFIuuea043478@gateway0.ipv6.occnc.com>
References: <201312151857.rBFIuuea043478@gateway0.ipv6.occnc.com>
Message-ID: <533BE7A9-7804-4A74-BBFB-C75CCE212434@cisco.com>


On Dec 15, 2013, at 10:56 AM, Curtis Villamizar <curtis at ipv6.occnc.com> wrote:

> So briefly, my answer is: as a WG, I don't think we want to go there.
> If we do go there at all, then we should define "good AQM" in terms of
> acheving a "good" tradeoff between fairness, bulk transfer goodput,
> and bounded delay.  IMHO sometimes vague is better.

As you may have worked out from my previous comments in these threads, I agree with you. I don't think this can be nailed down in a universal sense. What can be described is the result in the network, in that delays build up that persist, as opposed to coming and going, and as a result applications don't work as well as they might - and at that point, it is appropriate for the network to inform the transport.

From detlef.bosau at web.de  Fri Jan 10 11:34:14 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Fri, 10 Jan 2014 20:34:14 +0100
Subject: [e2e] Lost Layer?
Message-ID: <52D04B36.9010005@web.de>

I would like to discuss the talk
http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
given by John Day.

What do you think, e.g., of the claim
> ?
> TCP was split in the Wrong Direction!
> ? It is one layer, not two.
> ? IP was a bad idea.

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


From gaberger at cisco.com  Fri Jan 10 13:20:10 2014
From: gaberger at cisco.com (Gary Berger (gaberger))
Date: Fri, 10 Jan 2014 21:20:10 +0000
Subject: [e2e] end2end-interest Digest, Vol 117, Issue 2
In-Reply-To: <mailman.1.1389384000.12640.end2end-interest@postel.org>
References: <mailman.1.1389384000.12640.end2end-interest@postel.org>
Message-ID: <CEF5CD1D.24E92%g@garyberger.net>

If there is any clearer evidence today, look at the world of network
virtualization.. The use of VXLAN Network Identifiers (VNI) NVGRE Tenant
network identifier (TNI) or Stateless Tunnel Context ID (STT) becomes a
new network layer.

On 1/10/14 3:00 PM, "end2end-interest-request at postel.org"
<end2end-interest-request at postel.org> wrote:

>Send end2end-interest mailing list submissions to
>	end2end-interest at postel.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://mailman.postel.org/mailman/listinfo/end2end-interest
>or, via email, send a message with subject or body 'help' to
>	end2end-interest-request at postel.org
>
>You can reach the person managing the list at
>	end2end-interest-owner at postel.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of end2end-interest digest..."
>
>
>Today's Topics:
>
>   1. Lost Layer? (Detlef Bosau)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 10 Jan 2014 20:34:14 +0100
>From: Detlef Bosau <detlef.bosau at web.de>
>Subject: [e2e] Lost Layer?
>To: "<end2end-interest at postel.org>" <end2end-interest at postel.org>
>Message-ID: <52D04B36.9010005 at web.de>
>Content-Type: text/plain; charset=UTF-8
>
>I would like to discuss the talk
>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
>given by John Day.
>
>What do you think, e.g., of the claim
>> ?
>> TCP was split in the Wrong Direction!
>> ? It is one layer, not two.
>> ? IP was a bad idea.
>
>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
>
>
>
>------------------------------
>
>_______________________________________________
>end2end-interest mailing list
>end2end-interest at postel.org
>http://mailman.postel.org/mailman/listinfo/end2end-interest
>
>
>End of end2end-interest Digest, Vol 117, Issue 2
>************************************************

From Jon.Crowcroft at cl.cam.ac.uk  Sat Jan 11 03:40:52 2014
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sat, 11 Jan 2014 11:40:52 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <52D04B36.9010005@web.de> 
References: <52D04B36.9010005@web.de>
Message-ID: <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>

In missive <52D04B36.9010005 at web.de>, Detlef Bosau typed:

 >>I would like to discuss the talk
 >>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
 >>given by John Day.
 >>
 >>What do you think, e.g., of the claim
 >>> ???
 >>> TCP was split in the Wrong Direction!
 >>> ??? It is one layer, not two.

should have been 3 - as per the transport services work - its clear
you need a sublayer convergence (as per day's work) but also the
socket layer needs revising badly to allow for a wider set of
transport service semantics than came out of the fast 
hack that bbn and berkeley did

the API needs to allow for lots of different ways to process packets
(multiple paths, out of order processing etc ) which would allow mptcp
and obviate the need for spdy etc etc
hopefully, there'll be a bof on this at upcoming ietf in london
http://www.potaroo.net/ietf/all-ids/draft-moncaster-tsvwg-transport-services-01.pdf

 >>> ??? IP was a bad idea.

certainly the authors should have read IEN1 which would have led to a
much better identifier space (as revived in the ILNP work by ran
atkinson, 40 years later
http://ilnp.cs.st-andrews.ac.uk/
 
 cheers

   jon



From detlef.bosau at web.de  Sat Jan 11 04:50:42 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 11 Jan 2014 13:50:42 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
Message-ID: <52D13E22.7040605@web.de>

Am 11.01.2014 12:40, schrieb Jon Crowcroft:
> In missive <52D04B36.9010005 at web.de>, Detlef Bosau typed:
>
>  >>I would like to discuss the talk
>  >>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
>  >>given by John Day.
>  >>
>  >>What do you think, e.g., of the claim
>  >>> ???
>  >>> TCP was split in the Wrong Direction!
>  >>> ??? It is one layer, not two.
>
> should have been 3 - as per the transport services work - its clear

Why 3? Why not 4? Or 40?


Admittedly, sometimes I think CS guys are collecting layers just like
others are collecting stamps.

> you need a sublayer convergence (as per day's work) but also the
> socket layer needs revising badly to allow for a wider set of
> transport service semantics than came out of the fast 
> hack that bbn and berkeley did

Shouldn't we agree upon a model and then upon offered services and APIs
first?

When I read John's talk, my impression was (and this is not only from
John's talk), our current <small>TCP</small><big>IP</big> model is
roughly spoken as follows.


<tiny>TCP peer</tiny><HUGE BOLD LARGE>I P C L O U D</HUGE /BOLD
/LARGE><tiny>TCP peer</tiny>

And our current end to end excuse is: We only can control the TCP peers,
there is a big fat IP cloud where we have absolutely no idea what's
happening in there, so believe in a model instead and control this at
the end points.

In other words: We mix up the real IP cloud with an artificial model -
and ignore that these are not really the same.

And perhaps, that's what John wanted to say? (Which is sometimes a bit
ardous, because John often talks extremely much about the Internet's
history and where this company took the wrong road or when this
institution took a wrong decision, this may be interesting and sometimes
worthwhile to understand how things developed, however it is sometime
not quite concise and we sometimes don't really see the forest for the
trees here.)

Actually, the more I think about it, I have a huge problem with this "IP
cloud", because this metaphor withholds what's going on there and the
end points are, and this is simple control theory, NO WAY adequate to
control the mechanisms within a cloud of such complexity.

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


From sthaug at nethelp.no  Sat Jan 11 05:39:02 2014
From: sthaug at nethelp.no (sthaug@nethelp.no)
Date: Sat, 11 Jan 2014 14:39:02 +0100 (CET)
Subject: [e2e] Lost Layer?
In-Reply-To: <52D13E22.7040605@web.de>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<52D13E22.7040605@web.de>
Message-ID: <20140111.143902.71090496.sthaug@nethelp.no>

> > you need a sublayer convergence (as per day's work) but also the
> > socket layer needs revising badly to allow for a wider set of
> > transport service semantics than came out of the fast 
> > hack that bbn and berkeley did
> 
> Shouldn't we agree upon a model and then upon offered services and APIs
> first?

Maybe not, because you can never foresee all of the services and APIs
you might need in the future. You need an extensible model.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From Jon.Crowcroft at cl.cam.ac.uk  Sat Jan 11 06:40:55 2014
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sat, 11 Jan 2014 14:40:55 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <20140111.143902.71090496.sthaug@nethelp.no> 
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<52D13E22.7040605@web.de>
	<20140111.143902.71090496.sthaug@nethelp.no>
Message-ID: <E1W1zkA-0005jy-2u@mta1.cl.cam.ac.uk>

agree - in fact, the model of layers is obsolete in terms of s/w APIs for a
variety of reasons - when we did Haggle, we had a set of cooperating agents
to build up a protocol as needed - others (handley's protocol heaps, for
example) have looked at this - also, in terms of interfaces, one can use deep
reflection to modify internals of a protocol through an API, rather than
being restricted to modifying things above a restricted service interface...
so any OO trained programmer ought to be fine with that idea..

finally, a lot of cooler things can be done with typesafe systems in terms of
puttign new code into a protocol "stack" (or heap) safely with contracts
and/or proof carrying code - or else just build a whole lot of compeltely
different comms systems as needed out of lots of micro-protocol
components....(see
http://cacm.acm.org/magazines/2014/1/170866-unikernels/abstract
for this approach for cloud)

so yes, we have much better tools for extensibility nowadays...and could go a
lot further in future proofing things

In missive <20140111.143902.71090496.sthaug at nethelp.no>, sthaug at nethelp.no typed:

 >>> > you need a sublayer convergence (as per day's work) but also the
 >>> > socket layer needs revising badly to allow for a wider set of
 >>> > transport service semantics than came out of the fast 
 >>> > hack that bbn and berkeley did
 >>> 
 >>> Shouldn't we agree upon a model and then upon offered services and APIs
 >>> first?
 >>
 >>Maybe not, because you can never foresee all of the services and APIs
 >>you might need in the future. You need an extensible model.
 >>
 >>Steinar Haug, Nethelp consulting, sthaug at nethelp.no

 cheers

   jon


From detlef.bosau at web.de  Sat Jan 11 07:17:04 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 11 Jan 2014 16:17:04 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <20140111.143902.71090496.sthaug@nethelp.no>
References: <52D04B36.9010005@web.de>
	<E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>	<52D13E22.7040605@web.de>
	<20140111.143902.71090496.sthaug@nethelp.no>
Message-ID: <52D16070.50207@web.de>

Am 11.01.2014 14:39, schrieb sthaug at nethelp.no:

> Maybe not, because you can never foresee all of the services and APIs
> you might need in the future. You need an extensible model. Steinar
> Haug, Nethelp consulting, sthaug at nethelp.no 

As we use to say: KISS.

Keep It Small and Simple.

I think, the best way to achieve a versatile and extensible API is to
keep it lean, small, generic.

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


From jon.crowcroft at cl.cam.ac.uk  Sat Jan 11 10:20:55 2014
From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sat, 11 Jan 2014 18:20:55 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <52D16070.50207@web.de>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<52D13E22.7040605@web.de>
	<20140111.143902.71090496.sthaug@nethelp.no>
	<52D16070.50207@web.de>
Message-ID: <CAEeTejKEV_ePW5CNJ7cKyb5G_LXbVCNHUDC5zYxV4e3SDZfxvA@mail.gmail.com>

i think the kiss principle is a bit older than most people realize
http://en.wikipedia.org/wiki/William_of_Ockham


On Sat, Jan 11, 2014 at 3:17 PM, Detlef Bosau <detlef.bosau at web.de> wrote:

> Am 11.01.2014 14:39, schrieb sthaug at nethelp.no:
>
> > Maybe not, because you can never foresee all of the services and APIs
> > you might need in the future. You need an extensible model. Steinar
> > Haug, Nethelp consulting, sthaug at nethelp.no
>
> As we use to say: KISS.
>
> Keep It Small and Simple.
>
> I think, the best way to achieve a versatile and extensible API is to
> keep it lean, small, generic.
>
> --
> ------------------------------------------------------------------
> 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
>
>

From detlef.bosau at web.de  Sat Jan 11 11:43:12 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 11 Jan 2014 20:43:12 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <CAEeTejKEV_ePW5CNJ7cKyb5G_LXbVCNHUDC5zYxV4e3SDZfxvA@mail.gmail.com>
References: <52D04B36.9010005@web.de>	<E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>	<52D13E22.7040605@web.de>	<20140111.143902.71090496.sthaug@nethelp.no>	<52D16070.50207@web.de>
	<CAEeTejKEV_ePW5CNJ7cKyb5G_LXbVCNHUDC5zYxV4e3SDZfxvA@mail.gmail.com>
Message-ID: <52D19ED0.9030005@web.de>

Am 11.01.2014 19:20, schrieb Jon Crowcroft:
> i think the kiss principle is a bit older than most people realize
> http://en.wikipedia.org/wiki/William_of_Ockham
>

And it is perfectly extensible by appropriate add ons :-)


http://www.youtube.com/watch?v=eQ8iZu-BAVM

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


From detlef.bosau at web.de  Mon Jan 13 03:46:08 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Mon, 13 Jan 2014 12:46:08 +0100
Subject: [e2e] Yes, there IS a lost layer: The flow control layer,
 or "deadlock avoidance layer".  Re:  Lost Layer?
In-Reply-To: <52D04B36.9010005@web.de>
References: <52D04B36.9010005@web.de>
Message-ID: <52D3D200.4070104@web.de>

Am 10.01.2014 20:34, schrieb Detlef Bosau:
> I would like to discuss the talk
> http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
> given by John Day.
>
> What do you think, e.g., of the claim
>> ?
>> TCP was split in the Wrong Direction!
>> ? It is one layer, not two.
>> ? IP was a bad idea.
> Detlef
>

Perhaps, the problem of a "lost layer" becomes much more clear when we
realize what is actually missing.

In order to make this clear, we could have a look at a typical paper
which does things completely wrong:

"An Improved Greedy Routing Algorithmfor Grid using Pheromone-Based
Landmarks" by Lada-On Lertsuwanakul and Herwig Unger,
World Academy of Science, Engineering and Technology Vol:35 2009-11-25

The idea behind this work is certainly some kind of "ant routing". And
despite all other considerations, the major fault is to regard a data
flow as set of blocks, "ants".

It doesn't really matter whether we talk about data flows or media flows
here.

What is really required by the user/application (sic!!!!) is a flow that
can be successfully used or rebuilt from the packets, be it a byte flow
(in case of TCP) or a media flow (in case of RTP/UDP), a simple heap of
packets is of absolutely no use for the receiver, when the original flow
cannot be rebuilt. And because a receiver has finite (maybe huge but
finite!) space, the heap of received packets must not grow beyond all
limits, it even must not exceed the space which is available for flow
reconstruction AND it mus respect the simple fact that the receiver's
buffer space can only be delivered from data, when data can be forwarded
to the application in proper order, be it temporal order or the original
byte sequence.

Exactly that, and ONLY that, is the reason for both, the flow control
window AND the semantics of the TCP ACK field ("next byte expected") in
RFC 793.

Offering too much load to the receiver is not only a matter of space, it
is particularly a matter of data being available for forwarding to the
application. If this cannot happen and we cannot free buffer, we may see
a situation where the buffer is occupied and canot accept further data -
while no data can be forwarded to the application, and hence no buffer
space can be freed, because some indispensable packet is missing.

This is a typical deadlock situation.

And exactly this is the task of a flow control layer: Avoiding the
aforementioned deadlock. Call it "flow control layer" or "dead lock
avoidance layer", whatever you prefer.

The problem is extremely generic, it is a twist of state variables being
asynchronous in distributed systems, quite generally known as the "two
army problem".

In TCP and RFC 793 we work around this problem by killing flows after a
user defined timeout when nothing happens AND (certainly more important)
by, very literally, do-or-die Go Back N. (The receiver expects byte
4711, so send the packet - or die. Period.)

That's for the end points. And only for the end points.

That's not for flow control along the path. This is an orthogonal (and
in my opinion in TCP not yet solved) problem.

An interesting twist of the latter problem is that we need sufficiently
large buffers at the receiver for accepting all data in flight in case
of LFN and huge latency throughput products. Hence, we abuse the
"deadlock avoidance" window for flow control along the path.

As a consequence, TCP receivers must provide sufficiently large buffers
in order to allow the flow to utilize the path capacity. This lead to
some approaches like the "Remote Socket Architecture" by Schlager,
Wolisz. Why the heck does a smartphone with 10 kByte receiver buffer
space restrict a sender's data rate because it cannot keep a the path's
"whole delay throughput product"?

So the problem is that we miss a flow control layer. And we work around
this missing layer by intertwining flow control, rate control and
congestion control and by glueing things together which MUST be kept apart.





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


From detlef.bosau at web.de  Mon Jan 13 09:25:27 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Mon, 13 Jan 2014 18:25:27 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <CEF968E2.C979%william.d.ivancic@nasa.gov>
References: <CEF968E2.C979%william.d.ivancic@nasa.gov>
Message-ID: <52D42187.6010504@web.de>

Am 13.01.2014 16:09, schrieb Ivancic, William D. (GRC-RHN0):
> I strongly suggest reading John Day's book "Patterns in Network
> Architecture: A Return to Fundamentals."  It is not and easy read and has
> a lot of history that you may or may not find useful.  

It is - with all due respect towards John - the "history" which is often
difficult to read in John's publications.

Admittedly, I'm not interested in history, when a book contains to much
of it, I simply ignore it.

Science is, as DPR said, about asking questions and finding answers. And
a useful approach to asking questions is the
- what
- why
- how
approach.

- what is the question?
- why is it important, with particular attention to: If it is important,
why isn't it solved or why are existing solutions not satisfactory?
- how do I want to solve the problem.

I had quite some off list discussions with John - and frankly spoken, I
eventually resiled because I couldn't find a way to communicate with
John in concise questions and selecting adequate solutions. This may be
my fault, I'm perhaps a somewhat "difficult" person and perhaps I have a
very individual way of thinking.

> If you only look at
> one portion, I suggest finding the short discussion of how the phone
> number evolved from a location identifier to an application identifier -

That's another point of interest. John is quite often interested into
numbering and addressing problems. I'm, primarily, interested in
congestion control. There are numbers. That's it. How is  it called in
the HHTG? An SEP, IIRC.

(Not to be misunderstood. Wrong numbering can lead to huge problems. But
I'm not a religious person, so I'm no strong believer of
"Correctnumberingism".)
> (I think it is in the mobility section, but I don't have my copy handy).
> .  In fact, you might want to jump here first then go read from the
> beginning.  It should give you some insight as to why the current Internet
> Architecture has so much difficulty with mobility and multi-homing which
> is what originally drew me to this work.

And afterwards, you are that much into the existing architecture that
you fail to think otherwise.

William, during the past 14 years I was strongly into VJCC, simulations.
the e2e principle, or perhaps the first 13 of the past 14 years.

About 2013 I started to put the whole thing in question.

And the result was: I put the e2e principle in question and the more I
think about it, and I got harsh reactions when I mentioned this
to some people, the more I'm convinced: VJCC and offsprings was a
wonderful work around for the congestion collapse problem and it
deserves huge respect that it works until these days - however, the
problem itself remains still unsolved and we need a crank back to about
1989 and a clean slate approach with the knowledge about networks of
2014 in mind.


>
> In a nutshell,  Naming and Addressing needs to be done right and,

Yes. But this is not the reason for congestion collapses to happen.

>  IMHO, we
> still haven't gotten it quite right.  Sometimes it looks like we are
> getting close and then we stumble.  DTN sort of had a chance and missed.
> Maybe Information Centric Networking work will help move naming and
> addressing along.

Delay tolerant networking may provide wonderful insights.

However, the very first insight which I got into TCP (it was the first
insight because after this insight I intentionally abolished anything I
ever heard about TCP before) is that TCP is an asynchronous protocol.
And where TCP is not asynchronous, it is wrong.

Period.

After this sort of "garbage collection" you can start again with the
question: How can we convey a flow of bytes from one location to another -
thereby taking advantage of some existing network underneath.

And I intentionally forgot about all this self clocking and self
scheduling nonsense - even about discussions of stability.

In a sense, I'm better now :-)

(Reminds me of a tooth which caused problems for me for certainly more
than a decade. Eventually the upper half broke away and the lower half
was dug out by an oral surgeon - however: The problems were gone :-))

Perhaps, it's at least in part a matter of age. I turned 50 last year,
be it a case of mid life crisis or reasonable for whatever reasons, on
some occasions it is a good idea to clear out one's brain and start
thinking from scratch.

> Will
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>
>
>
>
> On 1/10/14 2:34 PM, "Detlef Bosau" <detlef.bosau at web.de> wrote:
>
>> I would like to discuss the talk
>> http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
>> given by John Day.
>>
>> What do you think, e.g., of the claim
>>> ?
>>> TCP was split in the Wrong Direction!
>>> ? It is one layer, not two.
>>> ? IP was a bad idea.
>> 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
>>


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


From slblake at petri-meat.com  Mon Jan 13 09:57:39 2014
From: slblake at petri-meat.com (Steven Blake)
Date: Mon, 13 Jan 2014 12:57:39 -0500
Subject: [e2e] Lost Layer?
In-Reply-To: <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
Message-ID: <1389635859.8286.58.camel@tachyon.blake>

On Sat, 2014-01-11 at 11:40 +0000, Jon Crowcroft wrote:

> certainly the authors should have read IEN1 which would have led to a
> much better identifier space (as revived in the ILNP work by ran
> atkinson, 40 years later
> http://ilnp.cs.st-andrews.ac.uk/
>  
>  cheers
> 
>    jon

Agreed.

If I understand the slides correctly, they argue that what is missing
are network-scope (e.g., AS-scope) addresses, to be used by
hosts/routers within a domain, restricting the use (e.g.,
routing/forwarding) of Internet-scope addresses to hosts and Internet
gateways (e.g., inter-exchange routers).  Whatever the other merits of
that approach, it won't solve the multihoming scalability problem.


Regards,

// Steve


From ycor at iit.demokritos.gr  Mon Jan 13 12:37:10 2014
From: ycor at iit.demokritos.gr (Ioannis Korovesis)
Date: Mon, 13 Jan 2014 22:37:10 +0200
Subject: [e2e] Lost Layer?
In-Reply-To: <52D42187.6010504@web.de>
References: <CEF968E2.C979%william.d.ivancic@nasa.gov>
	<52D42187.6010504@web.de>
Message-ID: <52D44E76.2090008@iit.demokritos.gr>


> Admittedly, I'm not interested in history, when a book contains to much
> of it, I simply ignore it.

So  we have a proposal to discuss John Day's "lost layer"  but
the proposer is not interested on his book at the same time

????



On 01/13/2014 07:25 PM, Detlef Bosau wrote:
> Am 13.01.2014 16:09, schrieb Ivancic, William D. (GRC-RHN0):
>> I strongly suggest reading John Day's book "Patterns in Network
>> Architecture: A Return to Fundamentals."  It is not and easy read and has
>> a lot of history that you may or may not find useful.
> It is - with all due respect towards John - the "history" which is often
> difficult to read in John's publications.
>
> Admittedly, I'm not interested in history, when a book contains to much
> of it, I simply ignore it.
>
> Science is, as DPR said, about asking questions and finding answers. And
> a useful approach to asking questions is the
> - what
> - why
> - how
> approach.
>
> - what is the question?
> - why is it important, with particular attention to: If it is important,
> why isn't it solved or why are existing solutions not satisfactory?
> - how do I want to solve the problem.
>
> I had quite some off list discussions with John - and frankly spoken, I
> eventually resiled because I couldn't find a way to communicate with
> John in concise questions and selecting adequate solutions. This may be
> my fault, I'm perhaps a somewhat "difficult" person and perhaps I have a
> very individual way of thinking.
>
>> If you only look at
>> one portion, I suggest finding the short discussion of how the phone
>> number evolved from a location identifier to an application identifier -
> That's another point of interest. John is quite often interested into
> numbering and addressing problems. I'm, primarily, interested in
> congestion control. There are numbers. That's it. How is  it called in
> the HHTG? An SEP, IIRC.
>
> (Not to be misunderstood. Wrong numbering can lead to huge problems. But
> I'm not a religious person, so I'm no strong believer of
> "Correctnumberingism".)
>> (I think it is in the mobility section, but I don't have my copy handy).
>> .  In fact, you might want to jump here first then go read from the
>> beginning.  It should give you some insight as to why the current Internet
>> Architecture has so much difficulty with mobility and multi-homing which
>> is what originally drew me to this work.
> And afterwards, you are that much into the existing architecture that
> you fail to think otherwise.
>
> William, during the past 14 years I was strongly into VJCC, simulations.
> the e2e principle, or perhaps the first 13 of the past 14 years.
>
> About 2013 I started to put the whole thing in question.
>
> And the result was: I put the e2e principle in question and the more I
> think about it, and I got harsh reactions when I mentioned this
> to some people, the more I'm convinced: VJCC and offsprings was a
> wonderful work around for the congestion collapse problem and it
> deserves huge respect that it works until these days - however, the
> problem itself remains still unsolved and we need a crank back to about
> 1989 and a clean slate approach with the knowledge about networks of
> 2014 in mind.
>
>
>> In a nutshell,  Naming and Addressing needs to be done right and,
> Yes. But this is not the reason for congestion collapses to happen.
>
>>   IMHO, we
>> still haven't gotten it quite right.  Sometimes it looks like we are
>> getting close and then we stumble.  DTN sort of had a chance and missed.
>> Maybe Information Centric Networking work will help move naming and
>> addressing along.
> Delay tolerant networking may provide wonderful insights.
>
> However, the very first insight which I got into TCP (it was the first
> insight because after this insight I intentionally abolished anything I
> ever heard about TCP before) is that TCP is an asynchronous protocol.
> And where TCP is not asynchronous, it is wrong.
>
> Period.
>
> After this sort of "garbage collection" you can start again with the
> question: How can we convey a flow of bytes from one location to another -
> thereby taking advantage of some existing network underneath.
>
> And I intentionally forgot about all this self clocking and self
> scheduling nonsense - even about discussions of stability.
>
> In a sense, I'm better now :-)
>
> (Reminds me of a tooth which caused problems for me for certainly more
> than a decade. Eventually the upper half broke away and the lower half
> was dug out by an oral surgeon - however: The problems were gone :-))
>
> Perhaps, it's at least in part a matter of age. I turned 50 last year,
> be it a case of mid life crisis or reasonable for whatever reasons, on
> some occasions it is a good idea to clear out one's brain and start
> thinking from scratch.
>
>> Will
>>
>> ******************************
>> William D. Ivancic
>> Phone 216-433-3494
>> Fax 216-433-8705
>> Networking Lab 216-433-2620
>> Mobile 440-503-4892
>> http://roland.grc.nasa.gov/~ivancic
>>
>>
>>
>>
>>
>>
>> On 1/10/14 2:34 PM, "Detlef Bosau" <detlef.bosau at web.de> wrote:
>>
>>> I would like to discuss the talk
>>> http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf
>>> given by John Day.
>>>
>>> What do you think, e.g., of the claim
>>>> ?
>>>> TCP was split in the Wrong Direction!
>>>> ? It is one layer, not two.
>>>> ? IP was a bad idea.
>>> 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
>>>
>


From Jon.Crowcroft at cl.cam.ac.uk  Mon Jan 13 15:55:27 2014
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Mon, 13 Jan 2014 23:55:27 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <1389635859.8286.58.camel@tachyon.blake> 
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<1389635859.8286.58.camel@tachyon.blake>
Message-ID: <E1W2rLr-00052F-9j@mta0.cl.cam.ac.uk>

well, afaik, they solve mobility sand tackle multihoming quite well

the key architect was a prime mover in at least one major ipv6 and one
major ipsec implementation, so its worth reading further than the 1st
level, coz they have track record (anyone who has read ien1, cares:)
In missive <1389635859.8286.58.camel at tachyon.blake>, Steven Blake typed:

 >>On Sat, 2014-01-11 at 11:40 +0000, Jon Crowcroft wrote:
 >>
 >>> certainly the authors should have read IEN1 which would have led to a
 >>> much better identifier space (as revived in the ILNP work by ran
 >>> atkinson, 40 years later
 >>> http://ilnp.cs.st-andrews.ac.uk/
 >>>  
 >>>  cheers
 >>> 
 >>>    jon
 >>
 >>Agreed.
 >>
 >>If I understand the slides correctly, they argue that what is missing
 >>are network-scope (e.g., AS-scope) addresses, to be used by
 >>hosts/routers within a domain, restricting the use (e.g.,
 >>routing/forwarding) of Internet-scope addresses to hosts and Internet
 >>gateways (e.g., inter-exchange routers).  Whatever the other merits of
 >>that approach, it won't solve the multihoming scalability problem.
 >>
 >>
 >>Regards,
 >>
 >>// Steve
 >>

 cheers

   jon


From slblake at petri-meat.com  Mon Jan 13 17:52:36 2014
From: slblake at petri-meat.com (Steven Blake)
Date: Mon, 13 Jan 2014 20:52:36 -0500
Subject: [e2e] Lost Layer?
In-Reply-To: <E1W2rLr-00052F-9j@mta0.cl.cam.ac.uk>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<1389635859.8286.58.camel@tachyon.blake>
	<E1W2rLr-00052F-9j@mta0.cl.cam.ac.uk>
Message-ID: <1389664356.28653.3.camel@tachyon.blake>

On Mon, 2014-01-13 at 23:55 +0000, Jon Crowcroft wrote:

> well, afaik, they solve mobility sand tackle multihoming quite well
> 
> the key architect was a prime mover in at least one major ipv6 and one
> major ipsec implementation, so its worth reading further than the 1st
> level, coz they have track record (anyone who has read ien1, cares:)

If you are referring to ILNP, I agree completely (check the
acknowledgements of RFC6740).

I was referring to John Day's slides that were posted to e2e.


Regards,

// Steve


From detlef.bosau at web.de  Tue Jan 14 03:35:13 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Tue, 14 Jan 2014 12:35:13 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <52D44E76.2090008@iit.demokritos.gr>
References: <CEF968E2.C979%william.d.ivancic@nasa.gov>	<52D42187.6010504@web.de>
	<52D44E76.2090008@iit.demokritos.gr>
Message-ID: <52D520F1.1090605@web.de>

Am 13.01.2014 21:37, schrieb Ioannis Korovesis:
>
>> Admittedly, I'm not interested in history, when a book contains to much
>> of it, I simply ignore it.
>
> So  we have a proposal to discuss John Day's "lost layer"  but
> the proposer is not interested on his book at the same time
>
> ????
>
>

No. But for the moment, I want to focus on the talk.

Not necessarily on the whole book. It is only to limit the focus.
Otherwise we end up in paradise with Adam, Eve, the apple, the serpent,
the garden of Eden...

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


From matta at bu.edu  Tue Jan 14 06:51:36 2014
From: matta at bu.edu (Matta, Abraham I)
Date: Tue, 14 Jan 2014 14:51:36 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <CEFA0FF8.4506A%matta@bu.edu>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<1389635859.8286.58.camel@tachyon.blake> <CEFA0FF8.4506A%matta@bu.edu>
Message-ID: <CEFAB8ED.450F5%matta@bu.edu>

It's not only "private" addresses within each scope (layer), it's also
that addresses identify processes (and not interfaces as IP addresses do.)
By late binding a process address to a particular interface, one can
better deal with mobility and multihoming.


Each layer also provides transport (flow) services, which can depend on
lower layers (i.e. a recursive model). Each layer basically implements its
own control loop over its scope. Functions like addressing, routing, flow
control, etc. are implemented recursively (http://csr.bu.edu/rina/). In
the current Internet, the IP layer has a huge scope (range of operation)
which makes it very hard to control (from control theory, we know how hard
it is to stabilize a feedback system when the feedback delay is large).

Best,
ibrahim




>
>On 1/13/14 12:57 PM, "Steven Blake" <slblake at petri-meat.com> wrote:
>
>>On Sat, 2014-01-11 at 11:40 +0000, Jon Crowcroft wrote:
>>
>>> certainly the authors should have read IEN1 which would have led to a
>>> much better identifier space (as revived in the ILNP work by ran
>>> atkinson, 40 years later
>>> http://ilnp.cs.st-andrews.ac.uk/
>>>  
>>>  cheers
>>> 
>>>    jon
>>
>>Agreed.
>>
>>If I understand the slides correctly, they argue that what is missing
>>are network-scope (e.g., AS-scope) addresses, to be used by
>>hosts/routers within a domain, restricting the use (e.g.,
>>routing/forwarding) of Internet-scope addresses to hosts and Internet
>>gateways (e.g., inter-exchange routers).  Whatever the other merits of
>>that approach, it won't solve the multihoming scalability problem.
>>
>>
>>Regards,
>>
>>// Steve
>>
>



From hamed at eecs.qmul.ac.uk  Tue Jan 14 07:29:42 2014
From: hamed at eecs.qmul.ac.uk (Hamed Haddadi)
Date: Tue, 14 Jan 2014 15:29:42 +0000
Subject: [e2e] Lost Layer?
In-Reply-To: <CEFAB8ED.450F5%matta@bu.edu>
References: <52D04B36.9010005@web.de> <E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>
	<1389635859.8286.58.camel@tachyon.blake> <CEFA0FF8.4506A%matta@bu.edu>
	<CEFAB8ED.450F5%matta@bu.edu>
Message-ID: <CALeNysE76O0jz78ptLS-qisC4VfSdur6y4aB7UesDvPf5ZW7_A@mail.gmail.com>

you may also like to have a look at this book chapter that covers some of
the trade-offs very well with respect to multihoming and IPv6


"The Design Space of Network Mobility"

http://sigcomm.org/education/ebook/SIGCOMMeBook2013v1_chapter8.pdf



==
Hamed       http://www.eecs.qmul.ac.uk/~hamed/


On 14 January 2014 14:51, Matta, Abraham I <matta at bu.edu> wrote:

> It's not only "private" addresses within each scope (layer), it's also
> that addresses identify processes (and not interfaces as IP addresses do.)
> By late binding a process address to a particular interface, one can
> better deal with mobility and multihoming.
>
>
> Each layer also provides transport (flow) services, which can depend on
> lower layers (i.e. a recursive model). Each layer basically implements its
> own control loop over its scope. Functions like addressing, routing, flow
> control, etc. are implemented recursively (http://csr.bu.edu/rina/). In
> the current Internet, the IP layer has a huge scope (range of operation)
> which makes it very hard to control (from control theory, we know how hard
> it is to stabilize a feedback system when the feedback delay is large).
>
> Best,
> ibrahim
>
>
>
>
> >
> >On 1/13/14 12:57 PM, "Steven Blake" <slblake at petri-meat.com> wrote:
> >
> >>On Sat, 2014-01-11 at 11:40 +0000, Jon Crowcroft wrote:
> >>
> >>> certainly the authors should have read IEN1 which would have led to a
> >>> much better identifier space (as revived in the ILNP work by ran
> >>> atkinson, 40 years later
> >>> http://ilnp.cs.st-andrews.ac.uk/
> >>>
> >>>  cheers
> >>>
> >>>    jon
> >>
> >>Agreed.
> >>
> >>If I understand the slides correctly, they argue that what is missing
> >>are network-scope (e.g., AS-scope) addresses, to be used by
> >>hosts/routers within a domain, restricting the use (e.g.,
> >>routing/forwarding) of Internet-scope addresses to hosts and Internet
> >>gateways (e.g., inter-exchange routers).  Whatever the other merits of
> >>that approach, it won't solve the multihoming scalability problem.
> >>
> >>
> >>Regards,
> >>
> >>// Steve
> >>
> >
>
>
>

From detlef.bosau at web.de  Tue Jan 14 10:43:21 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Tue, 14 Jan 2014 19:43:21 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <20140114174404.7A470680096@frontend2.nyi.mail.srv.osa>
References: <20140114174404.7A470680096@frontend2.nyi.mail.srv.osa>
Message-ID: <52D58549.2010908@web.de>

Am 14.01.2014 18:44, schrieb Clark Gaylord:
> On Jan 13, 2014 12:25 PM, Detlef Bosau <detlef.bosau at web.de> wrote:
>> Am 13.01.2014 16:09, schrieb Ivancic, William D. (GRC-RHN0): 
>>> I strongly suggest reading John Day's book "Patterns in Network 
>>> Architecture: A Return to Fundamentals."  It is not and easy read and has 
>>> a lot of history that you may or may not find useful.  
>> It is - with all due respect towards John - the "history" which is often 
>> difficult to read in John's publications. 
>>
>> Admittedly, I'm not interested in history, when a book contains to much 
>> of it, I simply ignore it.
> https://www.youtube.com/watch?v=MuFZNqI8mc8
>
> @1:16
>
> :-)
I just want to discuss the facts. What's the problem with it?

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


From detlef.bosau at web.de  Tue Jan 14 10:44:09 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Tue, 14 Jan 2014 19:44:09 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <20140114174404.7A470680096@frontend2.nyi.mail.srv.osa>
References: <20140114174404.7A470680096@frontend2.nyi.mail.srv.osa>
Message-ID: <52D58579.7030506@web.de>

Am 14.01.2014 18:44, schrieb Clark Gaylord:
> On Jan 13, 2014 12:25 PM, Detlef Bosau <detlef.bosau at web.de> wrote:
>> Am 13.01.2014 16:09, schrieb Ivancic, William D. (GRC-RHN0): 
>>> I strongly suggest reading John Day's book "Patterns in Network 
>>> Architecture: A Return to Fundamentals."  It is not and easy read and has 
>>> a lot of history that you may or may not find useful.  
>> It is - with all due respect towards John - the "history" which is often 
>> difficult to read in John's publications. 
>>
>> Admittedly, I'm not interested in history, when a book contains to much 
>> of it, I simply ignore it.
> https://www.youtube.com/watch?v=MuFZNqI8mc8
>
> @1:16
>
> :-)
I just want to discuss the facts. What's the problem with it?

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


From detlef.bosau at web.de  Tue Jan 14 10:49:30 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Tue, 14 Jan 2014 19:49:30 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <52D520F1.1090605@web.de>
References: <CEF968E2.C979%william.d.ivancic@nasa.gov>	<52D42187.6010504@web.de>	<52D44E76.2090008@iit.demokritos.gr>
	<52D520F1.1090605@web.de>
Message-ID: <52D586BA.6050509@web.de>

And admittedly, I would greatly appreciate getting in touch with human
beings with whom I can talk about my thoughts.
That's all.

Detlef

From detlef.bosau at web.de  Sat Jan 18 07:08:38 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 18 Jan 2014 16:08:38 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <CALeNysE76O0jz78ptLS-qisC4VfSdur6y4aB7UesDvPf5ZW7_A@mail.gmail.com>
References: <52D04B36.9010005@web.de>
	<E1W1wvv-0004NV-2n@mta1.cl.cam.ac.uk>	<1389635859.8286.58.camel@tachyon.blake>
	<CEFA0FF8.4506A%matta@bu.edu>	<CEFAB8ED.450F5%matta@bu.edu>
	<CALeNysE76O0jz78ptLS-qisC4VfSdur6y4aB7UesDvPf5ZW7_A@mail.gmail.com>
Message-ID: <52DA98F6.6070102@web.de>

Am 14.01.2014 16:29, schrieb Hamed Haddadi:
> you may also like to have a look at this book chapter that covers some of
> the trade-offs very well with respect to multihoming and IPv6
>


Oh yeah. I don't know the situation abroad.

But besides Jews, Illuminati and Freemasons, Germany's top conspiracy
theories are 9/11 and IPv6. This even tops the landing in the desert in
Nevada, which was sold as the landing on the moon..... ;-)

Hamed, I want to talk about flow control and not about addressing. And
my claim is, that - please wait for the second half of the sentence
before putting me in your killfile - congestion control is questionable
because (second half of the sentence) congestion control works around a
missing flow control.

And precisely this flow control layer is really missing in TCP.

Perhaps, I make it into anybody's kill file here, however I considered
this claim quite some years and quite carefully, and I would appreciate
discussing it.

And no, I don't want to discuss addressing issues in this context,
because once a connection is established, the flow's endpoints are
associated and the flow is in a state which is far beyond any addressing
issues.

Detlef


From detlef.bosau at web.de  Sat Jan 18 07:17:48 2014
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 18 Jan 2014 16:17:48 +0100
Subject: [e2e] Lost Layer?
In-Reply-To: <52D58549.2010908@web.de>
References: <20140114174404.7A470680096@frontend2.nyi.mail.srv.osa>
	<52D58549.2010908@web.de>
Message-ID: <52DA9B1C.20600@web.de>

When Clark talks about Shere Khan we should add the scene where the
Jungle Book
which describes the scientific community ;-)

https://www.youtube.com/watch?v=zEvoKVrrhf4

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