[e2e] VJCC vs. Keshav
Jon.Crowcroft at cl.cam.ac.uk
Thu Apr 18 02:45:25 PDT 2013
I wasn't clear (as usual)
keshav wrote a simulator (somewhat before NS exists I suppose
since it pre-dates them and even Tcl) called
REAL, which I suppose he used for his PhD - this is all online here:
The REAL simulator is rather nice...
I guess it was the basis later for the startup he had called Ensim
(maybe he'll notice this and comment here)
I think the point i was trying to convey was that
packet pair (and packet train) and fair queuing (and other more active
queue management algorithms) have seen evaluation by
many people using many tools (including measurement as well as
simulation -- and also even analytical models (adversarial queuing,
network calculi etc)
and (once you get away from fifo, fluid approx stuff works, so lots of
things get easier theoretically)
but yes, something only ever done in ns2 is hardly convincing.
there are other simualtors, however and some have detailed models
of physical layer - a nice trick to consider is uing hybrid systems such as Matlab to generate a box
of code which models CSMA/CD or what have you, including a detailed scattering/fading model
and then plug that in to a discrete event simulator such as NS2 - or you could use opnet, which has detailed models
of quite a lot of low level systems ....
the world is full of wondrous things
In missive <516FBAC2.3020603 at web.de>, Detlef Bosau typed:
>>Am 17.04.2013 22:54, schrieb Jon Crowcroft:
>>> more history
>>> 1. keshav wrote his own simulator (a variant maybe of the mit x sim
>>so did I, although the thing is not published. And of course, I did not
>>reinvent the wheel but used concepts known from the ns 2.
>>> 2. other people verified fq results in other simulators
>>> 3. some people have implemented lots of variants of fq and packet
>>> probe pair/trains as well
>>> maybe you could read the source materials properly,
>>> rather than just snippets of this maillist...
>>Jon, I did. So, there is no need to blame me here.
>>However: When you look at the source material, particularly the program
>>sources of simulators, you become aware of quite some simplifications
>>frequently made. That's why I made a critical remark on "packet pair"
>>techniques and the ns2.
>>Simply and frankly spoken: Proving packet pair techniques with a
>>simulator proves absolutely nothing. Because the program code in the
>>simulator is nothing else than the system model used in the papers.
>>E.g. in the ns2 you have some kind of "bandwidth" and a serialization
>>delay which packet size / bandwidth. Fine.
>>Now, you send a number of packets, this needs a (cumulative)
>>serialization delay = Sum over all packets (packet length/Bandwidth)
>>and this is divided by the cumulative packet length - and renders what?
>>And because each and any simulator uses the same approach, they prove
>>Unfortunately, these nasty CSMA/CD Ethernets or these disgusting CSMA/CA
>>WLANs or these horrible mobile networks dare not always to behave
>>Simulators are nice. However they are, to a certain degree, GIGO
>>systems. (GIGO: Garbage In, Garbage Out.)
>>This is not to criticize simulators, but to be aware of their limitations.
>>How do we simulate CSMA/CD Ethernets with all gory details? I really
>>don't know if this is possible at all.
>>Keeping this in mind, I have no problems with simulators. It is
>>necessary, however, to keep in mind possible limitations. And the
>>simplifications, whe made.
>>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
More information about the end2end-interest