[Ns-bugs] [Bug 74] New: Redundant routing table lookup for setting src addr of outoging IP packets
bugzilla-daemon at nsnam-www.ece.gatech.edu
Thu Sep 13 03:05:21 PDT 2007
Summary: Redundant routing table lookup for setting src addr of
outoging IP packets
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
The problem and possible solution is described in the first point in
I proposed to make the Ipv4RoutingProtocol responsible for setting the source
address in Ipv4Header when it is 0.0.0.0.
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
But that optimization goes another level. I am proposing something far simpler
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.
More information about the Ns-bugs