[Ns-bugs] [Bug 74] New: Redundant routing table lookup for setting src addr of outoging IP packets

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=74

           Summary: Redundant routing table lookup for setting src addr of
                    outoging IP packets
           Product: ns-3
           Version: pre-release
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: blocker
          Priority: P1
         Component: internet-node
        AssignedTo: ns-bugs at isi.edu
        ReportedBy: gjcarneiro at gmail.com


The problem and possible solution is described in the first point in
http://mailman.isi.edu/pipermail/ns-developers/2007-September/003348.html

I proposed to make the Ipv4RoutingProtocol responsible for setting the source
address in Ipv4Header when it is 0.0.0.0.

Tom proposed:
"""
I agree that we now have redundant searches in the routing tables, once 
in UDP and once in IP.  I think the crux of the problem is already 
described in this comment in Ipv4L3Protocol::Send()

       // XXX Note here that in most ipv4 stacks in the world,
       // the route calculation for an outgoing packet is not
       // done in the ip layer. It is done within the application
       // socket when the first packet is sent to avoid this
       // costly lookup on a per-packet basis.
       // That would require us to get the route from the packet,
       // most likely with a packet tag. The higher layers do not
       // do this yet for us.

I would suggest to perhaps fix along the lines suggested in this 
comment, because otherwise, if I understand correctly, the source 
address is incorrectly set down to the IP layer which can cause checksum 
issues when checksums are enabled.
"""

To which my reply would be, this technique won't work very well for very
dynamic adhoc routing protocols, because this way you store the route in the
socket based on the route discovered for the first packet sent, but then you
never change it ever again, even if the underlying routing protocol discovers a
new better route or the old one simply becomes invalid.  IMHO it's better to
keep it as it is, always go through the routing protocol.

If we really want to speed up things along those lines it should be possible,
for example let the Ipv4RoutingProtocol::RequestRoute receive an extra optional
parameter containing the last route found, which would be stored in the socket
as the source comment suggests.  But in this case the routing protocol is given
full control, and can ignore the route suggestion if it can find a better
route.  

But that optimization goes another level.  I am proposing something far simpler
for now.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.