摘要

現在的網絡性能監控能力受到現有的交換機對監控范圍支持的限制，迫使運營商嚴重依賴于對網絡核心設備可視性差的終端。交換機供應商對交換機增加了更多的監控功能，但是鑒于網絡運營商的不斷變化的需求，添加特定功能的方法是不可持續的。因此，我們尋找一種交換機硬件原語來支持網絡性能監控的表達性語言。我們相信，由此產生的交換機硬件設計可以解決當前和未來的各種性能監控需求。

我們提出一種性能查詢語言，Marple，它以熟悉的功能結構為模型，如map，flter，groupby和zip。 Marple在交換機硬件上支持可編程鍵值存儲基元。密鑰值存儲器按照線路速率進行靈活聚合（例如，每個數據包的排隊延遲的移動平均值），并且擴展到數百萬個鍵值規模。我們提出了一個Marple編譯器，其目標是P4可編程軟件開關和用于高速可編程交換機的模擬器。 Marple可以表示以前只能在終端主機上運行的交換機查詢，而Marple查詢只占用交換機硬件資源的一小部分。

一 引言

對于大型網絡的有效性能監控對快速定位網絡問題是至關重要的，如高延遲時間，網絡鏈路負載不平衡等問題。網絡監控的常見方法是從終端的網絡緩存中收集信息，或使用端對端探針來診斷性能問題。雖然終端可以監視到應用層的問題，但是它們在網絡鏈路層的問題是無法進行判斷的。例如，對于特定交換機進行本地優化隊列建立或導致隊列建立的精準流量具有挑戰性，迫使運營商間接的推斷是網絡級的問題。

基于交換機的監控可以使運營商能夠更加直觀地了解性能統計信息來診斷問題。 然而，傳統的交換機機制，如抽樣[7,21]，鏡像[8,42,65]和計數[34,49]是非常受限的。采樣和鏡像缺少對感興趣的事件的記錄，因為它不可能收集所有數據包的信息，而計數器只跟蹤流量統計。這些機制都不會提供相關的性能數據，如排隊延遲。

一些先進的技術意識到更好的交換機性能監控的重要性。入棧網絡測量技術在數據包本身寫入數據包經歷的排隊延遲。 Tetration芯片[9]提供了一個流量緩存，用于測量流量級別的性能指標。這些指標是有用的，但它們被指定為確定的粒度（例如，每5元組），并且度量本身被固定了。例如，度量的列表包括流水平等待時間和分組大小變化，但不包括延遲變化，即抖動。

運營商的要求是不斷變化的，重新設計硬件是昂貴的。 我們認為，添加制定功能的方式是不可持續的。 相反，我們主張構建性能監控原語，可以靈活地重用于各種需求。 可編程交換機現在支持靈活解析，標題處理[33,56]和調度[57]。我們的目標是將網絡監控添加到此列表。

受到早期設計硬件支持高級語言設計的啟發[36,50,59]，本文將語言導向的硬件設計應用于靈活的性能監測問題，。特別地，我們設計了一種語言，可以表達廣泛種類的性能監控實例，然后設計高速交換機硬件原語來服務于這種語言。通過設計硬件來支持表達性語言，我們相信最終的硬件設計可以滿足各種各樣的當前和未來的性能監視需求。

圖1概述了我們的性能監測系統。為了使用該系統，運營商使用Marple語言寫一個查詢（或者是為長期運行的監視器來統計數據(例如:，檢測TCP超時)，或解決一個特定的問題）該查詢被編譯成一個可以可編程的交換機上運行的交換機程序，用我們為Marple服務設計的新交換機硬件原語擴充。交換機將結果輸出到收集服務器，在那里，運營商可以檢索查詢結果。我們現在簡單地描述一下我們系統的三個組成部分:

查詢語言、交換機硬件和查詢編譯器。

性能的查詢語言

Marple使用熟悉的功能結構，如map、filter、group by和zip進行性能監視。Marple提供一個流的抽象概念,其中包含每一個隊列中的每一個數據包信息。程序員可以將注意力集中在使用filter來尋找關注的數據包的信息，使用groupby來查找數據包集群信息，使用map計算新的無狀態數量，并使用zip來檢測同步的性能條件。

用于性能查詢的硬件設計

一個簡單的Marple實現可以將每個包的元數據從網絡流到一個中心位置，并對其運行流查詢。現代擴展數據處理系統支持每秒100 k-1m操作每核心，但一個處理速度為1 Tbit / s速度的交換機處理一個1K大小的數據包需要每秒運行1M次操作，比現有系統高2-3個量級。

我們在網絡監視中使用高速可編程交換機作為高優先級的設備，因為他們可以通過編程操作多tbit / s數據包流。早期的過濾和靈活的交換機聚合在交換機上大大減少了每秒的記錄的數量，以一個標準的數據處理系統運行信息收集服務器。

雖然可編程的交換機支持許多Marple的無狀態語言結構，但每一種結構僅能修改單個數據包的組成(例如:，map和filter)，它們不支持多個數據包之間的狀態聚合(例如:groupby)。為了支持靈活的數據包聚合,我們在硬件上設計一個可編程鍵值存儲結構,那里的key代表流標識符，值代表通過聚合功能得到的數據流的信息。這個鍵值存儲必須以每個時鐘周期1個包的速度進行更新(1Ghz)，并支持數百萬個鍵(即流)。不幸的是，SRAM和DRAM都不能同時滿足快速和高密度的要求。

我們將key - value存儲系統分成一個小而快速的芯片緩存SRAM和一個大但慢的DRAM的芯片存儲。傳統的緩存會因為未命中導致寫延遲的不同，然而，數據包轉發需要確定的延遲保證。我們的設計實現了了這一點，如果它已經被放入到后備存儲器中，它決不會將一個值讀入緩存。相反，它將緩存未命中看作是來自新流的數據包的到達。當流被處理完成后，我們將流的值合并到在后備存儲中的流的舊值中。因為合并發生在關鍵的包處理路徑上，所以后備存儲可以在單獨的收集服務器上的軟件中實現。

雖然并不總是可以聚合功能而不損失準確性，但我們定義了一類精煉的聚合功能，我們將其稱為線性狀態，以實現準確的合并。許多有用的聚合功能都是線性的，如計數器，指定類型數據包計數器(例如:只統計超時的TCP包），以及處理指定窗口期的數據包的功能。我們設計了一個交換機指令來支持線性狀態的功能，發現很容易滿足1Ghz的頻率，同時占據的硅區域也較為合理。

查詢編譯器

我們設計一個編譯器可以讀取marple查詢語句并將其編譯成交換機的配置。主要設計目標有兩個：(1)P4行為模型[19],一個可用于端到端評估的開源的軟件可編程交換機(2)可用于高速可編程交換機硬件模擬器,可以使用不同的指令集進行試驗。Marple編譯器在輸入查詢中檢測出線性狀態的聚合，并成功地實現我們添加到Banzai的線性-狀態開關指令。

評價

我們展示了Marple可以有效的表達各種性能監控示例，比如檢測和本地化TCP incast，并度量已過期的TCP包的傳送情況。Marple查詢需要4到11個管道階段，這對于32個階段的交換機管道來說是很有限的[33]。我們使用路徑驅動的仿真來評估鍵值存儲的性能。對于64 Mbit片上緩存而言,它占據了64×10-Gbit / s交換機芯片大約10%的面積。我們估計,從單個top-of-rack緩存回收速度的交換機可以由一個運行radish的8核服務器進行處理。我們通過兩個Mininet案例研究來評估Marple的可用性，這些研究使用Marple來診斷高延遲。marple是開放源代碼的,可以在http://web.mit.edu/marple下載。

二 marple 查詢語言

本節描述Marple查詢語言。第三部分討論語言構造的交換機實現，而第四部分則描述編譯器。Marple提供了一個網絡范圍性能信息流的抽象。當數據包進入和離開隊列時，網絡中每個隊列的每個包的信息都會保存，流中的元組包含性能元數據，例如隊列長度和時間戳。網絡操作符在此流上編寫查詢，就好像整個流都是由一個運行查詢的假想服務器處理的。實際上，編譯器將網絡上的查詢分塊，并在每個交換機上執行每個部分。

Marple程序使用熟悉的功能結構(filter、map、groupby和zip)來處理性能流，所有這些都以流作為輸入，并生成流作為輸出。這個函數式語言模型足以支持不同的性能監視用例，但仍然足夠簡單，可以在高速硬件中實現。Marple的語言結構如圖2所示。

數據包流性能

作為基本輸入流的一部分，我們稱之為pktstream，Marple為每個隊列中的每個包提供一個數組，包含以下元素：

(switch, qid,hdrs, uid, tin, tout, qsize)

switch和qid表示數據包所在的的交換機和隊列。包可以在單個交換機中遍歷多個隊列，因此我們提供不同的項。常規的包頭(以太網、IP、TCP等)都可以在hdrs集合中使用，它的uid可以唯一地確定數據包。

數據包性能流提供對各種性能元數據的訪問:tin和toiut表示數據包的入棧和出棧時間戳，而qsize則表示數據包所在隊列的隊列深度。使用兩種時間戳來檢測屬于不同流的數據包是有益的。此外，使用隊列大小是有好處的，因為我們不能總是從兩個時間戳上確定隊列大小:一個鏈接可能服務多個隊列。

pktstream中的元組是按照包的出棧時間的順序處理的，因為這是pktstream中所有的數組元素都知道的最早的時間。如果一個包被丟棄了，tout和qsize都是無限的。可按任意順序處理對應于丟棄的包的數組。

Restrictingpacket performance metadata of interest

考慮指定隊列Q、交換機S的高延遲數據包的實例。這是通過查詢表示的結果：

?

fileter限制了函數中部分元素之間的關系。filter有filter(R,pred)的形式，其中R是一些包含性能元數據的流。而filter假設pred可能涉及包頭、性能元數據，或者兩者兼而有之。filter的結果是另一個只包含滿足假設的數據組的流。

Computingstateless functions over packets.

Marple允許用戶在傳入的流中計算數組的功能。一個簡單的例子就是將包時間戳四舍五入到一個“區間”:

map操作對“tin /epoch_size”的表達式進行重新計算，這是在流中可用的數組元素上進行運算，并生成一個新的元素的過程。這個構造的一般形式是map(R，[expression]，[field])，通過輸入流的元素數組建立了一個新的輸出流的元素數組。

在多個包上有狀態地聚合

Marple允許在用戶指定的粒度上對多個元組進行聚合統計。例如，對屬于每個傳輸層流的數據包進行查詢計數：

在這里，groupby將傳入的pktstream按照傳輸5元組的方式劃分成子流，然后應用聚合函數計數來計算每個子流中的元組的數值。Marple允許用戶在每個子流的元組上編寫靈活的聚合函數。例如，用戶可以通過按指數加權移動平均(EWMA)來跟蹤每個連接的延遲峰值:

在這里，聚合函數ewma使用avg的當前值和傳入的包時間戳來獲取一個ewma avg。與前面的示例不同，EWMA聚合函數依賴于正在處理的數據包的順序。

groupbys采用一般形式的groupby(R，[aggFields]，fun)。這個構造的靈感來自函數式編程的折疊[45]。在現有的查詢語言中，這種依賴于順序的折疊的表達是具有挑戰性的。例如，SQL只允許確定順序的交換聚合，不管它是內置的還是用戶定義的。

聚合函數fun是具有兩個參數：一個狀態變量的列表、一個入棧數據包數組的列表。Fun函數的定義可以是如下幾種方式：表達式 (x = ...)；分支表達方式 (if pred {...}else {...})；groupby中控制輸出流的emit()形式。下面，我們將展示一個用于檢測新連接的聚合示例：

groupby的輸出是包含聚合數組(例如:，5元組)和聚合值(例如fcount)的流。輸出流只包含指定的元組，即那些在聚合函數執行時emit（）函數所包含的元組。例如，new_flow的輸出流由每個新的傳輸層連接的第一個包組成。如果函數沒有emit()s，則用戶仍然可以讀取聚合字段和它們當前的聚合狀態值作為表。

多個查詢的鏈接

由于所有的Marple都構建和使用流，因此Marple允許用戶編寫查詢，這些查詢將先前的查詢結果作為輸入。一組元組從一個查詢流到下一個查詢，每個查詢可以從傳入的元組中添加或過濾信息，甚至完全刪除元組。例如，下面的程序跟蹤流的大小分布，即從相同的5元組中，由超過一個固定的時間量增量delta分隔開的數據包。

fl_detect函數使用相同流被發現的時間來查找新的流的位置。因為emit（）聲明的位置，從fl_track中獲得的flowlet大小只在看到新流程的第一個包時流到其他操作符中。

?

Map函數 fl_bkts將fl_track所釋放的流的數量大小放入一個bucket索引中，該索引用于計算fl_hist對應的bucket中的flowlet數量。

通過查詢添加結果

Marple提供了一個zip操作符，它連接兩個查詢的結果，以檢查兩個條件是否同時保存。考慮從多個連接到單個隊列的數據包的輸入實例，這也是TCP協議的典型事例。這可以通過結合兩個不同的條件來檢查:(1)在短時間間隔內的活動流的數量是高的，并且(2)隊列占用很大。

用戶可以使用兩個聚合來計算當前時間區間中活動流的數量。

?

這個時間區間中的活動流的數量可以通過zip操作符將原始包流中的隊列占用信息相結合。

在兩個輸入流上的zip操作的結果是一個包含元組的流，這是兩個流中的所有元組元素的連接，只要兩個輸入流包含從相同的原始數據包中處理的有效元組。zip是一種特殊類型的流連接，其結果可以在無需兩個流的同步情況下進行計算，因為兩個流的元組都源自pktstream。zip的結果可以像其他流一樣處理:結果查詢中的filter檢查上面的兩個前提條件。

我們不需要更多的一般形式的連接，類似于像CQL[30]這樣的流查詢語言。流連接具有相當復雜的語義，可以產生特別大的結果。因此，Marple將用戶限制為簡單的zip連接。

我們在圖7中展示了幾個Marple查詢的例子。例如，Marple可以表達簡單計數器的測量、各種形式的TCP重排序、高損耗連接、端到端網絡延遲的流和TCP 數據包的流入。

Marple查詢的限制條件

有些聚合對于在網絡范圍內實現流的查詢具有挑戰性。例如，考慮在整個網絡中的任何地方都看到的數據包上的一個EWMA，按照tout的順序進行數據包的處理。即使使用時鐘同步，這個聚合也很難實現，因為它要求我們在交換機或將所有信息包傳輸到中心位置之間進行協調。

Marple的編譯器拒絕那些需要在多個交換機上按照tout的順序處理的多個數據包的聚合。具體地說，我們只允許在這三個條件中中的聚合：

(1)????????????在每個交換機上獨立操作，在這種情況下，我們通過交換機來劃分查詢；

(2)????????????獨立地在每個包上操作，在這種情況下，我們在數據包經過的下一個交換機上進行聚合來執行協調。

(3)????????????是關聯式和可交換的，在這種情況下，可以將每個交換機的結果組合在一起，以產生整個網絡的正確的總體結果。例如一個流中的數據包流經網絡的總的次數。在這種情況下，程序員可以用assoc和comm關鍵字來注釋聚合函數。

三 SCALABLE AGGREGATION AT LINE RATE

交換機如何實現MARPLE的語言架構？我們需要交換機上存在以下指令功能以實現：groupby、map、filter、zip的功能。

?

在四種語言結構中，map、filter和zip是無狀態的:它們僅對包的數組元素進行操作，不修改交換機狀態。這種無狀態的操作已經被支持在支持可編程包頭處理的新興可編程交換機上[3,13,25,33]。另一方面，groupby構造需要在交換機上維護和更新狀態。

由于兩個原因，在交換機上進行有狀態的操縱（groupby）是具有挑戰性的。首先，高端交換機上在下一個數據包到達之前更新狀態的時間預算可以低到1納秒。第二，交換機需要保留的狀態量與聚合記錄的數量成比例(例如:每一數據流)，它可能隨時間而無限增長。我們在硬件中使用可編程的鍵值存儲來處理這兩個挑戰，其中鍵表示聚合字段，而值表示由聚合函數更新的狀態。我們的鍵值存儲有一個“分割”的設計:一個存儲在交換機上的小的、快速的芯片上的鍵值處理以線性速率傳送的數據包，而一個大而緩慢的后備存儲器允許我們擴展到大量的流量。

高速開關ASICs通常在多個端口上共用入口管道和出口管道，時鐘頻率為1GHZ，支持多達10億64字節數據包每秒的聚合容量[33]。要處理來自1ghz的數據包的狀態更新，芯片上的鍵值必須在存儲SIC上的SRAM中。然而,可用的SRAM監測僅限于幾十兆比特(約10 k - 100 k的流)。

為了擴展到更多的流，芯片上的鍵值存儲作為更大的外芯片的緩存。在傳統的緩存設計中，緩存失敗需要訪問非確定性延遲的的外部存儲來讀取存儲狀態。因為聚合操作需要我們讀取值來更新它，所以整個狀態更新操作在這個過程中會產生不確定性的延遲。這導致了交換機管道的癱瘓。不幸的是，管道癱瘓影響了在所有端口上提供數據包處理的能力。

我們設計了一個鍵值存儲方式甚至能在cache失效的情況下保證能夠線性處理。不同于因為從DRAM中取數據導致的管道阻塞，我們將進入的數據包作為新的數據流的第一個數據包并且將流的狀態賦予一個新的初始值。來自相同流的后續包在鍵值存儲中的新創建的流條目中進行聚合，直到數據流被傳出。當數據流被傳出時，我們在使用合并函數的時候將流的值合并到后面的存儲中，并將合并的結果寫入后備存儲器中。在我們的設計中，開關只寫入后備存儲器，但從未讀取它，這有助于避免不確定性的延遲。如果沒有最近的傳出，后備存儲器可能與芯片緩存不一致。我們通過強制定期重寫來解決這個問題。

要將一個流的新聚合值與它在備份存儲中的舊值正確地合并，緩存需要維護并將副本發送到后備存儲器。一個簡單的副本用法是將每個流的每個包的狀態存到數組元素中，這樣后備存儲就可以簡單地運行整個包流的聚合函數。然而，在實際的實現中，副本的大小應該是有界的，而不是隨著流中包的數量而增長。在接下來的四個部分,我們將描述兩類可以與少量的輔助狀態合并的查詢(§3.1和§3.2),討論不可以合并(§3.4)的查詢,并提供聚合的一般條件，兩種可聚合查詢的類型并將它們與不可合并的查詢區分開來(§3.5)。

3.1相關的狀態

一個簡單的可的類別聚合是關聯函數。假設在狀態s上的聚合函數是s = op(s,f)，op是一個關聯運算，f是一個數據包數組元素。然后,如果op身份元素I和插入流的默認值s0 =I,很容易顯示這個函數可以使用函數op(sbacking scache)合并，sbacking和scache存儲在主存儲器中。關聯條件允許我們合并聚合函數，比如addition、max、min、set union和set intersection。

3.2線性狀態條件

考慮一下EWMA聚合函數，它維護流中所有包中排隊延遲的移動平均值。聚合函數更新EWMA s如下:

我們把s初始化為s0。假設一個流F被從芯片緩存中刪除，并被s的EWMA寫入后備存儲器。流F流出后的第一個數據包當做新流入片上緩存的新的數據流處理，以狀態s0作為初始狀態。假設來自F的N個數據包命中了芯片緩存，導致EWMA的參數從s0變為scache。然后，正確的EWMA的 scorrect滿足：

?

EWMA可以通過如下條件獲得：每次狀態更新后片上cache存儲的；當合并scache 和sbacking時，將、相加。

我們可以將這個實例概念化。讓p作為一個向量，存儲有從流的最后k個數據包中獲得的頭信息和性能元數據，K是在查詢編譯的時刻確定的整數（4.3節）。我們可以將任何聚合函數與狀態更新的形式S = A(p)·S + B(p)合并，其中S為狀態，A(p)和B(p)為最后k包的函數。我們把這種情況稱為線性狀態條件。

有界數據包的要求很重要。考慮圖7中的TCP非單調查詢，它計算的數據包的序列號比到目前為止所看到的最大序列號要小。聚合可以如下表達：

雖然表面類似于(p)·S + B(p)，但系數B(p)是maxseq（到目前為止最大的序列號）的函數。從直觀上看，由于B(p)不是有界包history的函數，所以需要合并的輔助狀態很大。3.5將這些內容形式化。

相反，從圖7中略微修改的TCPout- sequence查詢是線性的，因為它可以寫成

上一個數據包的序列號lastseq，只依賴于最后兩個包:當前和前一個包。在這里，A(p)和B(p)是固定范圍內數據包的函數，k= 2。

線性狀態的合并查詢需要交換機存儲最初的K個包和最近的k包的鍵的信息，因為它(re)出現在鍵值存儲中;詳情可在附帶的技術報告[15]中找到。一個聚合函數是線性的狀態，前提是對于函數中的每個變量，狀態更新滿足線性狀態。如果所有的聚合函數都是線性的，則查詢是線性的。

3.3可擴展的聚合函數

一個沒有emit()和線性(或關聯)聚合函數的groupby可以在不丟失準確性的情況下實現可擴展性。此類聚合的示例(從圖7)包括跟蹤TCP連接中的連續數據包，這些數據包都是無序的，并計算每個連接的TCP超時次數。

如果groupby使用emit()來將元組傳遞給另一個查詢，那么即使它的聚合函數是線性的或關聯的，它也不能被有效地實現。emit()輸出的是聚合函數的當前狀態，它假定當前狀態總是在開關的芯片緩存中可用。只有當流還未流出，有效地將鍵值存儲區縮小到其芯片緩存時，這才可能實現。

3.4處理不可擴展的聚合

線性狀態和聯系可以實現聚合的函數并可實現可衡量的應用,有兩個查詢的類型我們無法進行衡量：(1)聚合函數查詢,既沒有關聯,也不是線性的和(2)groupby含有emit()語句的查詢。

第一種類型的一個例子是前面討論的TCP非單調查詢。第二個類的示例是圖7中的流大小查詢，其中第一個groupby生成的流的大小flowlet大小進入第二個groupby函數。

對于非可伸縮的查詢，有很多變通方法。其一是重寫查詢以刪除emit()s。例如，我們可以重寫損失率查詢(圖7)，獨立地記錄在單獨的鍵值存儲中，每個流的數據包和數據包的總數，并且在每次需要查詢損失速率時，都由使用者查詢兩個鍵值存儲。每個鍵值存儲都可以被量化，但是實現是在一個瞬時損失的準確性相對于精確地跟蹤每一個包使用一個zip后的損失率。第二，操作人員可能滿足于流的值，在兩次流出之間的值都是準確的。第三，操作人員可能需要運行一個查詢來收集數據，直到芯片緩存已滿，然后停止數據收集。最后，如果鍵的數量足夠小到在緩存中(例如:如果密鑰是一個應用程序類型，那么系統可以提供準確的結果。

3.5聚合的統一條件

我們提出一種普遍的條件，將可合并的函數與不可分割的函數分離開來。非正式的，可合并的聚集函數是那些在函數狀態本身的大小中保持輔助狀態線性的函數。這個特性也使聯合和線性的狀態得到統一。我們現在用幾個無證明的定理形式將結果形式化。附隨的技術報告[15]包含證明。

讓n表示在Marple查詢中跟蹤的狀態的大小:它必須是有界的，并且不應該隨著包的數目而增加。在后臺存儲中，當合并芯片緩存中的scache、主存中的Sbacking時，交換機可以維護并將輔助狀態aux發送給后備存儲，以正確地執行合并。在EWMA的例子中,是輔助狀態。然后，一個合并函數m作為一個聚合函數f是一個滿足如下條件的函數:

m(scache,aux,sdf)=f(s0，{p1，…，pN}

對于任何N和數據包序列p1，…pN。F是每一個有序數據包函數的簡寫。

首先，我們證明了每個聚合函數都有一個合并函數，假定允許他使用大量的輔助數據。

定理3.1。每個聚合函數都有一個對應的合并函數，使用O(n2n)量級的輔助位。

不幸的是，內存是有限的，而Marple不應該使用比用戶聚合函數所表示的更多的狀態。我們說，如果輔助狀態對任何數據包序列都有大小O(n)，那么聚合函數是可合并的。這個特性與我們迄今為止所描述的一致:狀態線性和結合性的條件確實可以通過這個定義來實現合并。

定理3.2。如果一個聚合函數是線性的或相關聯的，它有一個含O(n)位輔助狀態的合并函數。

定理3.3。TCP 非單調查詢在最壞的情況下需要Θ(n2n)輔助位。

這就引出了一個問題:我們能否確定一個聚合函數是否可以用O(n)量級的輔助位進行合并?我們提供了一個算法(在技術報告中描述)，它計算了合并給定聚合函數所需的最小輔助位大小。我們目前的算法輔助位的大小是n的平方量級。

然而，多項式時間算法是不太可能的。 我們通過考慮一個簡單問題的來說明這個問題的復雜性，在這個為題中聚合功能M作為輸入：給定聚合函數f和合并函數m，m是否能將對所有的數據包的聚合函數m進行聚合呢？

理論3.4。 確定聚合函數能否進行合并是co-NP-hard。

這個結果的實際含義是不太可能一個一般而有效的過程來檢查是否有任意的聚合功能可以使用少量的輔助狀態合并。因此，識別特定類別的函數（例如，狀態線性和關聯），并檢查聚合功能是否屬于這些類是我們希望做的最好的。

3.6 硬件可行性

我們優化硬件設計以適用線性查詢，并將其分解成五個組成部分。 每個組件都很好理解：我們的主要貢獻是將它們放在一起實施有狀態查詢。 我們現在詳細討論每個組件。

片上緩存是散列表，其中散列中的每一行表存儲一定數量流的密鑰和值。 如果一個新的流的數據包的散列流入到一個滿的散列表中，最近最少使用的一行被逐出。 每排存儲8個數據流的信息并存儲其key和value.我們選擇8個流程是基于8路L1緩存，這在處理器中非常常見[14]。 這個緩存驅逐政策接近理想但又不太適用的cache失效策略與LRU非常相似。

在交換機數據傳輸階段，片上緩存類似于用于計數器的片上哈希表的邏輯接口：每個數據包使用從中提取的key來匹配表中的條目分組報頭，并且相應的動作是由交換機來執行的。片上哈希表可用做部署具有特定聚合功能的交換機的高速緩存的路徑，以支持更一般的操作以及cache替換策略。

片外后備存儲是更大規模的存儲key-value的存儲裝置，例如網絡上的信息收集服務器上的存儲器。 如第5節所示，用來支持從交換機上的片上緩存輸出數據的速率的測量服務器的數量很少的，即使是一個64×100Gbit / s的交換機。

保存數據包history記錄

在數據包到達片上緩存的流水線階段，我們在狀態更新操作S = A（p）·S + B（p）之前使用預處理預先計算A（p）和B（p）（有界包的函數）。我們目前設計只處理S，A（p）和B（p）是標量的情況。說A（p）和B（p）取決于最后k個數據包的包字段。然后，這些流水線階段之前的處理過程像移位寄存器那樣起作用并存儲來自最后k個數據包的字段。 每個階段都包含一個讀/寫寄存器，由到達該階段的數據包讀取該寄存器作為包頭的一部分，并寫入下一級的寄存器。一旦來自最后k個分組的值已被讀入包字段。A（p）和B（p）可以用可編程交換機的無狀態指令進行交換。

執行線性狀態操作

一旦A（p）和B（p）是已知的，我們使用乘法累加（MAC）[17]計算A（p）·S + B（p）。 這個操作很容易實施：我們的電路合成實驗表明一個MAC指令滿足1 GHz的時序，；并占據很小的偏上空間。幾百平方納米的交換機芯片可輕松支持幾百條MAC指令。

非線性狀態的查詢

我們使用一組在Domino [56]中開發的用于非線性查詢的狀態指令來支持非線性查詢。 我們的評估表明這些指令對于非線性狀態的查詢是足夠的。

4查詢編譯器

我們將Marple查詢編譯成兩個形式：P4行為模型[19]，emitting P4代碼配置； Banzai機器模型，emitting Domino代碼配置。在兩種情況下，emitted代碼配置了一個交換機流水線，其中每個階段是一個match-action表[33]或我們的鍵值存儲。

編譯器對輸入查詢的初步處理是轉換抽象語法樹（AST）（圖5a）。然后編譯：

（1）從全局AST（§4.1）生成交換機本地AST，

（2）從交換機本地AST生成P4和Domino管道配置，（§4.2）；

（3）識別線性狀態聚合函數，并設置合并這些功能所需的輔助狀態用于可擴展實現（§4.3）。為了實施關聯聚合函數（§3.1），我們使用程序確定聚合是否是組合的。如果是關聯的，則合并函數是聚合本身。

我們使用圖4所示的查詢作為運行示例來說明編譯器的細節。 該查詢通過網絡中的S1、S2交換機計算出每個時間區間的無需TCP數據包的數量。

?

4.1全網絡向本地交換機查詢

編譯器將對隊列中的所有包的全網查詢轉換為本地查詢以生成特定于交換機的配置。 我們分兩步實現。首先，我們確定流的位置，即對流中的元組有過修改的交換機序列，最終輸出流的查詢。例如，被標號為s的交換機過濾過的查詢的輸出流有一個流位置為set s。其次，我們確定如何使用聚合函數對查詢進行分割將對整個網絡的查詢轉換為本地查詢。

從最終輸出流確定流位置

pktstream的流位置是網絡中所有交換機的集合。 過濾器輸出的流位置是一組由過濾器確定的交換機。 具體來說，我們通過交換機中的switch== X形式的基本語法來確定對過濾器中輸出流的元組修改過的交換機列表。我們使用指令集操作將交換機的指令變化為布爾邏輯。 zip的輸出流的位置是兩個輸入的流位置的交集。通過map和groupby不改變流的位置。

運行示例的流位置如圖5b所示。pktstream的流位置是所有網絡交換機的集合，但是通過查詢中的過濾器僅限于S1和S2（左側科）。 然后通過zip操作符查詢將該位置傳播到AST的根。

分割全網范圍的聚合

?如§2所述，我們只允許滿足三個條件之一的聚合：它們在每個交換機上獨立運行，在每個數據包上獨立運行，或者是關聯的和可交換的。下面我們來描述一下我們如何檢查第一個條件，后兩個條件的檢查方法為：groupby通過uid聚合（條件2）或包含程序員的注釋（條件3）。

要檢查每個交換機上是否獨立運行聚合，我們用每個AST節點標記一個額外的布爾屬性，交換機的可分割性，對應于輸出流是否已經由它出現的交換機分割。直觀地，如果一個流是被交換機分割，我們允許分組順序相關的聚合作用于該流的多個數據包; 否則我們不會。

通過AST確定和傳播交換機分區很簡單，基本pktstream不進行交換機分區的。過濾器和zip操作符產生交換機分區的流，如果它們的輸出僅出現在單個交換機上。 Groupby產生一個交換機分區流（若該流被交換機聚合）。在所有其他情況下，運算符保留操作數的交換機分區屬性。

我們運行示例的交換機分區屬性是如圖5c所示。 濾波器在兩個交換機上產生輸出流，因此不進行切換分區。 Groupby通過交換機進行聚合因此是交換機分區的。 在交換分區檢查成功后，留下了一套獨立的對應于每個AST根操作出現的交換機位置的獨立的交換機本地AST。

4.2 查詢到管道配置上的AST

這個編譯器通過§4.1的交換機本地查詢AST生成一個運算符序列。那么這個操作符序列就可以以相同的順序使用來生成交換機管道配置。在構建管道時需要注意兩個方面結構：（1）管道應遵循不同的運算符之間的讀寫依賴關系，（2）重復的子查詢不應該創建額外的管道階段。 我們生成一個查詢AST的后期遍歷的序列，保證了一個節點的操作數在操作之前被添加到管道中點。此外，我們從管道中重復數據刪除子查詢結果以避免在最終輸出中重復階段。 對于運行示例，該算法產生運算符序列：tcps(filter) →

tslots (map) → joined (zip) → oos (groupby).

接下來，編譯器從操作符中發出交換機管道的P4代碼。 filter和zip配置只涉及到在數據包元數據上設置“有效”位。 map配置向計算表達式傳遞數據包數組元素。 groupby配置使用一個由聚合字段作為索引的寄存器，并通過在聚合函數中指定的動作進行更新。 我們通過標準程序將marple聚合函數改變為c語言風格的操作。 這允許我們將聚合功能適合單P4操作的代碼中.

為了實現Banzai交換機管道模擬器[56]，Marple編譯器通過連接C風格的代碼段釋放Domino代碼為單個Domino程序。然后，Domino編譯器將該程序并將其編譯為aBanzai原子管道。 原子是ALU，代表可編程交換機的指令集。 原子實現無狀態（例如，增加分組字段）或有狀態（例如，原子地遞增開關計數器）計算.

4.3 處理線性狀態聚合

我們現在考慮檢測的問題是線性狀態的聚合函數（聚合函數可以寫成S = A（p）·S + B（p））。一般的解決這個問題是有挑戰性的，因為聚合功能可以采取各種形式。 例如，任務是線性狀態，但需要檢測代數簡化。

語言導向硬件設計

我們采取務實的做法，犧牲完整性仍然保留有用的函數。 具體來說，我們只通過匹配編譯器的語法字段來查找線性狀態的更新（即沒有代數變換）。 盡管如此簡化，Marple編譯器正確識別所有的圖7中的線性狀態聚合。

為了描述線性狀態檢測的工作原理，我們介紹一下一些術語。 回想一下聚合函數需要兩個參數（§2）：狀態變量列表（例如，計數器）和列表元組字段（例如，TCP序列號）。 我們用這個本小節中的術語變量來指狀態變量或數組元素。 這些是唯一可以出現在聚合函數中的變量.

我們執行三步程序以實現線性狀態檢測，如圖6。首先，對于聚合函數中的每個變量功能我們分配一個history。 這個history告訴我們以前有多少我們需要查看的數據包來準確地確定變量的值（history = 1表示當前數據包）。 例如，為了獲得一個字節計數器的值，我們需要回頭看看數據包流開始的地方（history =∞），而跟蹤上一個TCP的變量序列號我們只需要回頭看前一個數據包（history= 2）。 與history的定義一致，常數的history值為0，數組元素的變量被賦予history=1.對于狀態變量，我們使用Alg。1來確定每個變量的history.

其次，每一個變量都有一個history，我們來看一下每個狀態變量的history。如果s的history是有限數k，那么s取決于最后的k個數據包和該變量的狀態更新是線性的，通過將A設置為0并將B設置為聚合函數本身。如果有無限的history，我們使用句法模式匹配以檢查s的更新是否是線性狀態.

第三，如果所有狀態變量都具有線性狀態更新，則聚合函數是線性的，我們生成輔助狀態以合并聚合函數（§3）。如果不，我們使用Domino [56]中開發的一組有狀態指令實現聚合功能。 我們現在詳細描述三個步驟。

確定變量的history

為了了解alg. 1，觀察狀態變量的所有賦值是否只使用具有有限的history的變量，若是那么狀態變量本身就有一個有限的history。 例如在圖4中，在分配之后，lastseq具有history1，因為它只取決于當前數據包的字段tcpseq和payload_len。為了處理代碼中的，如if（。。。）{...}聲明，我們對這一種情況進行概括。 狀態變量在如下情況下有確定的history：如果（1）在其所有分支中具有有限的history，（2）每個條件語句中的變量具有有限history

具體來說，計算一個變量的history是依靠于他所在數據包流過位置的狀態變量的history。 我們分別跟蹤每個分支的history，即分支序列包含所有的狀態。該算法以默認最大值作為每個狀態變量（行）的history（即近似為∞）的初始量，并且重復執行定點計算（線3-20）迭代聚合函數中的語句（第7-16行).

對于聚合函數中的狀態變量的每個賦值，該算法更新當前分支中狀態變量的history。 對于聚合中的每個分支函數，該算法保存一個新的分支和當前分支的history（第10-14行）。 在每個迭代的最后，算法將每個變量的history遞增表示變量又處理過一個數據包（第18行）。 算法為每個狀態變量返回保守的history k，包括可能是max_bound（行1，Alg。1），以反映無限的history.

現在我們將通過聚合函數的語句函數GETHIST來說明history是如何進行維護的。考慮一個在分支語句ctx中的表達式x = expr，在分支上下文ctx中。 然后x的history是ctx中的history和表達式expr的history的最大值。 要確定expr的history，假設AST的expr包含變量x1，x2，...，xn作為其葉節點。 然后，expr的history是xi的history的最大值。 例如，在oos_count中賦值后，lastseq的history記錄是最大值1（tcpseq和payload_len是當前數據包的函數）和0（對于封閉的最外層上下文為真).

確定狀態變量的更新是否是線性狀態

對于具有無限history的每個狀態變量S，我們檢查狀態更新是否是線性的：（1）s的每次更新是語法上的， S←A·S + B中的A或B為0;（2）A，B和依賴于變量的每個分支語句具有有限的history。 這種方法是健全的，但不完整：它漏掉如的形式.

確定輔助狀態

對于線性更新的每個狀態變量，我們初始化一個新的四個輔助狀態形成新插入的key：（1）運行的產品代號SA = 1; （2）數據包計數器c = 0; （3）入口日志，由插入后的錢k個數據包的數組元素決定; 和（4）退出日志，由最后k個包的字段決定。 在計數器的值變為k，當SA更新時，我們將A*SA賦給SA。當Key被驅逐時，我們將入口、出口日志中的SA保存到輔存中。

五、評估

我們以三種方式評估Marple。 在§5.1中，量化Marple查詢所需的硬件資源。 在§5.2中，我們測量key-value存儲的內存讀取效率。 在§5.3和§5.4，我們展示了使用Marple編譯成P4的兩個案例研究Mininet上運行的行為模型：調試微爆[44]并計算流量大小分布.

5.1硬件計算資源

圖7顯示了幾個Marple查詢。對于每個查詢，我們顯示（1）是否所有的聚合都是線性狀態的，（2）是否可以通過與后備存儲正確合并來縮放，（3）所需的交換機資源，通過管道深度（級數），寬度（最大并行計數）和Banzai原子數（計算總數）來衡量。

圖7顯示了許多只包含線性狀態聚合的有用的查詢，并且大多數都擴展到大量的key（§3.2）。值得注意的是，流量大小統計和有損連接查詢是由于它們包含emit（），因此盡管處于線性狀態，但不可擴展。 在§3.4中，我們展示了如何以犧牲一定精度為代價重寫其中一些查詢（例如，有損連接）.

我們通過編譯到Banzai交換機管道模擬的查詢來計算管道的深度和寬度。 Banzai是由無狀態原子構成的，其對一對數據包數組字段和狀態原子執行二進制運算（算術，邏輯和關系）。對于線性狀態操作，我們使用乘法累加原子作為狀態原子，而對于其他操作，我們使用Banzai自己的NestedIf原子[56]。 Domino編譯器確定輸入程序是否可以使用指定原子映射到管道。 如預期的那樣，所有線性狀態查詢都可以通過累乘映射到管道上.

Marple查詢所需的計算資源是適中的。 圖7中的所有查詢都需要一個短于11個階段的管道。這是可行的，例如，RMT架構提供32個階段[33]。此外，測量以外的功能可以并行運行因為每個階段所需的原子數量最多為6個，可編程交換機每級提供100個并行指令（例如，RMT提供224 [33]）.

5.2內存和帶寬開銷

在本節中，我們回答以下問題：

（1）片上key-value的尺寸是多少？

（2）失效率是多少？

（3）不可合并的查詢的準確性

實驗裝置

我們對三種條件下的數據包進行一個Marple查詢：來自10 Gbit/ s核心互聯網路由器，一個來自2016年芝加哥（約150M包）[24]和來自2014年的圣荷西（約189M包）[23]; 和2.5小時2010年大學數據中心的流量（?100M數據包）[32]。 我們將這些分別稱為Core16，Core14和DC。

我們對一個五元組聚合的marple查詢進行分析來評估內存大小對cache失效的影響。如§3.6所述，我們的硬件設計使用8路LRU緩存。 我們也評估另外兩個幾何形狀：一個散列表，它將重復的key和完全關聯的LRU刪除。 比較我們的8路與其他硬件設計的LRU展示硬件復雜性和失效重取速度的關系.

逐出速率

每個被驅逐的鍵值對都流到輔存存儲。 這需要后臺存儲能夠以key-value被逐出的速率進行處理，這取決于數據包流入速率和逐出比例，即流入數據包的逐出比例。驅逐比取決于片上緩存結構，數據包流動路徑和高速緩存大小（能存儲的鍵值對數量）。 因此，我們在以下條件下衡量驅逐比（1）Core16軌跡的三種結構（圖8b），（2）三個使用8路LRU結構（圖8a）和（3）緩存的大小尺寸在216（65K）和221（2M）鍵值對之間。

圖8b顯示，由于LRU在開始逐出內容之前必須將cache存儲空間填滿，因此full lru具有最低的外傳比例。 然而，8路關聯緩存是一個很好的折中：它避免了在全相聯LRU的硬件復雜度的同時，具有2％的失效比例。 圖8a示出了DC情況下具有最低的驅逐比。這是因為它比其他兩種情況有少得多的獨立key-value，并且這些key不太可能被逐出。

驅逐比的倒數（作為一個分數）與緩存處理的key-value的數量是成正比的。 例如，對于Core14具有2^19key-value對緩存，服務器負載減少25×（相當于4％的驅逐比）。

驅逐率

撤銷比率對交換機的特性來說是不可知的，如鏈路速度，鏈路利用率和片上高速緩存大小。將驅逐比轉為驅逐速率（每秒驅逐），我們首先計算core16上平均數據包的大小（700字節）和鏈接利用率（30％）.

接下來，我們評估64×10Gbit / s、64×100Gbit / s交換機上片上緩存大小。在64×10Gbit / s交換機上，SRAM密度≈3-4Mbit / mm2 [1]，最小的交換機芯片占用了200mm2 [39]。因此，SRAM上64Mbit的緩存占用面積的10％左右，我們認為這是合理的。 對于最近的64×100Gbit / s交換機[5]，SRAM密度是≈7Mbit/ mm2 [22]，交換機占用≈500mm2, 256 Mbit緩存（7.3％區域開銷）為合理的目標.

對于給定的查詢，我們將這些緩存大小除以大小聚合的鍵值對來獲取鍵值對的數量。然后，我們在圖8中查找這個數字以獲得該查詢的驅逐比，我們使用率利用率和數據包大小將其轉換為逐出速率.

一些抽樣查詢的排除率如圖9所示。64×10-Gbit / s交換機，64Mbit高速緩存，我們觀察到驅逐每秒≈1M包/s

。 對于64×100Gbit/ s的交換機一個256 Mbit的緩存和相同的平均數據包大小和利用率，驅逐速度可以達到每秒7.17M的數據包。 相對于每包收集器，Marple將服務器負

載降低25-80×

?

10 Gbit / s和100 Gbit / s交換機的驅逐速率都在每秒10M數據包/s以下，在多核向外擴展鍵值存儲的能力之內[2,11,43]，通常每個核心處理每秒100K-1M的操作。 例如，對于單核64×10Gbit / s交換機運行64位狀態位的聚合，單個8核服務器足以處理驅逐速率為每秒1.08M數據包。 單個64×100Gbit / s交換機運行相同的聚合，驅逐率上升到5.18M數據包每秒，需要四個這樣的服務器.

概括其他情景

圖8也概括了不同狀態大小的聚合。 第一，通過選擇5元組的子集來粗化聚合key以減少驅逐率，因為工作中的實際使用的key較少。 我們認為5元組可能是最細粒度的并且仍然實用有用的匯總水平; 因此，我們的結果顯示單個聚合的最壞的驅逐比例。二，在groupby值大小的變更導致不同的給定內存大小的鍵值對數不同。 三，運行具有相同數量鍵值對的多個groupby查詢，并通過相同的key聚合，導致所有查詢的同步逐出。 因此，驅逐速度可以從圖8中讀出相應地減少了內存大小.

不可合并查詢的準確性

既不是查詢線性狀態或關聯不能在后臺存儲中合并。如果這樣一個查詢的鍵被多次驅逐，Marple就不能保證其正確性并將其標記為無效。但是，這些鑰匙的值仍然有效，如果它們永遠不會被驅逐或者是驅逐一次，永遠不會再出現。 我們量化查詢的準確性作為在查詢生命周期的有固定值的鍵的一部分。圖10a顯示了使用三種條件下的查詢精度。DC結果幾乎完美，因為它具有較少的唯一鍵。如果查詢在較短的時間間隔內運行，則其準確性通常較高，因為緩存可能不是滿的，而且key的很小一部分被逐出。 圖10b顯示了Core16下一個范圍緩存大小下的效率與精度。 縮短查詢從5分鐘到1分鐘提升精度10％.

5.3 案例研究＃1：調試突發大流量數據包傳輸

為了展示Marple在實踐中的應用，我們提出了一個案例研究，微波爆發，即由突發傳輸引起的延遲尖峰，數據包進入隊列。我們在Mininet [47]中的設置包括四個主機（h1，h2，h3，h4）和兩個交換機（S1，S2）。 交換機S1連接到

h1和h3，S2連接到h2和H4。 交換機通過單個鏈路連接并進行P4模型下的 [19] Marple編譯的查詢.

?

主機h2通過TCP從h1重復下載1MB的對象。同時，h3向h4突發發送UDP流量， h4進行確認。假設網絡運營商注意到不規則的延遲尖峰下載（圖11a）。 她懷疑交換機中的隊列累積并通過寫入來測量流量看到的隊列深度：result=filter（pktstream，srcip == h1 anddstip == h2）.

將結果寫到在每個數據包上流到收集服務器。測到隊列延遲后，她注意到隊列大小的峰值在交換機上的出口端口3（圖11b）與周期性匹配的延遲尖峰。 為了分離相應的流，她將流量分為“突發”，她定義為一系列數據包的間隔至少為800毫秒，這是有兩個延遲尖峰決定的。 她發出以下Marple查詢：

def burst_stats([last_time, nburst, time], [pkts, tin]):

if tin - last_time > 800000:

nbursts++;

emit();

else:

time = time + tin - last_time;

pkts = pkts + 1;

last_time = tin;

result = groupby(R1, 5tuple, burst_stats)

她運行查詢72秒，并在圖12中看到結果。她得出結論，正確地說，h3和h4之間的UDP流量導致了延遲尖峰。有18個UDP突發，平均數據包大小和持續時間與我們的仿真設置相匹配.

Marple的靈活性使得診斷變得簡單。 相比之下，通過現有監測來定位微爆發的根本原因方法具有挑戰性。

.

5.4 案例研究＃2：Flowlet大小分布

我們在實踐中演示了Marple的另一個用例：計算作為流動閾值的函數的流動尺寸分布，時間間隔高于其后續數據包被認為是在不同的流程。該分析具有許多實際用途，例如，用于配置基于流的負載均衡策略[27，60]。在特別是LetFlow [60]的表現在很大程度上取決于流量大小分布.

我們的設置使用Mininet與一個單一交換機連接五臺主機：單個客戶端和四個服務器。 流量大小從真實數據中心按照經驗進行分發[28]。交換機運行圖7中的“flowletsize histogram”查詢delta的值，即流量閾值。

圖13顯示了各種值的流量大小的CD。 請注意，delta的實際值是該結果Mininet設置允許的帶寬; 數據中心部署可能會使用較低的delta值.

六、相關工作

基于端點監控。 由于交換機支持有限的測量，許多系統使用終端來監控網絡性能。 盡管終端解決方案是應用程序所必需的，對于調試所有網絡問題是不夠的，因為網絡核心對于端點缺乏可見性。使用交換機增強端點解決方案例如INT，數據分散在多個端點上。 我們相信網絡將需要基于終端的和基于交換機的系統，因為每個都看到別的看不到的東西。

基于交換機的監控

?大多數基于交換機的監控都具有每個流量計數（例如，NetFlow [7]）和采樣（例如，sFlow [21]），而不是性能測量。數據包采樣可以因采樣過疏而忽視重要事件[55]。 硬件NetFlow的實現不會保留每個流的記錄，因為hash沖突的原因流查詢表不能列表中插入新的流。marple緩存設計和合并解決了這個問題.

線速率數據包捕獲設備，例如[10] 在高數據速率下記錄所有數據包流量，為后期分析提供有價值的數據網絡流量。理想情況下，性能監控應該可以在網絡任何位置實現，但數據收集和存儲高要求使得無法在任意位置運行數據包捕獲。同樣的問題限制了其他反映流量或收集的策略。 相比之下，Marple的靈活的語言和基于交換機的聚合處理開銷很低，因為只收集需要的東西.

可編程交換機的計數器系統使用聚類數據結構和交換機上的流量計數器來進行流量統計。 Marple的性能監控能力遠強于之前的系統。

帶內網絡遙測（INT）[12,44]顯示隊列長度和其他通過捎帶開關的性能元數據他們在包上。 Marple使用類似INT的性能元數據，但是在交換機上直接提供靈活的聚合。 Marple的交換機上的聚合提供了相對于INT的三個優點。首先，沒有聚合，每個INT端點需要處理高數據速率下的每個數據包。 二，交換機聚合保存每個數據包數據分發所需的帶寬超過許多INT端點。 三，交換機聚合可以處理在它們到達端點之前丟棄INT數據包的情況。

網絡查詢語言 先前的網絡查詢語言[35，38,41,54]允許用戶主要提出有關流量和計數統計的查詢，因為他們的輸入數據是使用收集的NetFlow和匹配動作規則計數器[51]。 相比之下，marple允許運營商通過設計 新的交換機硬件支持Marple查詢，進而可以進行更多的查詢。marple一些功能和關系結構與Gigascope [35]和Sonata [41]相似，但直接在交換機中支持聚合。marple允許運營商通過編程進行在線查詢，從而實現以低開銷收集細粒度的定制統計數據。它與離線查詢系統相輔相成，離線查詢通過分析采樣或數據包捕獲收集的歷史數據來獲得結果。

七結論

性能監測是維護任何大型系統的重要組成。 Marple的網絡可見性和查詢語言揭秘應用的網絡性能，使運營商能夠快速診斷問題我們希望網絡運營商查詢他們需要的任何東西，而不受限于有限的交換機功能集。Marple使細粒度，可編程網絡監控向前邁進了一步，網絡運營商而不是網絡的廠商控制整個網絡。

?

總結

以上是生活随笔為你收集整理的Language-Directed Hardware Design for Network Performance Monitoring的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。