혼잡 제어의 원인과 비용
- 네트워크 혼잡 원인을 처리하기 위한 방법
→ 네트워크 혼잡을 일으키는 송신자들을 억제하는 메커니즘 필요
혼잡 제어가 발생하는 시나리오
- 초점
→ 호스트들이 자신의 전송률을 증가시키고 네트워크 혼잡이 발생함에 따라 발생하는 일
시나리오 1 : 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터
- 각각 출발지와 목적지 사이에 단일 홉을 공유하는 연결을 갖는다.
- 가정
- 호스트 A, B의 애플리케이션이 λ(in) 바이트/초의 평균 전송률로 연결상으로 데이터를 보냄
→ 이러한 데이터는 각 데이터 단위가 소켓으로 한 번만 전송된다.(원본 데이터)
- 소켓을 통해 트랜스포트 계층 프로토콜로 데이터를 넘겨주는 것
- 소켓을 통해 트랜스포트 계층 프로토콜로 데이터를 넘겨주는 것
- 하위의 트랜스포트 계층 프로토콜은 단순히 데이터를 캡슐화하고 전송하는 역할
→ 오류 복구, 흐름 제어, 혼잡 제어를 수행하지 않는다. - 호스트 A, B가 전송되는 패킷은 라우터와 용량 R의 공유 출력 링크를 통과한다.
- 라우터는 무제한의 버퍼 공간을 갖는다고 가정
- 호스트 A, B의 애플리케이션이 λ(in) 바이트/초의 평균 전송률로 연결상으로 데이터를 보냄
- 호스트 A,B가 라우터에게 제공하는 속도 → λ(in) 바이트/초
- 트랜스포트 계층과 하위 계층에서 헤더 정보의 추가로 인한 부가적인 오버헤드를 무시
시나리오 1에서 호스트 A의 연결 성능
연결당 처리량(per-connection throughput): 수신자 측에서의 초당 바이트 수(왼쪽)- 0과 R/2 사이의 전송률에 대해 수신자 측의 처리량은 송신자의 전송률과 같다.
- 전송률이 R/2 이상일 때 처리량은 단지 R/2에 불과 → 상한이 존재
- 이러한 상한은 두 연결 사이에서 링크 용량 공유의 결과
→ 링크는 안정상태에서는 R/2를 초과해서 패킷을 수신자에게 전달할 수 없다.
- 이러한 상한은 두 연결 사이에서 링크 용량 공유의 결과
- 호스트 A, B가 전송률을 높게 설정해도 각자 R/2보다 더 높은 처리량을 얻을 수 없다.
- 링크 용량 근처에서의 동작 결과(오른쪽)
- 전송률이 R/2에 근접하면, 평균 지연 시간은 점점 커진다.
- 전송률이 R/2를 초과할 경우
- 라우터 안에 큐잉된 패킷의 평균 개수는 제한되지 않음
- 출발지와 목적지 사이의 평균 지연은 무제한이 된다.
- 결론
- R 근처의 전체 처리량에서 동작하는 것은 처리량 관점에서는 이상적
- But, 지연 관점에서는 이상적이지 않다.
- 패킷 도착률이 링크 용량에 근접함에 따라 큐잉 지연이 커진다.
- 무한 버퍼를 갖는 이상적인 시나리오에서도 혼잡 네트워크의 비용이 발견된다.
시나리오 2: 2개의 송신자, 유한 버퍼를 가진 하나의 라우터
- 가정
- 라우터 버퍼의 양이 유한하다고 가정
→ 이미 버퍼가 가득 찼을 때, 도착하는 버퍼는 버려진다. - 각 연결은 신뢰적이라고 가정한다.
→ 트랜스포트 계층 세그먼트를 포함하는 패킷이 라우터에서 버려지면, 송신자에 의해 재전송됨 - 패킷이 재전송될 수 있으므로,
송신율(sending rate)이라는용어를 사용- 애플리케이션이 원래의 데이터를 소켓으로 보내는 송신율 → λ(in) 바이트/초로 표기
- 네트워크 안으로 세그먼트를 송신하는 트랜스포트 계층에서의 송신율 → λ`(in) 바이트/초로 표기
- 이때 세그먼트는 원래 데이터와 재전송 데이터를 포함한다.
- λ'(in)은 네트워크에 제공된 부하(offered load)라고 부른다.
- 라우터 버퍼의 양이 유한하다고 가정
시나리오 2에서의 성능
- 재전송이 어떻게 수행 과정에 따른다.
- 호스트 A가 라우터에 있는 버퍼가 비었는지 아닌지 알 수 있고,
버퍼가 비었을 때만 패킷을 송신할 수 있는 비현실적인 경우라고 가정
- λ(in) = λ`(in) 이므로 어떠한 손실도 발생하지 않는다.
- 연결의 처리량은 λ(in)과 같다.
- 패킷 손실이 발생하지 않는다고 가정 → 평균 호스트 송신율은 R/2를 초과 X
- 처리율 관점
→ 송신된 모든 것이 수신되기 때문에 성능은 이상적
2. 패킷이 확실히 손실된 것을 알았을 때만 송시자가 재전송하는 현실적인 경우
- 송신하는 호스트가 확인응답되지 않는 패킷이 사실상 손실되었다는 것을 확신함
→ 충분히 큰 타임아웃을 설정한다. - 송신자는 버퍼 오버플로 때문에 버려진 패킷을 보상하기 위해 재전송을 수행해야 한다.
- λ`(in)(최초의 데이터 전송가 재전송 합의 속도)이 R/2일 경우
→ 제공된 부하의 값에서 수신자 애플리케이션으로 전달되는 데이터의 전송률은 R/3
- 전송된 데이터의 R/2
- R*(1/3) = 0.333R바이트/초(평균)→ 원래의 데이터
- (R/2) - (R/3) = R/6 ⇒0.166R바이트/초(평균) → 재전송 데이터
- 전송된 데이터의 R/2
- λ`(in)(최초의 데이터 전송가 재전송 합의 속도)이 R/2일 경우
3. 송신자가 일찍 타임아웃해서 패킷이 손실되진 않았지만, 큐에서 지연되고 있는 패킷을 재전송하는 경우
- 원래의 데이터 패킷과 재전송 패킷 둘 다 수신자에게 도착한다.
- 수신자는 하나의 패킷 복사본만 필요하므로 재전송된 패킷은 버린다.
→ 이런 경우 라우터에서 원래 패킷의 재전송된 복사본을 전달하는 작업은 낭비
- 수신자는 하나의 패킷 복사본만 필요하므로 재전송된 패킷은 버린다.
- 라우터는 다른 패킷을 송신하기 위해 링크 전송 용량을 사용(위 방법에서의 낭비를 막기 위해)
→ 혼잡 네트워크의 또 다른 비용이 발생- 커다란 지연으로 인한 송신자의 불필요한 재전송은
라우터가 패킷의 불필요한 복사본들을 전송하는데 링크 대역폭을 사용하는데 원인이 된다.
- 커다란 지연으로 인한 송신자의 불필요한 재전송은
- 아래 곡선은 각 패킷이 라우터에 의해 두 번씩 전달(평균)된다고 가정했을 때,
부하에 대한 처리량을 나타냄 - 각 패킷이 두 번씩 전달됨
→ 제공된 부하가 R/2일 때 처리량은 R/4의 점선 값을 가진다.
시나리오 3: 4개의 송신자와 유한 버퍼를 갖는 라우터, 그리고 멀티홉 경로
- 가정
- 4개의 호스트는 그림과 같이 겹쳐지는 2홉 경로를 통해 패킷을 전송
- 각각의 호스트가 안정적인 데이터 전송 서비스 실행을 위해, 타임아웃/재전송 메커니즘 사용
- 모든 호스트는 λ(in)의 동일한 값을 갖고, 모든 라우터 링크는 R바이트/초 용량을 갖는다.
호스트와 라우터 연결 분석 - 작은 트래픽의 경우
- 라우터 R1과 R2를 지나는 호스트 A에서 호스트 C까지의 연결
- A ~ C 연결은 D ~ B 연결과 라우터 R1을 공유
- A ~ C 연결은 D ~ B 연결과 라우터 R1을 공유
- λ(in)의 극히 작은 값에 대해 버퍼 오버플로는 거의 발생하지 않는다.
- 위 시나리오 1,2처럼 처리량은 제공된 부하와 거의 같다.
- λ(in)의 약간 더 큰 값에 대해 원래의 데이터가 네트워크로 전송 및 목적지에 전달
- 해당 과정에서 오버플로가 거의 발생하지 않음 → 처리량이 약간 커진다.
- → λ(in)이 작은 값일 때, λ(in)의 증가는 λ(out)의 증가를 가져온다.
호스트와 라우터 연결 분석 - 트래픽이 매우 큰 경우
- λ(in) 값(따라서 λ^`(in))이 매우 큰 경우를 뜻함
- R1에서 전달된 후 R2에 도착한 A~C 트래픽
→ R2에서 λ(in) 값과 관계없이, R1에서 R2까지의 링크 용량, 최대 R인 도착률을 가질 수 있다.
- λ`(in)이 모든 연결(A ~ C연결과 B ~ D 연결)에 대해 매우 큰 경우
→ R2의 B ~ D 트래픽 도착률은 A ~ C 트래픽 도착률보다 클 수 있다.- A ~ C와 B ~ D 트래픽은 버퍼 공간을 R2 라우터에서 경쟁해야 함
→ R2를 성공적으로 통과하는 A~C 트래픽 양은 B~D에서 제공된 부하가 클수록 더 작아짐
→ 제공된 부하와 처리량 간의트레이드오프(tradeoff)가 발생함
- 제공된 부하가 무한대에 가까워지는 경우
- R2의 빈 버퍼는 즉시 B~D 패킷으로 채워짐
- A~C 연결의 처리량은 0이 됨
- 제공된 부하가 무한대에 가까워지는 경우
- A ~ C와 B ~ D 트래픽은 버퍼 공간을 R2 라우터에서 경쟁해야 함
- 제공된 부하를 증가시키면 처리량이 감소하는 원인
→ 네트워크가 수행한 헛된 ‘작업’의 양을 고려해 보면 알 수 있음- 과도한 트래픽 발생 시나리오 예시(바로 위 시나리오)
- 패킷이 두 번째 홉 라우터에서 버려질 때
→ 첫 번째 홉 라우터에서 수행된 작업은 헛된 것이 됨- 첫 번째 홉 라우터의 역할 : 두 번째 홉 라우터에게 패킷을 전달
- 첫 번째 홉 라우터의 역할 : 두 번째 홉 라우터에게 패킷을 전달
- 만약 첫 번째 라우터가 패킷을 포기하고, 유휴 상태를 유지할 경우
유휴 상태: 어떠한 프로그램에 의해 사용되고 있지 않은 상태- 첫번째 라우터에서 사용되는 전송 용량은 다른 패킷을 전송하기 위해 사용될 수 있다.
← 두 번째 라우터에게 패킷을 전달하기 위한 전송 용량을 아낄 수 있기 때문- 예시
- 전송 패킷 선택
→ 라우터가 이미 여러 개의 상향 라우터를 거친 패킷에게 우선순위를 줌
- 전송 패킷 선택
- 예시
- 패킷이 두 번째 홉 라우터에서 버려질 때
- 과도한 트래픽 발생 시나리오 예시(바로 위 시나리오)
- 패킷이 버려질 때, 또 다른 비용을 발생
- 버려지는 지점까지 패킷을 전송하는 데 사용된 상위 라우터에서 사용된 전송 용량은 낭비된 것
- 버려지는 지점까지 패킷을 전송하는 데 사용된 상위 라우터에서 사용된 전송 용량은 낭비된 것
- λ(out)은goodput(throughput)이라고도 불림
- goodput : throughput 중에서도 실제로 필요한 데이터만을 의미
- λ(out)은 λ(in)이 증가할 때 어느 정도까지 증가하다가 급감
혼잡 제어에 대한 접근법
- 실제로 혼잡 제어를 수행하는 2가지 광범위한 접근 방식 특정 네트워크 구조
혼잡 제어 접근 구별
- 네트워크 계층이 트랜스포트 계층에게 어떤 직접적인 도움을 제공하는지 파악하면 구별 가능
- 여기서 직접적인 도움이란 혼잡 제어 목적을 위한 것
종단 간의 혼잡 제어 - 혼잡 제어에 대한 종단 간의 접근 방식
- 이 방식에서 네트워크 계층은 혼잡 제어 목적을 위해 트랜스포트 계층에게 직접적인 지원 X
- 네트워크에서 혼잡의 존재는 관찰된 네트워크 동작에 기초하여 종단 시스템이 추측
- 네트워크 동작 예시 - 패킷 손실 및 지연
- 네트워크 동작 예시 - 패킷 손실 및 지연
- 네트워크에서 혼잡의 존재는 관찰된 네트워크 동작에 기초하여 종단 시스템이 추측
- IP 계층이 네트워크 혼잡에 관해 종단 시스템에게 어떠한 피드백 제공도 요구받지 않음
→ TCP는 혼잡 제어를 위한 종단 간의 접근 방식을 취함- TCP 세그먼트 손실은 네트워크 혼잡의 발생 표시로 간주하고 그에 따라 윈도 크기를 줄임
- TCP 세그먼트 손실은 타임아웃 또는 삼중의 중복 확인에 의해 나타남
- TCP 세그먼트 손실은 타임아웃 또는 삼중의 중복 확인에 의해 나타남
- TCP에 대한 새로운 제안
→ 증가하는 왕복 지연값을 네트워크 혼잡 증가 지표로 사용하는 것
- TCP 세그먼트 손실은 네트워크 혼잡의 발생 표시로 간주하고 그에 따라 윈도 크기를 줄임
네트워크 지원 혼잡 제어
- 라우터들은 네트워크 안에서 혼잡 상태와 관련하여 송/수신자 모두에게 직접적인 피드백 제공
- 피드백은 링크의 혼잡을 나타내는 하나의 비트처럼 간단
- 피드백은 링크의 혼잡을 나타내는 하나의 비트처럼 간단
- 최근엔 IP/TCP가 네트워크 혼잡 제어를 선택적으로 구현할 수 있음
- 네트워크 지원 혼잡 정보는 2가지 방법 중 하나로 네트워크에게 송신자로 피드백됨
직접 피드백→ 네트워크 라우터에서 송신자에게 보내는 것- “나는 혼잡하다!”라고 말하는 것과 같음
- “나는 혼잡하다!”라고 말하는 것과 같음
- 라우터 혼잡을 나타내기 위해 전송 패킷 안의 특정 필드에 표시/수정하는 것
- 수신자가 표시된 패킷을 수신했을 때, 혼잡 상태를 송신자에게 알림
- 이 형태의 알림은 완전한 왕복 시간이 걸린다.