1.3.9 Feature Description
아래의 내용들은 RUDP를 이해하는데 도움이될 몇몇 특징을 적어놓았다. 아래의 세부 내용들은 서버와 클라이언트 간의 연결속에서 세그먼트를 서보 주고받을 때에 사용된 용어 및 동작에 관한 내용들이다.
Retransmission timer
전송측은 설정가능한 전송주기 타이머를 가진다. 이 타이머는 data, nul, or reset 등이 전송되었을 때 마다 항상 초기화되어 가동된다. 만약 송신에 대한 응답을 받지 못하였을 경우.. 타이머가 지정된 시간에 동작하여 재전송하는데 이용된다. 만약 여전히 하나 혹은 여러개의 응답을 받지 못하였을 경우 이 타이머는 재가동 될것이다. 추천값은 600 ms 이다.
Retransmission Counter
위에서 나온 재전송 타이머의 최대 반복 횟수에 필요한 카운터이다. 이 것또한 설정가능한 값이며 추천값은 2이다. 만약 카운터 값이 설정된 값을 초과하게 되면 이 연결은 깨진 연결로 간주하고 처리해야한다. 아래의 Broken connection handling 에서 이러한 상태를 어떻게 처리하는지 세부적으로 설명하고 있다.
Stand-alone acknowledgments
stand-alone acknowledgment 세그먼도 하나의 세그먼트로 acknowledgment 에 관한 정보만을 포함하고 있다. 시쿤스 번호 필드에는 data, null, or rest의 다음 시퀀스 번호를 포함한다.
Piggyback acknowledgments
수신자가 전송자에게 data, null, or reset 세그먼트를 전송할 때는 마지막 시퀀스 번호에 대응한 엑크를 포함하여 전송하여야 한다.
Out-of-sequence acknowledgments counter
수신자는 시퀀스 번호가 잘못된 세그먼트가 도착하였을 경우 그 수를 세고 있어야 한다. 그 수가 한도를 초과하면 EACK에다가 out-of-sequence의 한도값을 넣어서 송신자에게 보내주어야 한다. 그리고 0으로 리셋한다. 추천값은 3이다. 만약 송신자에게 EACK를 포함한 놈이 도착되면 자신이 보낸 데이터가 수신자에게 전달되어 못하였음을 인지해야 한다.
Cumulative acknowledge timer
응답이 아니거나 잘못된 시퀀스를 받았을 경우 수신자는 타이머를 설정하고 기다려야한다. 이 타이머가 익스파이어 되면 아웃오프시퀀스 경우는 EACK를 전송한다. 다른 경우 스탠드얼론 엑크를 전송한다. 추천값은 300 ms 이다.
Null segment timer
클라이언트는 타이머를 연결이 열기는 순간부터 유지해야한다. 그리고 데이터 세그먼트를 전송할 때 마다 초기화 시켜서 재가동 시켜준다. 만약 클라이언트의 null segment 타이머가 익스파이어되면, 클라이언트는 서버로 null 세그먼트를 전송해준다. 즉 keep alive 첵크를 유지해야 한다는 이야기다. 이 세그먼트의 시퀀스 번호가 유효하다면 서버는 이에 응답해야 한다. 서버는 널 세그먼트의 이전의 값과 현재 값 두개를 타임아웃 값으로 유지해야한다. 만약 클라리언트로 부터 널 세그먼트를 수신 받으면 이 타이머는 리셋된다. 만약 이 타이머가 익스파이어되면 연결이 끊어진 것으로 간주한다. 이 부분에 대해서는 아래의 Broken Connection Handling 을 참조한다. 추천 값은 2 sec 이다.
Auto Reset
양쪽의 연결은 오토 리셑으로 초기화 할 수 있다. 이 오토리셑은 과도한 재전송, 널 세그먼트 타이머 익스파이어, 전송 상태 타이머의 익스파이어등 다양한 상황에서 사용될 수 있다. 오토 리셑은 양측 연결을 초기화 하고 각종 타이머값을 초기할 수 있으며, 시퀀스의 초기화 등 연결에 필요한 설정값을 다시 협상하여 재설정 할 수 있다. 오토 리셑 카운터의 최대값을 넘기지 않으면 연결을 유지한 상태에서 설정이 가능하다. 최대값을 넘든다면 당연히 연결설정이 초기화 된다. 추천값은 3이다.
Receiver Input Queue Size
입력 큐 사이즈는 설정 가능한 파라미터이다. 추천값은 32 패킷이다. 입려 큐의 사이즈는 플로우 컨트롤 메카니즘을 따른다. 대충 하나의 데이터 크기는 저 패킷수를 넘지 않도록 조절하라는 이야기인건가?
Congestion control and slow start
RUDP는 이러걸 지원하지 않는단다.
UDP port numbers
RUDP에서는 특정한 포트 번호를 제안하지 않고있다. 쓰고 싶은데로 정해서 쓰면된다. 단 일반적으로 쓰고 있는 디파인된 포트는 피하는게 좋다. RFC 1700 참조.
Support for redundant connections
만약 RUDP 연결이 실패하면 상위 레이어 프로토콜(ULP - Upper Layered Protocol)에서 스트널이 발생할 것이고 전송상태 타이머를 가동한다. 그리고 상위 레이어에서는 새로운 연결을 열어서 이전에 보내던 패킷을 다시 보내게 된다. 패킷이 중복되거나 잃어버리지 않는 것을 보장한다. 만약 ULP에서 새로운 연결로 상태정보를 보내지 않거나 상태 타이머가 익스파이어되면 이 연결은 해제되어 버린다. 이 타이머의 ㄱ밧은 설정 가능한 값이다. 추천값은 1 sec 이다.
Broken connection handling
만약 다음과 같은 현상이 발생하면 RUDP 연결이 끊어졌다고 가정한다.
- 재전송 타이머가 익스파이어되고, 최대값을 초과하였을 때
- 서버의 널 세그먼트 타이머가 익스파이어 됬을 때
만약 위의 두경우중 하나가 발생하고 상태 타이머가 0이 아니면, ULP는 연결이 끊어졌음을 인지하고 API를 통하여 시그널을 날린 후에 전송 상태 타이머를 가동한다. 만악 이 타이머가 익스파이어 되면 오토 리셑이 가동된다. 전송 상태 타이머의 값이 0이 되면, ULP는 연결이 실패한 것으로 간주하고 리셑시킨다.
Retransmission Algorithm
재선송은 EACK 세그먼트를 받던가, 혹은 재전송 타이머가 익스파이어되면 수행된다. EACK 세그먼틀 수신하였을 경우 unacknowledged sent queue를 비운다. EACK 세그먼트로 부터 마지막 잘못된 시퀀스 번호와 필요한 ACK 넘버를 추출한다. 그리고 응답하지 않은 큐에 있던 것들을 재전송한다.
Signals to Upper Layer Protocol (ULP)
아래의 시그날들이 API를 통해 ULP로 전송될 수 있다. 이것들은 비동기 적인 이벤트로 ULP에 전달된다.
- 연결 열림 : 전송을 위한 연결이 생성되었음.
- 연결 거부 : 종료 대기상태가 아닌 상태에서 연결이 종료되었을 때
- 연결 종료 : 종료 대기상태에서 종료되었을 때
- 연결 실패 : 재전송 알고리즘에 의해 연결이 끊어진 것으로 판명 되었을 때
- 오토 리셋 : 데이터가 로스되어 새로운 연결을 열었을 때
Checksum Algorithm
16-bit one's complement of the one's complement
FEC
Forward Error Connect(FEC)에 대해 별도로 디파인된건 없다. 알라서 처리하라는 이야기다.
1.4 Feature Negotiation
클라이언트는 협상가능할 파라미터를 포함한 SYN 세그먼트를 전송하여 연결을 초기화 한다.
서버는 어셉트를 하고, 클라이언트가 보낸 파라미터를 그냥 수용하거나 다른 값이 있을 경우는 그 값을 넣어서 SYN에 ACK를 담아서 응답을 보낸다. 클라이언트는 서버가 보낸 파라미터를 선택하고 수락된 연결을 거부 한 후 RST를 날린다. 그리고 필요한 것을 취사선택 한 후 다시 연결을 한다. 오토 리셑의 경우에는 이 과정을 수행할 수 없다.
2.0 Future Potential Enhancements
RUDP는 앞으로 클라이언트/서버의 연결에 시메트릭 모드를 지원할 것이다. 이것은 양쪽 어느곳에서나 연결을 능동적으로 시작할 수 있다.
RUDP는 익스텐드 시퀀스와 엑크널리지 필드를 현재 1 옥텟에서 2 옥텟으로 확장 지원할 것이다. 이것은 전송 윈도우가 현재 255보다 더 커짐을 의미한다.
또한 네트워크를 좀더 효율 적으로 사용할 수 있도록 Nagle Algorithm을 사용할 수 있도록 연구중이다.
3.0 References
[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences Institute,
September 1981.
[2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
Sciences Institute, August 1980.
[3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793,
USC/Information Sciences Institute, September 1981.
[4] Velten, D., Hinden, R. and Sax, J., "Reliable Data Protocol", RFC
908, BBN Communications Corporation, July 1984.
[5] Partridge, C. and Hinden, R., "Version 2 of the Reliable Data
Protocol", RFC 1151, BBN Corporation, April 1990.
[6] Braden, R., "Computing the Internet Checksum", RFC 1071, ISI,
September 1988
[7] V. Jacobson, "Congestion Avoidance and Control," Computer
Communication Review, Val. 18, no. 4, pp. 314-329, Aug. 1988.
[8] W. Stevens, RFC 2001 ?TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms?, January 1997
[9] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", April
30, 1990.
[10] Z. Wang, J. Crowcroft, A Dual-Window Model for Flow and Congestion
Control, The Distributed Computing Engineering Journal, Institute
of Physics/British Computer Society/IEEE, Vol 1, No 3, page 162-172,
May 1994.
[11] Romanow, Allyn, "TCP over ATM: Some Performance Results",
ATM Forum/93-784
4.0 Author's Addresses
Tom Bova Tel: +1-703-484-3331
Cisco Systems Email: tbova@cisco.com
13615 Dulles Technology Drive
Herndon, VA 20171
USA
Ted Krivoruchka Tel: +1-703-484-3325
Cisco Systems Email: tedk@cisco.com
13615 Dulles Technology Drive
Herndon, VA 20171
USA
--------------------------------------------------------------------------------------------
흠.. 첨에 시작할 때는 상당히 심플한 프로토콜로 간주하고 시작했는데.. 직접 다 구현하려면
이것 저것 치댈개 많아 보이네요.. 흠.. IPSec는 아직 다뤄보지 않았는데.. -_-
영어를 헤이트 하다보니 번역이 엉망임다... 혼자 볼려구 만든거지만 서도.. 혹시나 구린데가 있으면
주석 남겨 주세요.. 뱌뱌~