From: poelzi <poelzi@poelzi.org>
To: b.a.t.m.a.n@open-mesh.net
Subject: [B.A.T.M.A.N.] Small feature request
Date: Fri, 15 Jun 2007 15:26:23 +0200 [thread overview]
Message-ID: <4672937F.3040208@poelzi.org> (raw)
Hi,
I got a interessting paper forwarded which discussed routing in tcp on
ad-hoc networks (especially tcp vegas). The idea was like that:
If the routing protocol notices the tcp stack that the route has
changed, it can recalculate some of its parameters (here the BaseRTT
value) to optimize speed.
Implementing meshferry, a tcp over udp proxy to surround most of tcp
problems, I can see a lot of usage for this. Because batman doesn't know
the topology itself, i thought about a mechanism to detect route changes
without knowing topology itself.
All batman originator packets would become an additional flag, lets say
uint32. When batman starts, it generates a random uint32 for its
complete runtime.
On a new broadcast message, it sets this new flag to his own random
value. If it rebroadcasts a message, it used the original value XOR its
own. This mechanism detects route changes very likely and even batman
restarts.
If the this new flag changes, the route somewhere in the network has
changed, it can't say where, but it doesn't have to.
The operations are cheap, the overhead is small. And allows analysis if
routes are more static or switching (would be interessting to see).
Long term I was thinking about a socket interface between routing daemon
and transport daemon. For the case of switching routes, batman would
then notify the route to host x has changed somehow, so he can optimize
his parameters.
kindly regards
daniel
next reply other threads:[~2007-06-15 13:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-15 13:26 poelzi [this message]
2007-06-17 12:00 ` [B.A.T.M.A.N.] Small feature request Marek Lindner
2007-06-17 14:12 ` Daniel Poelzleithner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4672937F.3040208@poelzi.org \
--to=poelzi@poelzi.org \
--cc=b.a.t.m.a.n@open-mesh.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox