[Berlin-wireless] ETX(+bat) unrealistisch, war:Re: airtime? *robuste_packets*?

[Hannes Gredler]

On Wed, Nov 21, 2007 at 10:06:16AM +0100, Jens Nachtigall wrote:

| Das kann man nat?rlich machen, allerdings gehen die ETT-Pakete erstmal nur 1 
| Hop weit. Dort k?nnte man nat?rlich die Infos mehrerer Nachbarn 
| zusammenfassen, und jeweils wieder an den n?chsten senden... 
| H?rt sich f?r mich erstmal hackisch an; bzw. 2. Schritt zu ?berlegen, ob man 
| anstatt eines leeres Pakets was sinnvolles reinpacken kann. Die ETT-Pakete 
| wird man weil unicast und in beide Richtungen auch nicht so h?ufig 
| verschicken wollen wie die Hello-Pakete (alle 20 sek. und noch seltener). Da 
| h?tte man dann schon einiges an Verz?gerung 
| beim "Aggregieren->N?chster-Hop->Aggrerieren->usw".

hmm aggregieren ist zunaechst nicht vorgesehen.
der charakter von link-state protokollen ist,
dass ein lokales link sensing und damit auch
die ETT ermittlung lediglich lokal stattfindet.

| >
| > | Im Paper welches ett vorschl?gt, wird deshalb per unicast an jeden
| > | (durch die Hello-Pakete bekannten Nachbarn) zuerst ein 137B gro?es Paket
| > | geschickt, und unmittelbar darauf ein 1137B gro?es Paket, Dann misst man
| > | die Zeitdifferenz zw. Ankunft des ersten und zweiten (Dummy)Pakets und
| > | dann
| > |
| > | Bandbreite (besser Kapazit?t) des Links = 1000B / Zeitdifferenz
| >
| > du beziehst dich auf dieses paper ?
| >
| > http://research.microsoft.com/mesh/papers/multiradio.pdf
| >
| > im olsrd waere es auch realtiv einfach den gemessenen ETX
| > in einen ETT ueberzufuehren und per TC zu announcen.
| 
| Ja, das Paper meine ich [0]. Ich hatte mir das so ?berlegt, ohne den internen 
| Aufbau des olsrd so gut zu kennen wie Du:
| 
| 1. ETX (also angen?herte Verlustrate) zu allen Nachbarn ist bekannt
| 
| 2. alle x Sekunden (x > HelloInterval)  werden unicast die beiden Pakete an 
| jeden nachbarn verschickt (PktPair, siehe oben). Das geschieht in beide 
| Richtungen, und der Mittelwert aus beiden Bandbreiten ergibt, die 
| Gesamtbandbreite des Links.

ok, clever - damit bleibt das routing auch immer symmetrisch.
 
| 3. per TC wird statt ETX der ETT-Wert als Metrik announced, und der 
| SPF-Algorithmus funktioniert auch wie bisher, nur dass nun ETT statt ETX als 
| Gewicht/Metrik eines Links verwendet wird.

korrect

| Das w?re sozusagen Step 1, Step 2 k?nnte man dann mal gucken, ob es m?glich 
| ist ins PktPair noch zus?tzliche Infos unterzubringen, wenngleich ich dort 
| f?rs Fluten das Plugin-Interface besser geeignet finde.

ich hab aud performance gesichtspunkten so keine rechte freude mit dem
plugin interface, wuerde das wenn gerne in den olsrd core reinnehmen.
(abwaertskompatibel natuerlich).

| [0] Dort ist auch eine interessante Metric "Weighted Cumulative ETT" 
| beschrieben, wo nochmal intra-flow interference betrachtet wird, also wenn 
| ein Paket auf Kanal 1 reinkommt, w?re es zu bevorzugen, dass es auf einem 
| nicht-?berlappenden Kanal geforwarded wird bzw. auf ethernet. Kann im olsrd 
| aber leider nicht verwendet werden, sondern nur mit Source Routing (da nicht 
| isotonisch). 

du hast recht - beim 'olsrd kann das nicht' stimme ich dir nicht ganz zu - 

man braeuchte "lediglich" folgendes rezept:

1. eine neue data-plane hierzu. z.b. MPLS
   linux for mpls sieht recht vielversprechend aus.

2. eine label signaling protokoll extension im OLSR womit jeder
   node einfach explicit routes aufsetzen kann.

3. TC extensions um radio-frequency etc. zu verbreiten.

4. ein paar tweaks im SPF code um diese explicit routes
   auch im forwarding zu verwenden.

/hannes