__TODO

TODO: labelling:
  - add labels l2pkt/l3pkt/l4pkt to upper layer input/output of L1/L2/L3 protocols or modules? 
    i.e. NIC's upperLayerIn could be tagged as l3pkt, and IP's ifOut also as l3pkt
  - add @labels(node,configurator,!configurator) to FlatNetworkConfigurator and similar "singleton" modeules,
    to make them unique?
  - change the @labels(PPPFrame) label on pppg[] gates of hosts/routers to something slightly different
    (e.g. @labels(PPPFrame/pk)) so that PPPInterface does not appear in the palette on network level?


TODO:  finish making gate names consistent! around the SCTP and RTP modules
TODO:  PingApp is strange; it should send payload+controlInfo instead of ICMP packet

TODO: eliminate ARP overhead for PPP interfaces; 

TODO: UDPSocket::Callback::socketDatagramArrived() - change arg cMessage* to cPacket*

TODO: eliminate ARP overhead for PPP interfaces;

  [Ingmar Baumgart email, 2008 dec 10, "INET Framework: ARP performance issue"]
    The only issue which results in about 10% slowdown in our simulations is
    the unnecessary use of the ARP module for PPP interfaces. A quick fix
    would be to modify IP::sendDatagramToOutput() to use a sendDirect to
    skip the ARP module, if the outgoing interface is not a broadcast
    interface (mainly move the logic from ARP::processOutboundPacket() to
    IP::sendDatagramToOutput).
    Of course we could also remove the outgoing connection from the ARP
    module and use there sendDirect as well.

TODO: examples\wireless\hosttohost: Readme mentions some "attached Excel sheet" which is missing!!!

TODO: toplevel package legyen "org.omnetpp.inet"

TODO:  MTU patch from Irene Rungeler

TODO: add SCTP to the whatsnew file

- MAKE IT POSSIBLE TO USE DIFFERENT TYPES FOR EACH ELEMENT OF "LIKE" SUBMODULE VECTORS!
  In StandardHost etc, change
      udpApp[numUdpApps]: <udpAppType> like IUDPApp;
  to
     udpApp[numUdpApps]: <> like IUDPApp;


TODO:
- fix Ethernet channel usage (should use datarate on the channel!)
- failure/recovery (replacing with failed router is problematic!)
- gate labelling for the NED editor

-----------------------
add support for integrating the TIREM module?
   http://www.alionscience.com/index.cfm?fuseaction=products.view&productid=19
   "TIREM predicts radio frequency propagation loss over irregular terrain and seawater for
   ground-based and air-borne transmitters and receivers. TIREM is commercially
   available as a DLL and as a module in leading commercial M&S tools."

-----------------------
mailing list post on 2008-11-17 "INET Framework accuracy":
A really interesting paper is the technical report "Towards Comparable
Network Simulators", from Pengfei Di, Yaser Houri, Kendy Kutzner and  Thomas
Fuhrmann [see url below]. They measure 802.11 throughput with ns2 and
OMNeT++ INET Fw, and come to the conclusion that they are hard to compare,
due to differences in the radio model and MAC parameterization. Then they go
on to wrap ns2's 802.11 model into an OMNeT++ simple module, and with that,
the OMNeT++ simulation (not too surprisingly) shows excellent correspondence
with the ns2 simulation :)

http://i30www.ira.uka.de/research/documents/p2p/2008/towards_comparable_netw
ork_simulations.pdf

The paper is excellent work, and literally cries for follow-ups:

1. INET's radio model is pluggable, and as the report authors describe it,
   the ns-2 radio model seems to be quite simple (i.e. propdelay is a constant
   and does not depend on distance). Thus, it should be possible to reimplement
   ns-2's radio model in OMNeT++ with not too much effort (and contribute it to
   INET) and re-run the experiments with it.

2. OTOH I'm wondering, why not test the radio model and the 802.11MAC
   operation *separately*? I.e. write an ideal radio (ber==0 always) and test
   different 802.11 MAC models over that in all scenarios; then have more
   realistic radio models and test them with simple (contention-free) 802.11
   setups

3. INET 802.11MAC model parameterization could be adjusted so that it's
   possible to set it up with *exactly* the same parameters as ns-2.

4. the authors ported ns-2's 802.11 model into OMNeT++; wonder if this code
   is publicly available, or is there any plan to release it? there certainly
   would be value in doing that.
-----------------------


TODO: ethernet: use normal channels
TODO: eliminate cast after dup(), like (AirFrame*)airframe->dup()

TODO: IRoutingTable6, ITED, etc!

TODO routingTable optimizations from Gamer!

TODO: Document: decide interfaceId vs interfacePointer! issue: IPRoutingDecision contains interfaceID.
      if we change it to pointer, messages that are underway in the host during a deleteInterface()
      may crash!!! solution: use a vector inside InterfaceTable, and let each deleteInterface()
      leave a hole in it?
-----------------------
- move "q=queue" too into the default display string
- add gate @labels
- rename TCPBasicClientApp to TCPRequestReplyClientApp ?
- ethernet: ditch autoconfig and zero-datarate channels, use deliverOnReceptionStart and 10/100/1000Mbps channels!

-----------------------
TODO rename the following TED.h methods to begin with a verb:
  unsigned int linkIndex(IPAddress advrouter, IPAddress linkid)
  unsigned int linkIndex(IPAddress localInf)
  IPAddress peerRemoteInterface(IPAddress peerIP)
  IPAddress primaryAddress(IPAddress localInf)
-----------------------
cache gate IDs to speed up sending
-----------------------
put all c++ code into "inet" namespace
- networklayer\extras\FailureManager.cc: contains obsolete, hardcoded module type names!
- factor out common part of hosts/routers etc, and use subclassing
- remove channelInstaller
- examples: add fingerprints!
- create a new executable demo for Windows

--------
- get quagga to work
--------
- add IdealRadio, DistanceBasedRadio, GilbertElliotRadio.
   in DistanceBasedRadio: decouple transmission range from interference range
   (ie use 2 different module parameters)
--------
- model link failures, via isDown() method of InterfaceEntry. L2 modules
  should understand isDown(), and FailureManager should be enhanced with
  linkdown/linkup commands. See email on list archive on 9/17/2006 10:34 AM
--------
- create NetworkInterfaces/Base subdirectory: AirFrame, WirelessMacBase,
  ChannelAccess, etc.
--------
- Ieee80211Mac to fire TxNotifDetails when Ack arrives for a frame. Mgmt layer
  to use this notification to learn when ProbeRequest or AssociationResponse
  has been transmitted.
--------
- ChannelControl: grid; instead of having pMax parameter, it should ask all
  radios and collect pMax from them! (or, directly the range!)
--------
- radio models: when calculating the probability of bit errors, snirMIN is
  assumed for the whole duration of the frame! This means that if snir
  changes along the packet duration, we overestimate the probability of
  bit error. (there should be proper integration there)
--------
- IReceptionModel:
  - improve it to be able to accomodate antenna gain: calculation function
    should take node positions, antenna directions (maybe this should be in
    some IDirectionalReceptionmodel, plugging into some AbstractDirectionalRadio?)
  - allow for implementing "good/bad channel"-type radio models (Gilbert-Elliot)
    e.g. containsBadChannelState(starttime, endtime)
  - allow the radio model to add extra noise over time, or modify received power
    over time, e.g. using functions like
      PowerList calculateReceivedPower(...)
      PowerList ambientNoise(...)
    (maybe this should be some IDetailedReceptionModel, plugging into
    a specialized version of AbstractRadio?)
--------
- AbstractRadio: consider: don't sent up the packet if there're bit errors,
  just fire some specific radio state change notification! would simplify the
  Ieee80211Mac state machine a lot!
--------
- tummiepiggy's TCP bug ("TCP_S_FIN_WAIT_1 timeout" on mailing list)
--------
- quagga/socketmsg: use base/bytearraymessage instead
--------
- implement ICMP rate limiting, see e.g bsd.mod/netinet/ip_icmp.c, badport_bandlim()
- ICMP options: stopOnError (bool param), UDPBadPortSendICMP (bool param)
--------
- problem with NetworkConfigurator + RSVP's FailureManager: after deleting/recreating
  LSR, configured IP addresses and host routes to PPP peers get lost.
  Solution: implement failure/recovery with NF_FAILURE and NF_RECOVERY notifications!
--------
- check in Quagga documentation
- rename Daemon to QuaggaDaemon
--------
- "ack" in LinkStateMsg redundant? (never read)
Q: what is the TELinkInfo.state flag?
Q: what is UnResvBandwidth[8] indexed with? what is [4] and [7] that gets printed?

--------
- MPLS examples: there's heaps of ICMP errors coming from UDP ("port unreachable")
--------
- BUG: UDP ephemeral port setting: if chosen & stored in UDP, sending further dgrams need to look it up from the SockDesc...
--------
- reading routing files: it doesn't make sense to be able to manually set MULTICAST on an interface

- create example network with both Ethernet and PPP

- IP/IPv6: implement tunnelling

- revise fragmentation in IP

- added userId to TCPCommand -- rewrite TCPSocketMap to make use of userId
        - socket must be inserted into map before bind(), so that a userId can be assigned
        - what about incoming connections? how to assign userId to them?
           IF IT CANNOT BE DONE: remove userId from TCP!!!!

- TCP/UDP: unspec port should be 0 not -1!!!

- NAM trace: doesn't record drops, because DropTailQueue doesn't send notifications

- there's no IPAddress::getPrefix() and getSuffix() (like IPv6Address has)

- apps: add startTime param; IPAddressResolver should only be invoked at startTime not in initialize()!

- TCP tests fail now (TCPDump has changed)

- if a node pings itself, that'll be "destination unreachable" -- fix it

- Eth: restore original conn color when transmission ends

- "headerLength" param in snrEval???

- IPv4 configurator: should fill in next hop addresses too, not only interface (esp with Ethernet)

- IPv4: make it usable with ad-hoc models

- notifboard: switch to the context of the client before calling its receiveNotification()

- todo for omnetpp-3.2:
     - add handleParameterChange() to apps (needed for Scenario Manager!)
     - use new opp_msgc features? (kind=..., length=...etc)

----------------------
 - ExtInterface performance optimization: I am not sure how long the pointer from
   pcap_next() is valid [until the next such call perhaps?], but it might be possible
   to spare the allocation of the ExtFrame and the cost of copying the bytes into it
   inside cSocketRTScheduler::receiveWithTimeout(). I mean, the notification message
   could just directly contain the ptr from pcap_next(), plus caplen; so the ExtInterface
   module could directly deserialize from the pcap buffer (and also spare copying the
   bytes out of ExtFrame). There is no concurrency problem, because events are processed
   in strict timestamp order, the notification message has the same timestamp as the
   external event, and receiveWithTimeout() is only invoked again when time has passed
   that timestamp (``if (timeval_greater(targetTime, curTime))'' line in getNextEvent()).
   This could improve the packet rate the simulation can handle in real time.

----------------------
- MPLS models: "gateway" field of routing entries gets lost after TED::rebuildRoutingTable
----------------------
- ICMP: shouldn't we unify ICMP and ICMPv6...? at least types and codes?
  ICMPv6 uses different type&code numeric values but this is only of interest
  if we want to do emulation

- instead of sending up ICMP packet to UDP & TCP: create an ICMPErrorInfo, and
  IP (IPv6) would attach that to the bogus datagram, with message kind IP_I_ICMP_ERROR.
  (win: IP/ICMP dependencies can then be removed from TCP and UDP in makemakefiles!!!)

- ErrorHandling is not used anymore! do we need to send a copy of ICMP errors to the
  ICMP module itself as well?

- TCP: how to handle ICMP error reports?

-----------------------
- MPLS/LDP/RSVP:
    - document! ScenarioManager commands, XML file formats, unimplemented features
    - Quagga ospfd: could it serve as OSPF_TE??
- mpls models use interface NAME - why?

-----------------------
- OSPFv2 TODO:
     - should use the proper IPAddress class, not its own one...
     - OSPFTimer class only contains a timerKind() -- is this class necessary at all...?
     - rename ifIndex (SetIfIndex, GetIfIndex, etc) to interfaceId AND change default value to -1!
     - OSPFRouting::LoadInterfaceParameters: interfaceType is contained in InterfaceEntry, it's redundant to read it from XML!
     - try to reduce size of configuration. If Zebra can do it...
-----------------------
into the ipv6 doc:
"
Currently, IPv6 support consists of several modules. The IPv6 module
implements IPv6 datagram handling (sending, forwarding etc). It relies on
RoutingTable6 to get access to the routes. RoutingTable6 also contains the
neighbour discovery data structures (dest cache, neighbour cache, prefix
list -- the latter effectively merged into the route table). Interface
configuration (address, state, timeouts etc) is held in the InterfaceTable,
in IPv6InterfaceData objects attached to InterfaceEntry as its ipv6()
member.

The module IPv6NeighbourDiscovery implements all tasks associated with
neighbour discovery and stateless address autoconfiguration. Its data
structures are in RoutingTable6 (dest cache, neighbour cache, prefix list).
Neighbour discovery packets are only sent and processed by this module --
when IPv6 receives one, it forwards the packet to IPv6NeighbourDiscovery.

The rest of ICMPv6 (ICMP errors, echo request/reply etc) is implemented in
the module ICMPv6, just like with IPv4. ICMP errors are sent into
IPv6ErrorHandling, which the user can extend or replace to get errors
handled in any way they like.
"

-----------------------
TCP:
Slow Start should be applied every time TCP starts to send "after a
sufficiently long idle period".

"Idle" could be interpreted as when the send queue is empty (there's nothing
to send), and there's no unacknowledged data (i.e. previously sent segments
have all been acknowledged). But what is "sufficiently long"? I guess that
should be measured in RTT rather than absolute time (secs). So maybe we
should say 5*RTT is "sufficiently long"?
-----------------------
802.11 bugs: see mailing list...
-----------------------
FlatNetworkConfigurator: assigns the same address to all interfaces of a router.
This is not the usual way things are done on the internet. But if we assign
different addresses, which addr to use in the routing tables etc?
-----------------------
VOJTA:
 -make connect work without bind (autoassign local address based on
destination, currently unspecified address is sent and SYN+ACK will not
be sent back (at least for 127.0.0.1, I didn't check for others))
-----------------------
from http://www.freesoft.org/CIE/Course/Section3/10.htm:

# Per-interface assignment. IP addresses are assigned on a per-interface basis,
so a host might possess several IP addresses if it has several interfaces.
For example, a host with both Ethernet and serial interfaces would have an
IP address for each. This is an important consequence of prefix-based
addressing. An IP address doesn't really refer to a host, it refers to an
interface.

If a host is known by multiple addresses, then every service on this host
can be referred to by multiple names! Addressing this host requires picking
one of these. Since the packet is addressed to the interface and not the host,
path information is introduced into the address. The exact ramifications of
this effect depend heavily on the network design. In particular, careless
design can result in a host becoming reachable by one address but not by
another. The simplest solution to this problem is to select the host's most
reliable interface and advertise its IP address as the host's primary IP
address.

==> current FlatNetworkConfigurator is shit? how to do address assignment?

see also:
 "The Network Administrators' Guide" http://www.tldp.org/LDP/nag/node1.html
 "IP 101: All About IP Addresses" http://www.networkcomputing.com/netdesign/ip101c.html
  - according to this: network numbers and interface addresses don't necessarily
    have to do anything with each other! may look COMPLETELY different

from http://www.networkcomputing.com/netdesign/ip101.html:

The important thing to realize is that while a routing table keeps track of
network numbers, no one assigns a network number to any piece of equipment.
Every interface of a router or host connected on the network must have an IP
address and a subnet mask defined (many pieces of equipment will assign a
default subnet mask if none is applied). From this IP address and subnet mask,
the network number is derived by the IP stack and tracked in the routing table.

Q: if routing tables contain network numbers, are IP addresses of router
interfaces also addressable?