From detlef.bosau at web.de  Sun Mar 25 08:27:23 2012
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sun, 25 Mar 2012 17:27:23 +0200
Subject: [e2e] Flow Control in IP, Deadlocks in Routing Protocols.
Message-ID: <4F6F395B.9040509@web.de>

RFC 791 specifies:

>    There are no mechanisms to augment end-to-end data
>    reliability, flow control, sequencing, or other services commonly
>    found in host-to-host protocols.

>    The internet protocol does not provide a reliable communication
>    facility.  There are no acknowledgments either end-to-end or
>    hop-by-hop.  There is no error control for data, only a header
>    checksum.  There are no retransmissions.  There is no flow control.
Is this still valid?

In a paper I read the following:

> The functions of routing algorithm are the provision of the
> fastest path, deadlocks prevention, low latency insurance,
> network utilization balancing, and fault tolerance. Routing
> algorithms in mesh-connected topologies can be classified as
> follows:[4].

Does this make sense? The system model in the quoted paper is an overlay 
network upon the Internet.
To my understanding, routing deadlocks cannot happen in this context, 
because there is no flow control and consequently a sender does not wait 
for a receiver getting ready to receive a packet.

So, it may sound harsh, but in my opinion, the requirements stated in 
this section do not really make sense.

Thx.

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 dhavey at yahoo.com  Sun Mar 25 08:58:40 2012
From: dhavey at yahoo.com (Daniel Havey)
Date: Sun, 25 Mar 2012 08:58:40 -0700 (PDT)
Subject: [e2e] Flow Control in IP, Deadlocks in Routing Protocols.
In-Reply-To: <4F6F395B.9040509@web.de>
Message-ID: <1332691120.23275.YahooMailClassic@web130104.mail.mud.yahoo.com>

Perhaps it does, depends on context.  If the overlay protocol performs it's own flow control then there could be deadlock.

So we have 2 messages each waiting for the other to complete.  If the overlay refuses to send the message down the stack until the other message is completed then we could get a deadlock.

Otherwise it makes no sense.  If either message is passed to IP then it will get sent, therefore, there is no deadlock.

...Daniel



> >? ? There are no mechanisms to augment
> end-to-end data
> >? ? reliability, flow control, sequencing, or
> other services commonly
> >? ? found in host-to-host protocols.
> 
> >? ? The internet protocol does not provide a
> reliable communication
> >? ? facility.? There are no
> acknowledgments either end-to-end or
> >? ? hop-by-hop.? There is no error
> control for data, only a header
> >? ? checksum.? There are no
> retransmissions.? There is no flow control.
> Is this still valid?
> 
> In a paper I read the following:
> 
> > The functions of routing algorithm are the provision of
> the
> > fastest path, deadlocks prevention, low latency
> insurance,
> > network utilization balancing, and fault tolerance.
> Routing
> > algorithms in mesh-connected topologies can be
> classified as
> > follows:[4].
> 
> Does this make sense? The system model in the quoted paper
> is an overlay network upon the Internet.
> To my understanding, routing deadlocks cannot happen in this
> context, because there is no flow control and consequently a
> sender does not wait for a receiver getting ready to receive
> a packet.
> 
> So, it may sound harsh, but in my opinion, the requirements
> stated in this section do not really make sense.
> 
> Thx.
> 
> 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 detlef.bosau at web.de  Sun Mar 25 11:04:02 2012
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sun, 25 Mar 2012 20:04:02 +0200
Subject: [e2e] Flow Control in IP, Deadlocks in Routing Protocols.
In-Reply-To: <1332691120.23275.YahooMailClassic@web130104.mail.mud.yahoo.com>
References: <1332691120.23275.YahooMailClassic@web130104.mail.mud.yahoo.com>
Message-ID: <4F6F5E12.8070907@web.de>

On 03/25/2012 05:58 PM, Daniel Havey wrote:
> Perhaps it does, depends on context.  If the overlay protocol performs it's own flow control then there could be deadlock.

I will have a closer look on the paper, hower: to my understanding, it 
doesn't.

> So we have 2 messages each waiting for the other to complete.  If the overlay refuses to send the message down the stack until the other message is completed then we could get a deadlock.

Of course. However, if we set up an overlay above the Internet, we 
should be extremely careful to introduce mechanisms which may cause 
deadlocks....

-- 
------------------------------------------------------------------
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 paalh at ifi.uio.no  Mon Mar 26 05:05:43 2012
From: paalh at ifi.uio.no (=?iso-8859-1?Q?P=E5l_Halvorsen?=)
Date: Mon, 26 Mar 2012 14:05:43 +0200
Subject: [e2e] Available PHD research fellowship in the area of
	Video/signal/3D Processing
Message-ID: <C2A191B5-1EA4-417B-B177-02F15C754F67@ifi.uio.no>

There is a position as PhD Research fellow in Video Processing available
in the iAD Centre for Research Based Innovation at the Department for
Informatics, University of Oslo, Norway

The PhD research fellow will work in the area of real-time processing
and delivery of (3D) video where the fellow takes part in forming a
relatively new activity within our research group. Generally, topics
of interest include multiview/freeview coding, 3D object extraction
and 3D video analysis, 3D rendering and display, and efficient
(real-time) processing and transport of such streams. 

The position is connected to the iAD Centre for Research Based
Innovation with other partners such as Microsoft, Accenture, Funcom,
ComoYo, ZXY and the Universities in Troms?, Trondheim, Dublin
(Ireland) and Cornell (USA) 

The fellowship is for a period of 3 years. Starting date as soon as
possible, but no later than August 1, 2012. 

Application deadline: April 10, 2012

For more details about applying for the position:
https://uio.easycruit.com/vacancy/709951/64290?iso=no

For more details about the research plan associated with this
position see 
http://home.ifi.uio.no/paalh/iad-phd2012/

---- Paal Halvorsen ---- home.ifi.uio.no/paalh ----



From alexsm at gmail.com  Tue Mar 27 16:05:20 2012
From: alexsm at gmail.com (Alex Moura)
Date: Tue, 27 Mar 2012 20:05:20 -0300
Subject: [e2e] BufferBloat: What's Wrong with the Internet?
In-Reply-To: <DDBA3A42-7EB8-4915-AED4-D5B88470C120@gmail.com>
References: <20111212081120.B1B8812036A@pegasus.na-df.rnp.br>
	<DDBA3A42-7EB8-4915-AED4-D5B88470C120@gmail.com>
Message-ID: <CABPMKoVvtLsyC91-UAqtjL_aKr-2eoXiFEfwWyDsP6hfBndkiw@mail.gmail.com>

Linux 3.3: Finally a little good news for bufferbloat
By Robert X. Cringley
Mar 25, 2012
http://www.cringely.com/2012/03/linux-3-3-finally-a-little-good-news-for-bufferbloat/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20120327/6f1d1cff/attachment.html