<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 24.02.2013 18:36, schrieb John Day:<br>
</div>
<blockquote cite="mid:a062408b2cd4ffe646ba1@%5B10.0.1.3%5D"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=iso-8859-1">
<title>Re: [e2e] How do we deal with mobile
networks?</title>
<div>I don't know if this helps, but the fundamental premise of
this
form of architecture (and understood from the beginning in the
early
70s) is that the purpose of the data link layer is to provide
sufficient error control to ensure that end-to-end reliability
at the
Transport Layer is cost-effective.</div>
</blockquote>
<br>
Let me quote VJ's Rant on Queues from 2006 here:<br>
<br>
<blockquote type="cite">Suggestions (cont.)<br>
additional delay<br>
• Never introducewith packets): (apps will<br>
just try to fill it<br>
<i>‣ Let apps do their own FEC;</i><i><br>
</i><i>avoid link layer Reed-Solomon and ARQ.</i><br>
‣ Use smooth, simple downlink schedulers<br>
‣ Use predictive and anticipatory uplink<br>
schedulers<br>
</blockquote>
(Accentuation done by me)<br>
<br>
and RFC 791.<br>
<br>
<blockquote type="cite">
<pre>1.2. Scope
The internet protocol is specifically limited in scope to provide the
functions necessary to deliver a package of bits (an internet
datagram) from a source to a destination over an interconnected system
of networks. <i> There are no mechanisms to augment end-to-end data
reliability</i>, flow control, sequencing, or other services commonly
found in host-to-host protocols. The internet protocol can capitalize
on the services of its supporting networks to provide various types
and qualities of service.</pre>
</blockquote>
(Acc. d. b.me )<br>
<br>
And please note that the assumption "no flow control" should be
understood as "we must not do flow control on link layer", e.g. in
Ethernet.<br>
Please note that enabling flow control on link layer may lead to
communication deadlocks which are, without appropriate means,
neither detected nor handled by IP.<br>
<br>
So, it is a valid position to request that any retransmission of
lost packets should be done end to end, as required by VJ. <br>
<br>
However, I think, this position does not really hold.<br>
<br>
<blockquote cite="mid:a062408b2cd4ffe646ba1@%5B10.0.1.3%5D"
type="cite">
<div><br>
</div>
<div>IOW, since most loss above the Data Link Layer is due to
congestion, the Data Link Layer should provide enough error
recovery
to stay well within acceptable losses due to congestion in the
layers
above.</div>
</blockquote>
<br>
That should be the correct position, however to my understanding it
is not fully supported in literature and apparently, this is not
common sense at the moment. <br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: +49 711 5208031
mobile: +49 172 6819937
skype: detlef.bosau
ICQ: 566129673
<a class="moz-txt-link-abbreviated" href="mailto:detlef.bosau@web.de">detlef.bosau@web.de</a> <a class="moz-txt-link-freetext" href="http://www.detlef-bosau.de">http://www.detlef-bosau.de</a>
</pre>
</body>
</html>