기말고사 범위부터 정리해보려고 한다. 정리하는 방식은 고민을 많이 해보았는데, 수업 ppt를 활용하는게 가장 좋을 것 같다.
*본 포스팅에서 사용하는 자료는 DGIST 곽정호 교수님의 컴퓨터 네트워크 강의 수업 자료입니다! (사전 허락을 받았습니다)
중간고사 범위까지는 Transport layer의 reliability를 다루었다. 이젠 congestion flow가 무엇인지 다룬다. Congestion란 말 그대로 혼잡 현상인데, 정의는 "source 측에서 너무 많은 데이터가 유입되어서 네트워크에 있는 수 많은 큐들이 발산하는 현상" 이다. 즉, 네트워크 어딘가에 있는 라우터에서 큐에 너무 많은 packet들이 쌓여 packet들이 버려지거나, 혹은 중간에 손실되는 packet이 발생하는 현상을 의미한다. Flow control은 sender측의 "receive buffer 크기 (rwnd)"와 receiver측의 "rwnd"만 알면 조절할 수 있는 end-to-end 제어였지만 Congestion control은 중간에 어떤 라우터에서 큰 부하가 걸리는지 모르기 때문에 end-to-end가 아니다.
Congestion의 현상으로는 어떤 라우터의 버퍼가 다 차서 packet이 버려지는 lost packets 현상, packet이 큐 안에서 기다리면서 delay가 생기는 long delays 현상이 발생한다. 이것은 Flow control과는 다르게 매우 중요하고 어려운 문제이다. sender 측에서는 packet을 잃어버린건지, 아니면 중간 라우터에 있는 큐에서 delay되고 있는 것인지 모르기 때문이다. 만약 다시 packet을 보내면 더 잘못될 수도 있다! 아주 어려운 문제이다.
이제 세 가지 시나리오를 볼 것이다. 이 시나리오들은 두 개의 sender와 두 개의 receiver가 존재하는 상황이다. 세 가지 경우를 살펴보며 혼잡이 발생하는 경우에 대해서 깊게 생각해볼 수 있다. (그다지 중요하진 않다..) 그럼 가장 간단한 첫 번째 시나리오를 보자. 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터가 있는 경우이다. 이 경우 두 개의 sender가 output link capacity로 R을 공유하니, 각각 2/R의 throughput을 나누어가진다. 중간에 packet 손실이 없고 불필요한 retransmission도 필요 없는 이상적인 상황이다. 당연히 이런 상황이라면 congestion control이 필요 없을 것이다.
두 번째 시나리오는 2개의 송신자, 유한 버퍼를 가진 하나의 라우터이다. 즉, 첫번째 상황과 달라진 것은 라우터가 유한 버퍼를 가진다는 것이다. 즉, 라우터에 이미 버퍼가 가득 찼을 때 도착하는 패킷들이 버려진다는 것을 의미한다. (책) 각 연결은 신뢰적이라고 가정하자. 트랜스포트 계층 세그먼트를 포함하는 패킷이 라우터에서 버려지면, 결국 송신자에 의해 재전송될 것이다. 패킷이 재전송 될 수 있으므로, 이젠 송신율 (sending rate)이라는 용어 사용에 좀 더 주의해야 한다. 어플리케이션이 원래의 데이터를 소켓으로 보내는 송신율을 lamda_in 이라고 하자. 네트워크 안에서 세그먼트 (원래 데이터와 재전송 데이터를 포함)을 송신하는 트랜스포트 계층에서의 송신율을 lamda_in’’ bit/s 로 표시하고, 이것은 때때로 네트워크에 제공된 부하(offered load)라고 부른다.
길게 설명했지만, 결국 라우터의 버퍼가 유한이라면 중간에 packet loss가 생기고, 그 결과 retransmission이 필요하다는 것만 알고 넘어가면 된다.
그럼 여기서 궁금증이 하나 생긴다. "언제 retransmission을 해줄 것인가?" packet이 네트워크 중간 어딘가에 있는 라우터에서 손실되었다면, 그것을 어떻게 알고 빠른 시간안에 대처를 할 수 있는지가 중요할 것이다. 만약, 매우 이상적으로 host A가 라우터 버퍼가 다 차지 않고 비어있을 때만 packet을 전송한다고 하자. 그렇다면 버퍼가 다 채워질 일이 없으니 packet이 중간에 버려질 일도 없을 것이다. 그럼 retransmission이 발생하지 않는다.
하지만 위의 경우처럼 라우터의 버퍼가 비어있는지, 다 차있는지 어떻게 알겠는가. 매우 비현실적이다. 좀 더 현실적으로, 최초의 데이터 전송이 0.5R (R/2) 이라고 하자. 그럼 중간에 조금의 데이터 손실이 있고 수신자 어플리케이션으로 전달되는 데이터의 전송률은 0.33R (R/3) 정도 된다고 하자. 즉, 전송된 데이터 0.5R 중 0.333R bps는 원래의 데이터이고, 초당 0.166R bps는 재전송 데이터이다. 따라서 중간에 buffer overflow가 생긴 것이니, sender는 버려진 패킷을 다시 재전송해줘야 한다.
마지막으로 라우터 버퍼가 다 차서 packet loss가 된 상황 말고도 송신자에서 너무 일찍 타임아웃되는 바람에 packet이 손실되지 않았지만 큐에서 지연되고 있는 packet을 재전송하는 경우도 있다. 이런 경우 원래 data packet과 retransmission packet 둘 다 수신자에게 도착한다. 물론 수신자는 단 하나의 packet만 필요하기 때문에 retransmission packet은 버린다. 하지만, 이 재전송은 큰 낭비이다. 이러한 불필요한 재전송은 커다란 지연이 될 수 있다! 라우터가 packet의 불필요한 복사본을 전송함으로써 링크 대역폭을 사용하는 원인이 된다. 예를 들어, timeout이 매우 짧다면 계속해서 packet을 재전송 할 것이고, 그럼 중간의 라우터에서 폭주가 일어날 수 있다.. => Congestion Collapse가 이런 예시 아닐까?
마지막 시나리오 3: 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로
지금까지는 라우터 1개만 고려했었다. 이제는 여러 개의 라우터를 고려해보자.
마지막 혼잡 시나리오에서 4개의 호스트는 왼쪽 그림과 같이 겹쳐지는 2-홉 경로를 통해 패킷을 전송한다. 다시 각각의 호스트가 안정적인 데이터 전송 서비스를 실행하기 위해 타임아웃/재전송 매커니즘을 사용한다고 가정한다. 모든 호스트는 lamda_in의 동일한 값을 가지고, 모든 라우터 링크는 R byte/s 용량을 가진다고 가정한다.
A-C와 B-D를 보자. 이 둘은 R2에서 경쟁을 하게 된다. 그런데 보통 첫번째 홉의 라우터의 R로 인해 두번째 홉의 라우터의 R이 결정된다. 지금 R2는 A-C 입장에서 두번쨰 홉이고, B-D에서는 첫번째 홉이니, 만일 A-C가 R1에서 느릴 경우 R2에서도 적은 처리량을 분배받고 R1에서 빠르더라도 B-D가 먹는 R2에 의해 처리량이 분배된다. 즉, R2 라우터에서 경쟁이 일어나는데 B-D에서 엄청난 부하가 있다면 R2의 빈 버퍼는 모두 B-D 의 패킷으로 가득 찰 것이다. 따라서 R2에서 A-C 연결의 처리량은 0이 된다. 이것은 트래픽이 많은 경우 A-C 종단간 처리율이 0이 된다는 것을 의미한다.
과도한 트래픽 시나리오에서 패킷이 두 번째 홉 라우터에서 버려질 때마다, 두 번째 홉 라우터에게 패킷을 전달하는 첫 번째 홉 라우터에서 수행된 작업은 헛된 것이 된다. 만약 첫 번째 라우터에서 간단하게 그 패킷을 포기하고, 유휴 상태를 유지한다면, 네트워크는 그만큼 잘 돌아갈 것이다. 따라서 혼잡 때문에 패킷을 버려야 하는 또 다른 비용을 확인할 수 있다.
-> 패킷이 경로 상에서 버려질 때, 버려지는 지점까지 패킷을 전송하는데 사용된 상위 라우터에서 사용된 전송 용량은 헛된 것이다.
지금까지 3가지의 congestion 시나리오를 살펴보았다. 이러한 congestion이 발생하면 생각보다 고려할게 많다는 사실을 알 수 있다. 그럼 congestion이 심각하게 발생하면 어떻게 될까? 조금의 congestion이 발생하면 해당 라우터쪽에 packet을 덜 보내는 식으로 조절할 수 있겠지만, congestion이 심각하게 발생해서 손을 쓸 수 없는 상황이 생기지 않을까? 바로 이런 상황이 congestion collapse 이다. Congestion이 계속 발생하면 갑자기 네트워크가 down 되는 현상을 말한다. 한 번에 너무 많은 traffic이 몰리면, 이걸 감당하지 못하고 뻗어버리는 경우가 있다고 한다.
'Computer Network' 카테고리의 다른 글
| 컴퓨터 네트워크 정리 계획 (0) | 2022.12.31 |
|---|
기말고사 범위부터 정리해보려고 한다. 정리하는 방식은 고민을 많이 해보았는데, 수업 ppt를 활용하는게 가장 좋을 것 같다.
*본 포스팅에서 사용하는 자료는 DGIST 곽정호 교수님의 컴퓨터 네트워크 강의 수업 자료입니다! (사전 허락을 받았습니다)
중간고사 범위까지는 Transport layer의 reliability를 다루었다. 이젠 congestion flow가 무엇인지 다룬다. Congestion란 말 그대로 혼잡 현상인데, 정의는 "source 측에서 너무 많은 데이터가 유입되어서 네트워크에 있는 수 많은 큐들이 발산하는 현상" 이다. 즉, 네트워크 어딘가에 있는 라우터에서 큐에 너무 많은 packet들이 쌓여 packet들이 버려지거나, 혹은 중간에 손실되는 packet이 발생하는 현상을 의미한다. Flow control은 sender측의 "receive buffer 크기 (rwnd)"와 receiver측의 "rwnd"만 알면 조절할 수 있는 end-to-end 제어였지만 Congestion control은 중간에 어떤 라우터에서 큰 부하가 걸리는지 모르기 때문에 end-to-end가 아니다.
Congestion의 현상으로는 어떤 라우터의 버퍼가 다 차서 packet이 버려지는 lost packets 현상, packet이 큐 안에서 기다리면서 delay가 생기는 long delays 현상이 발생한다. 이것은 Flow control과는 다르게 매우 중요하고 어려운 문제이다. sender 측에서는 packet을 잃어버린건지, 아니면 중간 라우터에 있는 큐에서 delay되고 있는 것인지 모르기 때문이다. 만약 다시 packet을 보내면 더 잘못될 수도 있다! 아주 어려운 문제이다.
이제 세 가지 시나리오를 볼 것이다. 이 시나리오들은 두 개의 sender와 두 개의 receiver가 존재하는 상황이다. 세 가지 경우를 살펴보며 혼잡이 발생하는 경우에 대해서 깊게 생각해볼 수 있다. (그다지 중요하진 않다..) 그럼 가장 간단한 첫 번째 시나리오를 보자. 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터가 있는 경우이다. 이 경우 두 개의 sender가 output link capacity로 R을 공유하니, 각각 2/R의 throughput을 나누어가진다. 중간에 packet 손실이 없고 불필요한 retransmission도 필요 없는 이상적인 상황이다. 당연히 이런 상황이라면 congestion control이 필요 없을 것이다.
두 번째 시나리오는 2개의 송신자, 유한 버퍼를 가진 하나의 라우터이다. 즉, 첫번째 상황과 달라진 것은 라우터가 유한 버퍼를 가진다는 것이다. 즉, 라우터에 이미 버퍼가 가득 찼을 때 도착하는 패킷들이 버려진다는 것을 의미한다. (책) 각 연결은 신뢰적이라고 가정하자. 트랜스포트 계층 세그먼트를 포함하는 패킷이 라우터에서 버려지면, 결국 송신자에 의해 재전송될 것이다. 패킷이 재전송 될 수 있으므로, 이젠 송신율 (sending rate)이라는 용어 사용에 좀 더 주의해야 한다. 어플리케이션이 원래의 데이터를 소켓으로 보내는 송신율을 lamda_in 이라고 하자. 네트워크 안에서 세그먼트 (원래 데이터와 재전송 데이터를 포함)을 송신하는 트랜스포트 계층에서의 송신율을 lamda_in’’ bit/s 로 표시하고, 이것은 때때로 네트워크에 제공된 부하(offered load)라고 부른다.
길게 설명했지만, 결국 라우터의 버퍼가 유한이라면 중간에 packet loss가 생기고, 그 결과 retransmission이 필요하다는 것만 알고 넘어가면 된다.
그럼 여기서 궁금증이 하나 생긴다. "언제 retransmission을 해줄 것인가?" packet이 네트워크 중간 어딘가에 있는 라우터에서 손실되었다면, 그것을 어떻게 알고 빠른 시간안에 대처를 할 수 있는지가 중요할 것이다. 만약, 매우 이상적으로 host A가 라우터 버퍼가 다 차지 않고 비어있을 때만 packet을 전송한다고 하자. 그렇다면 버퍼가 다 채워질 일이 없으니 packet이 중간에 버려질 일도 없을 것이다. 그럼 retransmission이 발생하지 않는다.
하지만 위의 경우처럼 라우터의 버퍼가 비어있는지, 다 차있는지 어떻게 알겠는가. 매우 비현실적이다. 좀 더 현실적으로, 최초의 데이터 전송이 0.5R (R/2) 이라고 하자. 그럼 중간에 조금의 데이터 손실이 있고 수신자 어플리케이션으로 전달되는 데이터의 전송률은 0.33R (R/3) 정도 된다고 하자. 즉, 전송된 데이터 0.5R 중 0.333R bps는 원래의 데이터이고, 초당 0.166R bps는 재전송 데이터이다. 따라서 중간에 buffer overflow가 생긴 것이니, sender는 버려진 패킷을 다시 재전송해줘야 한다.
마지막으로 라우터 버퍼가 다 차서 packet loss가 된 상황 말고도 송신자에서 너무 일찍 타임아웃되는 바람에 packet이 손실되지 않았지만 큐에서 지연되고 있는 packet을 재전송하는 경우도 있다. 이런 경우 원래 data packet과 retransmission packet 둘 다 수신자에게 도착한다. 물론 수신자는 단 하나의 packet만 필요하기 때문에 retransmission packet은 버린다. 하지만, 이 재전송은 큰 낭비이다. 이러한 불필요한 재전송은 커다란 지연이 될 수 있다! 라우터가 packet의 불필요한 복사본을 전송함으로써 링크 대역폭을 사용하는 원인이 된다. 예를 들어, timeout이 매우 짧다면 계속해서 packet을 재전송 할 것이고, 그럼 중간의 라우터에서 폭주가 일어날 수 있다.. => Congestion Collapse가 이런 예시 아닐까?
마지막 시나리오 3: 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로
지금까지는 라우터 1개만 고려했었다. 이제는 여러 개의 라우터를 고려해보자.
마지막 혼잡 시나리오에서 4개의 호스트는 왼쪽 그림과 같이 겹쳐지는 2-홉 경로를 통해 패킷을 전송한다. 다시 각각의 호스트가 안정적인 데이터 전송 서비스를 실행하기 위해 타임아웃/재전송 매커니즘을 사용한다고 가정한다. 모든 호스트는 lamda_in의 동일한 값을 가지고, 모든 라우터 링크는 R byte/s 용량을 가진다고 가정한다.
A-C와 B-D를 보자. 이 둘은 R2에서 경쟁을 하게 된다. 그런데 보통 첫번째 홉의 라우터의 R로 인해 두번째 홉의 라우터의 R이 결정된다. 지금 R2는 A-C 입장에서 두번쨰 홉이고, B-D에서는 첫번째 홉이니, 만일 A-C가 R1에서 느릴 경우 R2에서도 적은 처리량을 분배받고 R1에서 빠르더라도 B-D가 먹는 R2에 의해 처리량이 분배된다. 즉, R2 라우터에서 경쟁이 일어나는데 B-D에서 엄청난 부하가 있다면 R2의 빈 버퍼는 모두 B-D 의 패킷으로 가득 찰 것이다. 따라서 R2에서 A-C 연결의 처리량은 0이 된다. 이것은 트래픽이 많은 경우 A-C 종단간 처리율이 0이 된다는 것을 의미한다.
과도한 트래픽 시나리오에서 패킷이 두 번째 홉 라우터에서 버려질 때마다, 두 번째 홉 라우터에게 패킷을 전달하는 첫 번째 홉 라우터에서 수행된 작업은 헛된 것이 된다. 만약 첫 번째 라우터에서 간단하게 그 패킷을 포기하고, 유휴 상태를 유지한다면, 네트워크는 그만큼 잘 돌아갈 것이다. 따라서 혼잡 때문에 패킷을 버려야 하는 또 다른 비용을 확인할 수 있다.
-> 패킷이 경로 상에서 버려질 때, 버려지는 지점까지 패킷을 전송하는데 사용된 상위 라우터에서 사용된 전송 용량은 헛된 것이다.
지금까지 3가지의 congestion 시나리오를 살펴보았다. 이러한 congestion이 발생하면 생각보다 고려할게 많다는 사실을 알 수 있다. 그럼 congestion이 심각하게 발생하면 어떻게 될까? 조금의 congestion이 발생하면 해당 라우터쪽에 packet을 덜 보내는 식으로 조절할 수 있겠지만, congestion이 심각하게 발생해서 손을 쓸 수 없는 상황이 생기지 않을까? 바로 이런 상황이 congestion collapse 이다. Congestion이 계속 발생하면 갑자기 네트워크가 down 되는 현상을 말한다. 한 번에 너무 많은 traffic이 몰리면, 이걸 감당하지 못하고 뻗어버리는 경우가 있다고 한다.
'Computer Network' 카테고리의 다른 글
| 컴퓨터 네트워크 정리 계획 (0) | 2022.12.31 |
|---|
