KR20120004961A - 송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법 - Google Patents

송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법 Download PDF

Info

Publication number
KR20120004961A
KR20120004961A KR1020117016718A KR20117016718A KR20120004961A KR 20120004961 A KR20120004961 A KR 20120004961A KR 1020117016718 A KR1020117016718 A KR 1020117016718A KR 20117016718 A KR20117016718 A KR 20117016718A KR 20120004961 A KR20120004961 A KR 20120004961A
Authority
KR
South Korea
Prior art keywords
tcp
network
rtt
data
software
Prior art date
Application number
KR1020117016718A
Other languages
English (en)
Inventor
바딤 스미르노프
Original Assignee
메인라인 넷 홀딩스 리미티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 메인라인 넷 홀딩스 리미티드 filed Critical 메인라인 넷 홀딩스 리미티드
Publication of KR20120004961A publication Critical patent/KR20120004961A/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/127Avoiding congestion; Recovering from congestion by using congestion prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

TCP 송신을 통해 현재 이용가능한 네트워크 경로의 대역폭의 활용을 최대화하는 방법이 개시된다. 본 발명의 실시예는 본 발명을 활용하는 매 특정 연결 및 네트워크 경로에 대해 현재 이용가능한 대역폭(또는 심지어 전체 대역폭)의 큰 부분을 자동으로 검출하고 활용하는 것을 허용한다. 게다가, 본 발명의 일부 실시예는 기법을 구현하는 소프트웨어가 오직 데이터의 송신측에서만 구동될 수 있고, 표준 수신기와 통신할 수 있다는 것을 제공한다. 본 발명의 실시예에 따라, 본 발명을 구현하는 소프트웨어는 TCP/IP 프로토콜 드라이버 및 네트워크 인터페이스 드라이버 사이에 위치할 수 있다. 이러한 중간 소프트웨어는 TCP/IP 드라이버로부터 실제 네트워크 상태를 감출 수 있고, 우선적 스푸프(Spoof) 데이터의 확인 응답 및 패킷 손실 은폐를 통해 TCP 연결 SWND의 엣지(edge)를 이동시킬 수 있다.

Description

송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법{MAXIMIZING BANDWIDTH UTILIZATION IN NETWORKS WITH HIGH LATENCIES AND PACKET DROPS USING TRANSMISSION CONTROL PROTOCOL}
본 출원은 2009년 1월 16일에 출원되고, 명칭이 "MAXIMIZING BANDWIDTH UTILIZATION IN NETWORKS WITH HIGH LATENCIES AND PACKET DROPS USING TRANSMISSION CONTROL PROTOCOL"인 미국 가특허출원 제61/145,505호에 대한 우선권을 주장하고, 이는 본 명세서에서 모든 취지를 위해 그 전체가 참조로 통합된다.
본 발명은 일반적으로 계산 시스템 및 네트워크에 관한 것이고, 더 구체적으로, 데이터 처리량의 악화에 의해 초래되는 네트워크 레이턴시(latency) 및 손실의 회피를 위한 시스템 및 방법에 관한 것이다.
TCP는 가장 널리 사용되는 네트워크 프로토콜 중 하나이다. TCP의 가장 중요한 특징은 신뢰성 있는 순차(ordered) 전달이다. TCP는 신뢰성 있는 데이터 연결을 요구하는 다수의 네트워크 애플리케이션 및 서비스에 의해 사용된다.
전체로서, 오늘날의 WEB 및 네트워킹의 기반을 형성하는 애플리케이션 계층 프로토콜의 폭넓은 세트는 송신 계층 프로토콜로서 TCP를 사용한다. 이들 프로토콜 중에는, HTTP, FTP, 메일 프로토콜, 데이터 베이스 원격 액세스 프로토콜이 존재한다. SSL상에 구축된 VPN 또한 TCP를 사용한다. 기존의 대부분의 컴퓨터 네트워크가 TCP의 특징을 이룰 만큼, 이 TCP는 대중적이고, 널리 퍼져있다. 거의 모두(전체가 아니더라도)가 널리 사용하는 운영체제가 내장(built-in) TCP 구현을 갖는 것은 보편화 되었다.
하지만, TCP의 주요 단점은 TCP가 동작하는 네트워크 채널의 전체 이용가능한 대역폭을 활용하지 못하는 불능(incapability)이다. 이러한 단점은 이미 언급된 TCP의 주요 장점(신뢰성 있는 순차 전달)으로부터 초래된다. 더 정확하게, 슬라이딩 윈도우(sliding window) 및 혼잡 회피 메카니즘과 같이 TCP의 신뢰성을 제공하는 다수의 메카니즘 또한 TCP의 비효율성에 기여한다.
TCP의 신뢰성 있는 전달은 데이터 확인 응답 메카니즘를 기초로 한다, 즉 전송된 각 데이터 부분은 수신시 수신측에 의해 확인 응답 된다. 이러한 목적을 위해, TCP 패킷으로 전송된 각 데이터 부분에는 TCP 세그먼트 헤더(header)에 존재하는 시퀀스 번호가 제공된다. 일단 데이터가 수신되면, 수신기 측은 후방의(backwards) TCP 세그먼트 헤더의 적합한 확인응답 번호를 설정함으로써 데이터의 송신측에 확인응답을 전송한다. 따라서, 들어오는 세그먼트의 확인응답 번호 필드는 네트워크를 빠져나가고, 수신측에 의해 수용된 데이터 바이트의 가장 큰 번호를 나타낸다. 다른 데이터의 부분을 전송하기 전에, 데이터의 매 단일 부분의 확인 응답을 기다리는 것이 너무 오래 걸린다는 것이 명백한데, 이는 슬라이딩 윈도우 메카니즘이 사용되기 때문이다. TCP의 규격은 확인 응답을 기다리는 것 없이, 미리 전송될 수 있는 데이터의 양(바이트 단위)을 나타내기 위한 용어 즉 전송 윈도우 크기(Send Window Size)를 사용한다. 즉, 가장 최근에 전송된 데이터 바이트의 시퀀스 번호와 가장 최근에 수신된 확인 응답 번호 사이의 차는 전송 윈도우 크기 값을 초과하지 않아야 한다. 일단 새로운 확인 응답이 수신되었다면, 윈도우는 이동되고(shifted), 새로운 데이터 부분의 송신이 허용된다.
이러한 슬라이딩 윈도우 메카니즘은 오히려 단순하고, 동시에 신뢰성 있는 전달 및 좋은 처리율의 가능성을 제공한다. 하지만, 명백한 처리량의 상한치가 이 메카니즘에 의해 초래된다: 송신율은 RTT[바이트/초] 값에 의해 나누어진 전송 윈도우 크기로 제한되는데, RTT는 연결 왕복 시간(Round Trip Time)(송신으로부터 가장 최근에 확인 응답된 데이터 바이트의 확인 응답까지의 경과된 시간)이다. RTT(네트워크 경로 레이턴시)가 더 높아질수록, 특정 전송 윈도우 크기에 대해 도달될 수 있는 송신율은 더 낮아진다는 것이 쉽게 관찰될 수 있다.
상기 제한은 사실 너무 심각하여, TCP가 시간이 중대한(critical) 또는 성능이 중대한 송신을 위한 전달로서 거의 사용되지 않는다. 높은 송신율을 요구하지만 신뢰성 있는 전달에 대해 중요하진 않은 VOIP와 같은 이러한 서비스는 대신에 신뢰성이 있진 않지만, 고속인 UDP 송신을 사용하고, 따라서, 다른 유사한 프로토콜/서비스도 그러하다.
TCP의 성능 문제는 네트워크의 대역폭이 더 높이 증가할 때 더 심각해진다. 현재 사용되는 TCP의 전송 윈도우 크기 계산 알고리즘은 종종 100 내지 200ms의 레이턴시를 갖는 광대역 연결의 이용가능한 대역폭의 10% 내지 30% 이상의 활용을 허용하지 못한다.
서술된 제한을 극복하기 위한 다수의 시도가 수행되었다. 이들 시도 모두는 TCP 프로토콜을 조작을 통해 현재 네트워크의 레이턴시를 감소시키는 어떠한 방식도 존재하지 않기 때문에, 전송 윈도우 크기를 증가시키는 것과, 이 전송 윈도우 크기를 높게 유지하는 것을 기본으로 했다.
잘 알려진 TCP 변형인 타호(Tahoe), 레노(Reno), 새로운 레노 및 베가스(Reno and Vegas) 모두는 전송 윈도우 크기 계산 및 송신/재송신 제어의 상이한 방식을 제안하고, TCP 주 단계: 느린(slow) 시작, 혼잡 회피, 고속 재송신 및 고속 회복을 위한 이들 자체의 TCP 행위 알고리즘을 서술한다.
결과적으로, TCP 타호는 느린 시작 및 혼잡 회피 단계를 구동한다. 느린 시작 동안, 혼잡 윈도우 크기는 최대 세그먼트 크기(Maximum Segment Size)로 초기에 설정되고, 도착하는 각 확인 응답시 확인 응답된 데이터 크기에 의해 증가되고, 따라서 지수적으로 증가된다. 혼잡 윈도우 임계치가 도입된다, 혼잡 윈도우 크기가 혼잡 윈도우 임계치에 도달할 때, TCP는 혼잡 윈도우 크기가 선형으로 증가되는 혼잡 회피 단계에 들어간다(도착하는 각 확인 응답시 혼잡 윈도우 크기에 의해 나누어진 확인 응답된 데이터 크기에 의해). 임계치는 초기에 최대 윈도우 크기로 설정된다. 패킷 손실시, 임계치는 혼잡 윈도우 크기의 반으로 설정되고, 느린 시작 알고리즘이 수반된다. 처리량을 상당히 감소시키는 주 TCP 타호의 문제는 늦은 손실 검출(타호는 타임아웃에 의해서만 손실을 검출한다), 그리고 기간적인 느린 시작 대체 시스템(fallback)이다.
TCP 레노는 TCP 타호의 기본 개념을 유지하지만, 이른 패킷 손실 검출을 허용하는 "고속 재송신"이라 불리는 기법이 도입된다. 고속 재송신 기법에 따라, 패킷 손실은 다수의 이중 확인 응답을 통해 원격 수신기에 의해 즉시 나타나야 한다. 즉각적인 패킷의 재송신 이후에, TCP 레노는 느린 시작으로 되돌아가지 않고, 고속 복구를 수행한다. 윈도우 임계치 및 혼잡 윈도우 크기는 초기 혼잡 윈도우 크기의 반으로 설정된다. 그런 후에, 혼잡 윈도우 크기는 매 도착하는 이중 확인 응답마다 MSS만큼 증가되고, 새로운 데이터 송신은 혼잡 윈도우 크기가 현재 확인 응답되지 않은 데이터 크기를 초과하지 않는 경우에 허용된다. 새로운 확인 응답 수신시 완료되는 고속 복구를 수행한 이후에, TCP 레노는 혼잡 회피로 되돌아간다.
TCP의 새로운-레노는 TCP 레노 메카니즘을 물려받지만, 수정된 고속 복구 단계를 구현한다. 고속 복구는 패킷 손실 검출의 순간까지 네트워크에 전송되었던 모든 패킷이 확인응답 될 때까지 종료되지 않는다. 부분적인 확인 응답(손실 검출의 순간까지 송신된 전체 데이터의 양을 커비하지 않는)은 연속적인 손실의 증거로서 처리되고, 더 많은 패킷이 즉시 재송신된다.
TCP 베가는 TCP 레노의 변형이다. TCP 베가는 예측된, 그리고 실제 대역폭의 추정치를 기초로 하는 추가적인 혼잡 회피 메카니즘을 사용하고, 이 메카니즘에 따라 혼잡 윈도우 크기를 조정한다. 또한, 패킷 손실이 예상치 못하게 높은 RTT 검출에 의해 개시된 이중 확인 응답에 의해 나타나기 전에, TCP 베가는 이른 재송신을 수행한다.
본 발명은 이들 기법의 어떠한 것도 따르지 않고, 오히려 상기 변형의 어떠한 것도 할 수 없었던 최적의 대역폭 활용을 달성하는 새로운 기법을 사용한다.
따라서, 종래 기술보다 대역폭 활용 면에서 더 효율적인 기법이 요구된다.
본 발명의 실시예는 2개의 양상: TCP 프로토콜의 변형과, 기존의 OS에 이들 변형을 도입하는 기법을 포함할 수 있다. 이들 양상들은 조합으로 또는 단독으로 사용될 수 있다.
TCP 프로토콜의 변형은 데이터 송신/재송신 동안 새로운 TCP 프로토콜 거동과, TCP의 성능을 향상시키기 위한 전송 윈도우 크기 계산의 새로운 알고리즘을 도입하도록 기존의 TCP 구현을 수정하는 것을 의미한다.
도입 기법은 기존의 컴퓨터 시스템의 호스트 OS의 일부로 이미 제공될 수 있는 기존의 TCP 구현을 제거하거나 디스에이블할 필요 없이, 대신에 원하는 결과를 달성하기 위해 기존의 TCP 구현의 행위를 수정하고, 적합한 방식으로 기존의 TCP 구현으로부터 부분적 데이터 재송신 제어를 다시 취하여, 기존의 컴퓨터 시스템에서 TCP 변형을 구현하는 소프트웨어를 사용하는 것을 의미한다.
본 발명에서 도입된 TCP의 변형은 이용가능한 대역폭 활용을 최대화하는 것을 허용한다. 본 발명의 실시예에 따른 TCP 변형 방식의 장점은 동일한 변형이 송신측 및 수신측의 TCP 구현(일부 실시예에 따라, 변형은 송신측에서 나타나는 것만을 필요로 한다)에서 작동되어야 하는 필요가 없다는 점이다. 이러한 점은 호환성 있는 변형이 연결의 양측 모두에서 작동되게 하는 TCP 변형에서의 이전의 시도 예컨대 SACK, 윈도우 스케일링(Window Scaling) 등으로부터 본 발명의 실시예를 구분한다.
본 발명의 실시예는 TCP 프로토콜의 변형을 도입하는데, 이 변형은 일반적으로 데이터 송신/재송신 알고리즘에 관련되고, 특히 상이한 TCP 실행 시간 단계 동안 전송 윈도우 크기 계산에 관련된다.
상이한 TCP 변형은 변형의 혼잡 회피 기법에 의해 구분된다. TCP 타호, 레노 및 새로운-레노는 이러한 변형이 오직 혼잡이 발생한 경우에만 혼잡을 검출할 수 있는, 소위 "반응형(reactive)' 혼잡 회피를 사용한다. '반응' 혼잡 회피는 전송 윈도우 크기가 패킷 손실이 검출될 때까지 증가되는 것을 가정한다. 패킷 손실이 혼잡의 증거로 여겨지며, 요구된 행위가 특정 변형에 의존하여 취해진다. 이러한 반응은 재송신 또는 고속 재송신을 수행하고, 느린 시작 또는 고속 복구 단계에 들어가는 전송 윈도우 크기 및 전송 윈도우 임계치 조정을 포함할 수 있다.
이러한 '반응' 혼잡 회피의 하나의 단점은 혼잡이 전혀 회피되지 못한다는 사실이다. 채널이 혼잡될 때까지 TCP는 전송 윈도우 크기를 증가시키는 것을 진행하고, 차후의 조처만이 혼잡을 감소시키고, 시간의 일부 기간 동안 패킷 손실을 방지한다. 이러한 방식을 수행함으로써, TCP 구현은 하나의 혼잡으로부터 다른 혼잡으로 진행하고, 이는 송신율을 조금 변하게 하고, 전체 처리량을 충분히 감소시킨다.
TCP 베가스는 '사전 행동의(proactive)' 혼잡 회피라 불리는 상이한 메카니즘을 사용한다. TCP 베가스의 아이디어는 혼잡이 실제로 발생하기 전에 혼잡을 회피하는 것이다. TCP 베가스는 전송 윈도우의 크기를 조정하고, 재송신 결정을 하기 위한 상이한 추정치를 사용한다. 이들 추정은 예측된, 그리고 실제 처리량의 차의 값과, 기본 및 현재 RTT 값의 차를 기초로 한다. 이들 수단은 대부분의 혼잡을 회피하는 것, 송신율을 평활화하는 것, 그리고 대역폭 사용을 최적화하는 것을 실제로 허용한다.
모든 TCP 변형은 연결 단계 각각에 대해 유사한 전송 윈도우 크기 계산 알고리즘을 사용한다. 공통으로 사용되는 2개의 추정치: 수신 윈도우 크기 및 혼잡 윈도우 크기가 존재한다. 그리고 전송 윈도우 크기는 이들의 최소값으로 설정된다.
느린 시작 단계 동안, 혼잡 윈도우 크기는 최대 세그먼트 크기로 처음에 설정되고, 후에 지수적으로 증가된다. 수신된 새로운 확인 응답마다, 혼잡 윈도우는 원격 측에 의해 확인 응답된 데이터 바이트의 수만큼 증가된다. 이러한 지수적 증가는, 혼잡 윈도우 크기가 전송 크기 임계치에 도달할 때까지 수행되고, 이후에 혼잡 회피 단계에 들어간다.
혼잡 회피 단계는 혼잡 윈도우 크기가 선형적으로 증가되는 것을 가정한다. 도착한 매 새로운 확인 응답마다, 혼잡 윈도우 크기는 혼잡 윈도우 크기로 나누어진 확인 응답된 바이트의 수만큼 증가된다.
본 발명의 실시예는 다른 TCP 변형이 두드러지게 하는 것과 같이, 느린 시작과 혼잡 회피 단계 사이를 명확하게 구분할 필요가 없다; 대신에 본 발명의 실시예는 새로운 '혼잡 회피를 이용한 송신' 단계를 사용할 수 있다. 혼잡 회피 단계를 이용한 송신 동안, 본 발명의 실시예는 전송 윈도우 크기를 지수적으로 또는 선형적으로 증가시킬 수 있거나, 현재 RTT 값에 의존하여 전송 윈도우 크기를 감소시킬 수 있다. 또한, 본 발명의 실시예가 손실된 패킷을 재송신할 때, 본 발명의 실시예는 '재송신' 단계 동안 상이한 규칙을 사용할 수 있다. 다음의: 특정 패킷에 대한 재송신 타임 아웃이 만료되는 것, 특정 패킷에 대한 제 3 이중 확인 응답이 도착하는 것, 또는 차후의 패킷이 선택 확인 응답 간격 내에 있는 동안, 패킷이 수신기에 의해 표시된 선택 확인 응답 간격 밖에 있는 것 중 하나가 발생할 때 패킷 손실이 발생 되었다고 여겨진다.
본 발명의 실시예는 다음과 같이 전송 윈도우 크기 조정 결정의 기초를 형성할 수 있다. 네트워크 경로의 레이턴시는 중간 라우터 '큐'의 채워짐(fullness)에 의존한다. 일단 큐가 비어 있으면, 모든 패킷은 즉시 라우터에 의해 전달되며, 라우터의 큐에서 서비스를 대기하는 패킷에 의해 초래되는 어떠한 추가적인 레이턴시도 나타나지 않게 된다. 이러한 사실은 네트워크 경로가 혼잡되지 않고, 라우터가 현재 속도에서의 송신을 극복하는 지를 식별한다. 이러한 경우 패킷과 패킷의 확인 응답은 가능한 가장 짧은 시간에 네트워크 통로를 통과할 수 있다. 일단 라우터의 큐가 패킷으로 채워지기 시작하면, 네트워크 레이턴시는 패킷이 횡단하는 각 라우터에서 작은 증분치를 얻으면서, 커지기 시작한다. 이러한 사실은 본 발명의 일부 실시예가 암시적으로 네트워크 경로의 라우터 '큐'의 채워짐을 추적하는 것과, 전송 윈도우 크기 조정 결정을 하기 위해 결과적으로 네트워크 경로가 혼잡한지를 추정하는 것을 허용한다.
심지어 네트워크 경로가 초기에 부분적으로 혼잡되더라도, 전송 윈도우 크기의 조정(그러므로, 추가적인 패킷의 삽입) 이후에 계산된 RTT와, 최소 RTT 사이의 차는 네트워크 상태 변화의 증거이다. 그리고, 차의 크기는 전송 윈도우 크기의 조정을 결정하는데 사용된다. 이러한 기법은 '레이턴시 기반 윈도우 조정'이라 불린다. 또한, 이 기법은 전송 윈도우 조정의 순간 및 크기의 더 정확한 결정을 하는데 도움이 되는 RTT의 변화량과 RTT의 변화 속도와 같은 파라미터를 고려한다.
본 발명의 일부 실시예는 전송 윈도우 조정 처리를 수행하기 위해 다음의 파라미터를 사용할 수 있다.
1. RTT - 왕복 시간 또는 왕복 지연 시간, 패킷의 송신과, 패킷의 확인 응답의 수신 사이에 경과된 시간.
2. MIN_RTT - 연결 동작의 사전 한정된 기간 동안 통보된 최소 RTT(MIN_RTT 의 유효 시간은 아래에 서술된다).
3. NEW_RTT - 가장 최근에 확인 응답된 세그먼트의 RTT.
4. S_RTT - 평활화된 RTT 추정치, S_RTT = (S_RTT*(RTT_SW - 1) + NEW_RTT)/RTT_SW, 여기에서 RTT_SW는 RTT가 평활하게된 윈도우의 크기이고, 따라서 S_RTT는 가장 최근의 RTT_SW 확인 응답에 대해 측정된 NEW_RTT 값의 일종의 평균이다. S_RTT는 사실 원래 TCP의 평활화된 RTT 추정치와 유사하다.
5. RTT_AVAR - 각 확인 응답시 측정되고, 확인 응답의 VAR_SW 개수에 대해 평활화된 RTT의 절대적인 변화량이고, 여기에서 VAR_SW는 변화량이 평활화되는 윈도우 크기이다. RTT_AVAR = (RTT_AVAR*(VAR_SW - 1) + NEW_AVAR)/VAR_SW인데, 여기에서 NEW_AVAR은 최근에 측정된 절대적인 변화량이고, NEW AVAR = NEW_RTT - S_RTT이다.
6. RTT_RVAR - RTT의 상대적인 변화량, RTT_RVAR = RTT_AVAR/S_RTT이다.
7. RTT_AGRW - 각 확인 응답시 측정되고, 확인 응답의 GRW_SW 개수에 대해 평활화되는 RTT의 절대적인 증가량(growth)인데, 여기에서 GRW_SW는 증가 평활 윈도우 크기이다. RTT_AGRW = (RTT_AGRW*(GRW_SW - 1) + NEW_AGRW)/GRW_SW이고, 여기에서 NEW_AGRW는 최근에 측정된 절대 증가량이고, NEW_AGRW = 새로운 S_RTT - 이전의 S_RTT이다.
8. RTT_RGRW - RTT의 상대적인 증가량, RTT_RGRW = RTT_AGRW/S_RTT이다.
9. RTO - 재송신 타임아웃, RTO = S_RTT*tot인데, 여기에서 tot는 타임아웃 임계치이다.
10. ACK_DS - 확인 응답된 데이터의 크기, 가장 최근에 수신된 확인 응답 번호에 의해 확인 응답된 바이트의 수.
11. MAX_RWND - 최대 수신 윈도우 크기, 항상 수신측에 의해 통보됨.
12. NEW_RWND - 최근에 통보된 원격 수신기의 윈도우 크기.
13. SWND - 전송 윈도우의 크기, 확인 응답 없이 전송되도록 허용되는 바이트의 개수.
14. AWND - 실제 윈도우의 크기, 이미 전송되었지만, 아직 확인 응답 되지 않은 바이트의 개수.
15. SWND_GRW - 매 SWND 증가마다 측정되고, 평활화된 전송 윈도우 크기의 증가량. 이 값은 가장 최근의 MIN_RTT 기간 동안에 평활화된 SWND의 증가량이다. SWND_GRW는 SWND가 동일한 값의 SWND만큼 증가될 때마다 증가되고, 이후 즉시 다음의 수식: SWND_GRW = SWND_GRW - SWND_GRW*(dt/MIN_RTT)에 따라, 이후에 평활화되는데, 여기에서 dt는 가장 최근의 평활화로부터 경과된 시간 간격이다. SWND_GRW는 0보다 작지 않아야 한다.
16. EIRT - 지수적 증가 RTT 임계치, NEW_RTT가 SWND에 대한 MIN_RTT를 초과하지 않아야 하는 시간 값(MIN_RTT의 일부)으로서, 지수적으로 증가될 수 있다.
17. EIGT - 지수적인 증가량의 임계치, RTT_RGRW/RTT_RVAR(또는 RTT_AGRW/RTT_AVAR)이 SWND에 대해 초과하지 않아야 하는 값으로서, 지수적으로 증가될 수 있다.
18. EIID - 지수적으로 증가하는 증분치의 제수, 지수적 증가 동안 SWND의 증분치를 나누는 값.
19. LIRT - 선형 증가 RTT 임계치, NEW_RTT가 SWND에 대한 MIN_RTT를 초과하지 않아야 하는 시간 값(MIN_RTT의 일부)으로서, 지수적으로 증가될 수 있다.
20. LIGT - 선형 증가량 임계치, RTT_RGRW/RTT_RVAR가 이 값을 초과하지 않는다면, SWND는 선형적으로 증가될 수 있다.
21. LIID - 선형 증가 증분 제수. 선형 증가 동안 SWND 증분치를 나누는 값.
22. CART - 혼잡 회피 RTT 임계치(이 시간 값은 MIN_RTT의 일부에서 측정된다); NEW_RTT가 CART만큼 MIN_RTT를 초과한다면, SWND는 혼잡을 피하기 위해 감소된다.
23. CAGT - 혼잡 회피 증가량의 임계치. RTT_RGRW/RTT_RVAR가 이 값을 초과한다면, SWND는 혼잡을 피하기 위해 감소된다.
24. CAWT - 혼잡 회피 윈도우 증가량의 임계치. SWND_GRW가 CAWT를 초과한다면, SWND는 선형적으로 감소되고, 그렇지 않다면 SWND는 비례하여 감소된다.
25. OAWT - 오버플로우 회피 윈도우 임계치. RWND가 이 값 이하로 내려간다면, 송신은 RWND가 다시 충분히 높다고 통보될때 까지, 정지된다.
26. CCRT - 특징 변화 RTT 임계치. SRTT가 이 임계치를 초과할 때, 네트워크 상태는 상당히 변화될 것이라 예측되고, MIN_RTT와 같은 필수 연결 파라미터는 리셋되고, 다시 공급된다.
27. CADD - 혼잡 회피 감소 제수, 혼잡 회피 감소 동안 SWND 감소량을 나누는 값.
28. PDDD - 비례적인 감소량 제수, 혼잡 회피 또는 패킷 손실 시 비례적인 감소 동안 SWND 감소량을 나누는 값.
일부 실시예에 따라, 혼잡 회피 단계를 이용한 송신은 연결 동작의 초기에 개시된다. 처음에 전송 윈도우의 크기는 m*MSS로 설정되는데, 'm'은 세그먼트에서의 최소 윈도우 크기이고, 'MSS'는 이러한 특정 연결에 대한 최대 세그먼트 크기이다. 그런 후에, 전송 윈도우의 크기는 매 들어오는 비-이중 확인 응답 동안 조정된다. SWND 조정 결정은 RTT 값과, 위에 언급된 채널 상태를 나타내는 RTT 증가량의 크기에 따라 수행된다. 일부 실시예에서, 사용 가능(free), 사용중, 거의 혼잡, 혼잡인, 4개의 채널 상태가 존재한다. '사용 가능', '사용중' 및 '거의 혼잡'의 채널 상태는 각각 낮은, 중간 및 높은 RTT 값(MIN_RTT에 관련된)으로 나타난다. '혼잡' 상태는 높은 RTT 값과 함께 패킷 손실로 나타난다. SWND는 네트워크가 '사용 가능' 상태가 되도록 결정되는 동안 지수적으로 증가되고, RTT가 더 높아지고, 네트워크가 '사용중'이 될 때, SWND는 선형적으로 증가된다. 높은 RTT는 다가오는 혼잡의 증거가 될 것이고, RTT는 주로 라우터의 큐가 거의 채워졌을 때, 그리고 실제로 특정 연결이 너무 높은 속도로 송신하는지, 또는 일부 다른 연결이 동일한 병목현상의 대역폭의 일부를 요청하는 지에 따라 어떠한 차이도 존재하지 않을 때, 주로 증가한다. 따라서, 네트워크 상태가 '거의 혼잡'인 것으로 검출될 때, SWND는 가능한 혼잡을 회피하기 위해 감소된다. 패킷 손실이 이미 발생하고, 네트워크 상태가 '혼잡'이 되었을 때의 경우는 '혼잡 회피를 이용한 송신' 단계로 다루어지지 않고, 이는 뒤에 서술된다.
RTT 증가 속도에 관련된 추가적인 조건은 SWND 조정의 순간을 결정하는데 적용된다. RTT는 주로 바로 증가하진 않고, 네트워크가 혼잡인 동안 지속적으로 증가한다. 네트워크가 안정적인 상태일 때, RTT는 주로 거의 S_RTT 주위에서 진동하고, 따라서, RTT의 증가량은 0 주위에서 진동한다. 하지만, RTT 증가량이 주목할 만해지는 것은 RTT가 증가를 거의 지속할 것이란 것을 의미한다. 이는 본 발명의 실시예가 미리 SWND 조정 결정을 수행하는 것을 허용한다. 더 작은 RTT의 증가량은 '거의 혼잡' 상태로 다가가는 네트워크뿐만이 아니라, 일부 네트워크의 불안정 상태에 의해 야기될 수 있다. 이러한 경우에서, 본 발명의 실시예는 상황이 안정화될 때까지의 잠시 동안 SWND를 증가시키는 것을 멈출 수 있다. 하지만, RTT 증가가 충분히 빠를 때, 이러한 특정 또는 일부 다른 연결이 네트워크를 혼잡시키는 것을 시작하고, (NEW_RTT - MIN_RTT)의 차가 SWND를 감소시키는 것을 개시하는 임계치를 초과할 때까지 기다릴 어떠한 이유도 존재하지 않는 것으로 보인다. 대신에, 본 발명의 실시예는 RTT 증가의 속도를 기초로 SWND를 감소시키는 것을 개시할 수 있다. 이러한 기법은 본 발명의 실시예가 RTT 차 기법보다, 일부 수개의 패킷이 일찍 다가오는 혼잡을 검출하는 것을 허용한다. 이는 중요할 수 있는데, 그 이유는 이들 패킷이 종종 가능한 혼잡 동안 손실될 수 있는 패킷이기 때문이다.
또한, SWND의 증가는 RTT 증가량이 0 이하로 너무 낮아질 때 정지된다. 이러한 마이너스의 증가 값은 송신을 종료하고 일부 연결 또는, 혼잡 이후의 채널 정화(purge)에 의해 초래되는 네트워크의 불안정 상태를 나타내고, SWND는 이들 경우에서 상황이 안정될 때까지 작은 RTT에 대해 증가되지 않아야 한다. SWND가 불안정 상태 동안 증가되었다면, SWND는 특정 네트워크 경로에 대해 가능한 실제 최대값을 초과할 수 있다. 하지만, SWND는 마이너스 RTT 증가 값에 대해 감소하지 않는데, 이는 증가 값이 다가오는 혼잡을 나타내지 않기 때문이다.
상이한 네트워크와 네트워크 경로가 상이한 RTT 변화 크기에 의해 구분되기 때문에, 높은 RTT 변화(또는 발진)이 지속되는 RTT 증가에 대해 혼동될 때, RTT 증가량은 대부분의 SWND 조정의 잘못된 결정의 대부분을 회피하도록 허용하는 RTT 변화에 의한 나눗셈에 의해 조정된다.
전송 윈도우의 크기는 NEW_RTT <= MIN_RTT*(1 + EIRT) 및 |RTT_RGRW/RTT RVAR| <= EIGT이라면 지수적으로 증가한다. 이러한 조건은 RTT가 충분히 낮은 경우, 네트워크가 '사용 가능' 상태이고, SWND가 최대 대역폭 활용을 신속히 달성하기 위해 신속하게 증가하도록 허용되는 결정으로부터 초래된다. 지수적 증분치는 일반적으로 일정한 값이 아니고, NEW_RTT에 의존하며, MIN_RTT*(1 + EIRT)에 인접할수록, 증분치는 작아지게 된다. 지수적인 증분치는 다음의 수식: ACK_DS*{[1 - (NEW_RTT - MIN_RTT)/ (MIN_RTT*EIRT)]*(1 - 1/EIID) + 1/EIID}에 따라 계산된다. 즉, 지수적인 증분치는 ACK_DS(NEW_RTT = MIN_RTT일 때)와 ACK DS/EIID(NEW_RTT = MIN_RTT*(1 + EIRT)일 때)값들 사이에 있다. 이는 RTT의 차가 임계치에 다다르는 동안, 지수적인 SWND의 증가량을 점진적으로 감소시키는 것을 허용한다.
MIN_RTT*(1 + EIRT) < NEW_RTT <= MIN_RTT*(1 + LIRT) 그리고 EIGT < |RTT_RGRW/RTT_RVAR| <= LIGT일 때, 전송 윈도우의 크기는 선형적으로 증가된다. 이는, 이들 조건 하에, RTT가 여전히 충분히 낮지만, 네트워크가 이미 어느 정도 사용되고, 그러므로 SWND가 더 정확한 방식으로 증가되어야 한다고 여겨지기에, 완료된다. 또한, 선형적인 증분치는 일정한 값이 아니고, NEW_RTT에 의존한다. 선형 증분치에 대한 수식은 (ACK_DS/SWND)*{[(1 + LIRT)/(LIRT - EIRT) - (NEW_RTT - MIN_RTT)/(MIN_RTT*(LIRT - EIRT))] *(1/LIID)}이다. 즉, 선형 증분치는 ACK_DS/LIID(NEW_RTT = MIN_RTT*(1 + EIRT) + l/∞ 일 때)와 0(NEW_RTT = MIN_RTT*(1 + LIRT)일 때)사이에 있다.
네트워크를 의미하는 NEW_RTT > MIN_RTT*(1 + CART) 또는 |RTT_RGRW/RTT_RVAR| > CAGT가 거의 혼잡되고, 송신율이 변경될 때 전송 윈도우의 크기는 감소된다. SWND는 SWND_GRW/CADD 만큼 감소되고, 즉 SWND는 거의 RTT ms 전의 값만큼 감소되는데, 이는 연속적인 SWND(그러므로 AWND)의 증가가 네트워크 상태를 악화시킬 때의 시간으로 가정되기 때문이다. 그 시스템이 현재 RTT와 동일한 시간이 경과할 때까지, 시스템의 조처가 임의의 결과를 도출할지를 통보할 수 없기 때문에, SWND는 MIN_RTT 당 한번보다 더 자주 감소되도록 허용되지 않는다.
NEW_RTT > MIN_RTT*(1 + CART) 또는 |RTT_RGRW/RTT_RVAR| > CAGT 지만, SWND_GRW < CAWT라면, 현재 연결이 일정하게 안정화된 속도로 송신하기 때문에, 네트워크는 다른 연결에 의해 혼잡되게 된다, 그러므로, SWND는 새롭게 나타난 조건에 따라 조정되어야 한다. 이용가능한 대역폭의 추정은 잘 알려진 수식 SWND/RTT에 따라 이루어지고, RTT가 변하기에, SWND 역시 동일한 속도로 변할 수 있다. 따라서, SWND = SWND*(MIN_RTT/NEW_RTT)이다. 그리고, 위에 논의된 이유를 위해, SWND는 MIN_RTT 당 한번보다 더 자주 감소되지 않아야 한다.
상기 2가지 SWND 감소 기법은 일시적인 네트워크의 불안정 상태, 특정 연결의 과도한 송신율, 또는 잠시 동안 이용가능한 대역폭을 부분적으로 점유하는 때때로의 작은 송신에 의해 초래된 혼잡을 회피하는 것을 허용한다. 하지만, 큰 송신은 매우 긴 시간의 기간 동안, 이용가능한 대역폭 및 다른 네트워크 특징을 변경하고, 이러한 사실은 실제적으로 현재 연결이 더 이상 이전에 사용된 네트워크에서 동작하지 않고, 연결의 실행시간의 변수 및 추정치 또한 변경되어야 한다는 것을 의미한다. 모든 실행시간의 파라미터의 계산은 항상 통보되는 최소 RTT이고, 기본 네트워크 경로의 특징 중 하나인 MIN_RTT 값을 기초로 한다. 하지만, 네트워크 상태가 충분히 변하였다면, 이러한 특징은 더 이상 유효하지 않다고 여겨질 수 있다. S_RTT로 도달되면, MIN_RTT*(1 + CCRT) 값은 MIN_RTT의 리셋을 트리거(trigger)할 수 있는 충분한 네트워크 상태의 변화를 식별한다. 이러한 경우, MIN_RTT는 S_RTT*f로 리셋될 수 있는데, 여기에서 'f'는 최소 RTT 조정 요소이다. 따라서, MIN_RTT의 유효기간은 충분한 S_RTT 증가에 의해 식별되는 주목할만한 네트워크 상태 변화 사이의 기간으로서 결정될 수 있다.
'혼잡 회피를 이용한 송신' 단계에서 시스템을 정하는 주 송신 조건은 AWND < SWND 이다; 하지만, 하나의 추가 제한 사항이 원격 수신기의 버퍼 오버플로우를 회피하기 위해 적용될 수 있다. 원래의 TCP 프로토콜은 SWND를 CWND와 RWND 중의 최소값으로 설정한다. 본 발명의 실시예는 직접 RWND 추정치를 사용하지 않는데, 이는 본 발명의 실시예가 심지어 인에이블된 윈도우 스케일링 옵션을 이용한 SWND에서의 오히려 엄격한 제한을 적용하기 때문이다. RWND는 이러한 제한이 초과 된다면, 원래의 TCP 구현이 더 이상의 데이터를 전송하지 않는 순간에, 원격 수신기가 잠시 수락할 준비가 된 바이트의 수를 나타낸다. 하지만, 본 발명의 실시예는 자신의 SWND가 과도하게 증가하도록 하고, 더 빠른 송신율을 허용하기 위해 이러한 제한을 무시할 수 있다. 상기 실시예 중 일부가 NEW_RWND < MAX_RWND*OAWT 일때, 심지어 AWND < SWND의 조건이 충족된다 할지라도, 추가의 데이터를 송신하지 않으므로, 여전히 RWND는 본 발명의 실시예에 대해 유용한 상태로 남아 있다. 이는 원격 수신기의 버퍼가 오버플로우 되지 않았다는 것을 보장할 수 있다. 통보된 RWND가 너무 낮게 떨어졌다면, 이 RWND는 원격 수신기의 버퍼 내에 잘못 정렬된 다수의 패킷이 존재하는지, 재정렬이 그 순간에 수행되거나, 또는 원격 수신기는 현재 송신율로 패킷을 수락할 수 없는 지를 식별한다. 이들 조건 모두는 송신율이 즉시 감소되지 않는다면 버퍼의 오버플로우와 다량의 패킷 드랍을 초래한다. 이들 이유에 대해, 본 발명의 실시예는 충분히 큰 RWND가 다시 통보될 때까지 송신을 정지시키기 위해 제공된다.
본 발명의 일부 실시예에 따라, 제 2 실행시간 단계가 사용될 수 있는데, 이 단계는 '재송신' 단계이다. 재송신 단계 동안, 손실된 것으로 이전에 검출된 패킷이 재송신되고, 모든 조건이 충족하는 지에 관계없이 어떠한 정상 송신도 허용되지 않는다. 위에 언급된 바와 같이, 패킷 손실은 다음: 특정 세그먼트에 대한 RTO가 만료되었는지, 특정 세그먼트에 대한 제 3 이중 확인 응답이 도착하였는지, 또는 이후의 패킷이 선택적인 확인 응답 범위 내에 있는 동안, 패킷이 수신기에 의해 나타난 선택 확인 응답 범위의 밖에 있는 것 중 하나로 식별된다.
RTO 값은 각 RTT 측정에 대해 다음의 수식: RTO = S_RTT*a + RTT_AVAR*b에 따라 계산된다. RTO 기간이 정규 검사 동안 특정 패킷의 전송 시간으로부터 경과된 것으로 발견된다면, 패킷이 손실되었다고 여겨지고, 시스템은 '재송신' 모드로 들어가며, 패킷이 재송신된다. RTO의 만료는 주로 혼잡 또는 일부 다른 심각한 네트워크(또는 원격 수신기)의 문제에 기인한 다량의 패킷 손실을 나타내는데, 이는 우연한 손실 또는, 작은 혼잡에 의해 초래된 손실이 제 3 이중 확인 응답 또는 SACK에 의해 매우 일찍 발견되기 때문이다. 일단 시스템이 RTO의 만료시 '재송신' 모드로 들어가면, SWND는 SWND = SWND*(MIN_RTT/RTO)로 조정되고, SWND의 감소는 다음의 MIN_RTT 기간 동안 그리고, 과도한 SWND 감소율을 회피하기 위해 '재송신' 단계가 종료될 때까지 더 이상 허용되지 않는다.
또한, 패킷 손실은 특정 패킷이 이후의 패킷이 수신되었지만, 특정 패킷이 수신되지 않았다고 보고된 특정 패킷에 대해 제 3 이중 확인 응답, 또는 SACK 옵션에 의해 식별될 수 있다. 이러한 이벤트는 '재송신' 단계에 익스트림(Extreme) TCP를 집어 넣어서, 손실된 패킷의 재송신을 초래한다. 하지만, 이러한 패킷 손실의 지시는 주로 네트워크가 그 순간에 약하게 혼잡되거나 손실이 우발적이고, 따라서 더 낮은 SWND의 감소량이 사용될 수 있다. 따라서, SWND는 SWND = SWND*(MIN_RTT/L_RTT)로 조정될 수 있는데, 여기에서 L_RTT는 손실된 패킷이 보내진 순간으로부터 패킷의 손실이 나타난 순간까지의 측정된 왕복 시간인 '패킷 손실 RTT'이다. 전송된다. 그러면, SWND는 다음의 MIN_RTT 기간 동안, 그리고 '재송신' 단계가 만료될 때까지 감소되는 것이 허용되지 않는다.
손실된 패킷의 확인 응답 바로 직후에, 시스템은 '재송신' 단계를 중지하고, '혼잡 회피를 이용한 송신' 단계에 다시 들어간다. 하지만, 패킷 손실은 손실된 패킷이 가정된 이후, 다수의 패킷이 원격측에 의해 어떻게 수신되었는지에 의존하는 '재송신' 종료 시 이후의 다량의 확인 응답을 종종 초래한다. 심지어 '손실 시' SWND 조정 이후, AWND가 다량의 확인 응답에 기인하여, '재송신' 단계의 종료시 SWND 보다 매우 더 적게 나타나는 것은 흔한 상황이다. 이러한 상황은 과도한 속도로 매우 다량의 데이터의 대부분의 즉시 전송을 초래하는데, 이는 심지어 더 극적인 네트워크 혼잡을 초래한다. 추가의 SWND 조정은 이를 회피하기 위해 '재송신' 단계의 종료시 수행될 수 있다. '재송신' 단계의 종료시 SWND > AWND + MSS*m 라면, SWND는 AWND + MSS*m로 설정되는데, 여기에서 MSS는 연결을 위한 최대 세그먼트 크기이고, 'm'은 최소 윈도우 크기(MSS에서)이다.
본 발명의 실시예는 TCP 송신 및 재송신 메카니즘에만 결합될 수 있다. 실시예는 TCP 연결 구축/폐쇄/리셋 기법의 어떤 것에도 간섭되지 않아야 한다. 게다가, 본 발명의 실시예는 TCP의 위에서 사용되는 상위 프로토콜 또는, 송신되는 데이터를 인지할 필요가 없다. 실시예는 TCP를 걸쳐 송신된 데이터를 가공하지 않은 8중(octet) 스트림으로 다룰 수 있고, 상위 레벨의 콘텐츠/동작에 간섭되고, 이 스트림을 제 3 파티로 수정, 복사 또는 통과시키는 어떠한 시도도 하지 않는다. 따라서, 본 발명의 실시예에 따른 TCP 송신/재송신 메카니즘의 수정은 TCP의 신뢰성 있는 순차 전달 특징을 혼란스럽게 하거나 TCP의 적합성을 약화시키지 않는다.
본 발명은 TCP의 장점을 그대로 유지하면서, 네트워크에서의 대역폭 활용을 최대화하는 방법을 제공한다.
도 1은 내장 TCP 프로토콜 지원 및 통신 데이터 흐름을 갖는 OS를 구동하는 컴퓨터 시스템에 대한 본 발명의 실시예의 도입의 기법을 도시하는 도면.
도 2는 처리 서브시스템 아키텍처 및 동작을 도시하는 도면.
도 3은 도 3은 패킷 결합 알고리즘을 도시하는 도면.
도 4는 연결 엔티티 생성 알고리즘을 도시하는 도면.
도 5는 도 5는 빠져나가는 패킷 처리 알고리즘을 도시하는 도면.
도 6은 들어오는 패킷의 처리 알고리즘을 도시하는 도면.
도 7은 송신 알고리즘을 도시하는 도면.
도 8은 타임아웃 검사 및 PLC 알고리즘을 이용한 재송신을 도시하는 도면.
도 9는 익스트림 TCP SWND 조정 알고리즘을 도시하는 도면.
도 10은 전형적인 계산 시스템을 도시하는 도면.
주로 사용되는 대다수의 운영체제는 이미 TCP 구현을 갖는다. OS에 내장된 TCP 구현의 대체물은 오히려 더 복잡할 수 있다. 그러므로, 본 발명의 일부 실시예는 기존의 TCP 구현을 완전히 대체하지 않고, 내장 TCP 구현을 갖는 운영체제에 대해 위에 논의된 통상적인 TCP 구현의 변형을 도입하는 기법의 특징을 이룬다. 이러한 기법은 가장 널리 사용되는 OS에 유연하고 호환성 있게 개발된다. 일부 실시예 중 하나의 특징은 기존의 내장 TCP 구현 자체를 대체하는 것 대신에, 일부 실시예가 TCP의 행위를 수정할 수 있고, 위에 논의된 TCP 변형에 따라, TCP의 행위를 제공하기 위해 원래의 구현으로부터 송신/재송신 제어를 부분적으로 다시 취할 수 있다는 것이다.
네트워킹을 할 수 있는 현재 모든 OS는, ISO의 OSI 개념의 일부 변형을 구현하는데, 이러한 개념에 따라 네트워크 프로토콜이 서브 시스템의 스택으로서 구현되고 이 서브시스템 각각은 대응하는 OSI 계층(또는 이웃 계층의 세트)에 서비스를 제공한다. 본 발명의 실시예는 네트워크 및 물리 계층 사이의 계층에서 패킷을 차단하고/생성하는 능력이 적절하게 동작하도록 요구한다. 기존의 OS는 주로 이러한 성능을 제공한다. 따라서, 본 발명의 실시예는 네트워킹과 물리 계층 구현 사이의 어딘가에 위치한 소프트웨어에 의해 구현될 수 있고, 로컬 전송기에 대한 원격 수신기, 그리고 원격 수신기에 대한 전송기로 보이는 추가적인 중간 서브시스템이 될 수 있다.
본 발명의 실시예를 구현하는 소프트웨어는 패킷 캡처링(Capturing) 연결 처리 서브시스템으로 구성될 수 있다.
패킷 캡처링 서브시스템은 패킷 차단 및 생성의 성능을 제공한다. 이러한 서브시스템은 소프트웨어의 외부 통신 인터페이스이고, 로컬 TCP 구현의 휴지상태(rest)를 이용한, 그리고 원격 수신기를 이용한 패킷의 교환을 허용할 수 있다.
연결 처리 서브시스템은 위에 서술된 TCP 흐름 제어의 변형을 구현하는 서브시스템이다.
패킷 캡처링 서브시스템은 외부 서브시스템이고, 본 발명의 실시예를 위해 구체적으로 설계된 소프트웨어 뿐만이 아니라, 제 3 당사자의 패킷 캡처링 소프트웨어에 의해 나타날 수 있다. 본 발명의 실시예는 패킷 캡처링 서브시스템으로서 임의의 패킷 캡처링 소프트웨어를 통한 사용을 줄일 수 있는데, 이러한 소프트웨어가 데이터 링크 또는 네트워크 계층에서 적어도 패킷을 캡처(차단) 및 송신하는 것을 허용하는 최소 API를 제공하는 경우에, 줄일 수 있다.
연결 처리 서브시스템은 TCP 변형 자체를 구현한다. 연결 처리 서브시스템은 다수의 서브시스템: 입력 서브시스템, 필터링 서브시스템, 처리 서브시스템, 출력 서브시스템을 차례로 포함한다.
입력 및 출력 서브시스템은 연결 처리 서브시스템 데이터 인터페이스를 형성한다. 입력 서브시스템은 패킷 캡처링 서브시스템으로부터 패킷을 수신하는 것을 담당하고, 이 패킷을 필터링 서브시스템을 통해, 처리 서브시스템에 전달하는 것을 담당한다. 출력 서브시스템은 처리 서브시스템으로부터 패킷을 수신하는 것을 담당하고, 이 패킷을 패킷 캡처링 서브시스템에 전달하는 것을 담당한다.
필터링 서브시스템은 입력에서 출력으로 패킷을 전달하는 것을 허용하여, 처리 서브시스템의 개입을 투명하게 회피한다. 패킷은 원하는 연결에만 TCP 변형을 적용하는 것을 허용하는 사전 한정된, 그리고 사용자의 한정 기준에 따라 필터링될 수 있고, 남아있는 연결의 행위는 변경되지 않게 한다. 이용가능한 패킷 캡처링 서브시스템이 일부 필터링 성능을 제공할 수 있다면, 이러한 패킷 캡처링 서브시스템은 필터링 서브시스템의 적어도 일부를 구현하는데 사용될 수 있다. 패킷 캡처링 서브시스템에서의 이른 패킷 필터링은 불필요한 시간 소모적인 횡단-서브시스템의 데이터의 송신을 회피할 수 있고, 따라서, 전반적인 성능을 증가시킬 수 있다.
처리 서브시스템은 위에 논의된 TCP 변형을 수행한다. 처리 시스템은 현재 처리된 연결의 상태를 추적하고, 데이터 송신/재송신을 수행한다. 각 연결은 신원, 데이터 및 변수에 의해 나타날 수 있는 TCP 연결 엔티티와 결합될 수 있다. 연결의 신원은 다른 연결로부터 특정 연결을 명백히 구별하는 것과, 추가의 처리를 위해 특정 연결의 신원에 캡처링된 패킷을 결합시는 것을 허용하는 네트워크 주소의 세트이다. 연결 데이터의 저장소는 전송될 준비가 되어있는 패킷 및, 전송되었고, 각각 확인 응답을 대기하는 패킷을 포함하는 송신 및 재송신 버퍼에 의해 나타난다. 연결 엔티티는 SWND, AWND, RTT, 변동 등과 같은 네트워크 및 연결 자체의 현재 상태를 반영하는 실행 시간 변수의 폭넓은 세트를 갖는다.
원래 내장 TCP 행위를 수정하기 위해 본 발명의 일부 실시예가 사용하는 2개의 메인 기법은 우선적 스푸프(Spoof)의 데이터 확인 응답과, 패킷 손실 은폐이다.
원래의 내장 TCP 구현은 SWND/RTT 보다 더 높은 속도로 송신할 수 없고, 원래의 SWND는 주로 원하는 송신율을 달성하기에 충분히 높지 않다. 본 발명의 실시예는 현재 원래의 SWND 값의 어떠한 지식도 갖지 않고, 이 실시예는 어떠한 SWND 값도 변경시킬 수 없다. 그러므로, 우선적 스푸프 데이터 확인 응답(PSDA) 기법이 사용될 수 있다. PSDA는 초기에 확인 응답을 발행하는(issue) 것과(실제 확인 응답이 도착하기 전), 이를 원래의 TCP 구현에 전달하는 것을 포함하는데, 이 확인 응답은 원래의 TCP 구현이 전송 윈도우의 엣지(edge)를 이동시키고, 새로운 데이터를 송신하도록 강제한다. 따라서 본 발명의 실시예는 SWND를 채우고, 원하는 속도로 송신을 수행하기 위해 충분한 패킷을 취할 수 있다. 또한, PDSA는 원래의 TCP가 TCP의 재송신 버퍼로부터 초기에 확인 응답된 패킷을 삭제하도록 할 수 있지만, 본 발명의 실시예는 자신의 재송신 기법을 구현함으로써 초기에 확인 응답된 패킷의 주소를 지정할 수 있다. PDSA는 2가지 방식: 우선적 스푸프의 확인 응답 번호로 비어있는 패킷을 나타내는 것, 또는 실제 들어오는 패킷의 확인 응답 번호를 우선적 스푸프 확인 응답 번호로 수정하는 것으로 수행된다. 우선적 스푸프 확인 응답 번호는 다음: 현재 소프트웨어의 연결 엔티티 송신 버퍼는 다음의 실제 데이터의 확인 응답 이후 SWND-AWND의 차를 채우기 위해 충분한 데이터를 항상 포함해야 한다는 것을 고려하여 계산된다. 이러한 차는 하나의 실제 확인 응답 당 확인 응답된 데이터의 평균 크기로서 추정된다. 또한, 우선적 스푸프 확인 응답 번호는: 이 확인 응답 번호는 원래의 TCP 구현에 의해 아직 전송되지 않은, 그리고 현재 소프트웨어에 의해 아직 버퍼되지 않은 데이터를 커버하지 않아야 한다는 제한, 즉, 원래의 TCP로 이러한 확인 응답 번호를 전달하는 것이 한정되지 않은 행위를 초래할 수 있고, 연결 동작을 손상시킬 수 있기 때문에, 우선적 스푸프 확인 응답 번호는 [최근에 버퍼링된 패킷 시퀀스 번호] + [최근에 버퍼링된 패킷 데이터 크기] 값을 결코 초과하지 않아야 한다는 제한을 만족시켜야 한다.
패킷 손실 은폐(PLC: Packet Loss Concealment)는 원래의 TCP 구현이 실제로 손실된 패킷을 통지하고, 이 패킷을 재송신하는 것을 막기 위해 사용된다. 원래의 TCP 패킷 재송신이 본 발명의 실시예의 동작(이중 패킷은 처리 중에 폐기된다)에 대해 그리 중요하진 않지만, 재송신은 추가적인 시간의 비용이 드는 데이터 송신을 수반하고, 전체 성능을 감소시킨다. 게다가, 이미 우선적인 스푸프로 확인 응답된 데이터의 손실(이러한 데이터는 이미 스푸프 확인 응답시 원래의 TCP 재송신 버퍼로부터 제거된다)이 원래의 TCP로부터 은폐되지 않는다면, 이 손실은 예측할 수 없게 행동할 수 있다. PLC는 PDSA에 의해 구현되고, 이 PDSA에 의해 부분적으로 무시된다. PLC의 2가지 구별될 수 있는 성질: RTO 만료로 나타난 손실의 은폐 및, 제 3 이중 확인 응답으로 나타난 손실의 은폐가 존재할 수 있다.
제 3 이중 확인 응답 수신시, 본 발명의 실시예는 '재송신' 단계에 들어가고, 어떠한 새로운 패킷도 송신되지 않는데, 이는 연결 엔티티의 송신 버퍼가 비어있지 않고, 우선적 스푸프 확인 응답 번호가 증가되지 않는다는 것을 의미한다. 이러한 경우에서, 우선적 스푸프 확인응답 번호는 각 들어오는 이중 확인 응답이 원래의 TCP에 대한 스푸핑 이중 확인 응답을 회피하도록 1만큼 증가된다. 우선적 스푸프 확인 응답 번호가 [최근에 버퍼링된 패킷 시퀀스 번호] + [최근에 버퍼링된 패킷 데이터 크기] 값에 도달한다면, 이 확인 응답 번호는 더이상 증가되지 않고, 따라서, 가장 최근에 버퍼링된 데이터 바이트(또한 명백히 원래의 TCP에 의해 가장 최근에 송신되는 것이 명백한)는 매 도착하는 이중 확인 응답마다 원래의 TCP에 대해 스푸프 확인 응답된다.
RTO의 만료 은폐는 PSDA에 의해 부분적으로 무시되는데, 그 이유는 대다수의 패킷이 RTO의 만료 이전에 미리 확인 응답 되기 때문이다. 하지만, RTO가 우선적 스푸프의 확인 응답에 의해 커버되지 않는 패킷의 버퍼링 순간으로부터 만료되었다면, 이러한 패킷 데이터를 확인 응답하는, 비어있는 특정 스푸프 패킷이 발행되고, 원래의 TCP에 전달된다. 그런 후에, 우선적 스푸프 확인 응답 번호는 최근의 스푸프로 확인 응답된 패킷의 [시퀀스 번호] + [데이터 크기]로 조정된다. 하지만, 본 발명의 실시예의 RTO 계산은 원래의 TCP RTO 계산에 상관될 필요가 없다. 따라서, 원래의 TCP 구현은 현재 소프트웨어가 특정 패킷에 대한 스푸프 확인 응답을 발행하기 전에 특정 패킷에 대한 TCP의 내부 RTO 만료를 검출할 수 있다. 이는 RTO가 나타낸 손실이 동작적으로 중요하지 않기에, 상당한 문제가 되진 않고, 이러한 경우, 손실로 나타낸 패킷은 원래 TCP 송신 버퍼 내에 여전히 존재하고, 재송신되는데, 이는 전체 성능에 대한 불충분한 감소를 초래하지만, 연결 동작 충돌을 초래하지는 않는다.
전체 처리 서브시스템 동작은 다음의 알고리즘 세트: 패킷 결합, 연결 엔티티 생성, 빠져나가는 패킷 처리, 들어오는 패킷 처리, 송신, 타임 아웃 검사 및 PLC를 이용한 재송신으로 서술될 수 있다.
처리 서브시스템의 동작은 새로운 패킷 수신의 대기를 개시한다. 일부 정지 상태가 이러한 대기 동안 충족된다면, 처리 서브시스템은 이러한 대기를 그만두고, 이 동작을 종료한다. 그렇지 않고, 일단 패킷이 수신되면, 패킷은 처리 동안 전달된다.
처리 서브시스템은 이 서브시스템이 수신한 패킷이 이미 필터링 또는 패킷 캡처링 서브시스템에 의해 필터링되었다고 간주한다. 이 처리 서브시스템은 수신된 패킷이 어떤 특정 연결에 관련되는지를 결정하는 패킷 결합 기법을 필요로 한다. 본 발명의 실시예는 각각 로컬 및 원격 호스트의 네트워크/송신 주소를 나타내는 용어: 로컬 IP/포트 및 원격 IP/포트에 작용할 수 있다. 연결 엔티티의 신원은 이들 2쌍의 주소에 의해 나타난다. 수신된 패킷은 패킷 주소의 세트가 신원에 매칭한다면, 현재 추적된 조건의 주소에 속하도록 결정된다. 일단 패킷의 연결이 결정된다면, 패킷은 특정 연결의 엔티티 배경 내에서 처리된다. 패킷의 연결이 결정되지 않은 상태로 남아있다면, 사전 한정된 새로운 연결의 생성 조건을 검사한 이후에, 패킷은 출력 서브시스템으로 투명하게 전달된다.
본 발명의 실시예는 본 발명에 의해 더 처리될 수 있는 특정 연결에 대한 연결 구축 동안 협상되는 일부 필수 정보를 요구할 수 있다. 따라서, 본 발명의 소프트웨어가 통신을 모니터링하는 동안 오직 새로운 연결이 구축될 때, 추가의 처리를 위한 새로운 연결 엔티티가 생성될 수 있다. 일부 실시예는 동작의 중반에 연결이 이미 되었다면, 추가의 처리를 위한 새로운 연결 엔티티를 생성하지 않는다(이러한 경우, 연결은 필터링 서브시스템에 의해 필터링되고, 원래 TCP 구현에 의해 처리된다). 새로운 엔티티 생성에 대한 주 조건은 SYN 플래그 세트를 갖는 TCP(원격에서 로컬 호스트로) 패킷에 대한 네트워크의 수신일 수 있다. 최대 윈도우 크기, 윈도우 스케일 및 최대 세그먼트 크기와 같은 이러한 중요한 실행 시간 파라미터는 패킷을 구축하는 이러한 연결로부터 획득된다. 위에 논의된 연결을 저장하는 조건이 충족되지 않는다면, 어떠한 새로운 연결 엔티티도 생성되지 않고, 패킷은 어떠한 처리 없이 출력 서브시스템에 전달된다.
패킷이 위에 논의된 바와 같이 기존의 현재 연결 엔티티 중 하나에 결합된 이후, 패킷은 패킷 방향에 따른 패킷의 배경 내에서 처리된다.
빠져나가는(로컬에서 원격 호스트로) 패킷은 다음의 수식: [새로운 패킷의 시퀀스 번호] = [최근의 패킷 시퀀스 번호] + [최근의 패킷 데이터 크기]이 참이라면, 연결 송신 버퍼에 추가된다. 이러한 조건은 오직 잘 정렬된 패킷이 송신을 위한 처리 서브시스템에 의해 버퍼링된다는 것을 보장한다. 그동안, 이중 또는 순서에 벗어난 패킷은 폐기된다. 빠져나가는 새로운 패킷이 버퍼링된 이후에, 송신 알고리즘이 수반된다.
들어오는(원격에서 로컬 호스트로) 패킷은 필수 연결 상태 정보를 얻기 위해 사용된다. 선택적 마이너(minor) 변형이 PSDA 및 PLC 요건을 충족시키기 위해 패킷에 적용된 이후에, 이들 패킷은 저장되지 않고, 투명하게 TCP까지 전달된다. 들어오는 패킷 수신시 취해지는 제 1 동작은 확인 응답된 패킷 또는 재송신 요청을 검출하는 목적으로 수행된 연결 재송신 버퍼 검사이다. RTT 계산 또한 확인 응답 검사 동안 수행된다. 연결 재송신 버퍼로부터의 패킷이 들어오는 패킷([버퍼링된 패킷 시퀀스 번호] + [버퍼링된 패킷 데이터의 크기] <= [들어오는 패킷 확인 응답 번호])으로 확인응답 된다면, NEW_RTT는 이러한 버퍼링된 패킷의 송신으로부터 패킷의 확인 응답의 수신까지 경과된 시간과 동일하게 설정된다. 버퍼링된 패킷의 제 3 이중 확인 응답이 검출된다면, L_RTT는 이러한 버퍼링된 패킷 송신에서 제 3 이중 확인 응답의 수신까지 경과된 시간으로 설정된다. 그런 후에, 송신을 위해 확인 응답되고, 요청된 패킷은 송신 버퍼로부터 삭제되거나, 각각 재송신을 위해 표시된다. 그런 후에, RWND, AWND, S_RTT, RTT 변화량 및 증가량과 같은 실행 시간 변수가 다시 공급되거나 재계산된다. 이들 변수를 다시 공급한 이후에, 주 파라미터 - SWND가 재계산된다. SWND, AWND 및 RWND가 어쩌면 변화되었고, 새로운 패킷의 송신은 이제부터 허용될 수 있기 때문에, 송신 알고리즘이 호출된다.
송신 알고리즘은 송신 버퍼 패킷의 추출 및 송신의 성공시 후속하는 전송 조건 검사를 포함한다. 송신 알고리즘은 초기 패킷 선택 및 전송 조건 검사를 통해 개시한다. 가장 작은 시퀀스 번호를 갖는 패킷은 송신 버퍼로부터 선택되고, 다음의 전송 조건: SWND > AWND + [선택된 패킷 데이터 크기] 및 NEW_RWND > MAX_RWND * OAWT이 검사된다. 상기 조건이 충족된다면, 패킷은 송신 버퍼로부터 추출되고, 송신되며, 패킷의 사본이 재송신 버퍼에 저장된다. 그런 후에, AWND는 송신된 패킷의 데이터 크기만큼 증가된다. 이들 행위는 송신 버퍼가 비워질 때까지, 또는 송신 조건이 충족되지 않을 때까지, 루프 내에서 반복된다.
PLC 알고리즘을 이용한 타임아웃 검사 및 재송신은 2개의 섹션으로 나눠질 수 있다. PLC 단계 동안, 송신 및 재송신 버퍼로부터의 패킷은, 각 개별적인 패킷이 처음에 버퍼링된 순간(즉, 원래의 TCP 구현이 상기 패킷을 송신했던 순간)으로부터 RTO 기간이 경과 되었는지를 결정하기 위해 검사된다. 이러한 패킷이 존재하고 PSDA에 의해 아직 확인 응답 되지 않았다면, 특정 손실 은폐 스푸프의 확인 응답 패킷이 발행되고, 원래의 TCP가 언급하고 있는 RTO 만료 및 재송신하는 것을 막기 위해, 원래의 TCP에 전달된다. 손실 은폐 스푸프 확인 응답 번호가 패킷 버퍼링의 순간으로부터 만료된 RTO를 통해 가장 최근에 버퍼링된 패킷을 커버해야 한다. 그런 후에, 우선적 스푸프 확인 응답 번호는 손실 은폐 스푸프 확인 응답 번호로 설정된다. 타임아웃 검사 및 재송신 단계는 RTO 만료에 대해 검사될, 그리고 재송신을 위해 표시될 재송신 버퍼로부터의 패킷을 가정한다. 그러면, 들어오는 패킷 처리 또는 타임아웃 검사 동안 재송신을 위해 표시된 모든 패킷은 재송신되지만, 다음의 제한이 과도한 재송신율을 회피하기 위해 적용된다: 특정 패킷이 MIN_RTT 당 오직 하나씩 재송신되도록 허용되고, 전체 송신율은 추정된 이용가능한 대역폭을 초과하지 않아야 한다.
도 1은 내장 TCP 프로토콜 지원 및 통신 데이터 흐름을 갖는 OS를 구동하는 컴퓨터 시스템에 대한 본 발명의 실시예의 도입의 기법을 도시한다. 본 발명의 실시예를 구현하는 소프트웨어는 데이터 전송 시스템에 도입되고, 물리 및 송신 ISO OSI 모델 계층 사이의 OS의 동작을 수행한다. 이러한 소프트웨어는 "익스트림 TCP"로 현재 참조된다. 데이터 전송 시스템은 정규 개인용 컴퓨터일 수 있거나, TCP 프로토콜을 통해 데이터를 전송하는 임의의 컴퓨터일 수 있다. 소프트웨어는 네트워크 패킷을 차단하고, 차단된 패킷의 변형 및 새로운 패킷 생성에 의해 TCP동작의 표준 흐름을 변경한다. 익스트림 TCP 소프트웨어(106)은 로컬 TCP(102)와 원격 TCP(103) 사이에 구축된 TCP 연결을 통해 원격 데이터 수신 시스템에 데이터 송신을 수행하는 데이터 전송 시스템(100)에 도입된다. 익스트림 TCP 소프트웨어(106)는 로컬 TCP(102)와 원격 TCP(103) 사이의 직접 연결 흐름을 막고, TCP의 변형을 구동하는 중간 가상 호스트가 된다. 익스트림 TCP 소프트웨어는 연결 처리 서브시스템(107)과 패킷 캡처링 서브시스템(108)으로 구성된다. 패킷 캡처링 서브시스템(108)은 들어오는, 그리고 빠져나가는 방향 모두의 네트워크 패킷을 차단하고, 이 패킷을 연결 처리 서브시스템(107)으로 재유도한다. 네트워크 패킷의 정상 흐름은 엔티티 및 데이터 흐름의 다음의 시퀀스: [로컬 TCP(102) - 데이터 흐름(133) - 로컬 네트워크 인터페이스(104) - 데이터 흐름(127) - 네트워크(105) - 데이터 흐름(128) - 원격 TCP(103)]로, 그리고 역방향에 대해서는 역 순서로 서술될 수 있다. 빠져 나가는 패킷의 재유도된 흐름은 [로컬 TCP(102) - 데이터 흐름(120) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(121) - 연결 처리 서브시스템(107) - 데이터 흐름(125) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(126) - 로컬 네트워크 인터페이스(104) - 데이터 흐름(127) - 네트워크(105) - 데이터 흐름(128) - 원격 TCP(103)] 이고, 들어오는 패킷은 다음의 흐름: [원격 TCP(103) - 데이터 흐름(129) - 네트워크(105) - 데이터 흐름(130) - 로컬 네트워크 인터페이스(104) - 데이터 흐름(131) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(121) - 연결 처리 서브시스템(107) - 데이터 흐름(125) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(132) - 로컬 TCP(102)]이다.
연결 처리 서브시스템(107)은 입력 서브시스템(109), 필터링 서브시스템(110), 처리 서브시스템(111) 및 출력 서브시스템(112)으로 구성된다. 입력(109) 및 출력(112) 서브시스템은 연결 처리 서브시스템(107)과 패킷 캡처링 서브시스템(108) 사이의 통신을 담당한다. 필터링 서브시스템(110)은 부적절한 패킷을 필터링하고, 이 패킷을 출력(112)에, 그리고 후에 데이터 흐름(113)을 통해 즉시 및 투명하게 패킷 캡처링 서브시스템(108)에 전달한다. 필터링 서브시스템(110)은 적합한 특징이 이 서브시스템(110)에 의해 제공된다면, 패킷 캡처링 서브시스템(108)에 의해 완전히 또는 부분적으로 구현될 수 있다.
처리 서브시스템(111)은 본 발명의 실시예의 프로토콜 변형의 구현을 구체화한다. 처리 서브시스템(111)의 아키텍처 및 동작은 공통적으로 도 2에 나타나고, 세부사항은 도 3 내지 도 9에 제공된다. 처리 서브시스템(111), 로컬(102) 및 원격 TCP(103) 사이에 별개의 수개의 가상 데이터 통신 흐름이 존재할 수 있다.
가상 데이터 흐름(114)은 [로컬 TCP(102) - 데이터 흐름(120) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(121) - 입력 서브시스템(109) - 데이터 흐름(122) - 필터링 서브시스템(110) - 데이터 흐름(123) - 처리 서브시스템(111)]로 나타난다. 처리 서브시스템(111)은 가상 데이터 흐름(114)을 통해 로컬 TCP(102)로부터 데이터를 수신하고, 데이터를 버퍼링하며, 익스트림 TCP 프로토콜 변형 개념에 따라, 가상 데이터 흐름(116)을 통해 원격 TCP(103)에 이 데이터를 송신/재송신한다. 가상 데이터 흐름(116)은 [처리 서브시스템(111) - 데이터 흐름(124) - 출력 서브시스템(112) - 데이터 흐름(125) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(126) - 로컬 네트워크 인터페이스(104) - 데이터 흐름(127) - 네트워크(105) - 데이터 흐름(128) - 원격 TCP(103)]로 나타난다. 원격 TCP(103)는 가상 데이터 흐름(117): [원격 TCP(103) - 데이터 흐름(129) - 네트워크(105) - 데이터 흐름(130) - 로컬 네트워크 인터페이스(104) - 데이터 흐름(131) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(121) - 입력 서브시스템(109) - 데이터 흐름(122) - 필터링 서브시스템(110) - 데이터 흐름(123) - 처리 서브시스템(111)]을 통해 처리 서브시스템(111)로 수신된 데이터를 확인 응답한다. 처리 서브시스템은 가상 데이터 흐름(115): [처리 서브시스템(111) - 데이터 흐름(124) - 출력 서브시스템(112) - 데이터 흐름(125) - 패킷 캡처링 서브시스템(108) - 데이터 흐름(132) - 로컬 TCP(102)] 을 통해 통신된 PDSA 및 PLC에 의해 로컬 TCP(102)의 행위를 수정한다.
도 2는 처리 서브시스템 아키텍처 및 동작을 도시한다. 실선은 처리 서브시스템 주 루프의 제어 흐름을 나타낸다. 처리 서브시스템은 정지 조건이 충족되는 것, 타임아웃 검사 시간이 도래하는 것, 또는 새로운 패킷이 데이터 흐름(207)을 통해 필터링/입력 서브시스템으로부터 수신되는 것 중 하나를 무한히 기다린다. 처리 서브시스템은, 정지 조건이 충족되었을 때 즉시 정지된다. 타임아웃 검사 시간이 도래하여, 제어가 타임아웃 검사 및 PLC 알고리즘(206)을 이용한 재송신에 전달된다면, 처리 서브시스템은 처리의 완료시 상태를 대기하게 된다. 새로운 패킷이 필터링/입력 서브시스템으로부터 수신되었다면, 패킷 결합(201)이 수행된다. 최근에 수신된 패킷이 현재 처리된 연결 엔티티 중 하나와 성공적으로 결합되었다면, 제어 및 데이터는 각각 제어 흐름(210) 및 데이터 흐름(211) 또는 제어 흐름(212) 및 데이터 흐름(213)을 통한 패킷 방향에 따라, 빠져나가는(203) 또는 들어오는(204) 패킷 처리 중 하나에 전달된다. 빠져나가는 패킷 처리 알고리즘(203)은 수신된 패킷을 버퍼하고, 우선적 스푸프의 확인 응답 패킷을 발행하는 PDSA를 수행하며, 이 수신된 패킷을 데이터 흐름(208)을 통해 출력 서브시스템에 전달한다. 들어오는 패킷 처리 알고리즘(204)은 연결 상태, 실행 시간의 변수를 다시 공급하고, PSDA 및 PLC의 목적으로 수신된 패킷을 수정하며, 데이터 흐름(214)을 통해 이 패킷을 출력 서브시스템에 전달한다. 그러면, 제어는 데이터 흐름(209)을 통해 패킷을 출력 서브시스템에 전달함으로써, 이전에 버퍼링된 패킷을 송신하는 송신 알고리즘(205)에 전달된다. RTO 만기로 나타난 손실 및 PLC의 필요성을 위한 타임아웃 검사 및 PLC 알고리즘 검사를 이용한 재송신은 손실 은폐 스푸프 확인 응답 패킷을 발행하고, 이 패킷을 데이터 흐름(215)을 통해 출력 서브시스템에 전달하며, 그런 후에 데이터 흐름(216)을 통해 이 패킷을 출력 시스템에 전달함으로써 원하는 패킷을 재송신한다. 그러면, 처리 서브시스템은 대기 상태가 된다. 새로운 패킷이 임의의 현재 처리된 연결 엔티티에 결합되지 않는다면, 이 패킷은 이 패킷 연결을 나타내는 새로운 엔티티의 생성이 가능한지를 검사하는 연결 엔티티 생성 알고리즘(202)에 대한 처리를 위해 전달된다. 제어 및 데이터는 제어 흐름(217) 및 데이터 흐름(218)을 통해, 연결 엔티티 생성 알고리즘에 전달된다. 그러면 연결 엔티티 생성은 데이터 흐름(220)을 통해 출력 서브시스템에 패킷을 전달하고, 흐름(219)을 통해 제어를 재송신 알고리즘(206)에 전달한다.
도 3은 패킷 결합 알고리즘을 도시한다. 이 알고리즘은 처리 서브시스템의 메인 루프로부터 제어{제어 흐름(300)을 통해} 및 데이터{데이터 흐름(305)을 통해}를 수신한다. 그러면, 패킷은 현재 처리된 연결 엔티티에 속하는지가 검사된다. 매칭하는 어떠한 연결 엔티티도 수신된 패킷에 대해 발견되지 않는다면, 제어{제어 흐름(301)을 통해} 및 데이터{데이터 흐름(303)을 통해}는 연결 엔티티 생성 알고리즘에 전달된다. 매칭하는 연결 엔티티가 발견되었다면, 제어 및 데이터는 각각 제어 흐름(304) 및 데이터 흐름(306) 또는, 제어 흐름(307) 및 데이터 흐름(308)을 통해 빠져나가는 또는 들어오는 패킷 처리 알고리즘에 전달된다.
도 4는 연결 엔티티 생성 알고리즘을 도시한다. 이 알고리즘은 패킷 결합 알고리즘으로부터 제어{제어 흐름(400)을 통해} 및 데이터{데이터 흐름(402)을 통한 패킷}를 수신한다. 새로운 연결 엔티티 생성 조건이 충족된다면, 새로운 엔티티가 생성되고, 데이터 흐름(403)을 통해 연결 엔티티 버퍼(405)에 저장된다. 그러면, 패킷은 데이터 흐름(407)을 통해 출력 서브시스템에 전달되고, 제어는 새로운 엔티티 생성 조건이 충족되는지에 관계없이 제어 흐름(406)을 통해 처리 서브시스템의 주 루프로 되돌아 간다.
도 5는 빠져나가는 패킷 처리 알고리즘을 도시한다. 이 알고리즘은 패킷 결합 알고리즘으로부터 제어{제어 흐름(504)을 통해} 및 데이터{데이터 흐름(506)을 통한 패킷}를 수신한다. 수신된 패킷은 잘 정렬된 연속 데이터 송신의 조건에 부합하는지 검사된다. 패킷이 이중이거나 잘못 정렬되었다면, 이 패킷은 폐기되거나 드랍된다. 패킷이 잘 정렬되어 있다면, 패킷은 연결 엔티티의 송신 버퍼(505){데이터 흐름(508)을 통해}에 저장된다. 그러면, PSDA의 필요성이 검사되고, 우선적 스푸프 확인응답 패킷이 발행되며, 데이터 흐름(507)을 통해 출력 서브시스템에 전달된다. 제어는 완료시 송신 알고리즘에 전달된다{제어 흐름(501)}.
도 6은 들어오는 패킷의 처리 알고리즘을 도시한다. 이 알고리즘은 패킷 결합 알고리즘으로부터 제어{흐름(605)} 및 데이터{데이터 흐름(611)을 통한 패킷}를 수신한다. 연결 엔티티 재송신 버퍼(610)로부터의 패킷은 확인 응답 되었는지가 검사되거나, 수신된 패킷에 의해 재송신을 위해 요청된다. 패킷이 확인 응답되었다면, NEW_RTT가 다시 공급되고, 확인 응답된 패킷은 재송신 버퍼(610)로부터 삭제된다. 재송신 요청이 검출된다면, 요청된 패킷은 추가의 재송신을 위해 표시된다. 모든 버퍼링된 패킷이 검사되었다면, 연결 상태 및 실행 시간의 변수가 다시 공급된다. 명백히 익스트림 TCP 프로토콜 변형의 본질인 SWND의 계산은 여기{(알고리즘(607)}에서 취해진다. 그러면, 수신된 패킷은 PSDA 및 PLC의 요건과 매칭하도록 수정되며, 이 패킷은 데이터 흐름(612)을 통해 출력 서브시스템에 전달된다. 제어는 송신 알고리즘{흐름(608)}에 전달된다.
도 7은 송신 알고리즘을 도시한다. 이 알고리즘은 빠져나가는{제어 흐름(608)을 통해} 또는 들어오는{제어 흐름(501)을 통해} 패킷 처리 알고리즘으로부터 제어를 수신한다. 패킷은 후속적으로 송신 버퍼(505)로부터 선택되고, 전송 조건이 검사된다. 특정 패킷이 송신되도록 허용된다면, 이 패킷은 송신 버퍼(505)로부터 추출되고, 송신되며{데이터 흐름(705)을 통해 출력 서브시스템에 전달함으로써}, 후에 패킷의 사본은 재송신 버퍼(610)에 저장된다. 일단 송신 조건이 충족되지 않거나, 송신 버퍼(505)가 비워진다면, 제어는 재송신 알고리즘{제어 흐름(703)을 통해}에 전달된다.
도 8은 타임아웃 검사 및 PLC 알고리즘을 이용한 재송신을 도시한다. 이 알고리즘은 처리 서브시스템 주 루프{흐름(800)}로부터, 또는 송신 알고리즘{흐름(703)} 또는 연결 생성 알고리즘{흐름(406)}으로부터 제어를 수신한다. 송신(505)및 재송신(610) 버퍼로부터의 제 1 패킷은 손실 은폐 스푸프의 확인 응답 필요성을 위해 검사된다. RTO가 특정 패킷의 버퍼링의 순간으로부터 만료되고, 패킷이 아직 PSDA에 의해 아직 스푸프 확인 응답 되지 않았다면, PLC 확인 응답이 발행되고, 데이터 흐름(813)을 통해 출력 서브시스템에 전달된다. 재송신 버퍼(610)로부터의 패킷은 RTO로 나타난 손실에 대해 동시에 검사된다. RTO가 패킷 재송신의 순간으로부터 만료되었다면, 이 패킷은 손실되었는지 의심되고, 재송신을 위해 표시된다. 그러면, 알고리즘은 이전에 표시된 패킷을, 데이터 흐름(814)을 통해 출력 서브시스템에 전달하여, 재송신한다. 제어는 재송신의 완료{제어 흐름(802)}시에 처리 서브시스템 주 루프로 되돌아간다.
도 9는 본 발명의 일부 실시예에 따라, SWND의 계산 알고리즘을 도시한다:
1. 패킷이 확인 응답되었다면:
1.1. NEW_RTT <= MIN_RTT*(1 + EIRT) 및 |RTT_RGRW/RTT_RVAR| <= EIGT라면, SWND = SWND + ACK_DS*{[1 - (NEW_RTT - MIN_RTT)/(MIN_RTT*EIRT)]*(1 - 1/EIID) + 1/EIID}이다(SWND는 지수적으로 증가된다).
1.2. MIN_RTT*(1 + EIRT) < NEW_RTT <= MIN_RTT*(1 + LIRT) 및 EIGT < | RTT RGRW/RTT RVARI <= LIGT 라면, SWND = SWND + (ACK_DS/SWND)*{[(1 + LIRT)/(LIRT - EIRT) - (NEW_RTT - MIN_RTT)/(MIN_RTT* (LIRT - EIRT))]*(1/LIID)}이다(SWND는 선형적으로 증가된다).
1.3. [NEW_RTT > MIN_RTT*(1 + CART) 또는 |RTT_RGRW/RTT_RVAR| > CAGT] 및 SWND_GRW >= CAWT 라면, SWND = SWND - SWND_GRW/CADD 이다(SWND는 선형적으로 감소된다).
1.4. [NEW_RTT > MIN_RTT*(1 + CART) 또는 |RTT_RGRW/RTT_RVAR| > CAGT] 및 SWND_GRW < CAWT 라면, SWND = SWND*(MIN_RTT/NEW_RTT) 이다(SWND는 비례하여 감소된다).
2. 손실이 검출되었다면:
2.1. RTO 만료로 나타난 손실이 나타났다면, SWND = SWND*(MIN_RTT/RTO) (SWND는 비례하여 감소된다).
2.2. SACK으로 나타난 손실의 제 3 이중 확인 응답이 검출되었다면, SWND = SWND*(MIN_RTT/L_RTT) 이다(SWND는 비례하여 감소된다).
도 10은 본 발명의 실시예에서 처리 기능을 구현하기 위해 사용될 수 있는 전형적인 계산 시스템(1000)을 도시한다. 이러한 타입의 계산 시스템은 예를 들어, 클라이언트 및 서버에서 사용될 수 있다. 또한, 당업자라면, 다른 컴퓨터 시스템 또는 아키텍처를 이용하여 본 발명을 어떻게 구현할지를 인지할 것이다. 계산 시스템(1000)은 예를 들어, 데스크톱, 랩톱 또는 노트북 컴퓨터, 휴대용 계산 디바이스{PDA, 휴대 셀(cell) 전화기, 팜톱(palmtop) 등), 메인프레임, 서버, 클라이언트 또는, 주어진 애플리케이션 또는 환경에 대해 바람직하거나 적합할 수 있는 임의의 다른 타입의 특수 또는 일반 목적의 계산 디바이스를 나타낼 수 있다. 계산 시스템(1000)은 처리기(1004)와 같은 하나 이상의 처리기를 포함할 수 있다. 처리기(1004)는 예를 들어, 마이크로처리기, 마이크로제어기 또는 다른 제어 논리 회로와 같은 일반 또는 특수 목적 처리 엔진을 사용하여 구현될 수 있다. 이러한 예시에서, 처리기(1004)는 버스(1002) 또는 다른 통신 매체에 연결된다.
또한, 계산 시스템(1000)은 랜덤 액세스 메모리(RAM) 또는, 처리기(1004)에 의해 실행될 정보 또는 지령을 저장하는 다른 동적 메모리와 같은 주 메모리(1008)를 포함할 수 있다. 또한, 주 메모리(1008)는 처리기(1004)에 의해 실행될 지령의 실행 동안, 일시적 변수 또는 다른 중간 정보를 저장하기 위해 사용될 수 있다. 마찬가지로, 계산 시스템(1000)은 읽기 전용 메모리("ROM") 또는, 처리기(1004)에 대한 정적 정보와 지령을 저장하기 위해 버스(1002)에 연결되는 다른 정적 저장 디바이스를 포함할 수 있다.
또한, 계산 시스템(1000)은 정보 저장 시스템(1010)을 포함할 수 있고, 이 시스템은 예를 들어, 매체 드라이브(1012)(drive) 및 탈착 가능 저장 인터페이스(1020)를 포함할 수 있다. 매체 드라이브(1012)는 드라이브 또는, 하드 디스크 드라이브, 플로피 디스크 드라이브, 자기 테입 드라이브, 광 디스크 드라이브, CD 또는 DVD 드라이브(R 또는 RW) 또는, 다른 탈착 가능 또는, 고정 매체 드라이브와 같은 탈착 가능 또는 고정 매체를 지원하는 다른 메카니즘을 포함할 수 있다. 저장 매체(1018)는 예를 들어, 하드 디스크, 플로피 디스크, 자기 테입, 광 디스크, CD 또는 DVD, 또는, 매체 드라이브(1012)에 의해 판독되고 기록되는 다른 탈착 가능 또는 고정 매체 드라이브를 포함할 수 있다. 이들 예시가 서술하는 바와 같이, 저장 매체(1018)는 특정 컴퓨터 소프트웨어 또는 데이터를 저장하는 컴퓨터-판독 가능 저장 매체를 포함할 수 있다.
대안적인 실시예에서, 정보 저장 시스템(1010)은 컴퓨터 프로그램 또는 다른 지령 또는 데이터가 계산 시스템(1000)에 적재되는 것을 허용하는 다른 유사한 요소를 포함할 수 있다. 이러한 요소는 예를 들어, 프로그램 카트리지(cartridge) 및 카트리지 인터페이스, 탈착 가능 메모리(예를 들어, 플래쉬 메모리 또는 다른 탈착 가능 메모리 모듈) 및 메모리 슬롯과 같은, 탈착 가능 저장 장치(1022) 및 인터페이스(1020), 그리고 소프트웨어 및 데이터가 탈착 가능 저장 장치(1022)로부터 계산 시스템(1000)으로 전달되는 것을 허용하는 다른 탈착 가능 저장 유닛(1022) 및 인터페이스(1020)를 포함할 수 있다.
또한, 계산 시스템(1000)은 통신 인터페이스(1024)를 포함할 수 있다. 통신 인터페이스(1024)는 소프트웨어 및 데이터가 계산 시스템(1000)과 외부 디바이스 사이에 전송되는 것을 허용하기 위해 사용될 수 있다. 통신 인테페이스(1024)의 예시는 모뎀, 네트워크 인터페이스(이더넷 또는 다른 NIC 카드와 같은), 통신 포트(예를 들어, USB 포트와 같은), PCMCIA 슬롯 및 카드 등을 포함할 수 있다. 통신 인터페이스(1024)를 통해 송신된 소프트웨어 및 데이터는 통신 인터페이스(1024)에 의해 수신될 수 있는 전기, 전자, 광 또는 다른 신호일 수 있는 신호의 형태이다. 이들 신호는 채널(1028)을 통해 통신 인터페이스(1024)에 제공된다. 이러한 채널(1028)은 신호를 전달할 수 있고, 무선 매체, 유선 또는 케이블, 광 섬유, 또는 다른 통신 매체를 사용하여 구현될 수 있다. 채널의 일부 예시는 전화선, 셀룰러 전화기 링크, RF 링크, 네트워크 인터페이스, 근거리 통신망 또는 원거리 통신망, 및 다른 통신 채널을 포함한다.
본 명세서에서, 용어 "컴퓨터 프로그램 제품", "컴퓨터-판독 가능 매체" 등은 일반적으로, 메모리(1008), 저장 디바이스(1018), 또는 저장 장치(1022)와 같은 매체를 참조하기 위해 일반적으로 사용될 수 있다. 컴퓨터-판독 가능 매체의 이들 및 다른 형태는 처리기(1004)를 통한 사용을 위한 하나 이상의 지령을 저장하는 데 수반될 수 있어서, 처리기가 특정 동작을 수행하도록 할 수 있다. 일반적으로 "컴퓨터 프로그램 코드(컴퓨터 프로그램의 형태 또는 다른 그룹화로 그룹화될 수 있는)로 참조되는 이러한 지령이 실행될 때, 이 지령은 계산 시스템(1000)이 본 발명의 실시예의 특징 또는 기능을 수행하는 것을 가능케 한다. 코드가 처리기로 하여금 특정 동작을 직접 수행하도록 하거나, 그렇게 하도록 컴파일하거나, 및/또는 그렇게 하도록 하는 다른 소프트웨어, 하드웨어 및/또는 펌웨어 요소(예를 들어, 표준 기능을 수행하는 라이브러리)와 결합될 수 있다는 것을 주목하라.
요소가 소프트웨어를 사용하여 구현되는 일 실시예에서, 소프트웨어는 컴퓨터-판독 가능 매체에 저장될 수 있고, 예를 들어, 탈착 가능 저장 드라이브(1014), 드라이브(1012) 또는 통신 인터페이스(1024)를 사용하여 계산 시스템(1000)에 적재될 수 있다. 제어 논리 회로(이러한 경우, 소프트웨어 지령 또는 컴퓨터 프로그램 코드)는 처리기(1004)에 의해 실행될 때, 처리기(1004)가 본 명세서에 서술된 본 발명의 기능을 수행하게 한다.
명확한 목적을 위해, 상기 서술은 상이한 기능 장치 및 처리기를 참조로 본발명의 실시예를 서술했다는 것이 인식될 것이다. 하지만, 상이한 기능 장치, 처리기 또는 영역 사이의 기능의 임의의 적합한 분배가 본 발명을 손상시키는 것 없이 사용될 수 있다는 것이 명백할 것이다. 예를 들어, 별도의 처리기 또는 제어기에 의해 수행되도록 도시된 기능은 동일한 처리기 또는 제어기에 의해 수행될 수 있다. 그러므로, 특정 기능 유닛에 대한 참조는 엄격한 논리 또는 물리 구조 또는 조직을 나타내는 것이 아닌, 오직 서술된 기능을 제공하는 적합한 수단에 대한 기준으로만 인식될 것이다. 본 발명의 일부 예시적인 실시예는 TCP 프로토콜과 관련하여 위에 논의되었다. 본 발명은 이에 제한되지 않고, 슬라이딩 윈도우 개념을 활용하는 다른 프로토콜에 대해 적용될 수 있다.
본 발명이 일부 실시예에 관련하여 서술되었지만, 이는 본 명세서로 한정된 특정 형태에 제한되지 않는 것으로 의도된다. 오히려, 본 발명의 범주는 오직 청구항만으로 제한되어야 한다. 게다가, 특정 실시예에 관련하여 특징이 서술될 수 있지만, 당업자라면, 서술된 실시예의 다양한 특징이 본 발명에 따라 결합될 수 있다는 것을 인지할 것이다.
게다가, 개별적으로 기재되었지만, 복수의 수단, 요소 또는 방법 단계는 예를 들어, 단일 장치 또는 처리기에 의해 구현될 수 있다. 게다가, 개별적인 특징이 상이한 청구항으로 포함될 수 있지만, 이들 특징은 어쩌면 이롭게 결합될 수 있고, 상이한 청구항에서의 포함은 특징의 결합이 실행 가능하지 않거나 및/또는 이로운 것이 아니라는 것을 의미하는 것이 아니다. 또한, 청구항의 하나의 카테고리에서의 특징의 포함은 이러한 카테고리로의 제한을 의미하는 것이 아니라, 오히려 특징은 적절하다면 다른 청구항의 카테고리에도 균등하게 적용될 수 있다. 또한, 본 명세서와 청구항에서 사용된, 단수 형태는 배경이 명확히 다르게 지시되지 않는다면, 복수의 지시 대상을 포함한다.
게다가, 다양한 수정 및 대안이 본 발명의 사상 및 범주를 벗어나지 않고, 당업자에 의해 구현될 수 있음이 명백하다, 본 발명은 전술한 예시적인 세부사항에 제한되지 않고, 청구항에 따라 한정될 것이다.
오직 예시적인 특정 실시예만이 위에 상세히 서술되었지만, 당업자라면, 다수의 변형이, 본 발명의 새로운 교시 및 장점으로부터 현저히 벗어나는 것 없이 어쩌면 예시적인 실시예에 존재할 수 있다는 것을 손쉽게 인식할 것이다. 따라서, 이러한 모든 변형은 본 발명의 범주 내에 포함되는 것으로 의도된다.
1002 : 버스 1004 : 처리기
1008 : 메모리 1010 :저장 디바이스
1012 : 매체 드라이브 1014 : 탈착 가능 매체 드라이브
1018 :매체저장 장치 I/F 1020 : 저장 장치
1024 : 통신 I/F 1028 : 채널

Claims (90)

  1. 혼잡을 회피하면서, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법에 있어서, 상기 송신은 슬라이딩 윈도우(sliding window)를 활용하는 프로토콜에 따라 수행되고, 상기 방법은
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계, 및
    상기 계산된 RTT를 기초로 하여, 전송 윈도우의 크기를 수정하는 단계로서, 상기 수정은 송신율에 의존하지 않는, 수정 단계를
    포함하는, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법.
  2. 제 1항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법.
  3. 혼잡을 회피하면서, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법에 있어서, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 방법은,
    제 1 시간 동안 데이터를 전송할 때, 제 1 모드에 따라 전송 윈도우의 크기를 제어하는 단계, 및
    이미 송신된 데이터가 상기 네트워크에 의해 드랍(dropped)될 수 있는 지에 대한 결정 시, 상기 이미 송신된 데이터를 재-송신할 때 제 2 모드에 따라 전송 윈도우의 크기를 제어하는 단계를
    포함하고, 상기 전송 윈도우의 상기 크기를 제어하는 상기 제 1 및 제 2 모드는 상이한, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  4. 제 3항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  5. 혼잡을 회피하면서, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법에 있어서, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 방법은
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계, 및
    상기 계산된 RTT를 기초로 하여 전송 윈도우의 크기 및, 상기 계산된 RTT의 변화율을 수정하는 단계를
    포함하는, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법.
  6. 제 5항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  7. 제 5항에 있어서, 상기 전송 윈도우의 상기 크기를 수정하는 단계는 일정 시간의 기간에 걸쳐 상기 계산된 RTT의 상기 변화량을 더 기초로 하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  8. 혼잡을 회피하면서, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법에 있어서, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 방법은
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계;
    송신된 세그먼트가 네트워크에 의해 드랍될 수 있는지를 결정하는 단계;
    상기 계산된 RTT와, 세그먼트가 드랍될 수 있는 지에 대한 결정을 기초로, 적어도 4개의 상태(state) 중 하나로 동작하도록 결정하는 단계로서, 상기 상태는 상기 네트워크에서 혼잡의 점진적으로 더 높은 레벨을 나타내는데,
    상기 적어도 4개의 상태 중 제 1, 제 2 및 제 3 상태는 점진적으로 더 높은 RTT, 그리고 드랍된 세그먼트의 부재와 관련되고,
    상기 적어도 4개의 상태 중 제 4 상태는 세그먼트가 드랍될 수 있는 지를 결정하는 것과 결합되는, 결정 단계;
    상기 제 1 상태에서의 동작 동안, 전송 윈도우의 크기를 지수적으로 증가시키는 단계;
    상기 제 2 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 증가시키는 단계;
    상기 제 3 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 감소시키는 단계; 및
    상기 제 4 상태에서의 동작 동안, 상기 제 3 상태 동안 사용된 것과 다른 수식(formular)에 따라, 상기 전송 윈도우의 상기 크기를 감소시키는 단계를
    포함하는, 네트워크상에서 컴퓨터를 통해 데이터를 전송하는 방법.
  9. 제 8항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  10. 제 8항에 있어서, 상기 제 4 상태에서의 동작 동안, 이전에 송신되었고, 드랍 되었다고 결정된 세그먼트가 재송신되는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  11. 제 10항에 있어서, 드랍 되었다고 결정된 세그먼트의 모든 재송신은 상기 제 4 상태에서의 동작 동안 수행되는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  12. 제 10항에 있어서, 상기 전송 윈도우의 크기는 상기 제 4 상태에 들어갈 시 한 번 감소되고, 상기 전송 윈도우의 크기는 상기 제 4 상태로부터 빠져나갈 때까지 다시 감소 되지 않는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  13. 제 8항에 있어서, 어느 상태가 동작할 지의 결정은 가장 마지막에 계산된 RTT(NEW_RTT)와, 최근에 계산된 가장 작은 RTT를 나타내는 사전 결정된 MIN_RTT 값 사이의 차를 기초로 하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  14. 제 13항에 있어서, RTT의 현재 증가량을 계산하는 단계를 더 포함하고, 상기 어느 상태가 동작할 지의 상기 결정은 상기 RTT의 현재 증가량을 적어도 부분적으로 기초로 하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  15. 제 14항에 있어서, 상기 RTT의 현재 증가량은 한정된 수의 사전 확인 응답을 걸쳐 연속적인 RTT 사이의 상기 변화의 평활하게 진행하는 평균을 기초로 하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  16. 제 14항에 있어서, 상기 적어도 4개의 상태는 세그먼트가 드랍 되었는지에 대한 어떠한 결정도 존재하지 않는 동안, RTT의 현재 마이너스 증가량을 나타내는 제 5 상태를 포함하고, 상기 방법은
    상기 제 5 상태의 동작 동안, 상기 전송 윈도우를 일정하게 유지하는 단계를
    더 포함하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  17. 제 8항에 있어서, 상기 제 3 상태에서의 동작 동안, 혼잡이 주로 제 8항의 상기 방법의 상기 동작에 의해, 또는 상기 네트워크상에서의 다른 컴퓨터 또는 엔티티에 의해 전송된 데이터에 의해 야기되는 지를 결정하는 단계와, 상기 결정을 기초로 상기 전송 윈도우를 감소시키는 상이한 2개의 수식을 사용하는 단계를 더 포함하는, 네트워크상에서 컴퓨터를 통해 데이터를 송신하는 방법.
  18. 네트워크상에서 상기 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법으로서, 상기 컴퓨터는 TCP 스택 소프트웨어를 포함하고 실행하는데, 상기 TCP 스택 소프트웨어는 상기 네트워크상에서 상기 네트워크에 연결된 다른 컴퓨터로부터 들어오는 데이터를 수신하고, 송신 제어 프로토콜(TCP)의 유효한, 그리고 수락된 버전에 따라 동작하도록 구성되는데, 상기 방법은
    상기 컴퓨터를 통해 TCP 변형 소프트웨어를 실행함으로써,
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에, 상기 TCP 변형 소프트웨어를 통해 상기 들어오는 데이터를 액세스함으로써,
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에, 상기 TCP 변형 소프트웨어를 통한 상기 들어오는 데이터의 수정으로서, 상기 TCP 스택 소프트웨어의 상기 동작의 변화를 초래하도록 구성되는, 상기 들어오는 데이터의 수정을 통해, 및
    상기 수정된 들어오는 데이터를 상기 TCP 스택 소프트웨어에 전송함으로써
    상기 TCP 스택 소프트웨어를 크게 수정하는 것 없이, 상기 TCP 스택 소프트웨어의 동작을 수정하는 단계를 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  19. 제 18항에 있어서, 상기 방법은 상기 TCP 스택 소프트웨어를 전혀 수정하지 않고 수행되는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  20. 제 18항에 있어서, 상기 들어오는 데이터를 수정하는 것은 상기 들어오는 데이터가 상기 컴퓨터에 도달한 이후에 수행되는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  21. 제 18항에 있어서, 상기 들어오는 데이터의 상기 수정은 상기 네트워크 세그먼트를 상기 들어오는 데이터에 추가하는 것을 포함하고, 상기 네트워크 세그먼트는 상기 네트워크에 연결된 다른 컴퓨터에 의해 수신되는 세그먼트로서 상기 TCP 스택 소프트웨어에 의해 다루어지는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  22. 제 18항에 있어서, 상기 들어오는 데이터의 상기 수정은 상기 들어오는 데이터에서 들어오는 기존의 네트워크 세그먼트의 저장된 상기 데이터를 수정하는 것을 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  23. 제 18항에 있어서, 상기 TCP 스택 소프트웨어의 상기 동작의 상기 변화는 TCP 변형 소프트웨어와 결합한 상기 TCP 스택 소프트웨어가 상기 TCP 프로토콜에 의해 허용된 크기보다 더 큰 효율적인 전송 윈도우(SWND)의 크기를 기초로 통신하게 하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  24. 제 23항에 있어서, 상기 들어오는 데이터를 수정하는 것은 상기 들어오는 데이터에 하나 이상의 우선적 확인 응답을 배치시키는 것을 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  25. 제 24항에 있어서, 상기 우선적 확인 응답은 상기 TCP 변형 소프트웨어에 의해 생성되고 추가된 새로운 네트워크의 세그먼트 내에 배치되는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  26. 제 24항에 있어서, 상기 우선적 확인 응답은 상기 들어오는 데이터의 기존의 네트워크 세그먼트 내에 배치되는데, 상기 기존의 네트워크 세그먼트는 상기 네트워크에 연결된 원격 컴퓨터로부터 수신되고, 상기 TCP 변형 소프트웨어에 의해 액세스 되며, 상기 우선적 확인 응답을 배치시키는 것은 상기 기존의 네트워크 세그먼트에서 기존의 확인 응답을 수정하는 것을 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  27. 제 23항에 있어서,
    상기 TCP 스택 소프트웨어를 통해 데이터를 상기 네트워크에 연결된 원격 컴퓨터에 송신하는 단계,
    상기 TCP 변형 소프트웨어를 통해 상기 TCP 스택 소프트웨어에 의해 송신된 상기 데이터를 차단하는 단계, 및
    상기 TCP 변형 소프트웨어를 통해 상기 데이터를 선택적으로 버퍼링(buffering), 송신 및 재송신하는 단계를
    더 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  28. 제 27항에 있어서, 상기 TCP 변형 소프트웨어를 통해 상기 데이터를 선택적인 버퍼링, 송신 및 재송신하는 단계는 예를 들어, TCP 변형 소프트웨어 및 TCP 스택 소프트웨어가 상기 송신 제어 프로토콜에 의해 허용된 크기보다 더 큰 전송 윈도우(SWND)의 크기를 기초로 하는 데이터를 함께 송신하는 것을 허용하기 위한 것이고, 그렇지 않을 경우 상기 데이터의 송신은 상기 송신 제어 프로토콜을 준수하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  29. 제 18항에 있어서, 상기 TCP 변형 소프트웨어를 통해 상기 들어오는 데이터를 수정하는 것은 상기 TCP 스택 소프트웨어로부터 임의의 패킷 손실 조건을 은폐하는 방식으로 상기 들어오는 데이터를 수정하는 것을 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  30. 제 29항에 있어서,
    상기 TCP 변형 소프트웨어를 통해 패킷 손실 조건을 검출하는 단계, 및
    상기 TCP 변형 소프트웨어를 통해 상기 패킷 손실 조건에 의해 요구되는 임의의 재송신을 수행하는 단계를
    더 포함하는, 네트워크에 연결된 컴퓨터를 통해 데이터를 송신하는 방법.
  31. 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체로서, 상기 지령은 처리기를 통한 실행을 위해 구성되고, 상기 처리기가 혼잡을 회피하면서, 네트워크상에서 데이터를 송신하도록 구성되며, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 지령은 상기 처리기로 하여금
    송신된 세그먼트의 왕복 시간(RTT)을 계산하게 하고,
    상기 계산된 RTT를 기초로 전송 윈도우의 크기를 수정하도록
    더 구성되며, 상기 변조는 송신율에 의존하지 않는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  32. 제 31항에 있어서, 상기 프로토콜은 상기 송신 제어 프로토콜(TCP)인, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  33. 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체로서, 상기 지령은 처리기를 통한 실행을 위해 구성되고, 상기 처리기로 하여금 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 지령은 상기 처리기로 하여금
    상기 제 1 시간 동안 데이터를 송신할 때, 제 1 모드에 따라 전송 윈도우의 크기를 제어하고,
    이미 송신된 데이터가 상기 네트워크에 의해 드랍될 수 있다는 것의 결정 시 상기 이미 송신된 데이터를 재-송신할 때 제 2 모드에 따라 전송 윈도우의 크기를 제어하도록
    더 구성되고, 상기 전송 윈도우의 상기 크기를 제어하는 것의 상기 제 1 및 제 2 모드는 상이한, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  34. 제 33항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  35. 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체로서, 상기 지령은 처리기를 통한 실행을 위해 구성되고, 상기 처리기로 하여금 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 지령은 상기 처리기로 하여금
    송신된 세그먼트의 왕복 시간(RTT)을 계산하고,
    상기 계산된 RTT와, 상기 계산된 RTT의 변화율을 기초로 전송 윈도우의 크기를 수정하도록
    더 구성되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  36. 제 35항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  37. 제 35항에 있어서, 상기 전송 윈도우의 크기를 수정하는 것은 일정 시간의 기간에 걸쳐 상기 계산된 RTT의 변동을 더 기초로 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  38. 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체로서, 상기 지령은 처리기를 통한 실행을 위해 구성되고, 상기 처리기로 하여금 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되고, 상기 지령은 상기 처리기로 하여금
    송신된 세그먼트의 왕복 시간(RTT)을 계산하고;
    송신된 세그먼트가 상기 네트워크에 의해 드랍될 수 있는지를 결정하고;
    상기 계산된 RTT와, 세그먼트가 드랍될 수 있는 지에 대한 결정을 기초로, 상기 네트워크에서 혼잡의 점진적으로 더 큰 레벨을 나타내는 적어도 4개의 상태 중 하나로 동작하도록 결정하는데,
    상기 적어도 4개의 상태 중 제 1, 제 2 및 제 3 상태는 점진적으로 더 큰 RTT, 및 드랍된 세그먼트의 부재와 결합되고,
    적어도 4개의 상태 중 제 4 상태는 세그먼트가 드랍될 수 있는지에 대한 결정과 결합되고;
    상기 제 1 상태에서의 동작 동안, 전송 윈도우의 크기를 지수적으로 증가시키고;
    상기 제 2 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 증가시키고;
    상기 제 3 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 감소시키고; 및
    상기 제 4 상태에서의 동작 동안, 상기 제 3 상태 동안 사용된 것과 다른 수식에 따라, 상기 전송 윈도우의 상기 크기를 감소시키도록
    더 구성되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  39. 제 38항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  40. 제 38항에 있어서, 상기 제 4 상태에서의 동작 동안, 이전에 송신되고, 드랍 된 것으로 결정된 세그먼트가 재송신되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  41. 제 40항에 있어서, 드랍된 것으로 결정된 세그먼트의 모든 재송신은 상기 제 4 상태에서의 동작 동안 수행되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  42. 제 40항에 있어서, 상기 전송 윈도우의 크기는 제 4 상태에 들어갈 시 한 번 감소되고, 상기 전송 윈도우의 크기는 상기 제 4 상태를 빠져나갈 때까지 다시 감소되진 않는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  43. 제 38항에 있어서, 어느 상태가 동작할 지의 결정은 가장 마지막에 계산된 RTT(NEW_RTT)와, 최근에 계산된 가장 작은 RTT를 나타내는 사전 한정된 MIN_RTT 값 사이의 차를 기초로 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  44. 제 43항에 있어서, RTT의 상기 현재 증가량을 계산하는 것을 더 포함하고, 상기 어느 상태가 동작할 지의 결정은 RTT의 상기 현재 증가량을 적어도 부분적으로 기초로 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  45. 제 44항에 있어서, RTT의 상기 현재 증가량은 사전 한정된 수의 확인 응답을 걸쳐 연속적인 RTT 사이의 상기 변화의 평활화된 진행(running) 평균을 기초로 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  46. 제 44항에 있어서, 상기 적어도 4개의 상태는 세그먼트가 드랍 되었다는 어떠한 결정도 존재하지 않는 동안, RTT의 현재 마이너스 증가량을 나타내는 제 5 상태를 포함하고, 상기 지령은 상기 처리기가
    상기 제 5 상태의 동작 동안, 상기 전송 윈도우를 일정하게 유지하도록 추가로 구성되는 것을
    특징으로 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  47. 제 38항에 있어서, 상기 지령은 상기 처리기로 하여금,
    상기 제 3 상태에서의 동작 동안, 혼잡이 주로 처리기에 의해 전송된 데이터에 의해, 또는 상기 네트워크상에서 다른 컴퓨터 또는 엔티티에 의해 전송된 데이터에 의해 야기되는 지를 결정하고, 상기 결정을 기초로 하는 상기 전송 윈도우를 감소시키는 2개의 상이한 수식을 사용하도록 더 구성되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  48. TCP 변형 소프트웨어를 포함하는 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체로서, 상기 컴퓨터 실행 가능 지령은 네트워크에 연결된 컴퓨터의 일부인 처리기를 통한 실행을 위해 구성되고, 상기 컴퓨터는 TCP 스택 소프트웨어를 포함하고 실행하며, 상기 TCP 스택 소프트웨어는 컴퓨터가 상기 네트워크상에서 상기 네트워크에 연결된 다른 컴퓨터로부터 들어오는 데이터를 수신하고, 상기 송신 제어 프로토콜(TCP)의 유효한, 그리고 수락된 버전에 따라 거동하도록 구성되고, 상기 지령은 상기 처리기로 하여금
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에 상기 들어오는 데이터를 액세스하고,
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에, 상기 TCP 스택 소프트웨어의 상기 동작의 변화를 초래하도록, 상기 들어오는 데이터를 수정하며, 및
    상기 수정된 들어오는 데이터를 상기 TCP 스택 소프트웨어에 전송하도록
    함으로써, 상기 TCP 스택 소프트웨어를 크게 수정하는 것 없이, 상기 TCP 스택 소프트웨어의 동작을 수정하도록 구성되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  49. 제 48항에 있어서, 상기 지령은 상기 TCP 스택 소프트웨어를 전혀 수정하지 않는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  50. 제 48항에 있어서, 상기 들어오는 데이터의 상기 수정은 상기 들어오는 데이터가 상기 컴퓨터에 도달한 이후에 수행되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  51. 제 48항에 있어서, 상기 들어오는 데이터의 상기 수정은 상기 들어오는 데이터에 네트워크 세그먼트를 추가하는 것을 포함하고, 상기 네트워크 세그먼트는 상기 네트워크에 연결된 다른 컴퓨터에 의해 수신된 세그먼트로서 상기 TCP 스택 소프트웨어에 의해 다루어지는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  52. 제 48항에 있어서, 상기 들어오는 데이터의 상기 수정은 상기 들어오는 데이터에서 들어오는 기존의 네트워크 세그먼트의 저장된 상기 데이터를 수정하는 것을 포함하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  53. 제 48항에 있어서, 상기 TCP 스택 소프트웨어의 상기 동작의 상기 변화는 TCP 변형 소프트웨어와 결합한 상기 TCP 스택 소프트웨어가 상기 TCP 프로토콜에 의해 허용된 크기보다 더 큰 효율적인 전송 윈도우(SWND)의 크기를 기초로 통신하게 하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  54. 제 53항에 있어서, 상기 들어오는 데이터를 수정하는 것은 하나 이상의 우선적 확인 응답을 상기 들어오는 데이터에 배치시키는 것을 포함하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  55. 제 54에 있어서, 상기 우선적 확인 응답은 상기 TCP 변형 소프트웨어에 의해 생성되고 추가된 새로운 네트워크의 세그먼트 내에 배치되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  56. 제 54항에 있어서, 상기 우선적 확인 응답은 상기 들어오는 데이터의 기존의 네트워크 세그먼트 내에 배치되는데, 상기 기존의 네트워크 세그먼트는 상기 네트워크에 연결된 원격 컴퓨터로부터 수신되고, 상기 TCP 변형 소프트웨어에 의해 액세스 되며, 상기 우선적 확인 응답을 배치시키는 것은 상기 기존의 네트워크 세그먼트에서 기존의 확인 응답을 수정하는 것을 포함하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  57. 제 53항에 있어서, 상기 TCP 스택 소프트웨어는 상기 네트워크에 연결된 원격 컴퓨터에 데이터를 송신하기 위해 더 구성되고, 상기 지령은 상기 처리기로 하여금
    상기 TCP 스택 소프트웨어에 의해 송신된 상기 데이터를 더 차단하고,
    데이터를 선택적으로 더 버퍼링(buffering), 송신 및 재송신하게
    하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  58. 제 57항에 있어서, 상기 TCP 변형 소프트웨어를 통해 상기 데이터를 선택적으로 버퍼링, 송신 및 재송신하는 것은 예를 들어, TCP 변형 소프트웨어 및 TCP 스택 소프트웨어가 상기 송신 제어 프로토콜에 의해 허용된 크기보다 더 큰 전송 윈도우(SWND)의 크기를 기초로 데이터를 함께 송신하는 것을 허용하기 위한 것이고, 그렇지 않을 경우 상기 데이터 송신은 상기 송신 제어 프로토콜을 준수하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  59. 제 48항에 있어서, 상기 들어오는 데이터를 수정하는 것은 상기 TCP 스택 소프트웨어로부터 임의의 패킷 손실 조건을 은폐하는 방식으로 상기 들어오는 데이터를 수정하는 것을 포함하는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  60. 제 59항에 있어서, 상기 지령은 상기 처리기가
    상기 TCP 변형 소프트웨어를 통해 패킷 손실 조건을 더 검출하고, 및
    상기 TCP 변형 소프트웨어를 통해 상기 패킷 손실 조건에 의해 요구되는 임의의 재송신을 더 수행하도록
    구성되는, 컴퓨터 실행 가능 지령을 포함하는 컴퓨터 판독 가능 매체.
  61. 네트워크에 연결된 계산 시스템에 있어서, 상기 계산 시스템은 처리기 및 메모리를 포함하고, 상기 메모리는 상기 처리기가 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되는 복수의 지령을 포함하고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되며, 상기 지령은 상기 처리기가
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계, 및
    상기 계산된 RTT를 기초로 하여 전송 윈도우의 크기를 수정하는 단계를
    더 수행하게 하며, 상기 수정은 송신율에 의존하지 않는, 계산 시스템.
  62. 제 61항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 계산 시스템.
  63. 네트워크에 연결된 계산 시스템에 있어서, 상기 계산 시스템은 처리기 및 메모리를 포함하고, 상기 메모리는 상기 처리기가 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되는 복수의 지령을 포함하고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되며, 상기 지령은 상기 처리기가
    상기 제 1 시간 동안 데이터를 송신할 때, 제 1 모드에 따라 전송 윈도우의 크기를 제어하는 단계, 및
    이미 송신된 데이터가 상기 네트워크에 의해 드랍되었는 지에 대한 결정 시, 상기 이미 송신된 데이터를 재-송신할 때 제 2 모드에 따라 전송 윈도우의 크기를 제어하는 단계를
    더 수행하게 하고, 상기 전송 윈도우의 상기 크기를 제어하는 상기 제 1 및 제 2 모드는 상이한, 계산 시스템.
  64. 제 63항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 계산 시스템.
  65. 네트워크에 연결된 계산 시스템에 있어서, 상기 계산 시스템은 처리기 및 메모리를 포함하고, 상기 메모리는 상기 처리기가 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되는 복수의 지령을 포함하고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되며, 상기 지령은 상기 처리기가
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계, 및
    상기 계산된 RTT와, 상기 계산된 RTT의 변화율을 기초로 하는 전송 윈도우의 크기를 수정하는 단계를
    더 수행하게 하는, 계산 시스템.
  66. 제 65항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 계산 시스템.
  67. 제 65항에 있어서, 상기 전송 윈도우의 상기 크기를 수정하는 단계는 일정 시간의 기간을 걸쳐 상기 계산된 RTT의 변동을 더 기초로 하는, 계산 시스템.
  68. 네트워크에 연결된 계산 시스템으로서, 상기 계산 시스템은 처리기 및 메모리를 포함하고, 상기 메모리는 상기 처리기가 혼잡을 회피하면서 네트워크상에서 데이터를 송신하도록 구성되는 복수의 지령을 포함하고, 상기 송신은 슬라이딩 윈도우를 활용하는 프로토콜에 따라 수행되며, 상기 지령은 상기 처리기가
    송신된 세그먼트의 왕복 시간(RTT)을 계산하는 단계,
    송신된 세그먼트가 상기 네트워크에 의해 드랍되었는 지를 결정하는 단계,
    상기 계산된 RTT와, 세그먼트가 드랍되었는 지에 대한 결정을 기초로, 상기 네트워크에서 혼잡의 점진적으로 더 큰 레벨을 나타내는 적어도 4개의 상태 중 하나로 동작하도록 결정하는 단계로서,
    상기 적어도 4개의 상태 중 제 1, 제 2 및 제 3 상태는 점진적으로 더 큰 RTT, 및 드랍된 세그먼트의 부재와 결합되고,
    적어도 4개의 상태 중 제 4 상태는 세그먼트가 드랍 되었는지에 대한 결정과 결합되는, 결정 단계,
    상기 제 1 상태에서의 동작 동안, 전송 윈도우의 크기를 지수적으로 증가시키는 단계,
    상기 제 2 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 증가시키는 단계;
    상기 제 3 상태에서의 동작 동안, 상기 전송 윈도우의 크기를 선형적으로 감소시키는 단계; 및
    상기 제 4 상태에서의 동작 동안, 상기 제 3 상태 동안 사용된 것과 다른 수식에 따라, 상기 전송 윈도우의 상기 크기를 감소시키는 단계를
    더 수행하게 하는, 계산 시스템.
  69. 제 68항에 있어서, 상기 프로토콜은 송신 제어 프로토콜(TCP)인, 계산 시스템.
  70. 제 68항에 있어서, 상기 제 4 상태에서의 동작 동안, 이전에 송신되고, 드랍 된 것으로 결정된 세그먼트가 재송신되는, 계산 시스템.
  71. 제 70항에 있어서, 드랍된 것으로 결정된 세그먼트의 모든 재송신은 상기 제 4 상태에서의 동작 동안 수행되는, 계산 시스템.
  72. 제 70항에 있어서, 상기 전송 윈도우의 크기는 제 4 상태에 들어갈 시 한 번 감소되고, 상기 전송 윈도우의 크기는 상기 제 4 상태로부터 빠져나갈 때까지 다시 감소되지 않는, 계산 시스템.
  73. 제 68항에 있어서, 어느 상태가 동작할 지의 결정은 가장 마지막에 계산된 RTT(NEW_RTT)와, 최근에 계산된 가장 작은 RTT를 나타내는 사전 결정된 MIN_RTT 값 사이의 차를 기초로 하는, 계산 시스템.
  74. 제 73항에 있어서, 상기 지령은 상기 처리기가 RTT의 현재 증가량을 계산하는 단계를 더 수행하게 하고, 어느 상태가 동작할 지의 결정은 RTT의 상기 현재 증가량을 적어도 부분적으로 기초로 하는, 계산 시스템.
  75. 제 74항에 있어서, RTT의 상기 현재 증가량은 사전 한정된 수의 확인 응답을 걸쳐 연속적인 RTT 사이의 상기 변화의 평활화된 진행 평균을 기초로 하는, 계산 시스템.
  76. 제 74항에 있어서, 상기 적어도 4개의 상태는 세그먼트가 드랍되었는 지에 대한 어떠한 결정도 존재하지 않는 동안, RTT의 현재 마이너스 증가량을 나타내는 제 5 상태를 포함하고, 상기 지령은 상기 처리기가
    상기 제 5 상태의 동작 동안, 상기 전송 윈도우를 일정하게 유지하는 단계를
    수행하도록 더 구성되는, 계산 시스템.
  77. 제 78항에 있어서, 상기 지령은 상기 처리기가
    상기 제 3 상태에서의 동작 동안, 혼잡이 주로 처리기의 동작에 의해, 또는 상기 네트워크상에서의 다른 컴퓨터 또는 엔티티에 의해 전송된 데이터에 의해 야기되는 지를 결정하는 단계와,
    상기 결정을 기초로 하여 상기 전송 윈도우를 감소시키는 2개의 상이한 수식을 사용하는 단계를
    수행하도록 더 구성되는, 계산 시스템.
  78. 네트워크에 연결된 계산 시스템에 있어서, 상기 계산 시스템은 처리기 및 메모리를 포함하고, 상기 메모리는 TCP 스택 소프트웨어와 TCP 변형 소프트웨어를 포함하는 복수의 지령을 포함하고, 상기 TCP 스택 소프트웨어는 상기 네트워크상에서, 상기 네트워크에 연결된 다른 컴퓨터로부터 들어오는 데이터를 수신하고, 송신 제어 프로토콜(TCP)의 유효한, 그리고 수락된 버전에 따라 동작하도록 구성되고, 상기 TCP 변형 소프트웨어는 상기 처리기로 하여금
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에 상기 들어오는 데이터를 액세스하는 단계,
    상기 들어오는 데이터가 상기 TCP 스택 소프트웨어에 도달하기 전에, 상기 TCP 스택 소프트웨어의 상기 동작의 변화를 초래하도록 구성하기 위해, 상기 들어오는 데이터를 수정하는 단계, 및
    상기 수정된 들어오는 데이터를 상기 TCP 스택 소프트웨어에 전송하는 단계를
    수행하게 함으로써, 상기 TCP 스택 소프트웨어를 크게 수정하는 것 없이, 상기 처리기가 상기 TCP 스택 소프트웨어의 상기 동작을 수정하도록 구성되는, 계산 시스템.
  79. 제 78항에 있어서, 상기 처리기는 상기 TCP 변형 소프트웨어를 실행하는 결과로서, 상기 TCP 스택 소프트웨어를 전혀 수정하지 않는, 계산 시스템.
  80. 제 78항에 있어서, 상기 들어오는 데이터를 수정하는 것은 상기 들어오는 데이터가 상기 컴퓨터에 도달한 이후에 수행되는, 계산 시스템.
  81. 제 78항에 있어서, 상기 들어오는 데이터의 수정은 상기 들어오는 데이터에 네트워크 세그먼트를 추가시키는 것을 포함하고, 상기 네트워크는 상기 네트워크에 연결된 다른 컴퓨터에 의해 수신된 세그먼트로서 상기 TCP 스택 소프트웨어에 의해 다루어지는, 계산 시스템.
  82. 제 78항에 있어서, 상기 들어오는 데이터의 수정은 상기 들어오는 데이터에서 들어오는 기존의 네트워크 세그먼트의 저장된 상기 데이터를 수정하는 것을 포함하는, 계산 시스템.
  83. 제 78항에 있어서, 상기 TCP 스택 소프트웨어의 동작의 변화는 상기 TCP 변형 소프트웨어와 관련된 상기 TCP 스택 소프트웨어가 TCP 프로토콜에 의해 허용되는 크기보다 더 크고 효율적인 전송 윈도우(SWND)의 크기를 기초로 통신하게 하는, 계산 시스템.
  84. 제 83항에 있어서, 상기 들어오는 데이터를 수정하는 것은 상기 들어오는 데이터에 하나 이상의 우선적 확인 응답을 배치시키는 것을 포함하는, 계산 시스템.
  85. 제 84항에 있어서, 상기 우선적 확인 응답은 상기 TCP 변형 소프트웨어에 의해 생성되고 추가된 새로운 네트워크 내에 배치되는, 계산 시스템.
  86. 제 84항에 있어서, 상기 우선적 확인 응답은 상기 들어오는 데이터의 기존의 네트워크 세그먼트 내에 배치되는데, 상기 기존의 네트워크 세그먼트는 상기 네트워크에 연결된 원격 컴퓨터로부터 수신되고, 상기 TCP 소프트웨어에 의해 액세스되며, 상기 우선적 확인 응답을 배치시키는 것은 상기 기존의 네트워크 세그먼트 에서 기존의 확인 응답을 수정하는 것을 포함하는, 계산 시스템.
  87. 제 83항에 있어서, 상기 TCP 스택 소프트웨어는 상기 네트워크에 연결된 원격 컴퓨터에 데이터를 더 송신하고, 상기 TCP 변형 소프트웨어는 상기 처리기로 하여금,
    상기 TCP 스택 소프트웨어에 의해 송신된 상기 데이터를 차단하는 단계, 및
    상기 데이터를 선택적으로 버퍼링, 송신 및 재송신하는 단계를
    더 수행하게 하는, 계산 시스템.
  88. 제 87항에 있어서, 상기 TCP 변형 소프트웨어를 실행할 때, 상기 처리기를 통해 상기 데이터를 선택적으로 버퍼링, 송신 및 재송신하는 단계는 예를 들어, TCP 변형 소프트웨어 및 TCP 스택 소프트웨어가 상기 송신 제어 프로토콜에 의해 허용된 크기보다 더 큰 전송 윈도우(SWND)의 크기를 기초로 하여 데이터를 함께 송신하는 것을 허용하기 위한 것이고, 그렇지 않을 경우 상기 데이터의 송신은 상기 송신 제어 프로토콜을 준수하는, 계산 시스템.
  89. 제 78항에 있어서, 상기 처리기를 통해 상기 들어오는 데이터를 수정하는 단계는 상기 TCP 변형 소프트웨어를 실행할 때, 상기 TCP 스택 소프트웨어로부터 임의의 패킷 분실 조건을 은폐하는 방식으로 상기 들어오는 데이터를 수정하는 것을 포함하는, 계산 시스템.
  90. 제 89항에 있어서, 상기 TCP 변형 소프트웨어는 상기 처리기로 하여금
    상기 TCP 변형 소프트웨어를 통해 패킷 손실 조건을 검출하는 단계, 및
    상기 패킷 손실 조건에 의해 요구된 임의의 재송신을 수행하는 단계를
    수행하도록 더 구성되는, 계산 시스템.
KR1020117016718A 2009-01-16 2009-10-21 송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법 KR20120004961A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14550509P 2009-01-16 2009-01-16
US61/145,505 2009-01-16

Publications (1)

Publication Number Publication Date
KR20120004961A true KR20120004961A (ko) 2012-01-13

Family

ID=42139066

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020117016718A KR20120004961A (ko) 2009-01-16 2009-10-21 송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법

Country Status (9)

Country Link
US (1) US9882831B2 (ko)
EP (2) EP2661030A3 (ko)
JP (1) JP2012515491A (ko)
KR (1) KR20120004961A (ko)
CN (2) CN102484609B (ko)
AU (1) AU2009337511A1 (ko)
CA (1) CA2749826A1 (ko)
TW (1) TW201108687A (ko)
WO (1) WO2010082091A2 (ko)

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2481971B (en) * 2010-07-07 2016-12-21 Cray Uk Ltd Apparatus & method
JP5625748B2 (ja) * 2010-10-28 2014-11-19 ソニー株式会社 通信装置、通信システム、プログラム及び通信方法
US9059934B2 (en) 2012-02-24 2015-06-16 Citrix Systems, Inc. Window regulator for improved performance in a communications network
US9413672B2 (en) * 2012-06-06 2016-08-09 Apple Inc. Flow control for network packets from applications in electronic devices
US10009445B2 (en) * 2012-06-14 2018-06-26 Qualcomm Incorporated Avoiding unwanted TCP retransmissions using optimistic window adjustments
WO2014069642A1 (ja) * 2012-11-05 2014-05-08 日本電気株式会社 通信装置、送信データ出力制御方法、及びそのプログラム
US10136355B2 (en) 2012-11-26 2018-11-20 Vasona Networks, Inc. Reducing signaling load on a mobile network
US9286047B1 (en) 2013-02-13 2016-03-15 Cisco Technology, Inc. Deployment and upgrade of network devices in a network environment
JP2014165551A (ja) * 2013-02-21 2014-09-08 Fujitsu Ltd 通信装置、通信方法、プログラム、及び、通信システム
US9444741B2 (en) * 2013-03-11 2016-09-13 Broadcom Corporation Facilitating network flows
US9769288B2 (en) * 2013-04-06 2017-09-19 Citrix Systems, Inc. Systems and methods for dynamic receive buffering
US20140337505A1 (en) * 2013-05-08 2014-11-13 Htc Corporation Method for data transmission and corresponding electronic device
JP6205912B2 (ja) * 2013-07-05 2017-10-04 富士通株式会社 情報処理装置、配信方法および配信プログラム
US9385959B2 (en) 2013-09-26 2016-07-05 Acelio, Inc. System and method for improving TCP performance in virtualized environments
US10355997B2 (en) 2013-09-26 2019-07-16 Appformix Inc. System and method for improving TCP performance in virtualized environments
US10291472B2 (en) 2015-07-29 2019-05-14 AppFormix, Inc. Assessment of operational states of a computing environment
US10581687B2 (en) 2013-09-26 2020-03-03 Appformix Inc. Real-time cloud-infrastructure policy implementation and management
US9397915B2 (en) 2013-11-12 2016-07-19 Vasona Networks Inc. Reducing time period of data travel in a wireless network
US9345041B2 (en) 2013-11-12 2016-05-17 Vasona Networks Inc. Adjusting delaying of arrival of data at a base station
WO2015071891A1 (en) * 2013-11-12 2015-05-21 Vasona Networks Inc. Supervision of data in a wireless network
EP3069567A4 (en) * 2013-11-12 2017-04-26 Vasona Networks, Inc. Reducing time period of data travel in a wireless network
US10341881B2 (en) * 2013-11-12 2019-07-02 Vasona Networks, Inc. Supervision of data in a wireless network
US10039028B2 (en) 2013-11-12 2018-07-31 Vasona Networks Inc. Congestion in a wireless network
WO2015071892A1 (en) * 2013-11-12 2015-05-21 Vasona Networks Inc. Congestion in a wireless network
EP3069476B1 (en) * 2013-11-12 2021-04-07 Vasona Networks, Inc. Adjusting delaying of arrival of data at a base station
CN103841042B (zh) * 2014-02-19 2017-09-19 华为技术有限公司 在高运行效率下传输数据的方法和装置
US10708187B2 (en) * 2014-05-22 2020-07-07 Intel Corporation Data center congestion management for non-TCP traffic
CN105432054B (zh) 2014-06-25 2019-04-05 华为技术有限公司 确定传输缓存量的方法和设备
US9906454B2 (en) 2014-09-17 2018-02-27 AppFormix, Inc. System and method for providing quality of service to data center applications by controlling the rate at which data packets are transmitted
CN105763474B (zh) * 2014-12-19 2019-10-25 华为技术有限公司 数据传输方法和装置
US10374904B2 (en) 2015-05-15 2019-08-06 Cisco Technology, Inc. Diagnostic network visualization
US9800497B2 (en) 2015-05-27 2017-10-24 Cisco Technology, Inc. Operations, administration and management (OAM) in overlay data center environments
US11278798B2 (en) 2015-05-29 2022-03-22 Netduma Software, LTD. Selecting a connection in a network
US10581746B2 (en) 2015-05-29 2020-03-03 Netduma Software, LTD. Selecting a connection in a network
US10089099B2 (en) 2015-06-05 2018-10-02 Cisco Technology, Inc. Automatic software upgrade
US10033766B2 (en) 2015-06-05 2018-07-24 Cisco Technology, Inc. Policy-driven compliance
US10536357B2 (en) 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US10142353B2 (en) 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US9967158B2 (en) 2015-06-05 2018-05-08 Cisco Technology, Inc. Interactive hierarchical network chord diagram for application dependency mapping
US20170324641A1 (en) * 2016-05-04 2017-11-09 Microsoft Technology Licensing, Llc Modified slow start for background connections
US10298504B2 (en) * 2016-05-04 2019-05-21 Microsoft Technology Licensing, Llc Adaptive gain reduction for background connections
US10931629B2 (en) 2016-05-27 2021-02-23 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10171357B2 (en) 2016-05-27 2019-01-01 Cisco Technology, Inc. Techniques for managing software defined networking controller in-band communications in a data center network
US10574706B2 (en) * 2016-05-29 2020-02-25 Flash Networks, Ltd Method and system for upload optimization
CN105827537B (zh) * 2016-06-01 2018-12-07 四川大学 一种基于quic协议的拥塞改进方法
US10289438B2 (en) 2016-06-16 2019-05-14 Cisco Technology, Inc. Techniques for coordination of application components deployed on distributed virtual machines
US10708183B2 (en) 2016-07-21 2020-07-07 Cisco Technology, Inc. System and method of providing segment routing as a service
US10715442B2 (en) * 2016-08-23 2020-07-14 Netduma Software, LTD. Congestion control
US11570117B2 (en) * 2016-08-23 2023-01-31 Netduma Software, LTD. Congestion control
US10986030B2 (en) 2016-08-23 2021-04-20 Netduma Software, LTD. Congestion control
TWI641251B (zh) * 2016-11-18 2018-11-11 財團法人工業技術研究院 網路流量監控方法與系統
US10972388B2 (en) 2016-11-22 2021-04-06 Cisco Technology, Inc. Federated microburst detection
US10050884B1 (en) * 2017-03-21 2018-08-14 Citrix Systems, Inc. Method to remap high priority connection with large congestion window to high latency link to achieve better performance
US10708152B2 (en) 2017-03-23 2020-07-07 Cisco Technology, Inc. Predicting application and network performance
US10523512B2 (en) 2017-03-24 2019-12-31 Cisco Technology, Inc. Network agent for generating platform specific network policies
US10250446B2 (en) 2017-03-27 2019-04-02 Cisco Technology, Inc. Distributed policy store
US10594560B2 (en) 2017-03-27 2020-03-17 Cisco Technology, Inc. Intent driven network policy platform
US10764141B2 (en) 2017-03-27 2020-09-01 Cisco Technology, Inc. Network agent for reporting to a network policy system
US10873794B2 (en) 2017-03-28 2020-12-22 Cisco Technology, Inc. Flowlet resolution for application performance monitoring and management
US10868742B2 (en) 2017-03-29 2020-12-15 Juniper Networks, Inc. Multi-cluster dashboard for distributed virtualization infrastructure element monitoring and policy control
US11068314B2 (en) 2017-03-29 2021-07-20 Juniper Networks, Inc. Micro-level monitoring, visibility and control of shared resources internal to a processor of a host machine for a virtual environment
CN107135163A (zh) * 2017-04-12 2017-09-05 上海大学 一种基于无人机宽带数据链下行链路的传输控制方法
US11323327B1 (en) 2017-04-19 2022-05-03 Juniper Networks, Inc. Virtualization infrastructure element monitoring and policy control in a cloud environment using profiles
US10659376B2 (en) 2017-05-18 2020-05-19 International Business Machines Corporation Throttling backbone computing regarding completion operations
US10680887B2 (en) 2017-07-21 2020-06-09 Cisco Technology, Inc. Remote device status audit and recovery
US10554501B2 (en) 2017-10-23 2020-02-04 Cisco Technology, Inc. Network migration assistant
US10523541B2 (en) 2017-10-25 2019-12-31 Cisco Technology, Inc. Federated network and application data analytics platform
US10594542B2 (en) 2017-10-27 2020-03-17 Cisco Technology, Inc. System and method for network root cause analysis
CN108111434B (zh) * 2017-12-14 2021-03-16 四川大学 一种基于可靠udp和喷泉码的航空自组网可靠传输方法
US11233821B2 (en) 2018-01-04 2022-01-25 Cisco Technology, Inc. Network intrusion counter-intelligence
US11765046B1 (en) 2018-01-11 2023-09-19 Cisco Technology, Inc. Endpoint cluster assignment and query generation
US10873593B2 (en) 2018-01-25 2020-12-22 Cisco Technology, Inc. Mechanism for identifying differences between network snapshots
US10574575B2 (en) 2018-01-25 2020-02-25 Cisco Technology, Inc. Network flow stitching using middle box flow stitching
US10798015B2 (en) 2018-01-25 2020-10-06 Cisco Technology, Inc. Discovery of middleboxes using traffic flow stitching
US10917438B2 (en) 2018-01-25 2021-02-09 Cisco Technology, Inc. Secure publishing for policy updates
US10999149B2 (en) 2018-01-25 2021-05-04 Cisco Technology, Inc. Automatic configuration discovery based on traffic flow data
US10826803B2 (en) 2018-01-25 2020-11-03 Cisco Technology, Inc. Mechanism for facilitating efficient policy updates
US11128700B2 (en) 2018-01-26 2021-09-21 Cisco Technology, Inc. Load balancing configuration based on traffic flow telemetry
TWI689820B (zh) * 2018-08-23 2020-04-01 瑞昱半導體股份有限公司 Usb傳輸系統、usb裝置與支援usb傳輸的主機
CN110874334B (zh) * 2018-08-30 2023-10-20 瑞昱半导体股份有限公司 Usb传输系统、usb装置与支持usb传输的主机
TWI727269B (zh) * 2019-02-27 2021-05-11 瑞昱半導體股份有限公司 通用序列匯流排裝置及其資料傳輸方法
US10999206B2 (en) 2019-06-27 2021-05-04 Google Llc Congestion control for low latency datacenter networks
CN112584525B (zh) * 2020-12-07 2023-02-03 广州技象科技有限公司 基于多用户接入的上行数据分割方法及装置
CN112822230B (zh) * 2020-12-28 2022-03-25 南京大学 一种基于概率的发送端初始速率设置方法和系统
CN117835317A (zh) * 2023-10-19 2024-04-05 湖北星纪魅族科技有限公司 短距数据传输方法、装置、电子设备和存储介质

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3000546B2 (ja) * 1997-03-07 2000-01-17 株式会社超高速ネットワーク・コンピュータ技術研究所 輻輳制御方法
JPH11112576A (ja) * 1997-10-06 1999-04-23 Hitachi Ltd インターネットワーク装置のコネクション制御方法
EP0948168A1 (en) * 1998-03-31 1999-10-06 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Method and device for data flow control
US7367045B2 (en) 2002-03-16 2008-04-29 Trustedflow Systems, Inc. Trusted communications system
EP1376944B1 (en) * 2002-06-18 2006-05-10 Matsushita Electric Industrial Co., Ltd. Receiver-initiated transmission rate increment
US20070008884A1 (en) * 2003-10-08 2007-01-11 Bob Tang Immediate ready implementation of virtually congestion free guarantedd service capable network
JP2005130298A (ja) * 2003-10-24 2005-05-19 National Institute Of Information & Communication Technology データ転送制御装置、データ転送制御方法およびデータ転送制御プログラム
JP2005244517A (ja) * 2004-02-25 2005-09-08 National Institute Of Information & Communication Technology データ転送制御装置、データ転送制御方法及びデータ転送制御プログラム
US7512066B2 (en) * 2004-03-30 2009-03-31 Hewlett-Packard Development Company, L.P. Congestion control system
EP1762052A1 (en) * 2004-06-22 2007-03-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Network feedback method and device
CA2589161A1 (en) * 2004-11-29 2006-06-01 Bob Tang Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet nextgentcp (square wave form) tcp friendly san
US9344533B2 (en) * 2012-10-23 2016-05-17 Microsoft Technology Licensing, Llc Receive window auto-tuning
JP4702151B2 (ja) * 2006-04-10 2011-06-15 パナソニック株式会社 ネットワーク中継装置およびネットワーク通信システム
JP4407700B2 (ja) * 2007-02-02 2010-02-03 日本電気株式会社 通信端末、通信システム、輻輳制御方法、及び輻輳制御用プログラム
CN101094047A (zh) * 2007-07-06 2007-12-26 中国人民解放军国防科学技术大学 基于网络状态测量的分阶段慢启动传输控制方法

Also Published As

Publication number Publication date
CA2749826A1 (en) 2010-07-22
EP2387837B1 (en) 2013-07-10
CN104883322A (zh) 2015-09-02
WO2010082091A9 (en) 2011-04-07
US20140192639A1 (en) 2014-07-10
EP2661030A3 (en) 2014-08-27
WO2010082091A2 (en) 2010-07-22
AU2009337511A1 (en) 2011-09-08
CN104883322B (zh) 2019-07-12
JP2012515491A (ja) 2012-07-05
US9882831B2 (en) 2018-01-30
EP2661030A2 (en) 2013-11-06
EP2387837A2 (en) 2011-11-23
TW201108687A (en) 2011-03-01
CN102484609B (zh) 2015-04-15
CN102484609A (zh) 2012-05-30
WO2010082091A3 (en) 2010-12-02

Similar Documents

Publication Publication Date Title
KR20120004961A (ko) 송신 제어 프로토콜을 사용하여 높은 레이턴시 및 패킷 드랍을 갖는 네트워크에서의 대역폭 활용을 최대화하는 방법
US11876714B2 (en) Method and apparatus for network congestion control based on transmission rate gradients
EP3742690B1 (en) Data transmission method, computing device, network device and data transmission system
US9160670B2 (en) Transmission control protocol (TCP) congestion control using transmission delay components
US5442637A (en) Reducing the complexities of the transmission control protocol for a high-speed networking environment
US7099273B2 (en) Data transport acceleration and management within a network communication system
US8605590B2 (en) Systems and methods of improving performance of transport protocols
CN104683259A (zh) Tcp拥塞控制方法及装置
CN117278654A (zh) 基于tcp-bpf的动态网络自适应修改方法

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid