GSOC 2020 NetDevice Up/Down consistency updates

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

GSOC 2020 NetDevice Up/Down consistency updates

Anantha krishnan saji
Hello all,

Last week, I looked into the working of PointToPointNetDevice in Linux. I
have updated my findings on the document (link
<https://docs.google.com/document/d/1KCZevur9F5bes84OBoN5e96kNfRyfCP_hRep722xpw4/edit?usp=sharing>).
I feel like some more information is needed to answer questions like,

What is the reaction of NetDevice when the user unplugs the cable or when
the device is put down by a command?

This week, I will connect the callbacks to IP Interfaces and create methods
that will be triggered by the callback to correctly set the state of IP
Interface. Additionally, I will try to find answers to the above questions.

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

Re: GSOC 2020 NetDevice Up/Down consistency updates

Tom Henderson-2
On 6/2/20 2:54 AM, Ananthakrishnan S wrote:

> Hello all,
>
> Last week, I looked into the working of PointToPointNetDevice in Linux. I
> have updated my findings on the document (link
> <https://docs.google.com/document/d/1KCZevur9F5bes84OBoN5e96kNfRyfCP_hRep722xpw4/edit?usp=sharing>).
> I feel like some more information is needed to answer questions like,
>
> What is the reaction of NetDevice when the user unplugs the cable or when
> the device is put down by a command?
>
> This week, I will connect the callbacks to IP Interfaces and create methods
> that will be triggered by the callback to correctly set the state of IP
> Interface. Additionally, I will try to find answers to the above questions.
>

Hi Ananthakrishnan, you have written a nice summary, and you ask an
important question above.  Several years ago, there were a few meetings
and efforts to define, more generally, what it means to 'start' and
'stop' an ns-3 object.  A summary is here:
https://www.nsnam.org/wiki/Object_Start_Stop_specification

Although the definition of what should be done was developed fairly
well, no one ended up having the time to work on a thorough implementation.

I'd like to recommend that you also start a document that defines the
user API and behavior you are trying to handle.  For instance, do we
'stop/start' a device, or call 'ifdown/ifup', or 'sleep/wake', etc.?  Do
we need to separately handle 'stopped' or sleeping vs. 'failed' devices?
  Can devices be added or deleted in the middle of the simulation, and
what about Object::Initialize in that case?  If there is a socket using
that device, and the device goes down, is there
backpressure/notification up to the application?  How would a routing
protocol be notified of the change in state?  How could you define a
rich enough test case and the conditions that should be checked to test
its operation?

I agree with starting on the PointToPoint device and try to work that
out fully before then considering the more general device or ns-3 Object
issues.

- Tom