Issue 5615049: New feature - switched-ethernet-device

Vedran Miletić

Overall, this seems good. Just two questions/comments: - Do you have a plan to validate ...

12 years, 9 months ago (2012-07-16 12:02:19 UTC) #1

Peter Barnes

Mostly minor comments. Not-minor: need a page for the Models manual. Major: After reading everything ...

12 years, 9 months ago (2012-07-16 20:08:48 UTC) #2

Jeff Y

> Overall, this seems good. Just two questions/comments: > - Do you have a plan ...

12 years, 9 months ago (2012-07-17 13:50:29 UTC) #3

Jeff Y

On 2012/07/16 20:08:48, Peter Barnes wrote: > Mostly minor comments. > > Not-minor: need a ...

12 years, 9 months ago (2012-07-17 16:14:36 UTC) #4

Tom Henderson

On 2012/07/17 16:14:36, Jeff Y wrote: > On 2012/07/16 20:08:48, Peter Barnes wrote: > > ...

12 years, 9 months ago (2012-07-25 13:05:34 UTC) #5

On 2012/07/17 16:14:36, Jeff Y wrote:
> On 2012/07/16 20:08:48, Peter Barnes wrote:
> > Mostly minor comments.
> > 
> > Not-minor:  need a page for the Models manual.
> > 
> > Major:  After reading everything I realize I don't understand the model
being
> > implemented here. Is this supposed to be a switch?  or just a full-duplex
NIC,
> > of which a switch contains many?  (If not a switch, discuss in the Model
page
> > how to implement one, or provide an implementation.)
> > 
> Hi Peter,
> 
>   Thank you for the comments - I'll merge these along with Vedran's changes. 
> 
> The model page is a good idea. Can you point me to any documentation on how to
> contribute new text to the models document? 

If you cd into ns-3-dev/src and run "./create-module.py switched-ethernet", it
will generate a skeleton module named switched-ethernet for you.  If you descend
into the doc directory, you should find an outline of a model chapter, outlining
the suggested material to cover.  For a worked example (written before this
template was formed, but overall is close to your device type):
http://www.nsnam.org/docs/release/3.14/models/html/csma.html

This file then needs to be added to the Makefile in ns-3-dev/doc/models/

> 
> This is just a full-duplex NIC model (i.e. a NIC that sits at an endpoint in a
> server blade) and a full-duplex Ethernet cable (switched-ethernet-channel)
that
> can be connected to an Ethernet switch. In order to have the most accurate
> representation of switched ethernet model, an L2 switch would be best.
However,
> I have used this model with the CSMA bridge model and custom delays
(cut-through
> latency for a commercial L2 switch) to get a pretty close approximation of
> actual packet latency. 

if you have any documentation of how you convinced yourself that the latency in
the model is close to real-world, you can add a summary or details in a
validation section in the model library chapter.

I can add the description of a switch to the model
> documentation, but I think it would take me a little while to code up and test
a
> switch design that is customizable (varying pipeline depth, crossbar delay,
> number of ports, etc). I see this patch as an intermediate step that allows a
> more faithful simulation of switched Ethernet but one that must be used with a
> few caveats (since it does not include a switch model).

Sign in to reply to this message.

Tom Henderson

Aside from Vedran and Peter's comments, I think it is hard to merge this without ...

12 years, 9 months ago (2012-07-25 13:08:35 UTC) #6

Jeff Y

Tom, Thanks for the pointer. I think that I used an earlier version of the ...

12 years, 9 months ago (2012-07-26 17:59:49 UTC) #7

Jeff Y

On 2012/07/25 13:08:35, Tom Henderson wrote: > Aside from Vedran and Peter's comments, I think ...

12 years, 9 months ago (2012-07-26 18:02:54 UTC) #8

Tom Henderson

Jeff, do you have any interest in trying to move this forward now? I was ...

11 years, 8 months ago (2013-08-22 02:53:45 UTC) #9

Jeff Y

Hi Tom, I would definitely be interested in getting this merged. I'd probably need to ...

11 years, 8 months ago (2013-08-22 13:20:05 UTC) #10

Vedran Miletić

Jeff, have you considered the possibility of sharing the code between this and csma, as ...

11 years, 8 months ago (2013-08-22 13:38:12 UTC) #11

Jeff Y

Vedran, This would probably be a good idea. I haven't looked at the CSMA code ...

11 years, 8 months ago (2013-08-22 16:37:41 UTC) #12

MurphyMc

On 2013/08/22 16:37:41, Jeff Y wrote: > Vedran, > > This would probably be a ...

10 years, 8 months ago (2014-08-16 09:18:45 UTC) #13

Jeff Y

Murphy, Thanks for your mail. I transitioned jobs right around the time this patch was ...

10 years, 8 months ago (2014-08-20 14:56:04 UTC) #14

hugo.s.pinto

Hello, I also needed this code for a project, and so I was exploring it ...

10 years, 7 months ago (2014-09-29 14:47:19 UTC) #15

hugo.s.pinto

Hello, I also needed this code for a project, and so I was exploring it ...

10 years, 7 months ago (2014-09-29 14:47:19 UTC) #16

Tom Henderson

On 2014/09/29 14:47:19, hugo.s.pinto wrote: > Hello, > > I also needed this code for ...

10 years, 7 months ago (2014-09-29 15:22:19 UTC) #17

MurphyMc

On 2014/09/29 14:47:19, hugo.s.pinto wrote: > Hello, > > I also needed this code for ...

10 years, 7 months ago (2014-09-30 00:21:53 UTC) #18

hugo.s.pinto

Murphy, do you have any example code that uses your full duplex implementation? As I ...

10 years, 7 months ago (2014-09-30 16:21:33 UTC) #19

Tom Henderson

On 2014/09/30 16:21:33, hugo.s.pinto wrote: > > Tom, I am also a bit tight on ...

10 years, 7 months ago (2014-09-30 20:23:07 UTC) #20

barnes26_llnl.gov

On Sep 30, 2014, at 1:23 PM, tomh.org@gmail.com wrote: > One possible way forward is ...

10 years, 7 months ago (2014-09-30 20:36:20 UTC) #21

On Sep 30, 2014, at 1:23 PM, tomh.org@gmail.com wrote:
> One possible way forward is to do both of the following:
> 
> * extend existing CSMA module so that it has two modes:  full-duplex and
half-duplex (existing behavior)
>  -- should full-duplex be the default going forward?
> 
> * improve the half-duplex behavior, starting with
> https://codereview.appspot.com/109450044/
> 
> Questions:
> 
> 1) is it too much of a misnomer to have a full-duplex Ethernet in a
> module named CSMA (which is not even a full CSMA/CD model in half-duplex
mode)?

On the one hand, when I plug in an Ethernet cable, the box figures out if it's
one of two devices (and enters full duplex), or one of many (and enters
half-duplex CD).  It would be nice to if ns-3 was so smart.


> ...
> In other words, we might consider to evolve the existing CSMA as a
> historical "shared medium" kind of model, implementing improvements
> suggested above, but then have a separate full duplex Ethernet model.

On the other hand, it might be cleaner to leave the existing CSMA/CA as an
historical shared channel abstraction, and launch a new CSMA/CD half/full duplex
model.  I think all the pieces are lying around...

> 2) we ought to have an Ethernet switch model at some point.  Are there any
issues we should be concerned about in anticipating this, or are the existing
proposals expected to be already compatible with some future-defined Ethernet
switch model?

How is a (real) Ethernet switch different from the SwitchedEthernetDevice
proposed here?  Just half/full negotiation?

> https://codereview.appspot.com/5615049/

_______________________________________________________________________
Dr. Peter D. Barnes, Jr.                Physics Division
Lawrence Livermore National Laboratory  Physical and Life Sciences
7000 East Avenue, L-50                  email:  pdbarnes@llnl.gov
P. O. Box 808                           Voice:  (925) 422-3384
Livermore, California 94550             Fax:    (925) 423-3371

Sign in to reply to this message.

Tom Henderson

On 2014/09/30 20:36:20, barnes26_llnl.gov wrote: > On Sep 30, 2014, at 1:23 PM, mailto:tomh.org@gmail.com wrote: ...

10 years, 7 months ago (2014-09-30 21:43:45 UTC) #22

On 2014/09/30 20:36:20, barnes26_llnl.gov wrote:
> On Sep 30, 2014, at 1:23 PM, mailto:tomh.org@gmail.com wrote:
> > One possible way forward is to do both of the following:
> > 
> > * extend existing CSMA module so that it has two modes:  full-duplex and
> half-duplex (existing behavior)
> >  -- should full-duplex be the default going forward?
> > 
> > * improve the half-duplex behavior, starting with
> > https://codereview.appspot.com/109450044/
> > 
> > Questions:
> > 
> > 1) is it too much of a misnomer to have a full-duplex Ethernet in a
> > module named CSMA (which is not even a full CSMA/CD model in half-duplex
> mode)?
> 
> On the one hand, when I plug in an Ethernet cable, the box figures out if it's
> one of two devices (and enters full duplex), or one of many (and enters
> half-duplex CD).  It would be nice to if ns-3 was so smart.
> 
> 
> > ...
> > In other words, we might consider to evolve the existing CSMA as a
> > historical "shared medium" kind of model, implementing improvements
> > suggested above, but then have a separate full duplex Ethernet model.
> 
> On the other hand, it might be cleaner to leave the existing CSMA/CA as an
> historical shared channel abstraction, and launch a new CSMA/CD half/full
duplex
> model.  I think all the pieces are lying around...

I would be fine with this outcome, if we can find a shepherd/maintainer for
getting this done.

> 
> > 2) we ought to have an Ethernet switch model at some point.  Are there any
> issues we should be concerned about in anticipating this, or are the existing
> proposals expected to be already compatible with some future-defined Ethernet
> switch model?
> 
> How is a (real) Ethernet switch different from the SwitchedEthernetDevice
> proposed here?  Just half/full negotiation?

I am guessing that people may want to build nodes that are models of switches
(as opposed to our host-centric node models), that have different buffering
architectures, and have to deal with e.g. port line rate mismatches, or large
shortest-path-bridging networks someday, etc.

Sign in to reply to this message.

Tom Henderson

> > How is a (real) Ethernet switch different from the SwitchedEthernetDevice > > proposed ...

10 years, 7 months ago (2014-09-30 21:54:11 UTC) #23

MurphyMc

On 2014/09/30 16:21:33, hugo.s.pinto wrote: > Murphy, do you have any example code that uses ...

10 years, 7 months ago (2014-09-30 22:05:27 UTC) #24

On 2014/09/30 16:21:33, hugo.s.pinto wrote:
> Murphy, do you have any example code that uses your full duplex
> implementation? As I understand, you would need to have 2 CSMA channel
> instances to have a full duplex-channel, but I would like to see some code
> where the topology is created. Also, have you considered creating a helper?

I didn't see a reason to have a separate helper.  If I remember right, one can
use the existing helper and existing half-duplex setup/topology code (where a
given channel has only two devices on it) and convert it to full-duplex with a
single line of code -- use SetChannelAttribute to set FullDuplex to true on the
helper and you're done.

You don't need two CSMA channel instances.  Like the original patch, mine keeps
two copies of various data.  In the half-duplex case, it uses only one of them,
sharing between directions.  In the full-duplex case, it uses one for one
direction and the other for the other direction.

> Also, what do you think about my previous comments, regarding correctness
> of the algorithm? I was also wondering if it would make send to make one
> device only SendEnabled, and another only ReceiveEnabled.
> 
> Tom, I am also a bit tight on time right now, but I could contribute on the
> full-duplex part of the problem.
> 
> Thanks,
> Hugo
> 
> 
> On Tue, Sep 30, 2014 at 1:21 AM, <mailto:murphy.mccauley@gmail.com> wrote:
> 
> > On 2014/09/29 14:47:19, hugo.s.pinto wrote:
> >
> >> Hello,
> >>
> >
> >  I also needed this code for a project, and so I was exploring it a
> >>
> > bit, and it
> >
> >> looks like there are some parts of the code that are only needed for
> >>
> > half-duplex
> >
> >> csma that weren't dropped. In particular, with full-duplex
> >>
> > communication, I
> >
> >> don't understand why you need the backoff state in the netdevice, and
> >>
> > I don't
> >
> >> think you should have the propagating state in the wire state, because
> >>
> > you don't
> >
> >> need anymore to wait until the signal has reached all devices to make
> >>
> > sure there
> >
> >> were no collisions.
> >>
> >
> >  Let me know your thoughts. I would also like to know if you are
> >>
> > planning on
> >
> >> integrating this in any next ns3 release.
> >>
> >
> >  Hugo
> >>
> >
> > Just a note that in the case of my patch, that's all needed (since mine
> > incorporates both full and half duplex).
> >
> > https://codereview.appspot.com/5615049/
> >

Sign in to reply to this message.

Jeff Y

To briefly weigh in - Peter makes a good point about naming issues since a ...

10 years, 7 months ago (2014-10-01 15:13:53 UTC) #25

  To briefly weigh in -  Peter makes a good point about naming issues since
a full-duplex Ethernet link doesn't really need CSMA and renaming CSMA
would cause issues with existing code. My suggestion would be to start from
Murphy's patch and create a separate "Switched-Ethernet" or
"Full-Duplex-Ethernet" model to avoid confusion. My
"SwitchedEthernetDevice" may be slightly misnamed in that it is just a
full-duplex
Ethernet link that I used with a normal node and the csma-bridge helper for
a simple, delay-based switch.

  To answer Tom's question, "Whether the device model we do now for hosts
would be incompatible if one were to put it into a 'switch' node that
implements these things": I don't think so, but that may just be because I
was thinking about a very simple switch model.

  Another researcher I talked to, Mike Schlansker at HP, indicated that the
netdevice model was the main limitation for creating multi-port switches.
From his email: "The netdevice holds dedicated queuing needed for exactly
one output port.  Our initial attempts to build a multiport switch on top
of a netdevice resulted in a switch with a separate output buffers for each
output port.   More realistic switches, that I wanted to model, shared
buffering between multiple output ports." My understanding of this is that
sharing an output port would require a separate netdevice model to support
this type of switch.

--Jeff

On Tue, Sep 30, 2014 at 6:05 PM, <murphy.mccauley@gmail.com> wrote:

> On 2014/09/30 16:21:33, hugo.s.pinto wrote:
>
>> Murphy, do you have any example code that uses your full duplex
>> implementation? As I understand, you would need to have 2 CSMA channel
>> instances to have a full duplex-channel, but I would like to see some
>>
> code
>
>> where the topology is created. Also, have you considered creating a
>>
> helper?
>
> I didn't see a reason to have a separate helper.  If I remember right,
> one can use the existing helper and existing half-duplex setup/topology
> code (where a given channel has only two devices on it) and convert it
> to full-duplex with a single line of code -- use SetChannelAttribute to
> set FullDuplex to true on the helper and you're done.
>
> You don't need two CSMA channel instances.  Like the original patch,
> mine keeps two copies of various data.  In the half-duplex case, it uses
> only one of them, sharing between directions.  In the full-duplex case,
> it uses one for one direction and the other for the other direction.
>
>  Also, what do you think about my previous comments, regarding
>>
> correctness
>
>> of the algorithm? I was also wondering if it would make send to make
>>
> one
>
>> device only SendEnabled, and another only ReceiveEnabled.
>>
>
>  Tom, I am also a bit tight on time right now, but I could contribute
>>
> on the
>
>> full-duplex part of the problem.
>>
>
>  Thanks,
>> Hugo
>>
>
>
>  On Tue, Sep 30, 2014 at 1:21 AM, <mailto:murphy.mccauley@gmail.com>
>>
> wrote:
>
>  > On 2014/09/29 14:47:19, hugo.s.pinto wrote:
>> >
>> >> Hello,
>> >>
>> >
>> >  I also needed this code for a project, and so I was exploring it a
>> >>
>> > bit, and it
>> >
>> >> looks like there are some parts of the code that are only needed
>>
> for
>
>> >>
>> > half-duplex
>> >
>> >> csma that weren't dropped. In particular, with full-duplex
>> >>
>> > communication, I
>> >
>> >> don't understand why you need the backoff state in the netdevice,
>>
> and
>
>> >>
>> > I don't
>> >
>> >> think you should have the propagating state in the wire state,
>>
> because
>
>> >>
>> > you don't
>> >
>> >> need anymore to wait until the signal has reached all devices to
>>
> make
>
>> >>
>> > sure there
>> >
>> >> were no collisions.
>> >>
>> >
>> >  Let me know your thoughts. I would also like to know if you are
>> >>
>> > planning on
>> >
>> >> integrating this in any next ns3 release.
>> >>
>> >
>> >  Hugo
>> >>
>> >
>> > Just a note that in the case of my patch, that's all needed (since
>>
> mine
>
>> > incorporates both full and half duplex).
>> >
>> > https://codereview.appspot.com/5615049/
>> >
>>
>
>
> https://codereview.appspot.com/5615049/
>

Sign in to reply to this message.

Tom Henderson

On 2014/10/01 15:13:53, Jeff Y wrote: > > To answer Tom's question, "Whether the device ...

10 years, 7 months ago (2014-10-01 16:59:08 UTC) #26

hugo.s.pinto

Tom, I also agree that having a full-duplex ethernet in a csma module is somewhat ...

10 years, 7 months ago (2014-10-02 15:44:49 UTC) #27

Tom, I also agree that having a full-duplex ethernet in a csma module is
somewhat misleading. I would go for a separate module called ethernet,
which as Peter suggested could potentially support both full and
half-duplex modes.

In my case, I have no interest in the half-duplex mode. The issue that I
encountered were that there was no link-layer technology to connect
switches with high bandwidth and high delay links.

Regarding the availability of switches, I would like to point out that
currently there are already some switch implementations, such as the
openflow switch module, or the bridge module, which should of course work
with whatever full-duplex model we end up developing (as I believe they do
with the current patch) .

It would also would be nice if the device could be made general enough to
be used by more sophisticated switches, by e.g. configuring the device with
an external queue.

Hugo

On Wed, Oct 1, 2014 at 5:59 PM, <tomh.org@gmail.com> wrote:

> On 2014/10/01 15:13:53, Jeff Y wrote:
>
>
>     To answer Tom's question, "Whether the device model we do now for
>>
> hosts
>
>> would be incompatible if one were to put it into a 'switch' node that
>> implements these things": I don't think so, but that may just be
>>
> because I
>
>> was thinking about a very simple switch model.
>>
>
>     Another researcher I talked to, Mike Schlansker at HP, indicated
>>
> that the
>
>> netdevice model was the main limitation for creating multi-port
>>
> switches.
>
>>  From his email: "The netdevice holds dedicated queuing needed for
>>
> exactly
>
>> one output port.  Our initial attempts to build a multiport switch on
>>
> top
>
>> of a netdevice resulted in a switch with a separate output buffers for
>>
> each
>
>> output port.   More realistic switches, that I wanted to model, shared
>> buffering between multiple output ports." My understanding of this is
>>
> that
>
>> sharing an output port would require a separate netdevice model to
>>
> support
>
>> this type of switch.
>>
>
> The abstract base class for NetDevice doesn't constrain or specify any
> queueing model.  The CSMA NetDevice type, however, uses ns3::Queue which
> is not designed for multi-port usage.  So it may not be compatible at
> the CsmaNetDevice level, but at ns3::NetDevice, it seems like we could
> still handle shared memory with a different internal device organization
> than CsmaNetDevice.
>
> I wonder whether we could get better requirements written down regarding
> how we need to plan for supporting Ethernet switches (including both
> input and output buffering requirements, what service and drop policies
> are required by the buffers, etc.).  If anyone has a good reference for
> this, please send it along ...
>
> - Tom
>
>
>
> https://codereview.appspot.com/5615049/
>

Sign in to reply to this message.

hugo.s.pinto

Murphy, I understand your implementation now, and I see that you only use one device ...

10 years, 6 months ago (2014-10-06 21:52:49 UTC) #28

Murphy, I understand your implementation now, and I see that you only use
one device on each terminal. I believe that the following are bugs:

i) in csma-net-device.cc, in function CsmaNetDevice::TransmitStart (void),
      m_txMachineState = BACKOFF;

should be only in case of half-duplex links, otherwise state machine gets
stuck in backoff mode.

ii) in csma-channel.cc, in function CsmaChannel::TransmitEnd
  Simulator::Schedule (m_delay, &CsmaChannel::PropagationCompleteEvent,
this, srcId);

I believe that the device shouldn't be busy while propagating, because
otherwise you cannot have high speed links.. (this delay will substantially
limit the speeds you get). Let me know if you agree.

Thank you,
Hugo











On Thu, Oct 2, 2014 at 4:44 PM, Hugo Sousa Pinto <hugo.s.pinto@gmail.com>
wrote:

> Tom, I also agree that having a full-duplex ethernet in a csma module is
> somewhat misleading. I would go for a separate module called ethernet,
> which as Peter suggested could potentially support both full and
> half-duplex modes.
>
> In my case, I have no interest in the half-duplex mode. The issue that I
> encountered were that there was no link-layer technology to connect
> switches with high bandwidth and high delay links.
>
> Regarding the availability of switches, I would like to point out that
> currently there are already some switch implementations, such as the
> openflow switch module, or the bridge module, which should of course work
> with whatever full-duplex model we end up developing (as I believe they do
> with the current patch) .
>
> It would also would be nice if the device could be made general enough to
> be used by more sophisticated switches, by e.g. configuring the device with
> an external queue.
>
> Hugo
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 1, 2014 at 5:59 PM, <tomh.org@gmail.com> wrote:
>
>> On 2014/10/01 15:13:53, Jeff Y wrote:
>>
>>
>>     To answer Tom's question, "Whether the device model we do now for
>>>
>> hosts
>>
>>> would be incompatible if one were to put it into a 'switch' node that
>>> implements these things": I don't think so, but that may just be
>>>
>> because I
>>
>>> was thinking about a very simple switch model.
>>>
>>
>>     Another researcher I talked to, Mike Schlansker at HP, indicated
>>>
>> that the
>>
>>> netdevice model was the main limitation for creating multi-port
>>>
>> switches.
>>
>>>  From his email: "The netdevice holds dedicated queuing needed for
>>>
>> exactly
>>
>>> one output port.  Our initial attempts to build a multiport switch on
>>>
>> top
>>
>>> of a netdevice resulted in a switch with a separate output buffers for
>>>
>> each
>>
>>> output port.   More realistic switches, that I wanted to model, shared
>>> buffering between multiple output ports." My understanding of this is
>>>
>> that
>>
>>> sharing an output port would require a separate netdevice model to
>>>
>> support
>>
>>> this type of switch.
>>>
>>
>> The abstract base class for NetDevice doesn't constrain or specify any
>> queueing model.  The CSMA NetDevice type, however, uses ns3::Queue which
>> is not designed for multi-port usage.  So it may not be compatible at
>> the CsmaNetDevice level, but at ns3::NetDevice, it seems like we could
>> still handle shared memory with a different internal device organization
>> than CsmaNetDevice.
>>
>> I wonder whether we could get better requirements written down regarding
>> how we need to plan for supporting Ethernet switches (including both
>> input and output buffering requirements, what service and drop policies
>> are required by the buffers, etc.).  If anyone has a good reference for
>> this, please send it along ...
>>
>> - Tom
>>
>>
>>
>> https://codereview.appspot.com/5615049/
>>
>
>

Sign in to reply to this message.

Tom Henderson

I'd like to move this forward if possible. It seemed that sentiment leaned towards a ...

10 years, 6 months ago (2014-10-15 12:52:08 UTC) #29

MurphyMc

On 2014/10/15 12:52:08, Tom Henderson wrote: > I'd like to move this forward if possible. ...

10 years, 6 months ago (2014-10-16 02:28:43 UTC) #30

On 2014/10/15 12:52:08, Tom Henderson wrote:
> I'd like to move this forward if possible.  It seemed that sentiment leaned
> towards a separate full-duplex ethernet module; should we try to move forward
> with that goal?  

When I needed this, I started by diffing Jeff Y's full duplex model against the
CSMA model.  They are extremely similar (as Jeff Y notes), though the CSMA model
had gotten a few patches since they diverged.  I also read the reviews of the
original patch and found that many were actually reviews of things that existed
in the CSMA model.  This seemed like a bad road to go down.  It seems to me like
the maintenance work is increasing by duplicating code that's so similar and
that the minor additional complexity of merging the code is a better route.

I'll also note that 802.3 contains language like the following: "The Carrier
Sense Multiple Access with Collision Detection (CSMA/CD) MAC protocol specifies
shared medium (half duplex) operation, as well as full duplex operation."  So
whatever confusion comes from sticking them together is already a fact of life.
:)

I'm not particularly invested here, but thought I'd throw in some rationale for
a single merged implementation.

> We had a comment that the existing device model was not amenable to multiport,
> shared memory queue structures on the switch.  However, it was stated that the
> 'bridge' module could serve as a stand-in until a better ethernet switch model
> could be developed.  Agree?

I totally agree with this. The custom model I am using is based on the bridge. 
IMO the bridge is useful as-is, and it's a huge step up from half-duplex
anything.

> If so, can someone propose minimal functional requirements of the device to
get
> us started thinking about validation tests?  e.g.
> 
> * the following attributes should be configurable on the device model and on
the
> channel model...
> * the device should support channel delays of up to X ns (what to do if user
> exceeds assumptions about cable length)?
> * two devices should be able to be hooked up in cross-over configuration and
> support X Gb/s with packet sizes of X in full-duplex mode
> * two devices should be able to be hooked together with a 'bridge' device in
> between, and we ought to see what difference in performance with respect to
> cross-over cable connection?
> * N devices should be able to be hooked together with a 'bridge', and we
should
> see the behavior change as follows...
> 
> Should we take MurphyMc's patch as starting point?  Who has time to contribute
> further to debugging, documenting, testing this (over the next two months)?

If you're not planning on a merged implementation with CSMA, there's not much
difference between my version and the original patch.  Mine should have a couple
extra patches from the mainline and slightly better adherence to ns-3 coding
conventions, but it also adds some unnecessary complexity if it's not going to
have both modes.

> The switch model could perhaps be suggested as a GSoC project if there are no
> takers now.  For example, UIUC has developed some models and published here
> about them:  http://web.engr.illinois.edu/~caesar/papers/ethsim.pdf  Perhaps
> someone could try to port that work and use the tests in the paper as starting
> points?

Sign in to reply to this message.

MurphyMc

On 2014/10/06 21:52:49, hugo.s.pinto wrote: > Murphy, I understand your implementation now, and I see ...

10 years, 6 months ago (2014-10-16 02:35:26 UTC) #31

On 2014/10/06 21:52:49, hugo.s.pinto wrote:
> Murphy, I understand your implementation now, and I see that you only use
> one device on each terminal. I believe that the following are bugs:
> 
> i) in csma-net-device.cc, in function CsmaNetDevice::TransmitStart (void),
>       m_txMachineState = BACKOFF;
> 
> should be only in case of half-duplex links, otherwise state machine gets
> stuck in backoff mode.
> 
> ii) in csma-channel.cc, in function CsmaChannel::TransmitEnd
>   Simulator::Schedule (m_delay, &CsmaChannel::PropagationCompleteEvent,
> this, srcId);
> 
> I believe that the device shouldn't be busy while propagating, because
> otherwise you cannot have high speed links.. (this delay will substantially
> limit the speeds you get). Let me know if you agree.
> 
> Thank you,
> Hugo

I didn't actually pay much attention to the logic -- it was my intention to
replicate it from the original patch which had already been written and reviewed
by people that no doubt know ns-3 better than I do.  I was just trying to
integrate the original patch with the CSMA model.

That said, your comments seem reasonable and like they merit further review.  As
far as limiting the link speed, I will note that I didn't see this in my testing
-- once I added full duplex, my results matched expectations.  It's totally
possible I just didn't run up against it.

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Oct 2, 2014 at 4:44 PM, Hugo Sousa Pinto
<mailto:hugo.s.pinto@gmail.com>
> wrote:
> 
> > Tom, I also agree that having a full-duplex ethernet in a csma module is
> > somewhat misleading. I would go for a separate module called ethernet,
> > which as Peter suggested could potentially support both full and
> > half-duplex modes.
> >
> > In my case, I have no interest in the half-duplex mode. The issue that I
> > encountered were that there was no link-layer technology to connect
> > switches with high bandwidth and high delay links.
> >
> > Regarding the availability of switches, I would like to point out that
> > currently there are already some switch implementations, such as the
> > openflow switch module, or the bridge module, which should of course work
> > with whatever full-duplex model we end up developing (as I believe they do
> > with the current patch) .
> >
> > It would also would be nice if the device could be made general enough to
> > be used by more sophisticated switches, by e.g. configuring the device with
> > an external queue.
> >
> > Hugo
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Oct 1, 2014 at 5:59 PM, <mailto:tomh.org@gmail.com> wrote:
> >
> >> On 2014/10/01 15:13:53, Jeff Y wrote:
> >>
> >>
> >>     To answer Tom's question, "Whether the device model we do now for
> >>>
> >> hosts
> >>
> >>> would be incompatible if one were to put it into a 'switch' node that
> >>> implements these things": I don't think so, but that may just be
> >>>
> >> because I
> >>
> >>> was thinking about a very simple switch model.
> >>>
> >>
> >>     Another researcher I talked to, Mike Schlansker at HP, indicated
> >>>
> >> that the
> >>
> >>> netdevice model was the main limitation for creating multi-port
> >>>
> >> switches.
> >>
> >>>  From his email: "The netdevice holds dedicated queuing needed for
> >>>
> >> exactly
> >>
> >>> one output port.  Our initial attempts to build a multiport switch on
> >>>
> >> top
> >>
> >>> of a netdevice resulted in a switch with a separate output buffers for
> >>>
> >> each
> >>
> >>> output port.   More realistic switches, that I wanted to model, shared
> >>> buffering between multiple output ports." My understanding of this is
> >>>
> >> that
> >>
> >>> sharing an output port would require a separate netdevice model to
> >>>
> >> support
> >>
> >>> this type of switch.
> >>>
> >>
> >> The abstract base class for NetDevice doesn't constrain or specify any
> >> queueing model.  The CSMA NetDevice type, however, uses ns3::Queue which
> >> is not designed for multi-port usage.  So it may not be compatible at
> >> the CsmaNetDevice level, but at ns3::NetDevice, it seems like we could
> >> still handle shared memory with a different internal device organization
> >> than CsmaNetDevice.
> >>
> >> I wonder whether we could get better requirements written down regarding
> >> how we need to plan for supporting Ethernet switches (including both
> >> input and output buffering requirements, what service and drop policies
> >> are required by the buffers, etc.).  If anyone has a good reference for
> >> this, please send it along ...
> >>
> >> - Tom
> >>
> >>
> >>
> >> https://codereview.appspot.com/5615049/
> >>
> >
> >

Sign in to reply to this message.

Tom Henderson

I would like to propose trying to move forward with the full duplex extension rather ...

10 years, 4 months ago (2014-12-09 06:20:27 UTC) #32

Jeff Y

Thanks, Tom. I apologize, but I am currently very limited on development time at the ...

10 years, 4 months ago (2014-12-16 20:19:24 UTC) #33

tomh_tomh.org

On 12/16/2014 12:19 PM, Jeff wrote: > Otherwise, what tests do we need? Create two ...

10 years, 4 months ago (2014-12-16 20:52:11 UTC) #34

MurphyMc

10 years, 1 month ago (2015-03-15 09:55:33 UTC) #35

I'm getting back to using this, so I've made changes that relate to Hugo's
comments, as well as having rebased on top of 3.22.  Results are in my fork on
github if anyone is interested.
https://github.com/MurphyMc/ns-3-dev-git/tree/feature_csma_full_duplex_rebase...

On 2014/10/06 21:52:49, hugo.s.pinto wrote:
> Murphy, I understand your implementation now, and I see that you only use
> one device on each terminal. I believe that the following are bugs:
> 
> i) in csma-net-device.cc, in function CsmaNetDevice::TransmitStart (void),
>       m_txMachineState = BACKOFF;
> 
> should be only in case of half-duplex links, otherwise state machine gets
> stuck in backoff mode.
> 
> ii) in csma-channel.cc, in function CsmaChannel::TransmitEnd
>   Simulator::Schedule (m_delay, &CsmaChannel::PropagationCompleteEvent,
> this, srcId);
> 
> I believe that the device shouldn't be busy while propagating, because
> otherwise you cannot have high speed links.. (this delay will substantially
> limit the speeds you get). Let me know if you agree.
> 
> Thank you,
> Hugo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Oct 2, 2014 at 4:44 PM, Hugo Sousa Pinto
<mailto:hugo.s.pinto@gmail.com>
> wrote:
> 
> > Tom, I also agree that having a full-duplex ethernet in a csma module is
> > somewhat misleading. I would go for a separate module called ethernet,
> > which as Peter suggested could potentially support both full and
> > half-duplex modes.
> >
> > In my case, I have no interest in the half-duplex mode. The issue that I
> > encountered were that there was no link-layer technology to connect
> > switches with high bandwidth and high delay links.
> >
> > Regarding the availability of switches, I would like to point out that
> > currently there are already some switch implementations, such as the
> > openflow switch module, or the bridge module, which should of course work
> > with whatever full-duplex model we end up developing (as I believe they do
> > with the current patch) .
> >
> > It would also would be nice if the device could be made general enough to
> > be used by more sophisticated switches, by e.g. configuring the device with
> > an external queue.
> >
> > Hugo
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Oct 1, 2014 at 5:59 PM, <mailto:tomh.org@gmail.com> wrote:
> >
> >> On 2014/10/01 15:13:53, Jeff Y wrote:
> >>
> >>
> >>     To answer Tom's question, "Whether the device model we do now for
> >>>
> >> hosts
> >>
> >>> would be incompatible if one were to put it into a 'switch' node that
> >>> implements these things": I don't think so, but that may just be
> >>>
> >> because I
> >>
> >>> was thinking about a very simple switch model.
> >>>
> >>
> >>     Another researcher I talked to, Mike Schlansker at HP, indicated
> >>>
> >> that the
> >>
> >>> netdevice model was the main limitation for creating multi-port
> >>>
> >> switches.
> >>
> >>>  From his email: "The netdevice holds dedicated queuing needed for
> >>>
> >> exactly
> >>
> >>> one output port.  Our initial attempts to build a multiport switch on
> >>>
> >> top
> >>
> >>> of a netdevice resulted in a switch with a separate output buffers for
> >>>
> >> each
> >>
> >>> output port.   More realistic switches, that I wanted to model, shared
> >>> buffering between multiple output ports." My understanding of this is
> >>>
> >> that
> >>
> >>> sharing an output port would require a separate netdevice model to
> >>>
> >> support
> >>
> >>> this type of switch.
> >>>
> >>
> >> The abstract base class for NetDevice doesn't constrain or specify any
> >> queueing model.  The CSMA NetDevice type, however, uses ns3::Queue which
> >> is not designed for multi-port usage.  So it may not be compatible at
> >> the CsmaNetDevice level, but at ns3::NetDevice, it seems like we could
> >> still handle shared memory with a different internal device organization
> >> than CsmaNetDevice.
> >>
> >> I wonder whether we could get better requirements written down regarding
> >> how we need to plan for supporting Ethernet switches (including both
> >> input and output buffering requirements, what service and drop policies
> >> are required by the buffers, etc.).  If anyone has a good reference for
> >> this, please send it along ...
> >>
> >> - Tom
> >>
> >>
> >>
> >> https://codereview.appspot.com/5615049/
> >>
> >
> >

Sign in to reply to this message.

Issue 5615049: New feature - switched-ethernet-device

Description

Patch Set 1 #

Messages