2020년 8월 30일 일요일

Google, "TIMELY: RTT-based Congestion Control for the Datacenter" 직역

작성중인 글입니다.

이 글은 Google의 "TIMELY: RTT-based Congestion Control for the Datacenter"[1] 논문의 직역입니다. 제 이해 수준에 따라 오역되거나, 단어 선정이 어색할 수 있습니다. 본문의 인용[#]은 제 글의 인용 안에 숫자를 바꿔 포함하거나 불필요 판단시 생략하며, 그림은 재도식할 때까지 당분간만 논문을 캡쳐하여 포함하고 직역 완료 후 재도식 하겠습니다.

요약

데이터 센터 전송은 낮은 메시지 전송 지연과 높은 처리량을 목표로 한다. 우리는 스위치의 피드백을 필요로 하지 않고, 호스트에서 측정한 왕복 시간인 단순한 패킷 지연이 효과적인 혼잡 신호임을 보인다. 첫 번째, 우리는 NIC[2] 하드웨어의 발전이 RTT[3]를 마이크로초 정확도로 측정 가능하다는 것과, 이러한 RTT는 스위치 큐잉을 추정하기에 충분하다는 것을 보인다. 그 다음 우리는 높은 대역폭을 전송하는 동안 낮은 패킷 지연을 유지하기 위해, TIMELY가 어떻게 RTT 변화도(gradient)를 사용하여 전송률[4]을 조절할 수 있는 지를 서술한다. 우리는 OS 우회 능력을 가진 NIC들을 통해 동작하는 호스트 소프트웨어에 우리의 설계를 구현한다. 우리는 Clos 네트워크 토폴로지[5] 상의 수백 대까지의 머신의 실험을 사용하여, 이것이 탁월한 성능을 제공하는 것을 보인다. OS를 우회하는 메시지에 TIMELY를 켜면 PFC[6]의 fabric[7]에서 회선 처리량에 9배 근접하게 유지하여 꼬리 지연(tail latency)[8]을 99 퍼센트 감소시킨다. 우리의 시스템은 또한 꼬리 지연을 13배 감소하여, 최적화된 커널에서 수행되는 DCTPC[9]를 능가한다. 우리가 아는 한, TIMELY 는 데이터 센터를 위한 첫 번째 지연-기반 혼잡 제어 프로토콜이며, Vegas 와 같은 이전의 지연-기반 기법보다 작은 규모의 RTT신호를 가지더라도 (NIC 의 offload[10] 를 통해) 그 목적을 달성한다.

1. 서문

(3, 4, 5번 섹션 작성 후 작성)

2. 데이터 센터에서 혼잡 신호로서의 RTT 값

(3, 4, 5번 섹션 작성 후 작성)

3. TIMELY 프레임워크

TIMELY는 현실에서 사용되는 전송 프로토콜과 독립적인 전송률(rate) 제어 프레임워크를 제공한다. 그림6은 그 세 가지 구성, 1) 네트워크 혼잡을 감시하는 RTT 측정, 2) RTT 신호를 목표 송신율(sending rates)들로 변환하는 계산 엔진, 그리고 3) 목표 전송률을 달성하기 위해 세그먼트 사이에 지연을 입력하는 제어 엔진을 보인다. 우리는 NIC 하드웨어 지원으로 호스트 소프트웨어에 TIMLEY를 구현하고, 각 flow의 독립적인 개체(instance)를 실행한다.

그림6. TIMELY 개요

3.1. RTT 측정 엔진

우리는 수신자가 명시적으로 새로운 데이터에 ACK로 응답하면 RTT를 추출하는 전통적인 전송을 가정한다. 우리는 그림7과 같이 RTT를 정의하며, 다수의 패킷으로 구성된 세그먼트가 하나의 버스트[11]로 전송되고, 수신자에 의해 한 단위로 ACK 응답되는 메시지의 타임라인을 보인다. 

그림7. 완료 시간에서 RTT 구하기

하나의 완료 이벤트는 데이터 세그먼트를 위한 하나의 ACK를 수신하여 생성되고, ACK 수신 시간을 포함한다. 첫 번째 패킷이 전송된 시간부터 ACK를 수신한 시간까지가 완료 시간(completion time)으로 정의된다. TCP와는 다르게, 1-2 패킷당 RTT보다는 패킷 집합을 위한 하나의 RTT가 있다. 지연 구성 요소는 1) 일반적으로 64 KB까지의 세그먼트의 모든 패킷을 진송하는 직렬화 지연, 2) 세그먼트와 데이터 센터를 건너 전파하는 ACK의 왕복 배선 지연, 3) ACK를 생성하는 수신자의 회송 시간(turnaround time), 그리고 4) 양방향에서 겪는 스위치의 큐잉 지연이 있다. 우리는 RTT를 전파(propagation)와 큐잉 지연 구성요소 만으로 정의한다. 첫번째 구성요소는 NIC의 회선 전송률(line rate)와 세그먼트 크기의 결정론적 함수이다. 우리는 전체 소요 시간에서 이를 계산하고 차감하므로, TIMELY의 전송률 계산 엔진에 입력되는 RTT는 세그먼트의 크기에 독립적이다. 세 번째 구성요소는 우리의 NIC 기반 ACK 구성에서 충분히 영(0)에 가까우므로 무시할 수 있다. 남아있는 구성요소 중 두 번째는 스위치에서 패킷 기반의 저장과 전달 행동을 포함하는 전파 지연이다. 이는 최소 RTT이고, 주어진 flow에서 고정된다. 오직 마지막 구성요소인 큐잉 지연이 RTT에서 변동을 일으키며, 이것이 우리가 혼잡 탐색하기 위해 집중하는 것이다. 요약하면, 호스트A(그림7에서 보이는)에서 실행하는 TIMELY는 RTT 를 다음과 같이 계산한다.


맥락적으로, 10Gbps 네트워크에서 64 KB의 직렬화(serialization)는 51㎲가 걸리고, 전파는 10-100 ㎲의 범위일 것이며, 1500 B 큐잉은 1.2 ㎲가 걸린다. 우리는 세그먼트 RTT를 정밀하게 측정하기 위한 두 형태의 NIC지원을 의존하며, 다음과 같이 기술한다.

ACK 타임스템프 우리는 NIC가 완료 타임스템프, tcompletion을 지원하도록 요구한다. 그림 2에서 보였다시피, OS 타임스탬프는 스케쥴링과 인터럽트들과 같은 변동을 겪으므로, 쉽게 혼잡 신호를 모호하게 할 수 있다. tsend는 NIC에 세그먼트가 전달되기 바로 직전에 호스트 소프트웨어가 읽은 NIC의 하드웨어 시간이다.

즉각적인 ACK 생성 우리는 NIC 기반의 ACK 생성을 요구하여 수신자 측의 회송(turnaround) 시간을 무시할 수 있다. 하나의 대안은 타임스탬프를 사용하여, 호스트의 처리 지연으로 인한 ACK 회송 지연을 측정하는 것이다. 우리는 이 선택을 피하였는 데, 이는 증가하는 전송 회선 형식(argumenting transport wire formats)이 이 명시적인 차이를 포함하도록 요구할 수도 있기 때문이다. 

다행히, 일부 현대적인 NIC들은 하나 또는 두 기능을 제공하고, 우리의 요구사항인 세그먼트 ACK에 타임스탬프를 찍는 메시징 구현이 자연스럽게 만족한다. RDMA 문맥 안에서 TIMELY 의 특정 구현은 섹션5 에서 기술된다. 우리는 NIC의 일괄처리 행동(batching behavior), 새 데이터의 수신에 대해 정확하게 연결되는 ACK, 그리고 ACK 회송시간의 보상에 대한 주의 깊은 적용으로 우리의 설계가 더 일반적으로 TCP에 적용될 수 있다고 믿는다.

3.2. 전송률 계산 엔진

이 구성요소는 섹션 4에서 기술된 우리의 RTT 기반 혼잡 제어 알고리즘을 구현한다. 전송률 계산 엔진의 인터페이스는 단순하다. 각 종료 이벤트마다 RTT 측정 엔진은 마이크로 초의 RTT를 전송률 계산 엔진에 제공한다. 이는 단순히 입력을 요구하지만, NIC 에서 발생한 지연과 같은 추가적인 시간 정보도 유용할 수 있다. 패킷 레벨 동작의 요구사항은 없으며, 우리는 일반적인 동작에서 NIC offload 때문에 하나의 완료 이벤트의 세그먼트 크기는 64 KB까지라고 예상한다. 전송률 계산 엔진은 매 종료 이벤트마다 혼잡 제어 알고리즘을 실행하고, flow를 위한 최신화된 목표 전송률을 산출한다.

3.3. 전송률 제어 엔진

메시지가 송신될 준비가 되었을 때, 전송률 제어 엔진은 전송을 위해 이를 세그먼트들로 쪼개고, 각 세그먼트를 순서대로 스케쥴러로 보낸다. 실행시간 효율성을 위해, 우리는 단일 스케쥴러를 구현하여 모든 flow를 처리한다. 스케쥴러는 세그먼트 크기, flow 전송률(전송률 계산 엔진에 의해 제공된), 그리고 적절한 전송 수준(pacing) 지연을 가진 현재 세그먼트의 전송 시간을 계산하기 위한 마지막 전송 시간을 사용한다. 세그먼트는 이후 스케쥴러의 우선순위 큐에 배치된다. 과거의 전송 시간들을 가진 세그먼트들은 라운드-로빈[12] 방식으로 서비스가 제공된다. 미래 전송 시간을 가진 세그먼트들은 큐에 대기한다. 전송 수준 지연(pacing delay)이 경과된 후, 전송률 제어 엔진은 세그먼트를 NIC으로 전달하여 패킷의 burst 로 즉시 전송되도록 한다. 데이터는 우선 64 KB 세그먼트들로 묶이고(batched), 이어서 스케쥴러가 두 묶인 세그먼트들 사이에 삽입하기 위한 전송 수준 지연을 계산한다. 64 KB는 최대 일괄처리 크기이며, 요구사항이 아님을 주의한다. 예를 들어, 임의의 주어진 시간에 교환할 작은 메시지만을 가진 한 flow 의 세그먼트 크기는 64 KB보다 작을 것이다. 우리는 나중에 64 KB보다 작은 세그먼트 크기들에 대한 결과도 나타낸다.
  TIMELY는 NIC offload 의 광범위한 사용으로 주어지는 트래픽 burst들을 통해 더 나은 제어를 제공하므로 윈도우 기반 보다는 전송률 기반이다. 대역폭-지연 결과물(product)은 데이터센터에서 작은 수의 패킷 버스트들이다. 예를 들어, 10 Gbps에서 51㎲가 하나의 64 KB 메시지이다. 이 체제에서(In this regime), 패킷 전송들에 세밀한 제어를 제공하지 않는다. 특정 목표 전송률을 명시하여 버스트들 간의 차이를 직접 제어하는 것이 더 쉽다. 안전 장치(safegurad)로서, 우리는 두드러진(outstanding) 데이터의 양을 하나의 고정된 최악의 경우의 한계로 제한한다.

4. TIMELY 혼잡 제어

우리의 혼잡 제어 알고리즘은 전송률 계산 엔진에서 수행된다. 이 섹션에서 우리는 우리의 환경과 주요 성능 측정 기준(key performance metrics)에 이어서, 우리의 변화도 기반 접근과 알고리즘을 기술한다.

4.1. 측정 기준과 설정

데이터 센터 네트워크 환경은 높은 대역폭과 낮은 지연 경로들에서 밀접하게 연결된(tightly-coupled) 형태의 계산으로부터 많은 폭발적인(bursty) 메시지 작업량으로 특정된다. 이는 여러모로 전통적인 넓은 영역의 인터넷의 반대이다. 대역폭은 풍부하고, flow 완료 시간(예를 들어, 원격 프로시저 호출(RPC))은 우선적인 관심사이다. 짧은 RPC들에게, 최소한의 완료 시간은 전파와 직렬화의 지연에 의해 결정된다. 그러므로, 우리는 RTT를 낮게 유지하기 위해 모든 큐잉 지연의 최소화를 시도한다. 꼬리 지연은 하나의 작은 패킷 조각이라도 늦게 되면 어플리케이션 성능을 떨어뜨리므로 중요하다. 일관된 낮은 지연은 낮은 큐잉 지연과 거의 영(0)에 가까운 패킷 손실을 암시한다. 더 긴 RPC들은 공유된 네트워크를 가로지르는 더 많은 데이터를 전송하는 데 걸리는 시간 때문에 더 큰 완료 시간들을 가질 것이다. 추가되는 시간을 낮게 유지하기 위해서, 우리는 반드시 높은 통합 처리량(high aggregate throughput)을 유지하여 모든 flow 에 도움을 주고, 대략적인 공정성을 유지하여 하나의 flow도 불리하지 않아야 한다(no one flow is penalized).
  평가를 위한 우리의 첫 번째 측정 기준은 꼬리(99 퍼센트의) RTT와 통합 처리량으로, 이들은 얼마나 빠르게 우리가 짧고 긴 RPC 들을 완료하는 지를 (어느정도의 공정성을 가정하며)결정한다. 패킷의 RTT 와 처리량에 충돌이 있는 경우, 우리는 작은 량의 대역폭을 희생하는 댓가로 RTT 가 낮게 유지되는 것을 선호한다. 왜냐하면 처음부터 대역폭은 풍부하고, 증가하는 RTT는 직접적으로 짧은 전송의 완료 시간에 영향을 주기 때문이다. 이 효과에서, 우리는 처리량 / 지연 곡선을 타고 어느 지점에서 꼬리 지연을 용납할 수 없는 지를 찾는다. 두 번째 측정 기준은 공성성과 손실이다. 우리는 이를 자세히 연구하기 보다는 양쪽을 확인하여 알린다. 마지막으로, 우리는 더 높은 평균보다는 안정적인 설계를 선호하지만, 예측 가능한 성능의 댓가를 위한 동요(oscillating)는 허용한다.

4.2. 지연 변화도 접근

FAST TCP 와 Compound TCP 와 같은 지연 기반 혼잡 제어 알고리즘들은 TCP Vagas 의 중대한 작업(seminal work)에 의해 영감을 받았다. 이들은 기준선 이상으로 증가하는 RTT 를 혼선의 지표(indicative)로 해석한다. 만약 지연이 더 증가하여 버퍼 점유가 병목 큐 근처의 일부 미리 정의된 한계점(threshold)에서 유지되면 그들은 송신율을 줄인다. 그러나, Kelly 등은 반복(loop) 지연 제어 시간보다 입력 시간(in time)이 짧을 때 큐 크기를 제어하는 것이 불가능하다고 주장한다. 이것이 경쟁하는 트래픽으로 인해 10 Gbps 링크를 통해 64 KB 메시지가 최소 51㎲ 이거나 상당히 더 높아질 수 있으며, 반면에 한 패킷의 큐잉 지연이 1㎲인 데이터 센터의 경우이다. 이런 환경에 있는 어떠한 알고리즘이 할 수 있는 최선(the most)은 큐 점유의 분산을 제어하는 것이다. 큐 크기의 제어가 가능하다고 해도, 다수의 큐가 병목이 될 수 있는 데이터 센터를 위한 한계점을 선택하는 것은 악의적으로 어려운 튜닝 문제이다.
  TIMELY's 의 혼잡 제어기는 높은(standing) 큐를 유지하는 대신에, 큐잉의 시간에 관한 파생물 또는 지연 변화도에 반응하여 낮은 지연을 달성한다. 이것은 우리가 큐잉 지연의 변화를 나타내는 RTT들의 차이점을 정확하게 측정할 수 있기 때문에 가능하다. RTT들의 증가로 인한 양수의 지연 변화도는 큐의 증가를 나타내고, 반대로 음수의 변화도는 큐의 감소를 나타낸다. 이 변화도를 이용하여, 우리는 높은 큐가 생성될 때까지 기다리지 않고 큐 증가에 반응할 수 있다. 이 전략이 우리가 낮은 지연을 달성하도록 돕는다.
  지연 변화도는 병목 큐에서 전송률 부조화의 대리인이다. 우리는 단지 큐 크기들에 기반한 명시적 피드백보다 더 좋은 안정성과 융합된 속성들이 가지는 전송률의 부조화에서 명시적 피드백을 찾은 RCP, XCP, PI, 그리고 QCN 에서 영감을 받았다. 후자일 수록 덜 정확하게 큐가 제어되도록 할 수 있다. 중요한 차이점은 이전의 컨트롤러들은 네트워크의 큐에서 동작하지만, TIMELY 는 종단 간(end to end)의 지연 변화도를 사용하여 유사한 이익을 달성한다.
  우리가 가정한 모델은 N 개의 종단 호스트가 전체 전송률 y(t)로 처리율(drain rate) C 를 가진 병목 큐로 데이터를 전송한다. 즉, 외부 전송률(outgoing rate)은 ≤ C 이다. 우리는 병목 큐를 통하는 큐잉 지연을 q(t) 로 표시한다. 만약 y(t) > C 이면, 이 큐가 생성하는 전송률은 (y(t) - C)이다. 왜냐하면 규잉된 데이터가 C 의 속도로 처리(drain)되므로, 큐잉 지연 변화도는 dq(t) / dt = (y(t) - C) / C 로 주어진다. 이 변화도는 무차원(dimensionless)이다. 이 것은 y(t) > C 이면 양수이고, 얼마나 빠르게 큐가 높아지는 중(building)인지 신호를 준다. y(t) < C 일 때 음수의 변화도는 얼마나 빠르게 큐가 빠져나가는 중(draining)인지 신호를 준다. 그러므로, RTT 신호들을 통해 측정된 지연 변화도는 병목에서의 전송률 부조화의 지표로 행동한다. 이 논리는 네트워크에 제로가 아닌 큐가 있는 동안 유지된다. 제로 큐가 있거나, 큐의 크기가 변하지 않을 때, 측정된 변화도 역시 제로다. TIMLEY는 총합의 유입(incoming) 전송률 y(t)를 처리율(drain rate)인 C에 맞추려 노력하여, ((y(t) - C) / C) = (dq(t) / dt) = (d(RTT) / dt) 의 측정된 오류의 비율로 연결당 전송율(per-connection rate) R(t)에 적응(adapt)시킨다.

4.3. 주요 알고리즘


알고리즘 1은 우리의 혼잡 제어 알고리즘의 의사코드이다. TIMLEY 는 각 연결에서 단일 전송률 R(t)를 유지하고 매 완료 이벤트마다 RTT 표본을 사용하여 이를 갱신한다. 이것은 처리량을 가용한 대역폭에 가깝도록 유지하기 위해 다듬어진(smoothed) 지연 변화도를 오류 신호로 사용하여 변화도 추적, 전송율 조정을 적용(employ)한다. 추가적으로, 우리는 사용할 수 없거나(under utilization), 과도하게 높은 패킷 지연의 극단적인 경우를 찾고 대응하기 위한 한계점(threshold) 를 사용한다. 그림8은 두 한계점들과 변화도 구간을 보여준다.

그림8. 상ㆍ하 RTT 한계점과 변화도 추적 구간

RTT가 명목상(nominal) 운영 범위 안에 있을 때, 변화도 추적 알고리즘은 RTT 표본들로부터 지연 변화도를 계산하고 이를 송신율를 조정하는 데 사용한다.

지연 변화도 계산하기. 우리는 NIC를 사용하는 정확한 RTT 측정에 의존한다. 지연 변화도를 계산하기 위해서, TIMELY는 두 개의 연속된 RTT 표본 사이의 차이를 계산한다. 우리는 이를 최소 RTT 로 나눠서 이 차이를 표준화하고, 무차원 양(dimensionless quantity)을 획득한다. 실제로는, 최소 RTT 의 정확한 값은 중요하지 않으며, 왜냐하면 우리는 큐가 증가하고 있는 지 감소하고 있는 지만을 결정하기 때문이다. 그래서 우리는 미리 알 수 있는 데이터센터 네트워크의 회선 전파 지연을 나타내는 고정된 값을 사용한다. 마지막으로, 우리는 이 결과를 EWMA 필터[13]에 보낸다. 이 필터는 우리가 큐의 전체적인 상승과 하락의 경향을 탐지할 수 있도록 하며, 반면에 혼잡을 나타내지 않는 작은 큐의 변동(fluctuation)은 무시한다.

전송률 계산하기. 다음, TIMELY는 일반화된 변화도를 사용하여 연결의 목표 전송률을 갱신한다. 만약 변화도가 음수 또는 영과 같으면, 네트워크는 총 수신률을 따라갈 수 있고, 그러므로 더 높은 전송률을 위한 여지가 있다. 이 경우, TIMELY 는 연결의 추가적인 증가 R = R + δ 를 수행하여 더 많은 대역폭을 조사하고, 여기에서 δ 는 대역폭 추가 증가 상수이다. 변화도가 양수이면, 전체 전송률은 네트워크 용량(capacity)보다 크다. 그러므로, TIMELY는 변화도 인수로 측량(scaled)한 증가하는 전송률의 감소 β 를 수행한다.


전체 수신과 송신 전송률을 기반하는 지연 변화도 신호는 혼잡한 경로와 함께 모든 연결에 공통적이다. 잘 알려진 AIMD[14] 속성은 우리의 알고리즘이 모든 연결에서 공정성을 확보하는 것을 보장한다.
  지연 변화도가 일반적인 동작에서는 효과적이지만, 상당히 불리하거나 높은 지연의 상태들에서는 더 공격적인 반응이 필요하다. 다음 우리는 어떻게 TIMELY가 이러한 상황을 탐지하고 반응하는 지를 논한다.

낮은 RTT 기준점 Tlow의 필요성. 우리의 알고리즘을 위한 이상적인 환경은 패킷들이 완벽하게 보조를 맞추는 것이다. 그러나, 현실적인 설정에서, TIMELY 전송률은 64KB 까지 커질 수 있는 세그먼트 단위로 강요된다. 이 큰 분할은 네트워크에서 일시적인(transient) 대기열을 초래하는 패킷 버스트들을 초래하므로, 때때로 충돌이 있을 때 RTT 가 치솟는다(spikes). 신경쓰지 않으면, 핵심 알고리즘은 갑작스런 RTT 의 치솟음으로 인한 양수의 변화도를 탐지할 것이고, 불필요하게 혼잡을 추측하고 속도를 늦춘다(back-off). 우리는 낮은 기준점 Tlow을 이용하여 RTT의 치솟음을 거름(filter)으로써 이 행동을 회피한다. 지연 변화도 기반의 조정(adjustment)은 기준점보다 큰 RTT 표본들로 시작된다. 더 큰 메시지는 더 많은 폭발적인(bursty) 큐 점유를 초래하므로, Tlow는 네트워크에서 사용되는 세그먼트 크기의 (비선형) 증가함수이다. 우리는 우리의 평가에서 이 효과를 연구하였으며, 또한 호스트에서 어떻게 정밀하게 속도를 조절하는 것이 폭발성(burstiness)를 줄일 수 있는 지와 낮은 기준점의 필요성을 보인다.

높은 RTT 기준점 Thigh의 필요성. 핵심 변화도 알고리즘은 매우 작은 큐를 만드는 동안에 병목 처리량에 가깝도록 유지한다. 그러나, 이론적으로, 큐가 높고, 고정된 수준으로 유지되는 동안 변화도가 제로에 머무를 수 있다. 이 염려를 없애기 위해, Thigh는 허용할 수 있는 종단 간 네트워크 큐 지연, 다시 말해 꼬리 지연의 상위 경계로서의 역할을 한다. 이는 지연이 증가할 때 변화도와 무관하게 전송률을 줄이는 방법을 제공하고, 우리가 알고있는 특정을 가진 데이터 센터 환경에서 동작하기 때문에 가능한 보호이다. 만약 측정된 RTT 가 Thigh보다 높으면, 우리는 전송률을 곱수로(multiplicatively) 줄인다.


우리는 매끄러운(smoothed) RTT 보다 순각적인(instantaneous) 것을 사용했다는 것에 주의한다. 이 것이 일상적이지 않게 보일 수 있지만, 우리는 과도하게 큰 하나의 RTT 가 혼잡을 알린다고 자신하고, 우리의 우선순위는 낮은 패킨 지연의 유지와 손실 회피이므로, 이에 반응하여 느리게 할 수 있다. 우리는 평균 RTT 를 혼잡 기준으로 반응하려 노력하였지만, 피드백 루프에서의 추가 지연 때문에 패킷 지연을 손상시키는 것을 발견하였다. 평균이 상승하고, 혼잡 제어가 전송률을 낮출 때, 네트워크에서 큐잉 지연은 이미 증가하였다. 우리의 발견은 평균적인 큐의 길이가 RED QAM[15] 을 떨어뜨린다는 이론적인 분석을 제어를 통해 보여준 [16]와 일치한다. 우리는 6번 단원에서 어떻게 Thigh가 처리량-지연 상충 곡선에서 우리를 올바르게 태워주는 지를 보인다.

빠른 수렴을 위한 과민한 증가. ㄷㄷㄷㄷ

[2] Network Interface Card
[3] Round Trip (delay) Time, 왕복 (지연)시간
[4] 본문의 rate 와 pace 를 직역하면 모두 '속도'이다. 의미의 차이를 고려하여, rate 는 '전송률', pace 는 pacing 을 포함하여 '전송 수준'으로 번역한다.
[5] 1952년 찰스 클로스가 처음 공식화하였으며, 모든 leaf switch 는 모든 spine 과 연결되어, leaf 간 통신의 hop 수는 2로 고정된다. 세부 내용은 아래 내용 참고. 특히 그림을 보자.
[6] Priority-based Flow Control
[7] 직역하면 직물, 천 등인데, 데이터 센터 내부의 Clos 네트워크의 다른 이름으로 이해된다. 
[8] 데이터가 네트워크 MTU(또는 PDU)로 분할(segmentation) 되었을 때 뒷 부분의 데이터 도착이 지연되는 것을 의미하는 것으로 이해된다.
[9] Data Center TPC : 데이터센터의 트래픽을 위한 프로토콜이며, RFC 8257 이다.
[10] CPU가 처리하지 않고, NIC가 직접 처리하는 작업량으로 이해된다. 세부 정보는 아래 블로그들 참고.
[11] Burst. 직역하면 파열, 한바탕 터뜨림이다. 물리적 송수신 단위로 이해된다.
[12] 줄여서 RR 스케쥴링. 시분할 시스템의 선정형 스케쥴링으로, 세그먼트들 사이에 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum)로 처리하는 방식. 세부 내용은 위키 참고.
[13] Exponentially Weighted Moving Average 의 약자로, 지수적으로 가중된 이동 평균으로 번역할 수 있다. 노이즈 처리와 관련된 고성능 필터로 이해된다. 아래 참고.
[14] TCP 혼잡 제어 알고리즘으로, Addive Increase Multiplicative Decrease 의 약자이다. Network 의 상태가 좋아서 보내는 양을 증가시킬 때는 천천히, 반대로 감소시킬 때는 급격히 줄인다는 의미이다. 출처는 아래 블로그.
[15] TODO
[16] C. Hollot, V. Misra, D. Towsley, and W.-B. Gong. A control theoretic analysis of RED. In IEEE Infocom '01.

댓글 없음:

댓글 쓰기