actually packets stored in the channel may not have contended for the channel, whereas packets arriving at a queue are contending for the output to that queue....<div><br></div><div><br></div><div>this leads to an interesting model of shadow pricing - its a bit like changing he solid angle subtended by the source<br>
<br><div class="gmail_quote">On Fri, Mar 8, 2013 at 1:51 PM, Detlef Bosau <span dir="ltr"><<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Am 08.03.2013 00:22, schrieb Jon
Crowcroft:<br>
</div>
<blockquote type="cite">
<pre>hunh?</pre>
</blockquote>
<br>
Likewise :-)<div class="im"><br>
<br>
<blockquote type="cite">
<pre>a wire is just a channel no different from free space
except for interference and possibly slower than speed of light RF
propagation, and, depending on technology, lower interference and
lower path loss</pre>
</blockquote>
<br></div>
from a very abstract level you're right. However: From that abstract
level we don't talk about interference and path loss. <br>
Because from that abstract level, we apply Shannon-Hartley and are
simply fine.<br>
<br>
Particularly, no channel suffers from "path loss". It's not the
channel, where packets/blocks are lost. It's the receiver who
discards nonsense with defective CRC, if he is told to do so. NB:
This is definitely not the case for wireless speech connections.
Because there is no CRC check at all.<div class="im"><br>
<pre>the channel is irrelevant to this discusson, except that a wireless</pre>
<br></div>
I strongly disagree. The whole VJCC is based upon Little's law. So,
for VJCC, a channel is characterized by exactly four proberties.<br>
<br>
P1: A path capacity.<br>
P2: A path RTT.<br>
P3: Capacity and RTT are not necessarily constant but: at least <small><small>(quasi-)</small></small>stationary.<br>
P4: A loss rate, which is necessarily negligible.<br>
<br>
That's all - and these are the four inevitably required necessary
conditions for VJCC to work.<br>
<br>
(If these conditions do not hold, VJCC does something. And TCP
behaves somehow. However, this behaviour has hardly anything to do
with the congavoid paper and what we expect as "Congestion
Control".)<div class="im"><br>
<br>
<blockquote type="cite">
<pre>channel may be shared so you can see contention for the receive
antennae (some people talk about contention for the media too, but
that's a figment of the technology of choice for MAC)...
so i have no idea where you think packets are stored except in
senders' and receivers' NICs' buffers....</pre>
</blockquote>
<br></div>
This is an academic question. However: If no data were stored along
the channels, there would be no need for flow control and congestion
control, we could employ a wired handshake as in V.24 with RTS/CTS,
DSR/DTR.<br>
<br>
<br>
VJCC does not make a difference whether data is stored in buffers or
along the channel.<div class="im"><br>
<br>
<blockquote type="cite">
<pre>you need to haev a REALLY long haul link to get a lot of packets
in transit (propagation) - these are unusual cases (satellites)
</pre>
</blockquote></div>
and intercontinental fibres - and it's that "irrelevant" that BIC
and CuBIC have been proposed.<div class="im"><br>
<br>
<br>
<blockquote type="cite">
<pre>basically (comms #101) - you have the
packet serialisation time (s=clock speed*packet length)</pre>
</blockquote>
<br></div>
That's another point where I strongly disagree. The term
"serialization delay" is, frankly spoken, complete nonsense in the
context of wireless networks.<br>
<br>
We can talk about service times for a block/packet to be
successfully delivered along a wireless channel. <br>
<br>
Hence, we can talk about capacity/service time/loss rate for a
wireless channel. It does, however, make ABSOLUTELY NO SENSE to talk
about serialization delays in thes context. <br>
<br>
(I did not yet have a look at the NS3, so I don't know whether this
was changed. What's used in the NS2 in this context is simply
complete nonsense. The model used there is simply completely wrong.
Although I will ask for additional memory for my mailbox for the
next two hours to have capacity for the rants, I'm "looking forward
to".)<br>
<br>
(From what I'm told, CS guys are polite and well behaved. They do
not rant, but on some occasions they throw chairs ;-))<div class="im"><br>
<br>
<blockquote type="cite">
<pre>and you have the packet propagation time (p=link geodistance / c)
</pre>
</blockquote>
<br></div>
Which is of no interest for VJCC because it's encapsulated in the
service time.<div class="im"><br>
<br>
<blockquote type="cite">
<pre>so the case of packets in transit is plural, is when p/s > 1
which is not too many cases...
anyhow that's not what congestion or contention are about
</pre>
</blockquote>
<br></div>
If the path's capacity is sufficiently low (which is almost
certainly the case in terrestrial wireless networks) I agree.<br>
<br>
So, I said we can use stop'n wait.<div class="im"><br>
<br>
<br>
<pre cols="72">--
------------------------------------------------------------------
Detlef Bosau
Galileistraße 30
70565 Stuttgart Tel.: <a href="tel:%2B49%20711%205208031" value="+497115208031" target="_blank">+49 711 5208031</a>
mobile: <a href="tel:%2B49%20172%206819937" value="+491726819937" target="_blank">+49 172 6819937</a>
skype: detlef.bosau
ICQ: 566129673
<a href="mailto:detlef.bosau@web.de" target="_blank">detlef.bosau@web.de</a> <a href="http://www.detlef-bosau.de" target="_blank">http://www.detlef-bosau.de</a>
</pre>
</div></div>
</blockquote></div><br></div>