New module pgbr (PGBR routing protocol) and extension of topology-read module

New module pgbr (PGBR routing protocol) and extension of topology-read module

[Tom Henderson, 2013-10-31 13:45:39]

My initial scan of this is that it looks to be in good shape with respect to
following documentation and coding conventions.  

There are a few things bound together in this review that could be split apart,
to ease the merging and reviewing.  There is a strict priority queue model;
could it be considered for the 'src/network' module?  The topology reader patch
could be split out and separately considered.  The traffic generator may be of
more broad use as well.

I'm not suggesting to split this into separate code review issues at this time,
but we may want to consider reviewing this in chunks and seeing whether some of
the changes proposed can be pulled out over time and merged separately.

Why is the model limited to wired links only (there is a comment in the
documentation about this limitation)?  It seems like users will want to apply
this to energy-constrained devices, which are often wireless.  Also, models at
layer 3 and above shouldn't care about whether the underlying link is wired or
wireless, unless they are doing some kind of cross-layer integration.

[mineraud, 2013-10-31 15:05:10]

Hi Tom,

the organisation of the module was grouped because I had trouble updating
the code to the new version and organisation of ns-3. If I remember
correctly, I started with ns-3.5 or ns-3.6 and things have changed quite a
bit.
I could indeed split everything in separate patches because they could be
usefull for others even when not using PGBR.

The protocol is indeed limited to point-to-point networks at the moment.
One the one hand, because I used some hacks (similar to the global-routing)
to initiate the neighbours (required by the PGBR protocol). However, I was
planning to integrate it as a part of the protocol (pretty much with hello
messages) but have not taken the time to do it due to the limited research
added value. As a result, I need to initiate the protocol using the
protocol helper and this wouldnt work at the moment if some devices are not
point-to-point.

The protocol also requires to sense the link load and I have not
investigated this behaviour on wireless links.
The power manager could also be used for energy-constrained devices. But
the energy-aware mechanism for my protocol cannot (also a hack due to
communication mechanisms absent from the protocol at the current stage)

What would be the best solution to split the topology-reader, traffic
generator, traffic monitor, energy-consumption monitor, power manager into
separated patches?

P.S. Future directions are also to improve the modularity of the protocol
to support more extensions of flow-based routing.

BR,


2013/10/31 <tomh.org@gmail.com>

> My initial scan of this is that it looks to be in good shape with
> respect to following documentation and coding conventions.
>
> There are a few things bound together in this review that could be split
> apart, to ease the merging and reviewing.  There is a strict priority
> queue model; could it be considered for the 'src/network' module?  The
> topology reader patch could be split out and separately considered.  The
> traffic generator may be of more broad use as well.
>
> I'm not suggesting to split this into separate code review issues at
> this time, but we may want to consider reviewing this in chunks and
> seeing whether some of the changes proposed can be pulled out over time
> and merged separately.
>
> Why is the model limited to wired links only (there is a comment in the
> documentation about this limitation)?  It seems like users will want to
> apply this to energy-constrained devices, which are often wireless.
> Also, models at layer 3 and above shouldn't care about whether the
> underlying link is wired or wireless, unless they are doing some kind of
> cross-layer integration.
>
>
https://codereview.appspot.**com/15530043/<https://codereview.appspot.com/155...
>