FreeBSD의 TCP Congestion 윈도우
글쓴이: mandugukbap / 작성시간: 목, 2011/01/13 - 2:57오전
FreeBSD에서 어떤 TCP 연결 도중의 Congestion window를 플로팅 해 보았습니다.
첨부된 그림을 보시면 TCP의 혼잡 제어 메커니즘과 비슷한 것을 볼 수 있는데, x 좌표의 200에서 500 (패킷의 순서)에서 제대로 된 slow-start가 아닌 오르락 내리락 하는 모습이 보입니다. 가는 선으로 표현된 threshold (임계치)가 변하지 않는 것으로 보건데 타임아웃이나 혼잡감지에 의한 윈도우 감소는 아닌 듯 합니다.
이 현상을 잘 아시는 분 설명 좀 부탁 드리겠습니다.
File attachments:
| 첨부 | 파일 크기 |
|---|---|
 cong-wnd.gif | 3.19 KB |
Forums:
음.. 그래프를 보건데 여전히 의문인 것들이 있어
음.. 그래프를 보건데 여전히 의문인 것들이 있어 질문을 드립니다.
* 사용하신 FreeBSD 버전이 어떻게 되는지?
* Congestion window 을 plotting 하기 위해서 어딘가에서 정보를 얻으셨을 텐데, 그 경로가 어떻게 되는지? Current 의 SIFTR 을 사용하셨는지? 혹은 hook 을 등록하셨다면 어디에 하셨는지.
* 그리고 Congestion window 값은 tp->snd_cwnd 값이 맞는지.
* 혹시 raw data 가 있으시면 이용 가능한지.
* 위에서 `가는 선으로 표현된 threshold' 라 하시면 tp->snd_ssthresh 을 가르키는 것인지.
관심 감사 드립니다. * 사용하신 FreeBSD
관심 감사 드립니다.
* 사용하신 FreeBSD 버전이 어떻게 되는지?
FreeBSD 8 입니다.
* Congestion window 을 plotting 하기 위해서 어딘가에서 정보를 얻으셨을 텐데, 그 경로가 어떻게 되는지? Current 의 SIFTR 을 사용하셨는지? 혹은 hook 을 등록하셨다면 어디에 하셨는지.
SIFTR을 사용했습니다.
* 그리고 Congestion window 값은 tp->snd_cwnd 값이 맞는지.
SIFTR 로그의 9번쩨 컬럼입니다.
* 혹시 raw data 가 있으시면 이용 가능한지.
Trace 공개를 말씀 하시는건가요? 그건 불가능 한 걸로 알고 있습니다.
* 위에서 `가는 선으로 표현된 threshold' 라 하시면 tp->snd_ssthresh 을 가르키는 것인지.
SIFTR 로그의 8번째 컬럼입니다.
SIFTR 을 사용하셨다면 해당 모듈 자체가 disk
SIFTR 을 사용하셨다면 해당 모듈 자체가 disk 에 trace한 결과물을 저장할 수 있습니다. 제가 말한 raw data 가 그것입니다.
raw data 도 보지 못했고, 어떤 방식으로 plotting 을 하셨는지 자세히 몰라 왠지 저의 답변이 어림짐작일 수 있을 듯 합니다만 제가 상상할 수 있는 상황에 대해서 쓰겠습니다.
1. 그래프자체는 TCP input 과 output packets 들을 구분없이 함께 그린 듯 합니다. 보통 slow start 시 그래프는 exponential 하게 증가해야 하는데 (이론적인 지식으로는), 이 그래프는 그렇지 않다는 것은 ACK 을 받는 즉시 plotting 을 한 듯 하네요. 그래서 그래프가 더욱 난해해 진 듯 합니다.
2. 약 200 packet 후에 cwnd 가 1 maxseg 값으로 떨어진 원인은 3 dup ack 으로 인한 것이 아니라 retransmit timer 에 의한 현상으로 보입니다. 즉 이 그래프에서는 fast recovery 와 fast retransmit 에 대한 흔적으로 볼 수 없습니다. 그래프의 X 축이 packet count 이기 때문에 이를 눈으로 보기 힘든 상황입니다. Time 기반이었으면 더 좋았을 듯 합니다.
3. cwnd 가 reset 된 후 그래프가 증가하면서 처음 떨어질 때 (약 250 packet 지점)은 retransmit timer 의 작동 후 처음으로 duplicate ACK 을 받았는데, RFC3042 에 의한 (for limited transmit) 일시적인 cwnd 감소로 느껴지며 그 후 잠깐 cwnd 가 올라가는 원인은 tcp_input 에서의 cwnd 증가로 보입니다.
4. 그런 후 갑자기 cwnd 사이에 공백이 생기게 되는데 이는 RFC3042 작동 방식이 일시적으로 cwnd 을 감소시켰다가 보낸 직 후 cwnd 을 원래값으로 돌아가기 때문입니다.
즉 저의 소심한 의견으로는 결과값이 이렇게 나온 원인이
* TCP input 과 TCP output 의 결과값이 섞였기 때문
* RFC3042 에 의한 limited transmit
* TCP input 과 TCP output 의 서로 다른 thread 간의 racing
때문이라고 생각합니다. 감사합니다.
PS. 설마 제 말을 100% 신뢰하시는 건 아니시죠? :-)
답변 감사 드립니다. 그래프는 패킷을 플롯한게
답변 감사 드립니다.
그래프는 패킷을 플롯한게 아니라 Sender의 TCP congestion window 사이즈를 플롯한 것입니다. Input이나 Output이 따로 있지는 않을 것으로 생각됩니다.
RFC3042이 enable된 상황인지 한번 알아봐야 겠네요.
혹시 그 raw data는 어떤 형식으로 어디에 저장되는지 알려 주실 수 있는지요? SIFTR의 결과물이 siftr.log말고 다른 것이 있는줄은 몰랐습니다.
감사합니다.
SIFTR 의 첫번째 항목을 보시면 'i' 와 'o'
SIFTR 의 첫번째 항목을 보시면 'i' 와 'o' 가 정의되어 있습니다. 저는 이를 input 과 output 이라는 의미로 얘기를 드린 거구요. 제가 말한 Raw data 란 siftr.log 를 의미합니다. 제가 설명을 하면서 혼란스럽게 얘기를 한 듯 하네요.
siftr.log 을 올려주실 수 있으시면 좀 더 원인을 분석하는데 도움이 될 듯하구요. (위 제 답변도 전 100% 신뢰할 수 없는지라.. ㅡㅡ;;)
댓글 달기