Stacking it Up - Geoff Huston

8/7/2019 Stacking it Up - Geoff Huston

1/44

StackingitUp

ExperimentalObserva6onsontheopera6onofDualStackServices

GeoffHustonIETF-80

March2011

1


2/44

End-to-EndServiceMeasurements

ExamineIPv6/IPv4usefromtheperspecCveofaservicedeliveryplaorm(webserver)

IPv6isusedbyclientsonlywhenallthevariousIPv6infrastructurecomponentssupportIPv6,otherwise

theclientwillfallbacktoIPv4use

ServicemetricsforIPv6arereflecCveofend-to-endIPv6capability

2


3/44

Methodology

Testeverywebclientwith4differentretrievaltasksofa1x1pixelimage: V6only Dual-Stack V4Only V6OnlyLiteral(noDNS)

Takejustonetestresultforeachuniquesourceaddressper24hours

Lookatretrievalrates,failurebehaviourandtransacConCmes

Useserverpacketdumpandandweblogsasthebasisoftheanalysis

3


4/44

AccessCombina6ons

V4 V Dual NodeType

V4 V4-Only

V V-Only

V V-Preferred

V4 V-Capable(V4-Preferred)

Dual-StackLoss

4


5/44

IPv:couldvswill

2%

4%

6%

8%

IPv6 Preferred

IPv6 Capable

May 5Jul Sep Nov Jan Marwww.apnic.net


6/44

IPv:couldvswill

1%

2%

3%

5%

IPv6 Preferred

IPv6 Capable

Nov

6

Dec Jan Feb

4%

Site CMar


7/44

WherearewewithIPv?

ThesizeoftheIPv6deploymentintermsof

end-to-endhostIPv6preferenceisaround

0.2%ofthetotalnumberofInternetend

hostsatpresent

However,afurther4%ofhostscanuseIPv6,

eventhoughtheypreferIPv4indualstack

mode,usingauto-tunnelaccess

7


8/44

WhyistheresomuchhiddenIPv

capability?

Whyisthenumberofclienthostswhoare

capableofperforminganend-to-endIPv6

objectretrieval20Cmesgreaterthanthe

numberofclienthostswhoprefertouse

IPv6inadualstackcontext?

8


9/44

Dual-StackVPreferredbyAddressType

V6 Unicast

6to4

Teredo0.1%

0.5%

0.3%

9

Nov Dec Jan Feb Mar


10/44

V6 Unicast

6to4

Teredo

10

1%

2%

3%

4%

Dual-StackV4PreferredbyAddressType

Nov Dec Jan Feb Mar


11/44

Na6vevsTunnels

MosthostswithunicastIPv6generallypreferV6inadualstackscenario

Hostswith6to4auto-tunnelcapabilityappeartogenerallypreferV4inadualstackscenario

11


12/44

Na6vevsTunnels

OlderversionsofdualstacksowareinhostspreferredIPv6overIPv4inallsituaCons,including

auto-tunnels

ThisresultedinveryslowanderraCcperformancewhenaccessingsomedualstackserversduetothelocalIPv6failureCmers

Forexample,WindowsXPtakes20secondstorecoveraconnecConifa6to4connecConisnotfuncConingcorrectly

RecentOSreleaseshavede-prefedauto-tunneledIPv6belowthatofIPv4

12


13/44

PerformanceObserva6ons

13


14/44

PerformanceandTunnels

V6 Unicast

6to4

Teredo+4 Secs

+2 Secs

-2 Secs

0 Sec

14Nov Dec Jan Feb Mar

-4 Secs


15/44


15

UnicastIPv6performanceisonaverageequivalenttoIPv4performanceforweb

objectretrieval

Auto-tunnelperformanceisonaverageconsiderablyworse

Teredoishighlyvariablewith13secondsofaddiConaldelayperretrieval

6to4ismoreconsistentwithanaverage1.2secondsaddiConaldelayperretrieval


16/44


Twocausesofincrementaldelay:

TunnelsetupCmeStatefulTeredotunnelsrequireiniCalpacketexchangestosetthetunnelup(min1xRTT)

TunnellingcanextendtheRTTdelayaddiConoftunnelrelaysbetweenthesourceanddesCnaCon

Thisisexacerbatedwhentheforwardandreversepathsareasymmteric

16


17/44

V4-Only

Network

Dual-Stack

Network

to4PacketPath

17

Client

Dual-StackServer

192.88.99.1 Relay

2002::/16 Relay


18/44

V4-Only

Network

Dual-Stack

Network

Par6alMi6ga6onofto4Packet

Path

18

Client

Dual-StackServer

2002::/16

Relay

192.88.99.1 Relay


19/44

to4Performance

SetupTime

19


20/44

TunnelRTTost

to4Performance

20


21/44

to4Rela6vePerformance

6to4addsanaverageof1.2secondstotheobjectretrievalCme

notethisisone-way(astheserverhasalocal6to4relayfortheresponsetraffic,sothe6to4responsepathisthesameastheV4path)

thatsaverylongtransitCmeifthisisjustaddedtransitCme TheremaybeacongesConloaddelayaddedinhere Butthelevelof6to4trafficisverylow,socongesConoverloadisunlikely

21


22/44

Teredovsto4

Whatwesee:

4%ofhostsuse6to4(naCveV4,auto-tunnel) 0.1%ofhostsuseTeredo(NATV4,auto-tunnel)

ButwhysolileTeredo?

WindowsVistaandWindows7gethostbyname()willnotqueryforaAAAArecordiftheonlylocalIPv6interfaceisTeredo

anweexposelatentTeredocapability?

22


23/44

ExposingTeredo

UseanIPv6literalastheobjectURL:

hp://[2401:2000:6660::f003]/1x1.png

23


24/44

ExposingTeredo

24


25/44

ExposingTeredo

UseanIPv6literalastheobjectURL:

hp://[2401:2000:6660::f003]/1x1.png

Inthecontextoftheexperimentalsetupitwasobservedthat~30%oftheclientbasesuccessfullyfetchedthisIPv6

URLusingTeredo!

onversely,70%oftheclientsdidnotmanageasuccessfulobjectretrievalofthisURL

25


26/44


Teredoaddsafurtherperformance

penaltyintheformofstatesetupbetween

theTeredorelayandtheclient

26


27/44

TeredoPerformance

TunnelSetupTime

27


28/44

TunnelRTTost

TeredoPerformance

28


29/44

TeredoRela6vePerformance

Teredoaddsanaverageof1-3secondstotheobjectretrievalCme

Teredosetuptakesbetween0.6secondto3seconds AverageRTTcostofTeredois300ms Objectretrievaltakes~3RTTintervalstocomplete TotalCmecostissome2secondsonaverage

29


30/44

IPvPerformance

UnicastIPv6appearstobeasfastasIPv4forobjectretrieval

Auto-tunnellingIPv6aractssomeperformanceoverheads thesearestronglycontextdependent widespreaddeploymentof6to4relaysandTeredorelays

andserverswouldmiCgatethis,tosomeextent

DualStackserversmaywanttoconsiderusinglocal6to4relaystoimprovereversepathperformanceforauto-

tunnellingclients

30


31/44

FailureObserva6ons

31


32/44

DualStackFailure

HowmanyclientsretrievetheV4only

objectbutDONTretrievetheDualStack

objects?i.e.howmanyclientsexhibitDualStack

Failure?

32


33/44

DualStackFailureRate

33

0.2%

0.4%

0.6%

0.8%

Nov Dec Jan Feb Mar


34/44

DualStackFailure

This0.6%ofclientsistherateoffailureofIPv4

clientstoretrieveadualstackobject

Butthisisnotareliablemetricofunderlying

communicaConfailure

Thisistherateoffailureoftheclienttoretrieveadualstackobjectfromwithinajavascriptcodeobject

Theclientmay: Notexecutethejavascriptatall UserresetoftheretrievalbeforecompleCon InaddiContothefailuretofallbacktoIPv4retrieval 34


35/44

Connec6onFailure

ToaempttolookmorepreciselyforsomeinstancesofconnecConfailure,letslookingforconnecConsthat

failaertheiniCalTPSYN

NotethatthisapproachdoesnotdetectfailureoftheiniCalSYNpacket,so

theresultsarealowerboundoftotalconnecConfailurerates

35

Client

Server

SYN

SYN + ACK

ACK

X Response fails


36/44

Connec6onFailure

36


37/44

IPvConnec6onFailure

37


38/44

TeredoConnec6onFailure

TeredousesaniniCalIMPv6exchangetoassistintheTeredoServer/Relaystatesetup

NotethatthisapproachdoesnotdetectfailureoftheiniCalIMPv6echo

request,sotheresultsarealowerboundoftotalconnecConfailurerates38

Client

Server

SYN

SYN + ACK

ACK

X

SYN fails

ICMPv6Echo Req

ICMPv6 Echo Resp

X X

ICMP fails


39/44

IPvConnec6onFailureusingVLiteral

39


40/44

IPvConnec6onFailure

40

Some12%-20%ofto4connecConsfail! Thisisaveryhighfailurerate! Thefailureismostlikelyaprotocol41filterclosetothe

clientthatpreventsincoming6to4packetsreachingtheclient

Some38%ofTeredoconnecConsfail! Againthisisaveryhighfailurerate LocalIMPFilters+????SYNAKFilters

Some2%-5%ofunicastIPv6connecConsfail! Thisrateisbeerthanauto-tunnels,butissCll20xthe

rateofIPv4connecConfailure


41/44

Conclusions

Whatcanwesayabouttheperformanceand

robustnessofaDualStacknetworkenvironment

asaresultoftheseobservaCons?

41


42/44

ForanOnlineService

onverCngaservicetooperateasaDual

StackserviceisaviableopConintodays

environment

But:

asmallfracConofexisCngclientswillexperienceamuchslowerservice

averysmallfracConofexisCngclientswillfailtoconnecttothedualstackserviceatall

42


43/44

WhataboutIPv-OnlyServices?

IsanIPv6-onlyserviceaviableopContoday?

Notreally.

Only~4%oftheexisCngclientbasewouldsuccessfullyconnecttoanIPv6-onlyservice

End-hostauto-tunnellingisnotasoluCon Auto-tunnellingappearstoencountermanymoreperformanceandreliabilityproblemsthanitsolvesintermsofIPv6connecCvity

Auto-tunnellingisnotprovingtobeausefulmainstreamtransiContoolforIPv6

43


44/44

Stacking it Up - Geoff Huston

Documents

Transcript of Stacking it Up - Geoff Huston