GSOC 2020 NetDevice Up/Down Consistency Updates

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

GSOC 2020 NetDevice Up/Down Consistency Updates

Anantha krishnan saji
Hello all,

After discussing with the mentor, we reached a consensus on NetDevice
Behavior. A NetDevice can be in any of the three states: DOWN, UP, and
RUNNING. This is to distinguish between administrative (active/inactive)
and operational states (Connected/ Disconnected).

   - DOWN State means that NetDevice that is present in a node, will not be
   used for transmission of data. It is inactive.
   - UP state means that a NetDevice is active but there is no carrier
   connected to it. It might be doing device-dependent tasks.
   - Once an active NetDevice gets connected to a carrier, it goes into the
   RUNNING state and is able to transmit and receive packets.

To implement this, the following changes are proposed on the NetDevice API:

Add these methods:
NetDevice::SetDeviceUp()
NetDevice::SetDeviceDown()
NetDevice::AddDeviceStatusChangeCallback
NetDevice::RemoveDeviceStatusChangeCallback
NetDevice::IsStatusUp()
NetDevice::IsStatusDown()
NetDevice::IsStatusRunning()

There is no need for methods to set a NetDevice to the RUNNING state
because once a carrier is attached, NetDevice will change state to RUNNING
and once it loses the carrier, NetDevice goes back to UP state.

Deprecate the following:
NetDevice::AddLinkChangeCallback
NetDevice::IsLinkUp
NetDevice::isLinkDown

These methods need to be deprecated because new methods supersede their
functionality. This week I will make these changes in the code. Also, I
will add the documentation relevant to the changes.

Last week was spent on making this guideline on Net device behavior
inspired by the Linux Kernel. More details on this proposal can be found
here: link
<https://docs.google.com/document/d/1t7MN63itRNjUoCqjFLM3voVk2_Iw5UAWOisUsc33KVI/edit?usp=sharing>

Thanks and Regards,
Ananthakrishnan S
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Natale Patriciello
On 09/06/20 at 07:36pm, Ananthakrishnan S wrote:
> Hello all,
>
> After discussing with the mentor, we reached a consensus on NetDevice
> Behavior. A NetDevice can be in any of the three states: DOWN, UP, and
> RUNNING. This is to distinguish between administrative (active/inactive)
> and operational states (Connected/ Disconnected).


Hello,

I have a question: is the management of these states mandatory, or a
NetDevice can just provide empty implementation for the methods you
described, and everything can continue working (i.e., always in the
"connected" state, as per your definition)?

Thanks

Nat
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Tommaso Pecorella
Hi Nat,

actually NetDevice is a pure virtual class, i.e., all the methods must be implemented.

In order to minimize the transition to the new interface (i.e., don't break what's actually working), we are thinking to use virtual functions (not pure), and provide a default implementation of the relevant methods.

Actually all the state machine could be handled by the NetDevice, with just SetDeviceUp and SetDeviceDown being actually implemented in subclasses.

As for the difference between administrative and operational states, it's up to the particular NetDevice to implement what's "right" for NetDevice itself.
I.e., while for a Csma and a P2P interface it "makes sense" to have a connected and disconnected status (e.g., if we cut the cable), for a WiFi it's a little bit more complex to define a "disconnected" case.

However, at the end of the day a NetDevice will have to just refer to the 3 main states: DOWN, UP, and RUNNING, where only in RUNNING you can effectively transmit and receive.
About the difference between DOWN and UP, think to it in this way. In the DOWN state a WiFi wouldn't even send out probe requests, while in the UP state it does.

I understand that NetDevice::SetDeviceUp() and NetDevice::SetDeviceDown() might be confusing at first - but we are trying to mimic the Linux approach.
Setting an Interface to "down" in Linux doesn't (always) shut it down. The specific NetDevice is fully responsible to manage its internal transitions and to reflect them into the "public" states.

In other terms, a NetDevice is free to be always in "connected" state - if it does make sense for the device. However, we *do* expect to have callbacks fired if it looses its ability to transmit packets.

Suppose this (simple) example:
- WiFi or LTE NetDevices moving around. They loose their actual AP (or BS), and they try to gracefully do an handover.

Expected result:
- Successful seamless handover -> no callback fired, state is kept on RUNNING.
- Unsuccessful seamless handover (i.e., IP must be re-negotiated) -> Callback fired twice, state transition from RUNNING to UP, and back to RUNNING.
- Unsuccessful handover (no new AP or BS found) ->  Callback fired once, state transition from RUNNING to UP (or DOWN, it's up to the NetDevice).
Now suppose that after an Unsuccessful handover (no new AP or BS found) the interface is in UP state, and after some time it decides (autonomously) to go into deep sleep. -> Callback fired once, state transition from UP to DOWN.
... after some time, it wakes up (autonomously) to probe if the's an AP or a BS available ->  Callback fired once, state transition from DOWN  to UP.

Of course the deep sleep is a limit case, and might not even be worth implementing. Still... if one *wants* to implement it... why not ?

Mind that, for real, what we're interested into is to be able to support effective handover cases, where the full stack must react to these events in the right way, i.e., reconfiguring the IP addresses if needed, invalidate sockets if needed, etc. That's our goal.

Cheers,

T.



> On 11 Jun 2020, at 10:46, Natale Patriciello <[hidden email]> wrote:
>
> On 09/06/20 at 07:36pm, Ananthakrishnan S wrote:
>> Hello all,
>>
>> After discussing with the mentor, we reached a consensus on NetDevice
>> Behavior. A NetDevice can be in any of the three states: DOWN, UP, and
>> RUNNING. This is to distinguish between administrative (active/inactive)
>> and operational states (Connected/ Disconnected).
>
>
> Hello,
>
> I have a question: is the management of these states mandatory, or a
> NetDevice can just provide empty implementation for the methods you
> described, and everything can continue working (i.e., always in the
> "connected" state, as per your definition)?
>
> Thanks
>
> Nat

--------------------------------------------------------------

In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.
-- R. Callon, RFC 1925

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [hidden email]
       [hidden email]

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570






Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Natale Patriciello
On 11/06/20 at 02:36pm, Tommaso Pecorella wrote:
> Hi Nat,
>
> actually NetDevice is a pure virtual class, i.e., all the methods must be implemented.
>
> In order to minimize the transition to the new interface (i.e., don't break what's actually working), we are thinking to use virtual functions (not pure), and provide a default implementation of the relevant methods.

Yes please, because LTE is unlikely to pass to the new system that
you're thinking. I'll write some sentences which the bottom line is,
please provide a default configuration in which everything would work as
it is, as LTE will most probably use the default configuration without
additional code.

[cut]
> Suppose this (simple) example:
> - WiFi or LTE NetDevices moving around. They loose their actual AP (or BS), and they try to gracefully do an handover.

Unfortunately LTE is more complicated than that, it involves layers and
layers of protocol stack. For example, I don't think it loses the IP if
you do an handover in the same operator network. Moreover, it is
designed to be really different from the network you typically see in
school. In ns-3, there are multiple netdevices (even in the same node)
that have very different meanings. For example, you have the UE netdevice
towards the enb, the ENB netdevice towards the UEs, but also ENB
netdevice towards the central intelligence (with separate applications
in the EPC/PGW, as well in the ENB, that takes care of
encapsulation and de-caps. of packets and headers). To make everything more
subtle, consider that the single NetDevice in the ENB can in reality
serve multiple physical layers (one for each component carrier), and
each of these component carriers have a different state (e.g., they can
be active or inactive).

Now, an example, if an UE is handovering between ENBs, it will not
lose any data as there is an hidden queue in the RRC layer, that will be
activated when the UE comes back in the RRC-CONNECTED state. So the
NetDevice must stay in the "connected" state at every time.

I completely support the example of Linux for what regards the
architecture, but please consider that it may work for ethernet and WiFi
(as the code is inside Linux) but don't assume it applies for the LTE
stack. BTW, in Linux any LTE netdev is modeled as a pass-through modem,
without flow control, and nothing else in the middle. You just deliver
the packet to the modem, and the blob firmware will do the (nasty)
things for you. So, by coming back for my initial comment: please,
provide a default configuration :)


Thanks,
Nat
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Tommaso Pecorella
Hi Nat,

I understand your concerns, and the main goal is to *not* require any additional code in the exisiting NetDevices, unless one wants to support "extended" use-cases.

As for the LTE system, unfortunately I know it quite well - not the ns-3 code, I'm talking about LTE as a standard.

As I said, some NetDevice will have benefits from supporting the new interfaces. Some will not have any benefit - or it simlply woudln't make a lot of sense for them.

Keeping on the LTE example, I'd expect that a LteEnbNetDevice would always be in RUNNING state - it doesn't make sense to have it in a different state.

A LteUeNetDevice, veiceversa, *might* want to switch its states if the Node goes out of range. If it does, then IP will be happy. If it doesn't... well, I'll not throw a fit. It just means that the user will have to cope with the fact that the IP interfaces will "think" that the NetDevice is up and running.
In other terms, you'll not be able to simulate that the Node is loosing its IP and getting it back. Not a drama, the important part is to have this behaviour documented

Moreover, you'll not be able to simulate the transition between two different service providers, i.e., roaming between two operators. Is this important ? Your call. The important part is that the NetDevice (the base class) has the means to do it.

Right now, our goal is to support CSMA, P2P, and WiFi. LTE will be a bonus, and if we'll include it, we'll provide a patch.

Cheers,

T.


> On 11 Jun 2020, at 15:14, Natale Patriciello <[hidden email]> wrote:
>
> On 11/06/20 at 02:36pm, Tommaso Pecorella wrote:
>> Hi Nat,
>>
>> actually NetDevice is a pure virtual class, i.e., all the methods must be implemented.
>>
>> In order to minimize the transition to the new interface (i.e., don't break what's actually working), we are thinking to use virtual functions (not pure), and provide a default implementation of the relevant methods.
>
> Yes please, because LTE is unlikely to pass to the new system that
> you're thinking. I'll write some sentences which the bottom line is,
> please provide a default configuration in which everything would work as
> it is, as LTE will most probably use the default configuration without
> additional code.
>
> [cut]
>> Suppose this (simple) example:
>> - WiFi or LTE NetDevices moving around. They loose their actual AP (or BS), and they try to gracefully do an handover.
>
> Unfortunately LTE is more complicated than that, it involves layers and
> layers of protocol stack. For example, I don't think it loses the IP if
> you do an handover in the same operator network. Moreover, it is
> designed to be really different from the network you typically see in
> school. In ns-3, there are multiple netdevices (even in the same node)
> that have very different meanings. For example, you have the UE netdevice
> towards the enb, the ENB netdevice towards the UEs, but also ENB
> netdevice towards the central intelligence (with separate applications
> in the EPC/PGW, as well in the ENB, that takes care of
> encapsulation and de-caps. of packets and headers). To make everything more
> subtle, consider that the single NetDevice in the ENB can in reality
> serve multiple physical layers (one for each component carrier), and
> each of these component carriers have a different state (e.g., they can
> be active or inactive).
>
> Now, an example, if an UE is handovering between ENBs, it will not
> lose any data as there is an hidden queue in the RRC layer, that will be
> activated when the UE comes back in the RRC-CONNECTED state. So the
> NetDevice must stay in the "connected" state at every time.
>
> I completely support the example of Linux for what regards the
> architecture, but please consider that it may work for ethernet and WiFi
> (as the code is inside Linux) but don't assume it applies for the LTE
> stack. BTW, in Linux any LTE netdev is modeled as a pass-through modem,
> without flow control, and nothing else in the middle. You just deliver
> the packet to the modem, and the blob firmware will do the (nasty)
> things for you. So, by coming back for my initial comment: please,
> provide a default configuration :)
>
>
> Thanks,
> Nat

--------------------------------------------------------------

In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.
-- R. Callon, RFC 1925

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [hidden email]
       [hidden email]

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570






Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Tom Henderson-2
In reply to this post by Anantha krishnan saji
On 6/9/20 12:36 PM, Ananthakrishnan S wrote:

> Hello all,
>
> After discussing with the mentor, we reached a consensus on NetDevice
> Behavior. A NetDevice can be in any of the three states: DOWN, UP, and
> RUNNING. This is to distinguish between administrative (active/inactive)
> and operational states (Connected/ Disconnected).
>
>     - DOWN State means that NetDevice that is present in a node, will not be
>     used for transmission of data. It is inactive.
>     - UP state means that a NetDevice is active but there is no carrier
>     connected to it. It might be doing device-dependent tasks.
>     - Once an active NetDevice gets connected to a carrier, it goes into the
>     RUNNING state and is able to transmit and receive packets.

In Linux, the UP flag is distinct from RUNNING:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/if.h#L91

If we follow the proposal and make it a tri-state, it may cause some
confusion because in ns-3, UP would mean that it is not RUNNING, while
in a Linux system, RUNNING devices are also UP.

there are also some more recently introduced flags which may be useful:
'LOWER_UP' and 'DORMANT'.  Have you thought about supporting those?

>
> To implement this, the following changes are proposed on the NetDevice API:
>
> Add these methods:
> NetDevice::SetDeviceUp()
> NetDevice::SetDeviceDown()

For API consistency with other methods, it would probably be SetUp() and
SetDown ().

> NetDevice::AddDeviceStatusChangeCallback
> NetDevice::RemoveDeviceStatusChangeCallback
> NetDevice::IsStatusUp()
> NetDevice::IsStatusDown()

Likewise, IsUp() is more aligned to other methods than IsStatusUp().
IsDown() is not needed.

> NetDevice::IsStatusRunning()

If running is split from Up/Down, then IsRunning() would be needed.

>
> There is no need for methods to set a NetDevice to the RUNNING state
> because once a carrier is attached, NetDevice will change state to RUNNING
> and once it loses the carrier, NetDevice goes back to UP state.
>
> Deprecate the following:
> NetDevice::AddLinkChangeCallback
> NetDevice::IsLinkUp
> NetDevice::isLinkDown

There is some inconsistent handling of the above three methods in the
existing code.  In some cases, they just signal that the device is
initialized at time 0, in others, they will toggle state during runtime,
and in LTE, they are not functional.

We seem to be wading into a common inheritance problem in which there is
interest to add methods to the base class, but not all subclasses are
interested in implementing them (see Natale's comment).  Long ago, we
decided to use object aggregation to solve these kinds of issues.  What
do people think about creating a NetDeviceStatus or NetDeviceState
object and aggregating it to those NetDevice subclasses that want to
support this API?

- Tom
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Tommaso Pecorella
Just a thought about aggregation: I'm neutral to this point, provided that IP (or any layer above a NetDevice) will not be able to be agnostic about a NetDevice implementing it or not.

The goal of the project is to react to NetDevice events in a consistent and predictable way in the layers above the NetDevice - in order to support complex scenarios where a Node changes its network setup and (possibly) its IP numbers, routing, etc.

Object aggregation means that the "upper layers" will have to have a code like:
- Get the NetDevice
- Ask if it aggregates a particular object (e.g., NetDeviceState)
- If so, link to it
- Else, assume that the status is always ready-to-run

Using virtual functions means:
- Get a NetDevice
- Link to a callback (by default it won't do anything)
- Ask its status (by default it will be ready-to-run)

Complexity-wise, they're identical.
From the point of view of the NetDevice, they'll be identical.
From the point of view of the implementor they're not identical (see OMG-THEY-CHANGE-SOMETHING-IN-THE-BASE-CLASS -> PANIK)
From the point of view of the documentation (i.e., the final user) they're not identical <- this is what matters the most to me.

It will be far easier to spot what NetDevice is using the "new" system - simply because they do aggregate a class - and by doing so they support it.

Summarizing: I second the idea of using aggregation... but I'd still deprecate the "old" APIs - as they will generate confusion. Not a biggie - nobody is using them.

Cheers,

T.



> On 11 Jun 2020, at 17:14, Tom Henderson <[hidden email]> wrote:
>
>
> We seem to be wading into a common inheritance problem in which there is interest to add methods to the base class, but not all subclasses are interested in implementing them (see Natale's comment).  Long ago, we decided to use object aggregation to solve these kinds of issues.  What do people think about creating a NetDeviceStatus or NetDeviceState object and aggregating it to those NetDevice subclasses that want to support this API?
>
> - Tom

--------------------------------------------------------------

Ciò che consente all'uomo di superare i propri demoni, é quando gli pesa il culo per assecondarli.
-- Zerocalcare

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: [hidden email]
       [hidden email]

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570







Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Peter Barnes-4
In reply to this post by Natale Patriciello
So rather than saying “LTE won’t support", how about considering reasonable behaviors when the NetDevice is asked to change states.  For example, when asked to go DOWN (airplane mode?) wouldn’t it be reasonable for LTE to go to disconnected state?  and conversely when asked to go UP/RUNNING?

> On Jun 11, 2020, at 6:14 AM, Natale Patriciello <[hidden email]> wrote:
>
> in Linux any LTE netdev is modeled as a pass-through modem,
> without flow control, and nothing else in the middle. You just deliver
> the packet to the modem, and the blob firmware will do the (nasty)
> things for you.

____________
Peter Barnes
[hidden email] <mailto:[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Natale Patriciello
On 11/06/20 at 09:09am, Peter Barnes wrote:
> So rather than saying “LTE won’t support", how about considering
> reasonable behaviors when the NetDevice is asked to change states.

From my understanding, the focus of the project is not on LTE... So
maybe, the correct wording would have been a general warning, about the
fact that including LTE in the development process can be
tedious and time-consuming, so the idea of Tommaso of going with a
default configuration that will work everywhere gets a big +1 from me.

> For example, when asked to go DOWN (airplane mode?) wouldn’t it be
> reasonable for LTE to go to disconnected state?  and conversely when
> asked to go UP/RUNNING?


Of course, with time and dedicated resources, the community can add a
standard-compliant airplane mode, and can add the relevant states to the
UE RRC state machine presented here [1]. Probably the figure is not
updated, as I remember that there was some work done to add an IDLE
mode. Or probably is updated, I didn't follow such work. Anyway, ENB/EPC/PGW
will always be RUNNING, so a default "RUNNING" configuration will always
be needed.

Anyway, before the airplane mode, the community would have to consider
what is the meaning of the NetDevice states DOWN, UP, RUNNING, in case
of multiple component carriers, in which some can be active and
others disabled. The upper layer traffic is reaching LTE through a
single NetDevice, and then is routed among CCs following the bearer
ID assigned with a filter on the transport port. So, if the CCs have
different status (on/off), then some flows should see the NetDevice as
DOWN, while others as RUNNING. All of this can be easily an entire GSoC
project of its own.

I would recommend to the community of going with the default "RUNNING"
state for the moment, and concentrate in other aspect, such as [2],
which is invalidating all the results obtained with different CCs, at
least from the pathloss model point of view.

all this IMHO, I am not involved with LTE :)

Ciao,
Nat


[1] https://www.nsnam.org/docs/models/html/lte-design.html#ue-rrc-state-machine
[2] https://gitlab.com/nsnam/ns-3-dev/-/issues/181
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Anantha krishnan saji
In reply to this post by Tom Henderson-2
>
> there are also some more recently introduced flags which may be useful:
> 'LOWER_UP' and 'DORMANT'.  Have you thought about supporting those?
>

IFF_LOWER_UP and IFF_DORMANT flags are, I think, used to well describe the
state of a NetDevice.  IFF_LOWER_UP flag shows whether the device detected
a loss of carrier while IFF_DORMANT flag shows that the device cannot yet
be used because some driver-controlled protocol establishment has to
complete but NetDevice is operational in the sense it is connected. If
anyone is interested in reading more it is explained in  RFC 2863 section
3.1.12 and 3.1.13 link <https://tools.ietf.org/html/rfc2863#page-19>.
In the proposal, RUNNING state means that NetDevice is connected and
operational (i.e above-mentioned protocol establishments are taken care
of). Is there a need to support IFF_DORMANT?

For API consistency with other methods, it would probably be SetUp() and
> SetDown ().
>

I will change the methods accordingly.

Regards,
Ananthakrishnan S

On Thu, Jun 11, 2020 at 3:15 PM Tom Henderson <[hidden email]> wrote:

> On 6/9/20 12:36 PM, Ananthakrishnan S wrote:
> > Hello all,
> >
> > After discussing with the mentor, we reached a consensus on NetDevice
> > Behavior. A NetDevice can be in any of the three states: DOWN, UP, and
> > RUNNING. This is to distinguish between administrative (active/inactive)
> > and operational states (Connected/ Disconnected).
> >
> >     - DOWN State means that NetDevice that is present in a node, will
> not be
> >     used for transmission of data. It is inactive.
> >     - UP state means that a NetDevice is active but there is no carrier
> >     connected to it. It might be doing device-dependent tasks.
> >     - Once an active NetDevice gets connected to a carrier, it goes into
> the
> >     RUNNING state and is able to transmit and receive packets.
>
> In Linux, the UP flag is distinct from RUNNING:
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/if.h#L91
>
> If we follow the proposal and make it a tri-state, it may cause some
> confusion because in ns-3, UP would mean that it is not RUNNING, while
> in a Linux system, RUNNING devices are also UP.
>
> there are also some more recently introduced flags which may be useful:
> 'LOWER_UP' and 'DORMANT'.  Have you thought about supporting those?
>
> >
> > To implement this, the following changes are proposed on the NetDevice
> API:
> >
> > Add these methods:
> > NetDevice::SetDeviceUp()
> > NetDevice::SetDeviceDown()
>
> For API consistency with other methods, it would probably be SetUp() and
> SetDown ().
>
> > NetDevice::AddDeviceStatusChangeCallback
> > NetDevice::RemoveDeviceStatusChangeCallback
> > NetDevice::IsStatusUp()
> > NetDevice::IsStatusDown()
>
> Likewise, IsUp() is more aligned to other methods than IsStatusUp().
> IsDown() is not needed.
>
> > NetDevice::IsStatusRunning()
>
> If running is split from Up/Down, then IsRunning() would be needed.
>
> >
> > There is no need for methods to set a NetDevice to the RUNNING state
> > because once a carrier is attached, NetDevice will change state to
> RUNNING
> > and once it loses the carrier, NetDevice goes back to UP state.
> >
> > Deprecate the following:
> > NetDevice::AddLinkChangeCallback
> > NetDevice::IsLinkUp
> > NetDevice::isLinkDown
>
> There is some inconsistent handling of the above three methods in the
> existing code.  In some cases, they just signal that the device is
> initialized at time 0, in others, they will toggle state during runtime,
> and in LTE, they are not functional.
>
> We seem to be wading into a common inheritance problem in which there is
> interest to add methods to the base class, but not all subclasses are
> interested in implementing them (see Natale's comment).  Long ago, we
> decided to use object aggregation to solve these kinds of issues.  What
> do people think about creating a NetDeviceStatus or NetDeviceState
> object and aggregating it to those NetDevice subclasses that want to
> support this API?
>
> - Tom
>
Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Barnes, Peter D.
In reply to this post by Natale Patriciello
Thanks Nat, that helps a lot in understanding your perspective.

P

On Jun 11, 2020, at 11:51 AM, Natale Patriciello <[hidden email]<mailto:[hidden email]>> wrote:

On 11/06/20 at 09:09am, Peter Barnes wrote:
So rather than saying “LTE won’t support", how about considering
reasonable behaviors when the NetDevice is asked to change states.

From my understanding, the focus of the project is not on LTE... So
maybe, the correct wording would have been a general warning, about the
fact that including LTE in the development process can be
tedious and time-consuming, so the idea of Tommaso of going with a
default configuration that will work everywhere gets a big +1 from me.

For example, when asked to go DOWN (airplane mode?) wouldn’t it be
reasonable for LTE to go to disconnected state?  and conversely when
asked to go UP/RUNNING?


Of course, with time and dedicated resources, the community can add a
standard-compliant airplane mode, and can add the relevant states to the
UE RRC state machine presented here [1]. Probably the figure is not
updated, as I remember that there was some work done to add an IDLE
mode. Or probably is updated, I didn't follow such work. Anyway, ENB/EPC/PGW
will always be RUNNING, so a default "RUNNING" configuration will always
be needed.

Anyway, before the airplane mode, the community would have to consider
what is the meaning of the NetDevice states DOWN, UP, RUNNING, in case
of multiple component carriers, in which some can be active and
others disabled. The upper layer traffic is reaching LTE through a
single NetDevice, and then is routed among CCs following the bearer
ID assigned with a filter on the transport port. So, if the CCs have
different status (on/off), then some flows should see the NetDevice as
DOWN, while others as RUNNING. All of this can be easily an entire GSoC
project of its own.

I would recommend to the community of going with the default "RUNNING"
state for the moment, and concentrate in other aspect, such as [2],
which is invalidating all the results obtained with different CCs, at
least from the pathloss model point of view.

all this IMHO, I am not involved with LTE :)

Ciao,
Nat


[1] https://www.nsnam.org/docs/models/html/lte-design.html#ue-rrc-state-machine
[2] https://gitlab.com/nsnam/ns-3-dev/-/issues/181

____________
Peter Barnes
[hidden email]<mailto:[hidden email]>





_____________________________________________________________
Dr. Peter D. Barnes, Jr. CASC Division, B451 R2035
Lawrence Livermore National Laboratory Computation Directorate
7000 East Avenue, L-561 email:  [hidden email]<mailto:[hidden email]>
P. O. Box 808 Voice:  (925) 422-3384
Livermore, California 94550



Reply | Threaded
Open this post in threaded view
|

Re: GSOC 2020 NetDevice Up/Down Consistency Updates

Tom Henderson-2
In reply to this post by Anantha krishnan saji

> In the proposal, RUNNING state means that NetDevice is connected and
> operational (i.e above-mentioned protocol establishments are taken care
> of). Is there a need to support IFF_DORMANT?

My understanding is that it may be useful to model power control state
(sleep modes).

>
>     For API consistency with other methods, it would probably be SetUp()
>     and
>     SetDown ().
>
>
> I will change the methods accordingly.

The discussion helped to clarify that we need to work on the API a bit
more.

I found this reference on the callbacks that Android supports regarding
network connectivity, which may be used to guide a possible design for
LTE:
https://developer.android.com/reference/android/net/ConnectivityManager.NetworkCallback

I might be leaning away from my earlier suggestion to look at
aggregation because it seems like we should require that some aspects of
NetDevice state be supported for all device types, and just work on an
extensible and backward compatible way to support it.  Let's retry an
updated proposal in a week or so.

- Tom