Benutzer:Felix/VOIP Gutachten Material

RegTP Vorhabenplan 2005

http://www.regtp.de/aktuelles/start/in_03-13-00-00-00_m/Vorhabenplan_2005.pdf

• Unter Punkt II wird gesagt, dass die RegTP innovative Netze und Dienste unterstützen, effiziente Infrastrukturen förden, sowie technologieneutral sei will.
• Unter II.2 wird gesagt, dass eine hohe Verfügbarkeit von Breitbandanschlüssen ein primäres Ziel ist und dafür auch eine Entbündelung von Teilnehmeranschlüssen notwendig ist. Auch hier wird sich wieder auf Innovation bezogen. Darauf sollten wir uns dann auch beziehen.
• Weiterhin wird die Entgeltregulierung in III.1 als wichtiges Thema für 2005 genannt.
• In III.4 (Wettbewerbsförderung von Einzelmärkten) ist auch wieder von Entbündelung die Rede.
• Noch sehr schön: Die Überschrift von IV lautet "Wahrung der Nutzer- und Verbraucherinteressen". Der Verbraucherschutz ist der RegTP angeblich besonders wichtig. Problematisch ist allerdings, dass darunter auch die Notrufnummern fallen. Auch sollten wir evtl klären, inwiefern die Qualität bei einer Entbündelung leiden könnte.
• Unter VI geht es um die "Wahrung der Interessen der öffentlichen Sicherheit", also auch um die technische Umsetzung der Überwachungsmaßnahmen. Es sollen wohl noch Richtlinien u.a. für VoiP verfasst werden, damit man die Voraussetzungen für Überwachungsmaßnahmen der befugten staatlichen Behörden schaffen kann. Auch automaitisiertes Auskunftsersuchen wird als wichtig erachtet (also dass Benutzerdaten von berechtigten Stellen abgefragt werden können).

EU-Vorgaben (Treatment of voip under the EU Regulatory Framework)

(http://europa.eu.int/information_society/topics/ecomm/doc/useful_information/library/commiss_serv_doc/406_14_voip_consult_paper_v2_1.pdf )

• Vorgaben nur für Infrastruktur, nicht für Inhalt
• Ziele: Wettbewerb fördern durch:
  • Innovation fördern
  • leichteren Markteinstieg
  • liberale Märkte
• den europäischen Binnenmarkt fördern
• Interessen der EU-Bürger wahren

Vorgaben der EU:

• in-line powering: NRA's könnten voip-Provider dazu verpflichten, die Kunden aufzuklären, dass voip bei Stromausfall nicht funktioniert
• Noptrufe: Anrufstandortermittlung soll möglich sein, ohne dass der User selber irgendwelche Infos bereitstellen muss (beim Anruf oder Installation des Services) (to be continued)

End to end argument

Beispiel reliable file transfer: - wenn reliable einfache strategie ist, datei übertragen, checksumme, ok -> done, ko -> nochmal

- Wenn eine der beteiligten komponennten sehr viele fehler macht, dann wird performance des ganzen sehr schlecht -> optimierung ist also die verlässlichkeit dieser komponente zu erhöhen

- Ist _NUR_ Optimierung und hat tradeoff: Verlässlichkeitssteigerung der komponente kostet auch -> muss also richtige balance finden

Idee des end to end arguments: mann will end-to-end bestätigung haben - nicht nur "das datenpaket wurde korrekt übertragen, ob die ganze datei auch korrekt gesichert wurde weiss ich nicht"

Netzgewerkte systeme

Wenn ich aus irgendwelchen gründen eine Funktion nur komplett und korrekt implementieren kann wenn ich auf beiden endpunkten des netzwerkes etwas zusammen mache, dann hat es keinen sinn dazwischen auf irgendwelchen layern teile dieser funktion inkorrekt zu implementieren, weil man immer noch die globale implementierung braucht, da andere teile der kette fehlerhaft sind.

Es gilt aber das teilimplementierungen als performance-optimierung sinnig sind

Ist das auch "Law of Leaky Abstraction"?

- Leaky Abstraction heist das alle nichttrivialen abstraktionen löchrig sind, die abstraktion also nicht unter allen umständen aufrecht zu erhalten ist.

Das ist damit der Grund für das End-To-End argument!

End-To-End argument reformuliert mit leaky abstraction

Weil Leaky-Abstraction gilt, muss ein verlässliches system das aus abstraktionen zusammengesetzt ist immer noch das prüfen was die abstraktionen eigentlich verbergen sollten.

Leaky Abstraction

Abstraktionen sind immer (!) intern getunt für bestimmte anwendundungsfälle und gegen andere. Diese entscheidungen sind aber hinter der abstraktionsgrenze versteckt. Das Leak ist wenn man durch seine anwendung diese entscheidungen zu spüren bekommt.

Problem mit end-to-end

Das Problem ist, die Endpunkte auszumachen an denen man das argument festmachen sollte.

end to end (e2e) von "end to end vs. buy our box"

- End to end arguments are about where to situate functions in a computer system - Locate the functions higher up the protocol stack, towards the edge, closest to the application. - Keep the transportation function as unspecified as possible (down the protocol stack). - Do not over-specify the solution; a system optimized for one application (voice telephony) is less useful for others.