KR20140116466A

KR20140116466A - 클라이언트 디바이스 상에서의 패킷 송신을 스케줄링하기 위한 시스템 및 방법

Info

Publication number: KR20140116466A
Application number: KR20147021744A
Authority: KR
Inventors: 카햐 마스푸트라; 파드마바티 부마; 조 리우
Original assignee: 애플 인크.
Priority date: 2012-02-03
Filing date: 2013-01-28
Publication date: 2014-10-02
Also published as: US9031094B2; JP2015511449A; TWI477127B; US20130201995A1; US20130201843A1; US8812005B2; US8780722B2; US9215188B2; TW201347487A; WO2013116159A1; US20130201996A1; US8787168B2; CN108616458B; KR20160062189A; JP5893762B2; TW201338470A; CN104081736B; WO2013116160A1; US20130201833A1; US20130201825A1

Abstract

클라이언트 디바이스 상에서 패킷 스케줄링을 관리하기 위한 컴퓨터 구현 방법. 예를 들어, 방법의 일 실시예는 송신될 패킷을 수신하는 단계; 패킷을 네트워크 스택 레벨에서 큐에 인큐잉하는 단계; 패킷 스케줄링이 현재 드라이버 레벨에서 수행되고 있는지 또는 네트워킹 스택 레벨에서 수행되고 있는지를 판정하는 단계; 스케줄링이 현재 네트워크 스택 레벨에서 수행되고 있다면, 송신을 위한 패킷을 네트워크 스택 레벨에서 큐로부터 선택하는 단계; 및 스케줄링이 현재 드라이버 레벨에서 수행되고 있다면, 송신을 위한 패킷을 드라이버 레벨에서 큐로부터 선택하는 단계를 포함한다.

Description

클라이언트 디바이스 상에서의 패킷 송신을 스케줄링하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR SCHEDULING PACKET TRANSMISSION ON A CLIENT DEVICE}

우선권 주장

본 출원은 마스푸트라 카햐(Cahya Masputra) 등에 의해 2012년 2월 3일자로 출원되고 발명의 명칭이 "지능적 네트워크 큐 관리를 위한 시스템 및 방법(SYSTEM AND METHOD FOR INTELLIGENT NETWORK QUEUE MANAGEMENT)"인 미국 가특허 출원 제61/595,003호에 관한 것이고 그의 이익을 주장하며, 이 미국 가특허 출원은 이에 의해 전체적으로 본 명세서에 참고로 포함된다.

관련 출원의 상호 참조

본 출원은 마스푸트라 카햐 등에 의해 2012년 9월 15일자로 출원된, 함께 출원된 미국 출원 제13/620.920호 - 애플(Apple)에 양도됨 - 에 관한 것이다.

본 발명의 실시예는 클라이언트 디바이스에서 데이터 네트워크 통신을 관리하는 것에 관한 것이다. 다른 실시예들이 또한 기술된다.

데이터 네트워크는 사람들이, 네트워크 "상"에 있는 그들 각자의 클라이언트 디바이스를 사용하여, 서로 통신하고 네트워크 상의 다양한 소스로부터 정보를 얻게 한다. 예를 들어, 사용자의 워크스테이션 또는 랩톱 컴퓨터에서 구동되는 웹 브라우저 애플리케이션 프로그램은 웹 서버와 접속하여 웹 페이지를 다운로드할 수 있다. 접속은 라우터와 같은 특화된 컴퓨터를 포함할 수 있는, 네트워크의 여러 중간 노드들 또는 홉들에 걸칠 수 있다. 이들 디바이스는 엔드 노드들 사이의 루트 - 이를 통해 디바이스들이 데이터의 패킷들로 분산되어 있는 메시지를 포워드할 수 있음 - 를 탐색할 수 있다. 각각의 노드는 고유 어드레스 또는 범용 어드레스, 예컨대 인터넷 프로토콜(IP) 어드레스를 할당받을 수 있다. 인터넷은 컴퓨터들의 네트워크가 라우터를 통해 서로 접속되는 주지된 글로벌 인터-네트워크이다.

컴퓨터 네트워크 프로토콜은 계층화된 아키텍처를 갖는다. 전형적으로, 최상위 층은 웹 브라우저와 같은 애플리케이션 프로그램에 의해 제공되는 기능성을 포함한다. 이것은, 적어도 엔드 노드에서, 네트워크를 통한 2개의 컴퓨터 사이의 접속을 개시할 수 있는 층이다. 따라서, 예를 들어, 사용자는 자신의 컴퓨터 상에서 원하는 웹사이트를 선택할 수 있다. (그 컴퓨터에서 구동되는) 웹 브라우저는 선택된 웹사이트와 관련된 서버와 이루어지는 접속을 야기하는 절차를 시작한다. 웹 브라우저는 인터넷 프로토콜 수트(Internet protocol suite) 또는 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 스택으로 지칭되는 일련의 함수들을 통해 요청 "다운"을 전송한다. 프로토콜들의 이러한 스택은 전형적으로 그의 상위 층에 있는 소프트웨어에서, 종종 클라이언트 디바이스에서 구동되는 운영 체제(OS) 프로그램의 일부로서 구현된다. 일단 선택된 웹사이트가 웹 서버의 IP 어드레스로 변환되었다면, 서버는 인터넷을 통해 접속되고, 웹 서버에서 구현되는 유사한 프로토콜 수트의 상위 층 프로그램과 적절한 접속이 이루어진다.

접속을 이용하기 위해, 사용자의 컴퓨터에서의 TCP/IP 스택은 웹 브라우저로부터의 요청 메시지, 이 예에서는 웹 페이지를 식별하는 요청을 캡슐화한다. 메시지는, 네트워크 액세스 층을 포함한, 프로토콜 스택에서 아래로 가는 동안의 여러 수직 층에 의해 1회를 초과하여 캡슐화될 수 있다. 그것은 최종적으로 클라이언트 디바이스의 최저 층, 즉 물리 층(전형적으로 네트워크 액세스 층의 일부인 것으로 간주됨)에 도달한다.

사용자의 컴퓨터의 물리 층을 떠나고 이어서 네트워크 내의 하나 이상의 홉을 통과한 후에, 웹 브라우저로부터의 메시지는 웹 서버에 도달하고, 웹 브라우저의 피어(peer)로 간주되는 프로그램에 대해 웹 서버에서 프로토콜 스택 "위"로 이동된다. 그 후, 피어 프로그램은 요청된 웹 페이지에 대한 데이터가 수집되어 기존의 네트워크 접속을 통해 사용자의 컴퓨터로 회송되게 함으로써 그 메시지에 응답할 수 있다. 데이터는 다수의 메시지 또는 패킷으로 분산되며, 요청 메시지가 전송된 방식과 유사한 방식으로 전송된다.

애플리케이션 프로그램은 사용자의 클라이언트 컴퓨터에서 하나 이상의 프로세서에 의해 실행되는 여러 애플리케이션 또는 프로세스를 가질 수 있다. 각각의 개별 애플리케이션은 상이한 패킷 손실, 레이턴시, 및 흐름 탄성(flow elasticity) 요건을 가질 수 있는 상이한 유형들의 네트워크 데이터 트래픽을 생성할 수 있다. 예로서, 소셜 네트워킹 애플리케이션은 네트워크를 통해 제어 데이터, 텍스트, 오디오 및 비디오를 통신할 수 있으며, 이들 각각은 상기 변수들에 대해 상이한 요건들을 갖는다. 각각의 애플리케이션은 전형적으로 이 데이터를 통신하기 위해 그 자신의 포트 또는 포트들의 그룹을 제공받지만, 그들은 모두 사용자의 컴퓨터에서 동일한 하위 층 네트워크 리소스를 공유할 수 있다. 현재의 구현예에서, 네트워크를 통해 각각의 클라이언트 디바이스를 특정 목적지 노드(즉, 다른 클라이언트 또는 서버)에 상호 접속시키는 라우터는 큰 송신 및 수신 버퍼들을 포함한다. 그렇기 때문에, 패킷 손실이 거의 없거나 전혀 없고, 클라이언트 디바이스는 전형적으로 흐름 제어에 무관하게 패킷을 송신하도록 허용되어, 라우터 큐 내에서의 "버퍼 팽창(bloat)"을 초래한다. TCP와 같은 프로토콜은 검출된 패킷 손실에 기초하여 혼잡을 판정하고 송신 속도를 수정하는 자가 조율(self-tuning) 프로토콜이다. 큰 버퍼를 사용하여 패킷 손실이 경감되는 경우, TCP 프로토콜

또한, 현재 클라이언트 측 구현예에서, 패킷의 버퍼링은 드라이버 레벨에서 일어난다. TCP/IP 스택은 단순히 패킷을 드라이버로 아래로 푸시하고, 드라이버는 그 자신의 송신 및 수신 큐들을 관리한다. 클라이언트 내의 드라이버 레벨에서 수행되는 다량의 버퍼링(이더넷 드라이버는 송신 전에 큐에 최대 4000개 패킷을 버퍼링할 수 있음) 때문에, 네트워킹 스택은 정확한 네트워크/혼잡 정보를 제공받지 않는다. 그렇기 때문에, 드라이버 층과 네트워크 스택 층 사이에 피드백 채널이 이용되는, 클라이언트 디바이스 내에서 네트워크 큐잉을 수행하기 위한 보다 지능적인 메커니즘이 필요하다.

클라이언트 디바이스 상에서 패킷 스케줄링을 관리하기 위한 컴퓨터 구현 방법. 예를 들어, 방법의 일 실시예는 송신될 패킷을 수신하는 단계; 패킷을 네트워크 스택 레벨에서 큐에 인큐잉(enqueuing)하는 단계; 패킷 스케줄링이 현재 드라이버 레벨에서 수행되고 있는지 또는 네트워킹 스택 레벨에서 수행되고 있는지를 판정하는 단계; 스케줄링이 현재 네트워크 스택 레벨에서 수행되고 있다면, 송신을 위한 패킷을 네트워크 스택 레벨에서 큐로부터 선택하는 단계; 및 스케줄링이 현재 드라이버 레벨에서 수행되고 있다면, 송신을 위한 패킷을 드라이버 레벨에서 큐로부터 선택하는 단계를 포함한다.

본 발명의 실시예는 첨부 도면의 도면들에 제한으로서가 아니라 예로서 도시되며, 첨부 도면에서 유사한 도면 부호는 유사한 요소를 지시한다. 본 명세서에서 본 발명의 "일" 또는 "하나의" 실시예에 대한 언급은 반드시 동일한 실시예에 대한 것은 아니고, 적어도 하나를 의미하는 것임에 유의해야 한다.
<도 1a 및 도 1b>
도 1a 및 도 1b는 본 발명의 실시예에 따른 네트워킹 스택을 갖는 클라이언트 디바이스의 블록 다이어그램을 도시한 도면.
<도 2a 및 도 2b>
도 2a 및 도 2b는 본 발명의 실시예에 따른 두 가지 방법을 도시한 도면.
<도 3a 및 도 3b>
도 3a 및 도 3b는 본 발명의 2개의 상이한 실시예에 따라 데이터 패킷을 송신하기 위한, 네트워킹 스택과 드라이버 사이의 통신을 도시한 도면.
<도 3c>
도 3c는 본 발명의 일 실시예에 따른 클라이언트 측 소프트웨어 아키텍처를 도시한 도면.
<도 4>
도 4는 예시적인 센더 스레드(sender thread) 및 예시적인 스타터 스레드(starter thread)를 도시한 도면.
<도 5>
도 5는 예시적인 클래스 큐 인스턴스 및 스케줄러를 도시한 도면.
<도 6>
도 6은 서비스 클래스가 큐 인스턴스에 맵핑되는 일 실시예를 도시한 도면.
<도 7>
도 7은 서비스 클래스가 큐 인스턴스에 맵핑되는 다른 실시예를 도시한 도면.
<도 8>
도 8은 소켓 트래픽 클래스가 서비스 클래스에 맵핑되는 실시예를 도시한 도면.
<도 9a>
도 9a는 내장 QFQ 스케줄러 구성을 갖는 일 실시예에서 링크 공유 분포(link-share distribution)의 최악의 경우의 시나리오를 도시한 도면.
<도 9b>
도 9b는 일 실시예에 따른 패킷 필터(PF) 구성의 예를 도시한 도면.
<도 10a>
도 10a는 일 실시예에 따른 흐름 해시(flow hash)를 이용하는 흐름 제어를 도시한 도면.
<도 10b>
도 10b는 일 실시예에서 큐잉 알고리즘에 의해 사용되는 빈(bin)들의 현재 세트 및 빈들의 섀도우 세트를 도시한 도면.
<도 11a 및 도 11b>
도 11a 및 도 11b는 본 발명의 2개의 상이한 실시예에 따라 데이터 패킷을 수신하기 위한, 네트워킹 스택과 드라이버 사이의 통신을 도시한 도면.
<도 12>
도 12는 예시적인 작업 루프 스레드, 폴러(poller) 스레드, 및 DLIL 입력 스레드를 도시한 도면.
<도 13>
도 13은 일 실시예에 따른 스레드 데이터의 예시적인 세트를 도시한 도면.
<도 14>
도 14는 일 실시예에서 채용되는 애플리케이션 프로그래밍 인터페이스(API)를 도시한 도면.
<도 15>
도 15는 일 실시예에서 채용되는 API들을 갖는 복수의 서비스를 도시한 도면.
<도 16>
도 16은 클라이언트 측 데이터 처리 디바이스의 일 실시예를 도시한 도면.
<도 17>
도 17은 클라이언트 측 데이터 처리 디바이스의 다른 실시예를 도시한 도면.

본 발명의 실시예는 클라이언트 디바이스 상에서 실행되는 네트워킹 애플리케이션에 대한 능동적 큐 관리를 위한 컴퓨터 구현 방법에 관한 것이다.

도 1a는 본 발명의 실시예가 구현될 수 있는 클라이언트 컴퓨팅 디바이스(101)의 블록 다이어그램이다. 도시된 클라이언트 디바이스(101)는 인터넷과 같은 네트워크(150)를 통해 서버(120, 121) 및 다른 클라이언트 디바이스(122)와 통신하는 복수의 애플리케이션(105 내지 107)을 실행시킨다. 서버(120, 121)는 (제한이 아닌 예로서) 웹 서버, 이메일 서버, 인스턴스 메시징 서버, 및 파일 서버를 포함할 수 있다. 일 실시예에서, 애플리케이션(105 내지 107)은 네트워킹 스택(102)에 의해 제공되는 네트워킹 리소스에 액세스하기 위해 네트워킹 스택(102)에 의해 노출되는 네트워킹 애플리케이션 프로그래밍 인터페이스(API)(108)를 호출한다.

이 실시예의 네트워킹 스택(102)은 애플리케이션(105 내지 107) 각각을 대신하여 복수의 네트워킹 큐(110 내지 112)를 관리하기 위한 큐 관리 로직(115)을 포함한다. 네트워킹 스택 내의 패킷 스케줄러(116)는 (아래에서 더 상세히 설명되는 바와 같은) 패킷 분류에 기초하여 큐들 각각으로부터/으로 송신 및 수신될 패킷을 스케줄링한다. 도 1a에는 별개의 모듈들로서 도시되어 있지만, 큐 관리 로직(115) 및 스케줄러(116)는 단일의 통합된 소프트웨어 모듈로서 구현될 수 있다는 것이 인지될 것이다.

일 실시예에서, 큐 관리 로직(115)에 의해 관리되는 큐(110 내지 112)들 각각은 아웃고잉 네트워크 패킷(예컨대, TCP/IP 패킷)을 저장하기 위한 전송 큐(send queue) 및 인커밍 네트워크 패킷을 저장하기 위한 수신 큐(receive queue)를 포함한다. 전송 및 수신 큐들은 애플리케이션(105 내지 107)들 각각의 네트워킹 요건에 기초하여 애플리케이션(105 내지 107)들 각각에 대해 상이하게 관리된다. 예를 들어, 상이한 애플리케이션들은 상이한 패킷 손실, 레이턴시, 및 흐름 탄성 요건을 가질 수 있으며, 이들 모두는 큐 관리 로직(115)에 의해 모니터링 및 관리된다. 일 실시예에서, 각각의 애플리케이션(105 내지 107)의 네트워킹 요건이 미리(예컨대, 애플리케이션이 API(108)를 통해 처음 등록되는 때) 특정되고, 그 애플리케이션에 대한 네트워킹 패킷은 특정된 요건에 기초하여 큐 관리 로직(115)에 의해 관리된다. 예로서, 웹 브라우징 애플리케이션이 전형적으로 실시간 화상 채팅 애플리케이션보다 더 레이턴시에 내성이 있다. 그 결과, 웹 브라우징 애플리케이션은 실시간 화상 채팅 애플리케이션과는 상이한 특정된 서비스 레벨을 갖는 상이한 큐와 관련될 것이다.

일 실시예에서, 클라이언트 디바이스 상에 인스톨되는 각각의 드라이버(150)는 한 세트의 드라이버 큐(151 내지 153)들 - 이들 각각은 또한 상이한 서비스 레벨과 관련될 수 있음 - 을 관리하기 위한 큐 관리 로직(155)을 포함한다. 또한, 각각의 드라이버는 드라이버 레벨에서 패킷 스케줄링을 수행하기 위한 그 자신의 스케줄러(160), 및 큐(151 내지 153)를 관리하기 위한 그 자신의 큐 관리 로직(155)을 가질 수 있다. 네트워킹 스택(102)에서와 같이, 드라이버 큐 관리 로직(155) 및 드라이버 스케줄러(160)는 (도 1a에 도시된 바와 같은 별개의 모듈들보다는) 단일 로직 모듈로서 구현될 수 있다. 일 실시예에서, 각각의 드라이버(150)는 자체적으로 패킷 스케줄링을 관리하는 것(본 명세서에서 "드라이버 관리형(driver managed)" 스케줄링으로 지칭됨)을 선택할 수 있거나, 패킷 스케줄링/큐잉을 위해 네트워킹 스택(102)의 패킷 스케줄러(116) 및 큐 관리 로직(115)에 의존할 수 있다.

제한이 아닌 예로서, 이더넷 드라이버 및 셀룰러 무선(예컨대, 3G, 4G) 드라이버는 네트워킹 스택(102)의 스케줄러(116)에 의해 제공되는 패킷 스케줄링 및 큐잉에 의존할 수 있는 반면, 802.11n (Wi-Fi) 드라이버는 패킷 스케줄링 및 큐잉을 관리하는 데 드라이버 스케줄러(160)를 사용할 수 있다. 일 실시예에서, Wi-Fi 드라이버는 무선 멀티미디어 확장(Wireless Multimedia Extensions, WME)(또한 Wi-Fi 멀티미디어(WMM) 표준으로 공지되어 있음)을 구현하여, 음성, 비디오, 베스트 에포트(best effort) 및 백그라운드의 4개의 우선순위 레벨에 따라 네트워크 트래픽을 스케줄링한다. 그러나, 본 발명의 기본 원리는 임의의 특정 네트워킹 표준으로 제한되는 것은 아니다.

일 실시예에서, Wi-Fi 드라이버는 드라이버 관리형 스케줄링과 네트워크 계층에서의 스케줄링 사이에서 동적으로 스위칭할 수 있다. 예를 들어, WME를 지원하는 802.11n 네트워크 상에 있을 때, 드라이버는 드라이버 레벨 스케줄링을 선택할 수 있지만, 802.11b 또는 802.11g 네트워크 상에 있을 때, 드라이버는 네트워크 계층에서의 스케줄링을 선택할 수 있다. 일 실시예에서, 네트워크 스택 관리형(network stack-managed) 스케줄링을 이용하는 경우, 네트워크 스택(102)은 패킷이 디큐잉될 준비가 된 때 드라이버에 통지할 것이다. 그 후, 드라이버는 패킷을 (아래에서 더 상세히 설명되는 바와 같이) 디큐잉 및 송신할 것이다.

도 1a에 도시된 바와 같이, 패킷이 네트워킹 스택으로부터 드라이버로 푸시되고 네트워크 상태에 무관하게 드라이버에서 버퍼링되는 종래의 구현예와는 대조적으로, 본 발명의 일 실시예에서는, 드라이버 층(150)과 네트워킹 스택(102) 사이에 지속적인 피드백(171)이 제공된다. 드라이버(150)로부터 네트워킹 스택으로의 피드백은, 네트워킹 스택(102)이 드라이버(150)에 의해 관리되는 통신 링크의 네트워킹 상태를 인지하고 이 지식에 기초하여 패킷 스케줄링/큐잉을 수행할 수 있는 것을 보장한다. 일 실시예에서, 네트워킹 스택(102)은 검출된 네트워킹 상태에 기초하여 본 명세서에서 설명되는 바와 같이 지능적으로 패킷 스케줄링 및 큐잉을 구현한다. 유사하게, 네트워킹 스택(102)으로부터 드라이버(150)로의 피드백 신호는 네트워킹 스택의 송신/수신 큐(112) 내의 상태(예컨대, 이를테면 새로운 패킷이 특정 큐로부터 송신될 준비가 된 때)를 드라이버에 통지한다.

도 1b에 도시된 바와 같이, 스케줄링은 일부 통신 채널에 대해서는 네트워크 스택 층에서 그리고 다른 통신 채널(예컨대, 상기에 논의된 바와 같은 일부 WiFi 채널)에 대해서는 드라이버 층에서 채용될 수 있다. 특히, 예시된 실시예에서, 패킷 스케줄링은 서버(120, 123) 및 클라이언트(121)로의 통신 채널에 대해서 네트워크 스택 층(102)에서 수행될 수 있는 반면, 드라이버 관리형 스케줄링은 서버(122)로의 통신 채널에 대해서 수행될 수 있다. 또한, 도 1b에 도시된 바와 같이, 단일 애플리케이션(105)이 상이한 패킷 손실, 레이턴시, 및 흐름 탄성 요건을 지원하는, 상이한 큐들에 할당된 상이한 유형들의 데이터 트래픽을 가질 수 있다. 예를 들어, 특정 애플리케이션이 TCP/UDP 소켓을 오픈(open)하여 제어 데이터, 텍스트, 오디오, 및 비디오를 통신하도록 할 수 있는데, 이들 각각은 상기 변수들에 관하여 상이한 요건들을 갖는다. 그렇기 때문에, 한 가지 유형의 데이터(예컨대, 제어 데이터)는 제1 서비스 클래스와 관련된 큐(113)에서 큐잉될 수 있고 제 2 유형의 데이터(예컨대, 양방향 비디오)는 제 2 서비스 클래스와 관련된 큐(110)에서 큐잉될 수 있다. 또한, 상이한 애플리케이션들은 동일한 서비스 클래스와 관련된 동일한 큐에서 데이터를 큐잉할 수 있다. 예를 들어, 애플리케이션(105, 106)은 제어 데이터에 대한 서비스 클래스와 관련된 큐(110)에서 제어 데이터를 큐잉할 수 있고, 애플리케이션(106, 107)은 양방향 비디오 데이터에 대한 서비스 클래스와 관련된 큐(111)에서 양방향 비디오 데이터를 큐잉할 수 있다.

또한, 네트워크 접속성(예컨대, 클라이언트(101)가 이더넷에 연결되는지 또는 WiFi에 연결되는지) 및 다른 네트워크 변수에 따라, 클라이언트 디바이스(101)는 본 발명의 기본 원리에 여전히 부합하면서 네트워크 계층 큐 관리 및/또는 스케줄링만을, 또는 드라이버 관리형 큐 관리 및/또는 스케줄링만을 이용할 수 있다는 것이 이해될 것이다.

본 발명의 일 실시예에 따른 방법이 도 2a에 도시된다. 201에서, 송신될 패킷이 클라이언트 디바이스 상의 프로토콜 스택의 네트워킹 층에서 수신된다. 패킷이 202에서 판정된 드라이버 관리형 스케줄링을 이용하는 네트워크 링크와 관련되는 경우, 203에서 패킷은 드라이버 층에 제공된다. 그 후, 드라이버 층은 204에서 패킷을 큐잉하고, 스케줄링하며, 송신한다. 그러나, 패킷이 네트워크 계층에서 패킷 스케줄링을 수행하는 네트워크 링크와 관련되는 경우, 205에서, 네트워크 스택은 송신을 위한 패킷을 큐잉하고 스케줄링한다. 206에서, 드라이버는 패킷이 송신될 준비가 된 때 통지받으며, 207에서, 드라이버는 패킷을 송신한다.

클라이언트 컴퓨팅 디바이스(101)는 데스크톱 컴퓨터, 노트북 또는 랩톱 컴퓨터, 비디오 게임기, 또는 다른 소비자 전자 디바이스일 수 있다. 본 명세서에서 설명되는 일부 실시예에서, 클라이언트 디바이스(101)는 양방향 음성 및 비디오, 이메일 메시징, 및 미디어 플레이백 기능을 포함할 수 있는 휴대용 무선 디바이스이다. 클라이언트 디바이스(101)와 서버 사이의 통신 경로는, 이 예에서, 클라이언트 디바이스(101)와 무선 기지국(예컨대, 셀 타워 또는 Wifi 액세스 포인트) 사이에 무선 세그먼트를 갖는다. 인터넷 참조 모델에서, 클라이언트 디바이스(101)의 네트워킹 스택(102)은 임의의 적합한 무선 통신 네트워크 액세스 프로토콜(이의 일부 예가 아래에 제공됨)에 따라 기지국을 통해 네트워크 액세스 게이트웨이와 통신한다. 다른 클라이언트 디바이스(122)가 다른 기지국과 게이트웨이의 조합을 통해 연결(reach)될 수 있다. 네트워크 액세스 층의 최상부에는, 인터네트워킹 층(예컨대, 네트워크 상의 각각의 노드에 대한 인터넷 프로토콜(IP) 어드레스를 정의함), 전송 층(예컨대, 전송 제어 프로토콜(TCP), 호스트-호스트 흐름 제어와 접속의 개방 및 폐쇄를 수행함), 및 애플리케이션 층(예컨대, 애플리케이션 프로그램들 및 프로세스 프로토콜, 예를 들어 HTTP, SMTP, 및 SSH)이 있다.

도 2b는 패킷이 드라이버 관리형 스케줄링 또는 네트워크 스택 관리형 스케줄링 중 어느 하나를 이용하여 송신되는 본 발명의 실시예를 도시한다. 251에서, 송신될 패킷이 오픈 소켓 접속을 통해 특정 애플리케이션에 의해 생성된다. 예를 들어, 양방향 비디오 애플리케이션이 다른 클라이언트로 송신될 비디오 패킷을 생성할 수 있다. 252에서, 네트워크 계층은 패킷의 유형에 기초하여 특정된 서비스 클래스에서 패킷을 큐잉한다. 예를 들어, 하기에 논의되는 바와 같이, 10개의 상이한 서비스 클래스들이 10개의 상이한 유형의 데이터 트래픽에 대해 데이터를 큐잉하도록 정의될 수 있다. 따라서, 패킷이 양방향 비디오 패킷인 경우, 그 패킷은 양방향 비디오에 대한 서비스 클래스 큐에서 큐잉될 수 있다. 유사하게, 패킷이 제어 데이터를 포함하는 경우, 그 패킷은 네트워크 제어에 대한 서비스 클래스 큐에서 큐잉될 수 있다.

패킷이 큐잉되는 방식에 무관하게, 패킷은 드라이버 관리형 스케줄링 또는 네트워크 스택 관리형 스케줄링 여부에 따라 상이하게 디큐잉될 수 있다. 254에서 판정된 드라이버 관리형 스케줄링의 경우, 드라이버는 255에서 특정된 서비스 클래스로부터의 디큐 동작을 수행한다. 예를 들어, 드라이버가 802.11n을 구현하고 있는 경우, 드라이버는 WMM에 의해 정의된 4개의 서비스 클래스를 이용하는 스케줄링을 수행할 것을 선택할 수 있다(예컨대, 서비스 클래스와 큐 인스턴스 사이의 10:4 맵핑을 도시한 도 7을 참조). 대안적으로, 다른 네트워크 인터페이스 유형(예컨대, 이더넷, 3G 등)의 경우, 스케줄링은 네트워크 계층에서 수행될 수 있다(예컨대, 서비스 클래스와 큐 인스턴스 사이의 1:1 맵핑을 도시한 도 6을 참조). 따라서, 260에서, 네트워크 계층은 선택된 서비스 클래스로부터의 디큐 동작을 수행한다. 270에서, 패킷은 드라이버 층에 제공되며, 드라이버 층은 271에서 패킷을 송신한다.

따라서, 일 실시예에서, 패킷이 송신될 필요가 있는 경우, 그 패킷은 네트워크 인터페이스를 위해 구성된 네트워크 계층 스케줄러로 전달된다는 것을 상기로부터 알 수 있다. 스케줄러는 패킷으로부터 서비스 클래스를 추출한다; 서비스 클래스는 패킷을 인큐잉할 큐 인스턴스를 판별한다. 그 후, 패킷은 대응하는 큐 인스턴스 상으로 인큐잉되게 된다; 패킷은 큐가 충분하거나 또는 흐름 제어 중인 경우에 드롭될 수 있다(드롭/인큐에 대한 결정은 후술되는 바와 같은 큐잉 규율(queueing discipline)/알고리즘(예컨대, SFB)에 따른다). 드라이버는 수행할 작업이 있다는 것을 통지받는다. 어떤 시점에서, 드라이버는 패킷을 디큐잉한다. 큐 인스턴스는 식별될 필요가 있다. 인터페이스가 "네트워크 스택 스케줄링"을 위해 구성되는 경우, 스케줄러는 서비스될 적격 큐를 선택한다. 인터페이스가 "드라이버 스케줄링"을 위해 구성되는 경우, 드라이버는 서비스를 위해 선택될 큐를 스케줄러에 나타낸다. 일단 큐 인스턴스가 식별되면, 패킷(이용 가능하다면)이 큐로부터 디큐잉된다. 이어서 패킷은 패킷을 송신하는 매체를 통한 송신을 위해 드라이버에 전달된다.

도 1a 및 도 1b에 나타난 바와 같이, 일 실시예에서, 지속적인 피드백(172)이 (점선 화살표로 표시된 바와 같이) 네트워킹 스택(102)으로부터 애플리케이션(105 내지 107) 각각으로 제공되고, 애플리케이션(105 내지 107) 각각으로의/으로부터의 네트워크 플로우에 대한 흐름 제어를 제공하는 데 이용된다. 예를 들어, 특정 TCP 또는 UDP 소켓에 대한 송신 큐(110 내지 112)가 특정 임계치에 도달한 경우, 새로운 패킷 송신을 유예하거나 감소시킬 것을 각자의 애플리케이션(105 내지 107)에 명령하는 피드백 신호가 생성된다.

도 3a 및 도 3b는 본 발명의 상이한 실시예들에 따른 상이한 네트워크 드라이버 모델들을 도시한다. 도 3a에서, 애플리케이션(301)은 송신될 패킷을 네트워크 스택(302)으로 전송하고(1), 그 후 네트워크 스택은 네트워크 패킷을 드라이버의 IO 네트워킹 인터페이스(303)로 전송한다(2). 일 실시예에서, IO 네트워킹 인터페이스(303)는 패킷을 분류하고, 그 분류된 패킷을 패킷 분류에 기초하여 적절한 IO 출력 큐(304)에 배치한다(3). 전술된 바와 같이, WMM의 경우, 분류는 음성, 비디오, 베스트 에포트, 및 백그라운드를 포함할 수 있다. 그 후, 드라이버(305)는 그 자신의 패킷 스케줄러를 사용하여 적절한 IP 출력 큐(304)로부터 패킷을 디큐잉한다(4, 5).

도 3b에 도시된 네트워크 스택 관리형 모델에서, 애플리케이션(301)은 송신될 패킷을 네트워크 스택(302)으로 전송하고(1), 그 후 네트워크 스택은 (아래에서 설명되는 분류 체계를 이용하여) 패킷을 분류하고 그 분류된 패킷을 적절한 전송 큐(306)에 배치한다(2). 일 실시예에서, 패킷 분류들이 존재하는 만큼의 많은 상이한 전송 큐(306)들이 존재한다(예컨대, 10개의 상이한 패킷 분류들에 대해 10개의 상이한 전송 큐들). 네트워킹 스택(302)은 새로운 패킷이 큐들 중 하나에서 송신을 위한 준비가 된 때 드라이버 층에 통지한다(3). 이어서 드라이버의 IO 네트워킹 인터페이스(307)는 송신을 위해 패킷을 디큐잉하고 그 디큐잉된 패킷을 드라이버(305)로 전달한다(5, 6).

도 3c는 패킷들을 분류하기 위한 패킷 분류기(202), 애플리케이션(201)과 인터페이싱하기 위한 API(203), 인터넷 패킷 층(206), 전송 층(205)(예컨대, TCP, UDP), 및 소켓 층(204), 패킷 송신을 스케줄링하기 위한 패킷 스케줄러(209), 복수의 클래스 큐(210), 흐름 권고 모듈(flow advisory module)(207), 및 커널 프로그래밍 인터페이스(kernel programming interface, KPI)(211)를 포함하는 네트워킹 층(102)의 추가의 아키텍처 상세사항을 도시한다. 이들 콤포넌트 각각은 아래에서 더 상세히 설명된다.

A. 커널 프로그래밍 인터페이스

일 실시예에서, 하기의 비밀 KPI들의 세트가 채용된다:

ifnet_allocate_extended()

새로운 출력 모델을 지원하는 ifnet 인스턴스를 할당한다. 이것은 공개된 ifnet_allocate() KPI의 확장 (비밀) 버전이며, 이는 호출자에 의해 채워질 새롭게 정의된 ifnet_init_eparams 구조를 요구한다. 이 구조는 ifnet_init_params와 유사하며, 새로운 출력 모델에 관련된 여러 새로운 필드들을 갖는다:

ifnet_enqueue()

새로운 드라이버 출력 모델을 구현하는 인터페이스의 출력 큐에 패킷을 인큐잉한다. 이것은 pre_enqueue() 콜백을 구현하는 드라이버/패밀리에 제공된다.

{ifnet_dequeue, ifnet_dequeue_multi}()

새로운 드라이버 출력 모델을 구현하고 스케줄링 모델이 "정상"으로 설정된 인터페이스의 출력 큐로부터 하나 이상의 패킷을 디큐잉한다.

{ifnet_dequeue_service_class, ifnet_dequeue_service_

class_multi}()

새로운 드라이버 출력 모델을 구현하고 스케줄링 모델이 "드라이버 관리형"으로 설정된 인터페이스의 출력 큐로부터 하나 이상의 패킷을 디큐잉한다.

ifnet_set_output_sched_model()

스케줄링 모델을 "정상" 또는 "드라이버 관리형"으로 설정한다.

{ifnet_set_sndq_maxlen, ifnet_get_sndq_maxlen}()

출력 큐의 최대 길이를 설정하고 얻는다.

ifnet_get_sndq_len()

출력 큐의 현재 길이를 얻는다.

ifnet_start()

새로운 드라이버 출력 모델을 구현하는 인터페이스 상의 드라이버 층에서의 송신을 트리거한다. 이것은 드라이버의 start() 콜백이, 이미 호출되지 않았다면, 호출되게 할 수 있다.

{ifnet_set_bandwidths, ifnet_bandwidths}()

인터페이스의 업링크 및 다운링크 링크 레이트들을 설정하고 얻는다. 이 레이트들은, 정보가 드라이버의 층에서 이용가능할 때는 언제든지, ifnet가 붙여진 후에 언제라도 드라이버에 의해 설정될 수 있다.

{ifnet_transmit_burst_start, ifnet_transmit_burst_end}()

업링크 링크 레이트를 추정하기 위한 대안적인 메커니즘(드라이버가 하드웨어로부터 그러한 정보를 용이하게 구할 수 없을 때). 이들은 버스트의 송신의 처음과 끝에 관하여 네트워킹 스택에 통지한다.

일 실시예에서, 새로운 출력 모델(즉, 네트워크 스택 관리형 스케줄링)을 지원하는 것으로 자체 등록한 드라이버는 IFEF_TXSTART 플래그로 플래깅된다.

B. 데이터 링크 인터페이스 층(DLIL)(208)

스타터 스레드(402)(일 실시예가 도 4에 도시됨)

새로운 출력 모델(즉, 네트워크 계층 스케줄링)을 지원하는 인터페이스는 전용 커널 스레드인 "스타터 스레드"(402)를 이용하는데, 그의 작업은 드라이버의 start() 콜백을 호출하는 것이다. 일 실시예에서, 이 스레드는, 이미 호출되지 않았다면, ifnet_start()가 호출될 때는 언제든지, ifnet_enqueue()를 통해 패킷을 인큐잉하여, 패킷을 출력 큐에 인큐잉하는 즉시 애플리케이션 스레드가 리턴하게 하는 부분으로서 구동하도록 시그널링된다. 그것은 드라이버의 start() 콜백에 직렬화의 형태를 제공하여, 디큐가 순서대로 발생할 수 있게 한다. 그것은 또한 드라이버 층에서의 복잡도를 감소시키는데, 그 이유는 그것이 이 스타터 스레드의 콘텍스트로부터의 드라이버의 start() 콜백을 실행시킬 때 네트워킹 스택에 의해 어떠한 록(lock)도 유지되지 않으므로, 드라이버가 임팩트에 관하여 너무 많이 우려함이 없이 스레드의 실행을 잠시 차단할 수 있는 소정 동작(하드웨어 관련 또는 무관)을 수행할 수 있기 때문이다.

토큰 버킷 조절기(Token Bucket Regulator)

또한, 네트워크 계층 관리형 출력 모델은, 토큰 버킷 조절기(TBR)가 인터페이스에 대해 구성될 때, ifnet 층에서의 업링크 레이트 제한의 형태를 허용한다. 디폴트로, 인터페이스는 구성된 TBR을 갖지 않고; TBR을 인에이블하는 것은 ifconfig(8) 또는 pfctl(8)을 통한 수동 구성(manual configuration)을 요구한다. TBR이 인에이블되면, 스타터 스레드는 도 4에서 402에 도시된 바와 같이 출력 큐가 비어 있지 않을 때마다 주기적으로(매 10 ms마다) 웨이크업할 것이다. 각각의 기간 동안, 드라이버는 이용가능한 토큰만큼 많은 바이트를 디큐잉하도록 허용된다; 토큰은 각각의 기간의 시작 시에 리필되게 된다. 토큰의 수는 TBR이 그에 대해 구성되는 레이트에 따라 계산된다. 하나의 특정 TBR 구현은 (BSD에 의해 취해지는 접근법과는 다르게) 콜아웃이 할당될 것을 요구하지 않는다; 이 때문에, 그것은 매우 낮은 CPU 오버헤드로 극히 높은 레이트(수십 Gbps)를 도모할 수 있는데, 그 이유는 간격이 고정되고 그에 따라 콜아웃 분해능과는 독립적이기 때문이다(여러 플랫폼들에 걸쳐서 10 ms가 달성가능하다).

송신 큐(일 실시예가 도 5에 도시됨)

ifnet의 if_snd 멤버는 인터페이스에 대한 송신 큐를 유지한다. 이러한 데이터 구조는 내장 스케줄러, TBR, 및 선택적으로 대안적인 스케줄러에 관한 정보(유형, 인스턴스, 콜백)를 포함한다.

디폴트로, 일 실시예에서, 시스템은 패킷 스케줄러의 내장 인스턴스(ifcq 인스턴스)를 생성한다. 언급한 바와 같이, 패킷 스케줄러 및 그의 파라미터의 선택은 네트워크 인터페이스의 유형 및 일부 경우에서는 또한 네트워크의 토폴로지에 좌우된다. 일 실시예에서, 패킷 스케줄러가 연결되면, 그것은 그것의 인스턴스를 ifcq_disc에 저장하고, 스케줄러의 대응하는 루틴에 대해 enqueue(), dequeue() 및 request() 콜백들을 구성한다. "드라이버 관리형" 모델을 요구하는 인터페이스의 경우, 특수한 스케줄러가 연결되는데, 이는 dequeue() 콜백 대신에 대안적인 dequeue_sc()를 제공한다. 이들 콜백의 소정 실시예는 다음과 같다:

스케줄러(116)의 일 실시예는 N개의 클래스를 인스턴스화한다; 각각의 클래스는 서비스 클래스에 상관되고, 큐 인스턴스(110 내지 112)를 관리한다. 패킷들은 그들이 어떻게 분류되는지에 따라 그 큐 인스턴스들 중 하나에서 인큐잉된다. PF_ALTQ 지원이 구성되는 경우, 내장 스케줄러 및 그의 파라미터는 패킷 필터(PF) 인프라구조를 통해 (예컨대, pfctl(8)에 의해) 오버라이드될 수 있다. 이것은 패킷 스케줄링의 상이한 특성들이 모델링되는 (예컨대, 상이한 스케줄러들 및/또는 파라미터들을 시험적으로 사용함) 편리한 방식을 제공한다.

패킷 스케줄러(116)

패킷 스케줄러 모듈(116)의 일 실시예는 그의 클래스 큐 인스턴스(210)들 중 하나로 그리고 하나로부터 패킷들을 인큐잉 및 디큐잉하기 위한 입구점(entry point)을 제공한다. 일 실시예에서, 각각의 클래스는 큐에 대응한다. 그것은 스케줄링 알고리즘 및 파라미터에 따라 그의 큐들 모두를 관리한다.

일 실시예에서, 스케줄러(116)는 다음 기법들 중 하나를 통해 구성되고 ifnet에 연결되게 된다:

1. 내장(정적): 인터페이스가 네트워킹 스택에 연결되면, 드라이버에 의해 요청되는 큐 스케줄링 모델에 기초하여 스케줄러가 선택된다. "정상" 모델의 경우, 스택은 10개의 클래스(따라서 큐)를 갖는 스케줄러를 생성한다. "드라이버 관리형" 모델의 경우, 4개의 클래스들을 갖는 특별한 스케줄러의 인스턴스가 대신에 생성된다.

2. PF(동적): 일 실시예에서, 내장(정적) 구성은 PF 프레임워크를 통해 스케줄러 및 그의 파라미터를 구성함으로써 오버라이드될 수 있다. 이것은 PF_ALTQ 구성 옵션이 인에이블될 것을 요구하고, "altq=1" boot-args NVRAM 옵션이 존재할 것을 요구한다. 일 실시예에서, 그것은 디폴트로 인에이블/허용되지 않는다. 그러나, 인에이블되는 경우, 그것은 상이한 스케줄러들 및 파라미터들을 이용한 실험을 위한 간편하고 편리한 메커니즘을 허용한다.

일 실시예에서, 다음의 스케줄러들은 디폴트로 사용되지 않고, 오로지 PF에서만 이용가능하다:

일 실시예에서, 다음의 스케줄러가 디폴트로 (즉, 네트워킹 스택 층(102)에서) 이용된다:

맵핑

1. 1:1 맵핑

도 6에 도시된 바와 같이, 네트워크 계층 관리형 스케줄링에 대한 일 실시예에 이용되는 QFQ 구성은 패킷 서비스 클래스(601 내지 610)와 패킷 큐 인스턴스(611 내지 620) 간에 각각 1:1 맵핑을 제공한다. 도시된 바와 같이, 10개의 서비스 레벨은 4개의 그룹(630, 640, 650, 660)으로 대략적으로 분할되고, 각각의 그룹 내에 우선순위화가 제공된다. 그룹은 지연 내성(낮음-높음), 손실 내성(낮음-높음), 탄성 대 비탄성 흐름뿐만 아니라 패킷 크기 및 레이트와 같은 다른 인자의 관점에서, 분류된 트래픽들의 특성에 기초하여 정의된다. 본 명세서에서 기술되는 바와 같이, "탄성" 흐름은 상대적으로 고정된 대역폭을 요구하는 흐름인 반면에, "비탄성" 흐름은 비-고정된 대역폭이 허용될 수 있는 흐름이다. 도시된 1:1 맵핑은 네트워킹 스택이 각각의 서비스 클래스의 거동 및 차별화에 대한 완전한 제어를 달성하게 한다: 패킷이 어떻게 분류되었는지에 따라 그것이 큐들 중 하나에 직접 인큐잉된다; 디큐 동안, 스케줄러는 가장 적격인 큐로부터 송신될 패킷을 결정한다.

2. 10:4 맵핑

도 7에 도시된 바와 같이, 일 실시예에서 드라이버 관리형 스케줄링에 이용되는 TCQ 구성은 10개의 서비스 클래스(601 내지 610)와 4개의 큐 인스턴스(701 내지 704) 간에 10:4 맵핑을 제공한다. 이 스케줄러는 그것이 어떠한 종류의 패킷 스케줄링도 수행하지 않는다는 의미에서는 수동적이지만, 대신에 단순히 큐 인스턴스를 제공하고 서비스 클래스를 큐에 맵핑한다. 이러한 실시예의 네트워킹 스택은 스케줄링에 대한 제어를 갖지 않기 때문에, 큐들은 1:1 맵핑에 대한 특성과 유사한 특성을 갖도록 정의될 수 없다. 대신에, 낮음(L)으로부터 최고(H+)까지의 범위에 이르는 우선순위들을 갖는 것으로 인지될 수 있다. 그것이 본래 분류되었던 서비스 클래스를 나타내는 큐들 중 하나에 직접 패킷이 인큐잉된다. 디큐 동안, 드라이버는 송신에 가장 적격인 서비스 클래스를 선택하는 것을 담당한다. 큐들의 수는 4로 설정되며, 구현 아티팩트이다; 언급된 바와 같이, 이것은 또한 802.11 WMM 액세스 카테고리들의 수가 되도록 일어난다.

큐잉 규율

일 실시예에서, 큐잉 규율 또는 알고리즘 모듈이 클래스 큐의 단일 인스턴스를 관리한다; 큐는 단순히 하나 이상의 패킷(mbuf)으로 이루어진다. 알고리즘은 패킷이 인큐잉되어야 하는지 또는 드롭되어야 하는지를 판별하는 것을 담당한다.

일 실시예에서, 큐잉 알고리즘이 다음의 방식들 중 하나를 통해 구성되게 되고 스케줄러 클래스의 인스턴스에 연결되게 된다:

1. 내장(네트워크 스택 관리형): 스케줄러 클래스가 ifnet 상에서 패킷 스케줄러를 구성하는 부분으로서 인스턴스화되는 경우, 큐잉 알고리즘이 선택된다. 스케줄러의 모든 클래스(각각은 그 자신의 고유의 인스턴스를 가짐)가 동일한 큐 알고리즘을 공유한다.

2. PF (동적, 또는 드라이버 관리형): 대안적으로, 내장(정적) 구성은 스케줄러 및 그의 파라미터들을 구성함으로써 오버라이드될 수 있다 -- 패킷 필터(PF) 프레임워크를 통한 클래스에 대한 큐잉 알고리즘을 포함함.

알고리즘

일 실시예에서, 다음의 큐잉 알고리즘은 디폴트로 이용되지 않고, 오로지 PF를 통해서만 이용가능하다:

패킷 분류(Packet Classification)

언급된 바와 같이, 일 실시예에서, 각각의 아웃바운드 패킷은 패킷의 서비스 클래스에 대응하는 클래스 큐 인스턴스에 인큐잉된다. 서비스 클래스 할당 또는 패킷 분류는 네트워킹 스택 전반에 걸쳐 여러 곳에서 발생한다. 일반적으로, 패킷 분류는 명시적(애플리케이션에 의해 옵트인(opt-in)됨) 또는 암시적(시스템에 의해 설정되거나 오버라이드됨)일 수 있다.

명시적 분류(Explicit Classification): 일 실시예에서, 애플리케이션은, 도 8에 서비스 클래스에 맵핑되어 도시되어 있는 하기의 트래픽 서비스 클래스 값들 중 하나를 이용하여 -- setsockopt(2)를 통해 엄격하게 또는 sendmsg(2)에 의한 메시지 단위로 -- SO_TRAFFIC_CLASS 옵션을 발행함으로써 그의 트래픽들을 분류할 수 있다.

따라서, 일 실시예에서, 시스템은 네트워크 제어 패킷을 최고 우선순위 분류에 할당하여서, 제어 패킷이 모든 더 낮은 분류들을 갖는 패킷에 앞서서 포워드되는 것을 보장함을 상기로부터 알 수 있다. 이것은 소정의 제어 패킷(예컨대, 이를테면 TCP 확인응답(ACK) 패킷)이 다른 유형의 비제어 패킷보다 늦게 큐에 고정(이에 의해 시스템 성능을 감소시킴)될 수 있는 종래의 시스템에 비한 개선점이다.

일 실시예에서, 백그라운드 시스템 개시(SO_TC_BK_SYS)로 분류된 임의의 패킷은 클라이언트 디바이스 상에서 음성 호출이 발생하고 있는 동안에는 큐에서 유예될 것이다. 그렇기 때문에, 이러한 실시예는 낮은 우선순위 패킷(예컨대, 백그라운드 시스템 개시 패킷)이 송신되는 결과로서 음성 호출이 열화되거나 드롭될 수 있는 종래 시스템에 비해 상당한 이익을 제공한다. 따라서, 이러한 실시예에서, 서비스(예컨대, 이를테면 아이클라우드)에 백업될 사용자의 사진 스트림 또는 다른 데이터는 음성 호출과 간섭하지 않을 것이다.

시스템의 일 실시예는 백그라운 시스템 개시로 마킹되는 트래픽을 방지하여, 그것이 착신 전화 호출과 간섭하지 않아서, 호출의 신뢰성을 증가시키게 할 수 있다. 전화 호출이 개시된 때, 네트워크 계층(예컨대, TCP/IP 층)은 모든 백그라운드 시스템 개시 트래픽을 유예하라는 흐름 제어 통지를 수신할 것이다. 이에 응답하여, 네트워크 계층은 임의의 더 많은 패킷을 인터페이스로 내려 보내는 것을 중지할 수 있다. 그것은 또한 애플리케이션이 임의의 더 많은 데이터를 네트워크 스택에 기록하는 것을 중지시킬 수도 있다. 이는 애플리케이션이 수신거부(quiesce)되기 때문에 CPU 이용도를 개선하는 것을 도울 것이며, 그것은 또한 음성 호출의 신뢰성을 개선한다. 음성 호출이 합당한 지속 시간 내에 완료되면, 애플리케이션은 데이터 통신을 재개할 수 있다.

일 실시예에서, 특정 하위 우선순위 애플리케이션이 유예된 때, 네트워크 스택(102)은 (예컨대, 피드백 신호(171)를 통해) 통신 링크를 (주기적으로) 프로브하여 그것이 송신을 언제 재개할 수 있을지를 결정할 것이며, 이러한 정보를 각자의 애플리케이션에 통신할 것이다. 링크가 더 이상 로딩되지 않으면, 패킷 전송이 재개될 것이다.

요약하자면, 드라이버 층(150)과 네트워킹 스택(102) 사이의 지속적인 흐름 제어 피드백(171), 및 네트워킹 스택과 애플리케이션(105 내지 107) 사이의 피드백(172)은, 네트워크 채널 및 대역폭의 더 지능적이고 효율적인 할당을 제공한다.

일 실시예에서, 상기 값들은 보장성을 암시하는 것이 아니라, 오히려 그의 트래픽의 특성에 관한, 애플리케이션으로부터 시스템으로의 힌트이다. 시스템은 트래픽들의 분류에 기초하여 그들에 대해 어떤 형태의 차별화를 제공하는 데 최선을 다할 것이지만, 패킷 스케줄링 파라미터로부터 네트워크 토폴로지 또는 매체 상태에 이르는 범위의 다양한 인자로 인해 어떠한 보장도 이루어지지 않는다.

일 실시예에서, 상기 값들 중 하나와 관련된 소켓에 의해 생성된 트래픽은 큐/버퍼(mbuf)에서 대응하는 서비스 클래스 값을 전달할 것이다; 도 8에 도시된 바와 같이, SO_TC와 MBUF_SC 값들 사이에 1:1 맵핑이 존재한다.

도 9a는 내장 QFQ 스케줄러 구성을 갖는 일 실시예에서 링크 공유 분포의 최악의 경우의 시나리오를 도시한다. 소켓 레벨 분류 외에도, 커널 전반에 걸친 몇몇 곳들은 MBUF_SC_CTL 서비스 클래스를 이용하여 소정의 제어 유형 패킷(예컨대, ARP, ND NS/NA, IGMP/MLD)들을 분류한다. 이것은 또한 TCP ACK들에 의해 이용되는 서비스 클래스들의 일시적 증가를 포함한다.

암시적 분류(Implicit Classification): 이러한 형태의 분류는 패킷 필터(PF) 프레임워크를 통해 가능하다. 그것은 분류 규칙들이 PF를 통해 인스톨되게 하며, 그것들이 본래 애초에 분류되었던 방식에 무관하게 모든 IP 트래픽들에 대해 효력을 나타낸다. PF 및 pfctl(8)은 서비스 클래스 관련 키워드로 증강되어 왔다; 도 9b는 내장 설정(setting)들을 오버라이드하도록 pfctl(8)에 의해 처리될 수 있는 PF 구성 파일의 일례를 도시한다.

따라서, 명시적 분류 경우에, 애플리케이션은 디폴트 서비스 클래스(BE)를 갖는 소켓을 오픈한다. 애플리케이션은 SO_TRAFFIC_CLASS 소켓 옵션을 통해 소켓의 서비스 클래스를 설정할 수 있어서, 미래의 전송/기록 동작들 모두가 자동적으로 패킷이 대응하는 서비스 클래스로 마킹되게 할 것이다. 애플리케이션은 소켓으로 내려 보내진 각각의 데이터그램을 SO_TRAFFIC_CLASS 보조 메시지 옵션과 선택적으로 관련시킬 것을 선택할 수 있어서, 관련된 패킷이 대응하는 서비스 클래스로 마킹될 것이다(그러나, 다른 현재의 또는 미래의 패킷에는 영향을 미치지 않을 것이다). 이러한 경우, 많은 상이한 서비스 클래스들을 이러한 소켓과 용이하게 관련시킬 수 있다.

암시적 분류 경우에서, 분류 규칙들은 패킷 필터 엔진에 인스톨된다. 각각의 규칙은, 매칭 시, 패킷이 서비스 클래스로 마킹되게 할 시그니처(예컨대, 프로토콜, 포트 등)를 포함한다.

분류 태그(Classification Tag). 큐/버퍼(mbuf)를 MBUF_SC 값으로 마킹하는 것 외에도, 일 실시예에서, 패킷 분류를 수행하는 모듈(202)은 또한, 패킷의 유형 또는 흐름을 식별함에 있어서 시스템의 나머지를 돕기 위해, 하나 이상의 태그를 패킷과 연관시킨다. 일 실시예에서, 이들 태그는 mbuf의 내장 pf_mtag 서브구조 내에 상주하며, 분류가 어떻게 수행되는지(명시적 또는 암시적)에 무관하게 설정된다. 일 실시예에서 채용된 태그는 다음과 같다:

흐름 피드백

흐름 해시: 도 10a에 도시된 바와 같이, 일 실시예에서, 인터페이스를 통해 전송되고 있는 각각의 mbuf는 흐름 해시(1001)로 태그(이에 따라 PF_TAG_FLOWHASH로 마킹)되는데, 이는 인터페이스 층에서 특정 흐름에 속하는 모든 패킷들을 식별하는 것을 도울 것이다. 일 실시예에서, 흐름 해시(1001)는 32-비트 정수이고, 그것은 다음 장소들 중 하나에서 계산된다:

1. 소켓(204). 일 실시예에서, 소켓이 접속된 때, 소켓(204)에 대한 흐름 해시가 계산되고 저장된다. 또한, 이러한 소켓 상에서의 송신은 해시 값이 패킷들의 mbuf 구조 내에서 전달되게 할 것이다.

2. 패킷 필터(PF). 일 실시예에서, 패킷이 드라이버(150)에 입력되면, 흐름 해시가 계산될 것이며, 그것이 이미 분류되어 있는 것이 아니면, 관련된 PF 규칙 및 상태에 저장될 것이다. 패킷이 IP(206)에 성공적으로 회송되면, 패킷은 mbuf 구조에서 그것이 매칭되었던 규칙 또는 상태와 관련된 흐름 해시를 그것과 함께 전달할 것이다.

일 실시예에서, 흐름 해시를 계산하는 데 이용되는 해싱 알고리즘은 성능에 따라 컴퓨팅 시스템 플랫폼들에 걸쳐 상이하다. 하기의 표는 예시적인 플랫폼 및 대응하는 해시를 나타낸다:

TCP에 대한 흐름 제어 및 권고: 본 명세서에서 설명되는 큐 관리 기법을 이용하면, TCP를 이용하여 전송하는 애플리케이션은 인터페이스에서 큐잉되는 흐름당 패킷들의 수가 상한에 도달한 때 흐름 제어된다. 명시적 혼잡 통지(explicit congestion notification, ECN)와 같은 표시자 또는 패킷 드롭을 이용하는 대신, 인터페이스는 전송 층에 흐름 권고 피드백을 제공한다. 이는 임의의 패킷 손실 없이 행해질 수 있다.

접속 상에서의 흐름 권고가 다음의 두 가지 조건 중 하나가 참인 경우에 AQM으로부터 수신된다:

1. TCP 접속의 전송 레이트가 링크 상에서 지원되는 대역폭을 초과하여 증가한다.

2. 디바이스로부터 제1 홉인 무선 링크 상에서 이용가능한 대역폭이 감소한다.

이들 둘 모두의 경우에, 더 많은 패킷을 전송하는 것은 인터페이스 큐에 패킷들을 누적할 것이고, 애플리케이션에 의해 경험되는 레이턴시를 증가시킬 것이다. 그렇지 않은 경우, 그것은 성능을 감소시킬 패킷 드롭들을 야기할 수 있는데, 그 이유는 TCP 센더가 그들 패킷을 재송신해야 할 것이기 때문이다. 흐름 권고 메커니즘을 이용함으로써, TCP 센더는 임의의 패킷 손실 또는 임의의 성능 손실을 보지 않고서 이용가능한 대역폭에 적응할 수 있다. 인터페이스 큐는 TCP 패킷을 결코 드롭하지 않을 것이지만, 그것은 오로지 흐름 권고만을 접속에 전송할 것이다. 이러한 메커니즘 때문에, 디바이스 드라이버에서의 버퍼링이 상당한 양만큼 감소되어, 디바이스 상에서 모든 TCP 접속들에 대해 개선된 레이턴시의 결과를 가져왔다.

흐름 권고에 대한 TCP 접속의 주요 응답은 그것의 혼잡 윈도우를 감소시키는 것이며, 이는 사실상 그의 전송 레이트를 감소시킬 것이다. 이는 느린 시작 임계치를 백 오프하고 접속이 혼잡 회피 상태에 들어가게 함으로써 행해진다. 그러나, 접속이 이미 복구 중인 경우, 그것은 접속이 그 왕복 시간(round-trip time) 내에 이미 패킷 손실을 경험했고 그의 전송 레이트를 이미 낮추었다는 것을 의미한다. 이러한 경우, 혼잡 윈도우는 더 이상 감소되지 않는다.

흐름 제어되는 접속은 흐름 제어가 해제(lift)될 때까지 소켓을 기록가능하게 만드는 것을 회피시킬 것이다. 이는, 그것이 인터페이스 상에서 패킷을 전송할 수 없을 때, 네트워크 스택에서 단지 위로 버퍼링될 수 있는 더 많은 데이터를 애플리케이션이 기록하는 것을 방지할 것이다. 이는 최신 업데이트만을 전송할 필요가 있고 반대로 오래된 업데이트를 버릴 양방향 애플리케이션을 도울 것이다.

흐름 제어 상태에 있는 동안, 중복 확인응답들의 형태로 수신되는 TCP 확인응답 또는 SACK 정보에 패킷 손실의 표시가 있다면, 접속은 손실 데이터를 즉시 재송신하기 위해 흐름 제어를 중단하고 빠른 복구를 시작할 것이다. 이는 레이턴시를 더 이상 증가시키지 않을 것인데, 그 이유는 복구 동안에 전송되는 패킷들의 레이트가 제한되기 때문이다. 인터페이스가 어떠한 TCP 패킷도 드롭하지 않도록 보장되므로, 접속은 손실된 데이터를 가능한 한 빨리 재송신할 수 있을 것이다.

접속이 흐름 제어 상태에 있는 경우, 그것은 패킷들이 이전보다 느리게 인터페이스를 떠나고 있음을 의미한다. 이러한 상황에서는, 전송될 준비가 된 인터페이스 큐에 대기 중인 패킷들이 있을 수 있다. 보통, 이들은 마지막에 전송 윈도우의 끝에 있는 패킷들이다. 이러한 대기 시간이 접속에 대해 계산된 재송신 타임아웃보다 크다면, 타임아웃이 발생할 것이다. 이 시점에서, 이미 전송된 데이터를 재송신하는 것은 인터페이스 큐에 동일 패킷의 중복 사본들을 생성할 수 있다. 이는 이후에 중복 확인응답들을 생성할 수 있고, 접속이 불필요하게 복구에 들어가게 할 수 있다.

이러한 혼란을 피하기 위하여, 흐름 제어 TCP 접속이 이후까지 재송신 타이머로부터 패킷을 재송신하는 것을 회피시킬 것이다. 대기가 너무 길면, 접속은 영원히 대기하는 대신에 타임아웃될 수 있고, 에러가 애플리케이션에 리턴될 것이다.

재송신 타임아웃이 발생할 때마다, 타이머는 다시 시도하기 전에 백 오프된다. 이는 링크 상에서 급작스러운 지연 증가를 검출하는 것을 도울 것이다. 그러나, 흐름 제어된 소켓의 경우, 지연은 흐름이 일시적으로 차단되는 결과일 수 있다. 접속이 흐름 제어 상태로부터 벗어나면, 백 오프는 행해지지 않는다. 이는 그 때부터 시기 적절하게 재송신 타이머를 작동시키는 것을 도울 것이다.

인터페이스 큐 내의 패킷이 배출되고 큐 레벨이 임계치 아래로 떨어지는 경우, 인터페이스는 흐름 제어된 모든 흐름들이 데이터를 다시 전송하기 시작하게 하도록 흐름 권고를 생성할 것이다. 이 시점에서, TCP 소켓이 또한 기록가능하게 되고, 애플리케이션은 데이터를 기록하기 시작할 수 있다.

흐름 제어가 해제되면, 접속은 이전에는 결코 전송되지 않았던 새로운 데이터를 전송할 것이다. 이는 새로운 확인응답을 생성할 것이고 ACK 타이머를 개시할 것이다. 그것은 또한 이미 검출되지는 않았던 흐름 제어에 앞서 임의의 데이터 손실이 있었는지를 검출하는 것을 도울 것이다. 전송될 어떠한 새로운 데이터도 없다면, 재송신 타이머가 곧 작동할 것이고, 그것은 확인응답되어 있지 않은 임의의 미처리된 데이터의 재송신을 트리거할 것이다.

흐름 권고 및 흐름 제어 메커니즘을 이용하면, TPC 접속은 링크 대역폭의 변동에 적응할 수 있을 것이고, 호스트 상의 다수의 레벨들에서 패킷을 버퍼링함으로써 유도되는 지연을 최소화할 수 있을 것이다.

UDP에 대한 흐름 제어 및 권고: 일 실시예에서, UDP 소켓은 그것이 connect() 시스템 호출을 이용하여 피어에 접속되는 경우에만 흐름 제어가 가능하다. 인터페이스 큐에서 UDP 흐름으로부터의 패킷들의 수가 흐름 제어에 대한 한도보다 많다면, 권고가 생성된다. 소켓은 그 시점에서 흐름 제어된 것으로 마킹된다. TCP와는 다르게, 인터페이스 큐는 그 후에 생성되는 모든 UDP 패킷들을 드롭시킬 것이다. 소켓은 기록 가능하지 않을 것인데, 이는 선택 또는 폴링(poll) 또는 kevent 시스템 클래스들을 이용하여 기록 이벤트를 대기하는 애플리케이션이 흐름 제어가 해제될 때까지 그 이벤트를 얻지 않을 것임을 의미한다. 애플리케이션이 어떻게든 데이터를 소켓에 기록한다면, 패킷은 소켓 층에 의해 드롭될 것이고 에러(ENOBUFS)가 리턴될 것이다.

이는 모든 UDP 기록들이 드라이버에 의해 이후에 패킷을 드롭시키는 데에만 성공했던 이전 거동과는 상이하다. UDP 흐름 제어 및 권고는 애플리케이션들이 그들의 전송 레이트를 즉시 감소시킬 수 있도록 그들에 즉각적인 피드백을 제공할 것이다. 예를 들어, 비디오 애플리케이션은 네트워크를 통해 보다 적은 데이터를 전송하도록 그의 인코딩을 변경할 수 있다.

패킷이 흐름 제어된 UDP 소켓 상의 소켓 층에서 드롭되므로, 그것은 패킷이 처리되고 드라이버로 내내 전송되어 드롭되기만 했던 이전에 비해 많은 CPU 이용도를 절감한다. 다른 이점은 흐름 제어된 UDP 흐름이 인터페이스를 압도할 수 없다는 것이다. 이는 야기된 패킷 손실을 감소시키고 호스트 상의 다른 흐름에 대한 레이턴시를 개선할 것이다.

일 실시예에서, 인터페이스 층에서의 흐름의 트래킹은 큐잉 알고리즘으로서 SFB(Stochastic Fair Blue)(본 특허 출원서에의 부록 B 참조)의 사용으로 인해 가능해진다. 일 실시예에서, SFB의 구현은 2-레벨 블룸 필터(bloom filter)를 사용하고, 이에 의해 (흐름 해시 값(1001)으로 표시된 바와 같은) 흐름이 각각의 SFB 레벨에서 정확히 하나의 빈(1009)에 맵핑한다. 이 실시예의 각각의 빈은 패킷들의 개수뿐만 아니라 흐름 드롭/마킹 확률을 트래킹한다. 일 실시예에서, SFB는 또한 흐름 제어되는 흐름들의 리스트를 트래킹한다. 흐름 제어 및 흐름 권고에 대한 임계치는 빈 할당량(현재 큐 한도의 1/3로 설정됨)에 기초한다. 빈 확률은 이에 따라 업데이트되지만, 그것은 현재는 레이트 제한에 이용되지 않는다.

흐름 유예 및 재개

일 실시예에서, "기회주의적(opportunistic)"으로 마킹되는 소정 소켓들은 네트워크 인터페이스가 스로틀(throttle)될 때 유예된다. 그러한 소켓들에 의해 생성된 패킷들은 일 실시예에서 그것들이 영향받은 큐에서 인큐잉될 때 드롭될 것이다. 일 실시예에서, 소켓 상의 트래픽들이 무기한 차단되는 것을 애플리케이션에 통지하기 위해 NOTE_SUSPENDED 이벤트가 소켓 상에 생성될 것이다. 이어서 애플리케이션은 접속을 중단시킬지 여부를 결정할 수 있다. 인터페이스가 더 이상 스로틀되지 않을 때, 영향받은 큐들은 더 이상 패킷들을 차단하지 않을 것이며, 영향받은 소켓들 상에 NOTE_RESUMED 이벤트가 생성될 것이다. 내부적으로, 동일 메커니즘이 흐름 제어에 의해 이용될 수 있고, 권고가 유예 및 재개를 구현하는 데 이용된다.

인바운드 네트워크 계층 스케줄링 모델(Inbound Network Layer Scheduling Model)

일 실시예의 기회주의적 폴링(opportunistic polling)은 도 11b에 도시된 바와 같은 네트워크 드라이버 입력 모델을 이용한다. 드라이버 콤포넌트(1111)는 인커밍 패킷들에 대한 하드웨어(1112)를 폴링하고, IO 네트워킹 인터페이스(1110)는 드라이버를 폴링한다. 각각의 수신 큐 인스턴스는 드라이버(1111)의 IP 네트워킹 인터페이스(1110)를 폴링(3)하여, 디큐잉(3)될 준비가 된 그 수신 큐와 관련되고 네트워크 스택(1108)까지(4) 그리고 후속으로 요청 애플리케이션(1107)(이는 (6)에 도시된 바와 같이, 새로운 패킷들에 대해 관련되는 수신 큐 인스턴스(1109)를 폴링함)까지(5) 전달되는 임의의 패킷들이 있는지를 판정한다.

따라서, 이러한 새로운 모델에서, 도 11a의 동작 1 내지 동작 6에 의해 도시된 바와 같이, 인바운드 패킷들은 드라이버/패밀리에 의해 더 이상 네트워킹 스택까지 푸시되지 않는다. 대신, 인바운드 패킷들은 그것들이 네트워킹 스택(1108)에 의해 디큐잉될 때까지 드라이버의 수신 큐(1109)에 상주한다. 일 실시예에서, 이는 클라이언트 디바이스 하드웨어의 수신 인터럽트(IRQ)를 턴 오프시키는 것을 수반한다. 설명된 실시예가 고유한 한 가지 이유는, 네트워킹 스택(1108)이 (드라이버와 함께) 부하 인자에 따라 폴링(도 11b)과 레거시 모델(도 11a) 간을 오간다는 것이다. 일 실시예에서, 부하가 사전결정된 임계치(예컨대, 드라이버의 큐들에 축적된 패킷들의 특정된 레벨)에 도달하면, 시스템은 레거시 모델(도 11a)로 천이할 수 있다. 레거시 모델로 천이할 때, 하드웨어의 수신 IRQ는 턴 온되고, 드라이버(1105)는 네트워크 스택(1102)을 통해 패킷을 IO 네트워킹 인터페이스(1104)로부터 적절한 수신 큐 인스턴스(1103)로 그리고 궁극적으로 요청 애플리케이션(1101)으로 밀어 올린다.

커널 프로그래밍 인터페이스(KPI)

일 실시예에서, 상기 구성을 수용하기 위해, 일 세트의 비밀 KPI들이 채용된다:

ifnet_allocate_extended()

여러 관련 필드들을 갖는, 새로운 입력 모델을 지원하는 ifnet 인스턴스를 할당한다:

ifnet_input_extended()

드라이버(1111)가 네트워킹 스택(1108)에 패킷 체인의 시작 및 끝과 관련된 모든 정보뿐만 아니라 총 패킷 및 바이트의 카운트를 제공한다는 점을 제외하고는 ifnet_input()와 유사함. 이러한 정보를 이미 소유한 드라이버는 이러한 새로운 변형을 이용하도록 권장되는데, 그 이유는 그것이 보다 양호한 효율을 허용하기 때문이다. 이것은 드라이버가 새로운 모델(도 11b)을 채택하는지 여부에 무관하게 이용될 수 있다.

일 실시예에서, 새로운 입력 모델(도 11b)을 지원하는 것으로 자체 등록한 드라이버는 IFEF_RXPOLL 플래그로 플래깅된다.

데이터 링크 인터페이스 층(DLIL)(208)

입력 스레드: 일 실시예에서, 네트워킹 스택 전반에 걸친 입력 패킷 처리는 DLIL 입력 스레드의 콘텍스트 내에서 일어난다. 일부 인터페이스들은 그들 자신의 전용 입력 스레드를 갖는 반면, 다른 인터페이스들은 공통(메인) 입력 스레드를 공유한다. 일 실시예에서, 3개의 DLIL 입력 스레드 변형이 있다.

1. 메인

일 실시예에서, 메인 입력 스레드는 루프백 인터페이스뿐만 아니라, 자신의 전용 입력 스레드(즉, 이더넷/PDP 또는 RXPOLL을 지원하지 않는 것을 제외한 임의의 것)를 얻지 않는 다른 인터페이스에 의해 사용된다. 이 스레드는 또한 모든 프로토콜 등록 및 패킷 주입을 처리하는 데 이용된다. 이것은 dlil_main_input_thread_func()로 구현된다.

2. 레거시(Legacy)

일 실시예에서, 레거시는 dlil_input_thread_func()로 구현된 RXPOLL 모델을 채택하지 않는 이더넷/PDP 인터페이스들에 의해 이용된다.

3. RXPOLL

일 실시예에서, RXPOLL은 dlil_rxpoll_input_thread_func()로 구현된 RXPOLL 모델을 채택하는 임의의 인터페이스에 의해 이용된다.

폴러 스레드(Poller Thread)

일 실시예에서, 새로운 입력 모델(RXPOLL)을 지원하는 인터페이스는 전용 커널 스레드인 "폴러 스레드"(도 12에서 1202에 도시됨)를 이용하는데, 이 스레드의 작업은 드라이버로부터 하나 이상의 패킷을 구하기 위해 드라이버의 input_poll() 콜백을 호출하는 것이다; 이것은 폴링이 온 상태일 때 발생하고, 그렇지 않으면 폴러 스레드(1202)는 휴면 상태(dormant)에 머무른다. 이 스레드는 도 12에서 1201에 도시된 작업 루프 스레드와 유사한데, 여기서 이들 둘 모두는 패킷을 RXPOLL-가능 DLIL 입력 스레드의 수신 큐에 배치하기 위해 결국 ifnet_input()을 호출하게 된다.

이어서 패킷은 이 DLIL 입력 스레드의 콘텍스트로부터의 추가 처리를 위해 네트워킹 스택으로 올려 보내진다.

기회주의적 폴링

일 실시예에서, RXPOLL 가능 인터페이스는 IFNET_MODEL_INPUT_POLL_OFF 모드와 IFNET_MODEL_INPUT_ POLL_ON 모드 사이에서 천이한다. 일 실시예에서, 전자의 모드는 디폴트/초기 모드이다; 네트워크 스택은 그것이 부하 인자가 낮은 것으로 판별한 경우 인터페이스에 대해 이러한 모드를 선택한다. 부하 인자는 현재 DLIL 수신 큐에서의 패킷 및 바이트의 EWMA (P_avg, B_avg) 및 DLIL 입력 스레드 웨이크업 요청의 EWMA(W_avg)를 살펴보는 것에 의해 결정된다.

도 12의 DLIL 입력 스레드(1203)를 참조하면, 일 실시예에서, IFNET_MODEL_INPUT_ POLL_ON으로의 스위칭이 (P_avg

P_hiwat && (B_avg

B_hiwat || W_avg

W_hiwat))인 경우에 행해지며, 여기서 P_hiwat, B_hiwat 및 W_hiwat는 각각 패킷, 바이트 및 웨이크업 요청에 대한 높은 워터마크 값들이다. 반대로, IFNET_MODEL_INPUT_POLL_OFF로의 스위칭이 (P_avg

P_lowat && B_avg

B_lowat && W_avg

W_lowat)인 경우에 행해지며, 여기서 P_lowat, B_lowat 및 W_lowat는 변수들에 대한 낮은 워터마크 값들이다.

일 실시예에서, 이들 낮은 및 높은 워터마크 값들은 현재 소정의 작업부하에 기초하여 임의적으로 선택되며, 이들은 그에 따라 미래의 작업부하(및 다양한 링크 속도)를 수용하도록 조정되어야 한다.

일 실시예에서, 하이브리드 폴링 로직의 대부분은 dlil_rxpoll_input_thread_func() 내에 존재하는데, 여기서 모드들 사이에서의 천이는 상기 로직에 기초하여 드라이버의 input_ctl() 콜백을 호출함으로써 발생한다. 천이가 너무 자주 발생하지 않도록(유지 시간이 디폴트로 1초로 설정됨) 그 천이를 레이트 제한하는 것이 주의된다.

도 12는 폴링이 턴 오프/턴 온되는 경우의, 스레드(1201 내지 1203) 간의 관계의 일 실시예를 도시한다.

일 실시예에서, 폴링 오프/온 모드 간의 주요 차이는 ifnet_input() 또는 ifnet_input_extended()를 호출하는 데 있어서의 상황 및 빈도에 있다.

일 실시예에서, 폴링이 오프인 경우, 작업 루프 스레드(1201)는 하드웨어로부터의 수신 IRQ를 처리하는 호스트 CPU의 일부로서 스케줄링되게 된다; 이 IRQ는 디바이스가 (예컨대, DMA를 통해) 하나 이상의 패킷을 호스트로 전달했음을 호스트에 시그널링한다. 하드웨어에서 행해진 IRQ 통합(coalescing)의 레벨에 무관하게, 이러한 IOKit 작업 루프 스레드가 스케줄링되게 하는 빈도는 인바운드 패킷들의 레이트에 의해 구동된다. 이러한 스케줄링(콘텍스트 스위치 등)의 비용은, 특히 본 발명의 시스템 아키텍처가 모든 IRQ들을 CPU0으로 라우팅한다는 사실을 고려하면, 매우 중요하다. 따라서, 일 실시예에서, 높은 부하 인자 검출 시, 폴링은 턴 온된다.

폴링이 온인 경우, 작업 루프 스레드(1201)는 수신 IRQ를 턴 오프한 것으로 인해 작업거부된다. 패킷들은 여전히 디바이스로부터 호스트로 전달되게 되고, 이들은 이들이 input_poll() 콜백을 통해 네트워킹 스택(1108)에 의해 구해질 때까지 드라이버(1111)의 수신 버퍼에 누적된다. 이제 활성 상태인 폴러 스레드(1202)는, 작업 루프 스레드(1201)가 스케줄링되게 되는 빈도가 네트워킹 스택(1108)에 의해 엄격하게 제어된다는 점을 제외하고는, 이러한 스레드의 동등한 기능들을 수행한다.

일 실시예에서, 폴링은 매체로부터 패킷을 수신하는 것에 관련된 패킷당 처리 비용의 분할상환(amortizing)을 고려하면 개선된 성능을 초래한다. 폴링이 턴 온되면, 네트워크 스택은 드라이버에게 폴링 모드로 진입할 것을 명령한다. 폴링 모드에 있는 동안, 드라이버는 하드웨어로부터 도달하는 패킷의 통지와 관련된 그의 수신 인터럽트 또는 트랩 핸들러(trap handler)를 턴 오프할 것이다. 패킷들은, CPU가 인터럽트되지 않을 것이라는 점을 제외하고는, 계속해서 (디바이스로부터, DMA 또는 등가물을 통해) 호스트의 메모리로 오는 상태를 유지할 것이다. 이는 CPU 상의 부하를 감소시키는데, 그 이유는 각각의 인터럽트가 보통 그것을 처리하기 위해 일련의 작업을 트리거할 것이기 때문이다; 그리고, 그것은 성능에 약간의 부정적인 영향을 미칠 것인데, 그 이유는 그 때 CPU 상에서 어떤 것이 구동되고 있을지라도 그것이 선점하기 때문이다. 그 후, 네트워크 스택은 (디폴트로; 이것은 구성가능함) 1 밀리초 간격으로 폴링하고, 각각의 간격 동안에 드라이버로부터 패킷을 풀링한다. 그것이 패킷 레이트가 드롭되었음을 검출하면, 폴링 모드가 종료되고 인터럽트가 다시 인에이블된다.

일 실시예에서, 폴링은 (예컨대, "저전력" 모드에 있을 때) 전력 소비를 감소시키도록 또는 사용자 활동(또는 비활동)에 기초하여 채용될 수 있다. 예를 들어, 시스템이 저전력 모드에 있다면, 이 정보는 네트워크 스택에 제공되고, 네트워크 스택은 그 후에 모든 적격 네트워크 인터페이스들 상에서 폴링 모드에 진입할 것을 선택할 수 있다. 이어서, 시스템이 더 이상 저전력 모드에 있지 않아 폴링 모드가 종료될 수 있을 때 네트워크 스택은 통지받을 것이다.

이용 활동(use activity)에 대해, 시스템이 사용자 인터페이스 입력을 처리하기 바쁜 경우, 이 정보는 네트워크 스택에 제공되고, 네트워크 스택은 그 후에 모든 적격 네트워크 인터페이스들 상에서 폴링 모드에 진입할 것을 선택할 수 있다. 시스템이 더 이상 UI 입력들을 처리하는 데 바쁘지 않아 폴링 모드가 종료될 수 있을 때 네트워크 스택은 통지받을 것이다.

수신 큐

일 실시예에서, ifnet의 if_inp 멤버는 DLIL 입력 스레드(1203)에 대한 수신 큐를 유지한다. 일 실시예에서, 이 데이터 구조는 도 13에 도시된 정보를 포함한다.

그의 송신 대응부와는 달리, 수신 큐는 인터페이스보다는 DLIL 입력 스레드 인스턴스와 관련된다. 상기에 언급된 바와 같이, 소정 유형의 인터페이스들은 공통(메인) 입력 스레드를 공유하는 반면, 다른 유형의 인터페이스들은 그들 자신의 전용 입력 스레드를 얻는다. 또한, 최대 N개의 송신 큐가 있을 수 있는 송신과는 달리, 현재 입력 스레드당 단 1개의 수신 큐 인스턴스만이 있다. 이 구조는 또한 입력에 이용되는 실제 커널 스레드들, 작업 루프(1201)뿐만 아니라 폴러 스레드(1202)에 관한 정보를 유지한다. 일 실시예에서, 이들 스레드 모두는, 그들이 (보다 양호한 캐시 국소성을 위해) 동일 프로세서 세트에서 스케줄링되도록 하기 위해, 동일 스레드 친화성(affinity) 태그를 공유하도록 구성된다. 기회주의적 폴링에 필요한 파라미터들(예컨대, 모드, {P,B,W}_avg, {P,B,W}_{lo,hi}wat)이 또한 일 실시예에서 이 구조 내에 상주한다.

링크 이벤트

일 실시예에서, 인터페이스에 관련된 이벤트들은 네트워킹 스택(102)으로부터, 연결된 스케줄러(116) 및 큐 관리 로직(115)으로, 그리고 추가로 모든 클래스 큐 인스턴스(110 내지 112) 상으로 전송된다. 이는 스케줄러, 큐 관리 로직(115) 및 그의 클래스들이, 필요하다면, 그들의 파라미터들을 그에 따라 조정하게 한다. 이벤트는 다음과 같다:

전술된 바와 같이, 본 발명의 실시예는 2개의 상이한 스케줄링 모드에 대한 지원을 포함한다: (1) 네트워크 스택 층에서의 스케줄링 및 (2) 드라이버 층에서의 스케줄링. 드라이버는 어느 유형의 스케줄링을 이용할지를 선택할 수 있다. 일 실시예에서, 드라이버가 802.11n을 구현하고 있는 경우, 그것은 WMM에 의해 정의되는 4개의 서비스 클래스를 이용하는 스케줄링을 수행할 것을 선택할 수 있는 반면(예컨대, 서비스 클래스들과 큐 인스턴스들 사이의 10:4 맵핑을 도시한 도 7 참조), 드라이버가 임의의 다른 인터페이스(예컨대, 102.11b/g, 3G, 이더넷 등)를 구현하고 있는 경우, 그것은 네트워크 계층에서 스케줄링이 수행되게 할 것을 선택할 수 있다(예컨대, 서비스 클래스들과 큐 인스턴스들 사이의 1:1 맵핑을 도시한 도 6 참조).

일 실시예에서, 드라이버 관리형 모델에서, 모든 큐들은 네트워크 스택 관리형 모델에서와 같이 셋업될 수 있지만, 스케줄링은 드라이버 스케줄러(160)에 의해 수행된다. 그렇기 때문에, 드라이버 기반 스케줄러는 이후에 우선순위에 기초하여(즉, WMM에 대한 4개의 클래스를 이용하여) 특정 클래스에 대한 각각의 디큐 동작을 위한 다수의 패킷을 요청할 것이다.

스케줄러(116, 160)는 어떤 큐가 그로부터 패킷을 디큐잉할 것인지를 결정하는 반면, 큐 관리 로직(115)(이것이 패킷을 드롭 또는 큐잉하는 옵션을 갖기 때문에 "드롭퍼(dropper")로 또한 지칭됨)에 의해 구현되는 큐잉 알고리즘은 디큐 전에 어떤 큐에 패킷이 큐잉되어야 하는지를 결정한다. 일 실시예에서, 스케줄러(116)는 패킷을 큐 관리 로직(115)에 전달하며, 이어서 이 큐 관리 로직은 패킷이 드롭되는지 또는 인큐잉되는지를 판정한다.

상기에 언급된 바와 같이, 일 실시예에서, 네트워크 스택에 의해 이용되는 스케줄러(116)는 신속 공정 큐잉(QFQ)을 이용하는 반면, 드라이버 스케줄러(160)는 트래픽 클래스 큐잉(TCQ)을 이용하는데, 이들 각각은 위에서 상세히 설명되었다.

흐름 제어 및 SFB 큐잉에 대한 추가의 상세사항

일 실시예에서, 동일한 큐 관리 로직(115)이 선택된 스케줄러의 유형에 무관하게 이용된다. 추계적 공정 BLUE(SFB)가 드라이버 관리형 스케줄러(160) 및 네트워크 레벨 스케줄러(116) 둘 모두에 대해 큐 관리 로직(115)에 의해 구현되는 디폴트 큐잉 알고리즘으로서 이용될 수 있다. 도 10a에 나타난 바와 같이, 흐름 해싱은 상이한 흐름들/소켓들로부터의 패킷들이 네트워크 및 드라이버 층 둘 모두 내에서 용이하게 트래킹되고 SFB 알고리즘에 의해 이용되게 한다. 소켓(204)이 처음에 접속되면, 해시 값(1001)이 계산되어, 소켓 데이터 구조에 저장되고, 접속된 소켓(204)의 수명 동안 사용된다. 데이터가 소켓으로부터 하위 층들(예컨대, 전송(205), IP(206), 전송 큐(306), 및 드라이버(150))로 내려 보내질 때는 언제든지, 흐름 해시 값(1001)이 패킷과 함께 전송되고, 소켓/흐름을 고유하게 식별하는 데 이용된다. 일단 흐름이 식별되면, 카운터가 하나 이상의 SFB 빈(1009)(도 10a에서 변수 C로 나타냄) 내에서 각각의 새로운 패킷이 큐잉됨에 따라 증가되고 각각의 패킷이 디큐잉됨에 따라 감소된다. 따라서, 각각의 흐름에 대해 현재 큐잉되는 패킷들의 수가 알려지고, 그 흐름에 대한 흐름 제어를 수행하는 데 이용된다. 일 실시예에서, 특정 흐름이 (도 10a에서 카운터 C>=FADV THRESHOLD로 나타내어진 바와 같이) 특정 임계치를 넘어 큐잉된 패킷들을 갖는 경우, 그 흐름에 대한 확률 값은 약간의 간격만큼 증가된다. 일단 확률이 그의 한도(예컨대, 1)에 도달하면, 이는 너무 많은 패킷들이 있고(즉, 애플리케이션이 너무 빨리 전송함) 이 흐름에 대한 추가 패킷들이 드롭된다는 것을 나타낸다.

도 10a는 이러한 메커니즘을 상세히 도시한다. 일 실시예에서, 흐름 해시는 소켓(204)으로부터 하위 층들로 흘러 내려가는 모든 패킷을 태그하는 데 사용되어서, 이들 하위 층은 어느 패킷이 그 아래로 흐르는지를 인식하고 네트워크 계층에 피드백을 제공할 수 있다. 패킷들은 그 흐름과 관련된 전송 큐(306) 내에서 큐잉되며, 언급된 바와 같이, SFB는 흐름 해시를 이용하여 각각의 흐름에 대해 SFB 빈(1009) 내에 저장된 카운터(C₁, C₂)를 증가 및 감소시킨다. SFB는 그의 메모리 데이터 구조 내의 카운터들을 이용하여 큐잉 임계치가 초과되었는지를 판정한다. 예를 들어, 흐름에 대해 큐잉된 패킷들의 수가 임계치에 있는 50이면, 그것은 그 흐름에 대한 상태를 저장하고 전송 층에 피드백을 전송하여, 그 흐름을 지원하는 소켓(204)에 대한 흐름 제어를 턴 온한다. 따라서, 흐름은 정상으로부터 흐름 제어 상태로 이동하며, 패킷들이 큐로부터 디큐잉되고 링크를 통해 전송되게 되는 동안에는 그러한 상태에서 유지된다.

일단 큐 내의 패킷들의 수가 임계치 아래로 떨어지면, 큐잉 알고리즘은 소켓(204)에 대한 흐름 제어를 웨이크업하고 턴 오프시키는 흐름 권고 스레드(1050)를 웨이크한다. 그 결과, 소켓은 이어서 그것이 다시 흐름 제어 상태에 놓일 때까지 하위 층들을 통해 마음대로 패킷들을 아래로 전송할 수 있다. 따라서, 도 10a는 명시적 혼잡 통지(ECN)와 같은 TCP에서의 내부 메커니즘에 의존함이 없이 피드백을 제공하고 동일 호스트 상의 흐름들이 흐름 제어/정상 상태 사이에서 움직이게 하는 메커니즘을 도시한다. 이는 성능을 개선하는데, 그 이유는 단지 드롭될 데이터를 네트워크 스택으로 내려 보냄으로써 행해지는 불필요한 작업이 감소되기 때문이다. 또한, 그것은 드라이버 내에서의 큐 크기가 패킷 드롭 없이 감소되게 한다. 이는 애플리케이션이 단지 드라이버에 의해 드롭될 패킷들을 스택 아래로 맹목적으로 송신하는 종래의 메커니즘과는 대조를 이룬다. 대조적으로, 도 10a에서, 네트워크 스택이 큐 모니터링 때문에 링크 상에서 무엇이 진행 중인지를 알고 있으므로, 그것은 이 정보를 이용하여 전송 메커니즘의 거동을 지능적으로 변화시킬 수 있다.

도 10b에 더 상세히 도시된 일 실시예에서, SFB 알고리즘은 패킷의 해시 값을 취하며, SFB에 대해 고유하고 흐름을 위한 비트들을 선택하는 데 이용되는 다른 해시를 계산한다. 도시된 바와 같이, 소켓에 의해 계산된 오리지널 해시 값은 4 바이트(01, 02, 03, 04)이며, 이것은 SFB 큐잉 로직(1060)의 해시 발생기(1065)에 제공될 수 있다. 소정의 흐름 해시는 0의 값을 제공받을 수 있으며, 여기에서 설명되는 흐름 제어 메커니즘들이 사용되지 않는 흐름을 식별하는 데 사용될 수 있다. 일 실시예에서, SFB는 난수를 생성하고, 난수(A, B, C, D)를 이용하여 새로운 해시를 계산한다. 그것은 이들 4개의 값을 이용하여 빈들의 2개 세트, 즉 도 10b에 도시된 바와 같은 현재 세트 및 섀도우 세트(이들 각각은 2개의 레벨을 가짐)를 파퓰레이팅(populate)한다. 2개의 레벨은 새로운 해시 값들을 이용하여 인덱싱되는 어레이로서 구현된다(각각의 슬롯은 일 실시예에서 256 비트이다). 따라서, 흐름은 흐름 해시 값을 이용하여 SFB 빈에 맵핑된다. 흐름이 존재하는지 여부를 검사하기 위해, SFB 빈이 검사될 수 있다. SFB 알고리즘의 블룸 필터 기능성은 특정 흐름이 SFB 빈들 내에 존재하지 않는지 여부를 검사할 수 있다. 그러한 흐름이 존재하는 경우, 그것은 그 흐름과 관련된 데이터(예컨대, 위에서 언급된 확률 및 카운터)를 결정하도록 인덱싱될 수 있다. 이러한 데이터는 흐름이 여전히 존재하는 한 SFB에 의해 유지된다. 섀도우 세트는, 약간의 간격을 두고서 SFB가 리해싱(rehash)하기 때문에 사용된다. 블룸 필터의 특성 때문에, 많은 것이 동일한 빈에 맵핑될 수 있다. 많은 소켓이 있다면, 데이터를 너무 많이 전송하고 있는 일부 소켓은 동일 빈에 맵핑되는 많은 데이터를 전송하고 있지 않는 다른 소켓에 영향을 미칠 수 있다. 따라서, SFB는 새로운 난수에 기초하여 내부 해시를 주기적으로 재계산한다. 리해싱 후, 빈은 각각의 흐름에 대해 이리저리 이동할 수 있다. SFB 알고리즘의 추가 상세사항을 본 특허 출원서에 부록 B로서 첨부되고 본 명세서에 참고로 포함되는 참고문헌[Stochastic Fair Blue: A Queue Management Algorithm for Enforcing Fairness]에서 찾을 수 있다. 이러한 경우, 섀도우 세트는 데이터를 새로운 빈으로 이동시키는 데 사용될 수 있다.

기회주의적 거동, 흐름 제어, 트래픽 유예, 및 전송 층 개선을 포함한 애플리케이션 구동 트래픽 분류 및 흐름 피드백

도 6 내지 도 8과 관련하여 전술된 애플리케이션 구동 트래픽 분류는 다양한 기회주의적 거동을 인에이블하는 데 이용될 수 있다. 언급된 바와 같이, 각각의 애플리케이션은 어떤 트래픽 클래스가 그의 소켓에 대한 것이어야 하는지를 명시적으로 진술할 수 있다. 예를 들어, 이를테면 하나의 애플리케이션이 BK_SYS와 같은 낮은 우선순위 트래픽 클래스를 이용하여 날짜를 백업하고 있지만, 사용자는 음성 호출을 하기를 원한다. GSM이 작업하는 방식 때문에, 네트워크 데이터가 전송되고 있는 동안에 음성 호출이 진행 중이라면, 이것은 음성 호출이 열화되거나 드롭될 확률을 증가시킨다. 유사하게, 사용자가 호출 중에 동안 웹 브라우저를 여는 경우, 그것은 또한 호출에 영향을 미칠 수 있다. 이를 완화하기 위해, 일 실시예에서, 사용자가 음성 호출 중인 때 불필요한 트래픽을 억제하기 위해 트래픽 클래스가 사용된다. 임의의 비-긴급 트래픽(예컨대, 백그라운드 트래픽 - BKS_SYS)이 음성 호출 동안에 유예될 수 있다. 일 실시예에서, 유예된 소켓의 경우, 디큐가 발생하면 시스템은 디큐잉할 것이 없는 것처럼 가장하고, 인큐가 발생하면 패킷들은 드롭된다. 따라서, 송신 애플리케이션은 이것을 마치 네트워크가 정지했던 것처럼 볼 것이며, 다시 시도하기 전에 대기할 수 있다. 호출이 상대적으로 빠르면, 그것은 (소켓을 완전히 셧다운함이 없이) 호출이 끝났을 때 재개될 것이다. 이러한 기법은 BK_SYS (예컨대, BK, BE 등) 외의 트래픽 클래스들에 이용될 수 있다. 일 실시예에서, 전술된 흐름 제어/권고 메커니즘은 또한 이러한 상황에서 소켓들을 유예시키는 데 이용된다(예컨대, 유예된 경우, 흐름 제어 표시가 전송된다). 따라서, 소정 소켓들에 대한 트래픽을 분류함으로써(예컨대, BK_SYS), 트래픽 유예를 처리하기 위한 지능적 피드백 메커니즘이 제공되고 이들 소켓에 대한 기회주의적 거동이 커널에서 인에이블된다.

유예 상태는 흐름 제어 상태와는 상이하다는 것에 유의한다. 흐름 제어 상태에서, 애플리케이션은 여전히 데이터를 전송하고 있을 수 있지만, 유예 상태에서는, (예컨대, 음성 호출이 긴 시간을 소요하기 때문에) 링크가 차단된다. 따라서, 유예 상태에서는, 임의의 더 많은 패킷들을 전송하는 것을 중지하는 것이 유익한데, 그 이유는 (큐가 유예되므로) 그 패킷들이 단지 드롭되게 될 것이기 때문이다. 일 실시예에서, 유예된 애플리케이션은 타이머를 개시할 것을 선택하고, 너무 길게 유예되면, 단지 접속을 닫는 것을 선택할 수 있다.

요약하자면, 일 실시예에서, 음성 호출이 수신/이행된 경우:

(1) 시스템 내의 권한있는 엔티티가 셀룰러 네트워크 인터페이스(들)를 기회주의적 스로틀링 모드로 구성한다.

(2) 기회주의적 모드는 각각의 영향받은 인터페이스의 패킷 스케줄러 상에서 구성되게 된다.

(3) 스케줄러는 이 기회주의적 모드에서 유예될 모든 송신 큐들을 조사한다; 현재는, 이것이 BK_SYS 송신 큐에만 적용된다. 각각의 영향받은 송신 큐는 유예 모드에 진입한다; 모든 기존 패킷들은 플러시되고, 추가의 인큐들이 드롭을 야기할 것이다.

(4) 모든 기회주의적 소켓(BK_SYS 분류를 갖는 소켓)은 "유예 이벤트"를 수신할 것이다.

일 실시예에서, 음성 호출이 종료되는 경우:

(1) 시스템 내의 권한있는 엔티티가 셀룰러 네트워크 인터페이스(들)로부터 기회주의적 스로틀링 모드를 제거한다.

(2) 각각의 영향받은 인터페이스에 대한 패킷 스케줄러는 기회주의적 스로틀링 모드를 종료한다.

(3) 스케줄러는 이러한 기회주의적 모드에서 유예된 모든 송신 큐들을 조사한다; 현재는, 이것이 BK_SYS 송신 큐에만 적용된다. 각각의 영향받은 송신 큐가 재개된다; 추가의 인큐들이 허용된다.

(4) 모든 기회주의적 소켓(BK_SYS 분류를 갖는 소켓)은 "재개 이벤트"를 수신할 것이다.

또한, 본 명세서에서 "큰 수신 오프로드(offload)"로 지칭되는 성능 최적화가 수신 측에 대한 실현된다. 일 실시예에서, 이것은 네트워크 스택에서의 호출 함수들에 의해 패킷당 비용을 감소시킴으로써 작업한다. 예를 들어, 10개의 패킷이 수신되고, 10개 모두를 처리하기 보다는, 단지 1개 또는 2개만이 처리될 수 있다. AV 클래스(스트리밍 비디오)와 같은 소정 클래스들에 대해, 이러한 최적화를 인에이블할 수 있다. AV 비디오 애플리케이션에서, 소프트웨어는 그것이 재생을 시작하기 전에 수 초 동안 비디오를 버퍼링한다. 그래서, 이 때문에, 이 애플리케이션은 큰 수신 오버로드 기법들을 이용하여 성능 이익을 수신할 수 있는데, 그 이유는 그들이 지연 민감성이 아니기 때문이다.

일 실시예에서, 스택 위로 제공되는 피드백 때문에, TCP가 전송 및 수신하는 방식은 소정 소켓들에 대해 조정될 수 있다. 예를 들어, 애플리케이션이 흐름을 BK 또는 BK_SYS로 분류하면, TCP는 덜 공격적일 것이다. 예를 들어, 소켓이 BK이고 이 링크 상에서 높은 혼잡이 검출되는 경우, 애플리케이션은 백 오프될 수 있고, 다른 흐름들에 대해 더 우수한 응답 시간을 수신할 수 있다(예컨대, 네트워크에 백업하는 소켓은 다른 소켓 상의 HTTP를 수신하도록 지연될 수 있다). 애플리케이션이 소켓 트래픽 클래스를 명시적으로 특정할 수 있기 때문에 그 모두가 가능하다.

전술된 바와 같이, 일 실시예에서, 최고 분류(CTL)는 네트워크 제어 패킷에 사용되는데, 이러한 패킷은 ARP, ACK 응답, IPV6에 대한 이웃 탐색(neighbor discovery), 멀티캐스트 가입 및 탈퇴, DCP 관련 패킷, IPV6 스테이션 라우터 공지 패킷, 및 DNS 패킷을 포함할 수 있다. 그 결과, DNS 동작들은 사용자가 더 낮은 우선순위 소켓을 이용하여 큰 업로드를 수행하고 있는 경우에는 지연되지 않을 것이다. 유사하게, ACK 응답은 더 낮은 우선순위 소켓들 상에서의 활동의 결과로서 지연되지 않을 것이다. 이러한 유형의 제어 패킷들은 매우 작고, 어떠한 지연도 없이 배출될 수 있다.

또한, 언급된 바와 같이, 전술된 기법 및 아키텍처는 흐름 제어 및 유예 상태 동안에 내장 TCP 및 UDP 백오프 메커니즘들을 제공한다. 보통, TCP는 (예컨대, 전술된 바와 같은 ECN을 이용하여) 백 오프함으로써 자체적으로 혼잡에 응답한다. TCP는 패킷을 전송하며, 확인응답(ACK)을 얻지 않은 경우, 그것은 패킷을 되풀이해서 전송하고 각각의 재송신에 따라 백 오프한다. 이러한 재송신은, 패킷이 여전히 인터페이스 큐(151 내지 153)에 있고 링크가 이용가능하게 된 후에만 전송될 것이라는 것이 알려져 있는 경우에는, 리소스의 낭비이다. 따라서, 이러한 상황에서는, 내장 TCP 또는 UDP 메커니즘들을 이용하여 백 오프 및 재송신할 필요가 없다. 대신, 본 명세서에서 설명된 기법을 이용하여, 흐름 제어 권고가 발행되어 재송신 기능을 디스에이블하도록 할 수 있다.

또한, 일 실시예에서, TCP에 사용되는 재전송 타이머는 더 효율적으로 동작하도록 변경(tweak)될 수 있다. 전형적으로, TCP는 어떠한 ACK도 수신되지 않는 경우에 재송신 타이머를 백 오프한다(예컨대, 매번 2배만큼 증가시킴). 따라서, 재송신 타이머는 수 초가 될 수 있다. 인터페이스로부터의 피드백이 전술된 바와 같이 제공되므로, 이러한 백오프는 발생할 필요가 없다. 일단 흐름 제어 권고를 얻으면, 자동적으로 대기할 수 있는데, 그 이유는 패킷이 큐잉되는 것을 알기(그리고 계속해서 재전송하는 것을 원하지 않기) 때문이다. 그러나, 일 실시예에서, 재송신 타이머는 흐름 제어가 소켓에 대해 턴 오프된 후에 이용될 수 있다.

또한, 흐름 권고는 더 이상의 어떠한 데이터도 TCP에 기록하지 않는 애플리케이션에 내내 전달된다. 따라서, 애플리케이션은 모든 오래된 데이터(예컨대, 구 비디오 프레임)를 드롭할 수 있으며, 흐름 제어가 턴 오프되는 경우 더 새로운 데이터를 전송할 수 있다. 이는 애플리케이션이 오래된 데이터를 드롭하지 않으면 오디오 및 비디오가 동기화되지 않을 수 있는 양방향 비디오 데이터에 특히 유리하다.

UDP와 함께 송신하는 애플리케이션에 유사한 원리가 적용될 수 있다. 본 명세서에서 설명된 흐름 권고 기법 없이는, UDP는 그의 애플리케이션에 어떠한 피드백도 제공하지 않는다. 따라서, 인터페이스가 드롭하면, 애플리케이션은 그에 따라 스택의 하위 레벨에서 버퍼링되어야 하는 패킷을 알지 못하고 이를 계속해서 송신하여, 리소스를 낭비한다. 대조적으로, 흐름 제어 상태에 있는 경우, 애플리케이션에 의한 모든 기록들은 즉시 드롭될 수 있다(이에 의해 버퍼링 리소스들을 절감함). 상기의 내용을 행하는 것은 패킷들을 버퍼링함으로써 발생할 지연의 상당한 양을 감소시킨다.

인바운드 네트워크 트래픽을 처리하고, 네트워크 성능을 개선하고, 서비스 거부 공격(denial-of-service attack)을 처리하기 위한 기회주의적 폴링 메커니즘

전술된 바와 같이, 일 실시예에서, RXPOLL-가능 인터페이스들은 동작의 입력 폴링 오프 모드와 입력 폴링 온 (또는 레거시) 모드(예컨대, IFNET_MODEL_INPUT_POLL_OFF와 IFNET_MODEL_INPUT_ POLL_ON) 사이에서 천이한다. 일 실시예에서, 입력 폴링 오프 모드는 디폴트/초기 모드로서 사용되며, 네트워크 스택이 부하 인자가 낮음을 판정한 경우에 그에 의해 선택된다. 부하 인자는 변수들 P_avg, B_avg, 및 W_avg(각각, 패킷들의 개수, 바이트 및 웨이크업 요청에 대한 값들)를 평가함으로써 결정될 수 있다. 도 12에서의 DLIL 입력 스레드(1203)를 참조하면, 일 실시예에서, 입력 폴링 온 모드로의 스위칭은 (P_avg

P_hiwat && (B_avg

B_hiwat || W_avg

W_hiwat))인 경우에 행해지는데, 여기서 P_hiwat, B_hiwat 및 W_hiwat는 변수들에 대한 낮은 워터마크 값들이다.

반대로, 폴링 오프 모드로의 스위칭은 (P_avg

P_lowat && B_avg

B_lowat && W_avg

W_lowat)인 경우에 행해지는데, 여기서 P_lowat, B_lowat 및 W_lowat는 변수들에 대한 낮은 워터마크 값들이다.

일 실시예에서, 이들 낮은 및 높은 워터마크 값들은 소정의 작업부하에 기초하여 임의적으로 선택될 수 있으며, 이들은 그에 따라 미래의 작업부하(및 다양한 링크 속도)를 수용하도록 조정되어야 한다.

높은 부하 인자에 기초하여, 이러한 방식으로 폴링을 턴 온하는 것은 성능을 개선하고 서비스 거부 공격을 방지한다. 이는, 폴링 메커니즘을 이용해, 네트워크 계층에 있는 수신 큐가 드라이버 층에 있는 큐들로부터의 패킷들을, 그것이 이들을 큐잉할 충분한 여지를 갖는 경우에만 요청할 것이기 때문이다. 그것이 여지를 갖지 않는 경우, 그것은 더 많은 패킷 및 인터페이스에 의해 드롭될 패킷(즉, 드라이버 층 큐들이 가득 채워진 때)을 요청하도록 폴링하지 않을 것이다. 따라서, 서비스 거부가 드라이버 층에서 방지되고, 네트워크 계층까지는 전달되지 않는다.

여러 API 실시예들

일 실시예에서 구현된 API는 소프트웨어 콤포넌트(이하, "API 구현 소프트웨어 콤포넌트")에 의해 구현되는 인터페이스인데, 이 소프트웨어 콤포넌트는 상이한 소프트웨어 콤포넌트(이하, "API 호출 소프트웨어 콤포넌트")가 하나 이상의 함수, 메소드, 절차, 데이터 구조, 및/또는 API 구현 소프트웨어 콤포넌트에 의해 제공되는 다른 서비스에 액세스하고 이를 이용하게 한다. 예를 들어, API는 API 호출 소프트웨어 콤포넌트의 개발자(제3자 개발자일 수 있음)가 API 구현 소프트웨어 콤포넌트에 의해 제공되는 특정된 특징들을 레버리징하게 한다. 하나의 API 호출 소프트웨어 콤포넌트가 있을 수 있거나, 하나 초과의 그러한 소프트웨어 콤포넌트가 있을 수 있다. API는 소프트웨어 애플리케이션으로부터의 서비스에 대한 요청을 지원하기 위해 컴퓨터 시스템 또는 프로그램 라이브러리가 제공하는 소스 코드 인터페이스일 수 있다. API는 데이터가 메모리에 어떻게 레이아웃되는지에 대한 명시적인 낮은 수준의 설명보다는, 해석을 제공할 수 있거나 애플리케이션이 구성되는 경우에 컴파일될 수 있는 프로그래밍 언어의 관점에서 특정될 수 있다.

API는 API 구현 소프트웨어 콤포넌트의 특정된 특징들에 액세스하고 이들을 이용하는 경우에 API 호출 소프트웨어 콤포넌트가 사용하는 언어 및 파라미터를 정의한다. 예를 들어, API 호출 소프트웨어 콤포넌트는 API에 의해 노출되는 하나 이상의 API 호출(때때로 함수 또는 메소드 호출로 지칭됨)을 통해 API 구현 소프트웨어 콤포넌트의 특정된 특징들에 액세스한다. API 구현 소프트웨어 콤포넌트는 API 호출 소프트웨어 콤포넌트로부터의 API 호출에 응답하여 API를 통해 값을 리턴할 수 있다. API가 API 호출의 신택스 및 결과(예컨대, API 호출을 호출하는 방법 및 API 호출이 행한 것)를 정의하지만, API는 전형적으로 API 호출이 API 호출에 의해 특정된 함수를 어떻게 달성하는지를 밝히지 않는다. 다양한 함수 호출 또는 메시지가 호출 소프트웨어(API 호출 소프트웨어 콤포넌트)와 API 구현 소프트웨어 콤포넌트 사이에서 하나 이상의 애플리케이션 프로그래밍 인터페이스를 통해 전달된다. 함수 호출 또는 메시지를 전달하는 것은 함수 호출 또는 메시지를 발행, 개시, 부름, 호출, 수신, 리턴, 또는 그에 대해 응답하는 것을 포함할 수 있다. 이런 이유로, API 호출 소프트웨어 콤포넌트가 호출을 전달할 수 있고, API 구현 소프트웨어 콤포넌트가 호출을 전달할 수 있다.

예로서, API 구현 소프트웨어 콤포넌트(2010) 및 API 호출 소프트웨어 콤포넌트는 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈일 수 있다(API 구현 소프트웨어 콤포넌트 및 API 호출 소프트웨어 콤포넌트는 서로 동일하거나 상이한 유형의 소프트웨어 모듈일 수 있음이 이해되어야 한다). API 호출 소프트웨어 콤포넌트는 네트워크를 통해 API에 의해 API 구현 소프트웨어 콤포넌트와 통신하는 로컬 소프트웨어 콤포넌트(즉, API 구현 소프트웨어 콤포넌트와 동일한 데이터 처리 시스템 상에 있음) 또는 원격 소프트웨어 콤포넌트(즉, API 구현 소프트웨어 콤포넌트와는 상이한 데이터 처리 시스템 상에 있음)일 수 있다. API 구현 소프트웨어 콤포넌트는 또한 API 호출 소프트웨어 콤포넌트로서 작용할 수 있고(즉, 상이한 API 구현 소프트웨어 콤포넌트에 의해 노출되는 API로의 API 호출을 행할 수 있음), API 호출 소프트웨어 콤포넌트는 또한 상이한 API 호출 소프트웨어 콤포넌트에 노출되는 API를 구현함으로써 API 구현 소프트웨어 콤포넌트로서 작용할 수 있다는 것이 이해되어야 한다.

API는 상이한 프로그래밍 언어들로 기록된 다수의 API 호출 소프트웨어 콤포넌트들이 API 구현 소프트웨어 콤포넌트와 통신하게 할 수 있다(그에 따라 API는 호출을 변환하기 위한 특징을 포함할 수 있고, API 구현 소프트웨어 콤포넌트와 API 호출 소프트웨어 콤포넌트 사이에서 리턴할 수 있다); 그러나, API는 특정 프로그래밍 언어의 관점에서 구현될 수 있다.

도 14는 API(1420)를 구현하는 API 구현 소프트웨어 콤포넌트(1410)(예컨대, 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈)를 포함하는 API 아키텍처의 일 실시예를 도시한다. API(1420)는 하나 이상의 함수, 메소드, 클래스, 객체, 프로토콜, 데이터 구조, 포맷, 및/또는 API 호출 소프트웨어 콤포넌트(1430)에 의해 사용될 수 있는 API 구현 소프트웨어 콤포넌트의 다른 특징을 특정한다. API(1420)는 API 구현 소프트웨어 콤포넌트에서의 함수가 API 호출 소프트웨어 콤포넌트로부터 파라미터들을 어떻게 수신하는지, 그리고 그 함수가 API 호출 소프트웨어 콤포넌트에 결과를 어떻게 리턴하는지를 특정하는 적어도 하나의 호출 규약(calling convention)을 특정할 수 있다. API 호출 소프트웨어 콤포넌트(1430)(예컨대, 운영 체제, 라이브러리, 디바이스 드라이버, API, 애플리케이션 프로그램, 또는 다른 소프트웨어 모듈)는 API(1420)에 의해 특정되는 API 구현 소프트웨어 콤포넌트(1410)의 특징에 액세스하고 이를 사용하도록 API(1420)를 통해 API 호출을 행한다. API 구현 소프트웨어 콤포넌트(1410)는 API 호출에 응답하여 API(1420)를 통해 API 호출 소프트웨어 콤포넌트(1430)로 값을 리턴할 수 있다.

API 구현 소프트웨어 콤포넌트(1410)가 추가 함수, 메소드, 클래스, 데이터 구조, 및/또는 API(1420)를 통해 특정되지 않고 API 호출 소프트웨어 콤포넌트(1430)가 이용가능하지 않은 다른 특징을 포함할 수 있음이 인식될 것이다. API 호출 소프트웨어 콤포넌트(1430)가 API 구현 소프트웨어 콤포넌트(1410)와 동일한 시스템 상에 있을 수 있거나, 원격으로 위치되어 네트워크를 통해 API(1420)를 이용하여 API 구현 소프트웨어 콤포넌트(1410)에 액세스할 수 있다는 것을 이해해야 한다. 도 14는 API(1420)와 상호작용하는 단일 API 호출 소프트웨어 콤포넌트(1430)를 도시하고 있지만, API 호출 소프트웨어 콤포넌트(1430) 외에, 상이한 언어(또는 동일 언어)로 기록될 수 있는 다른 API 호출 소프트웨어 콤포넌트가 API(1420)를 이용할 수 있다는 것을 이해해야 한다.

API 구현 소프트웨어 콤포넌트(1410), API(1420), 및 API 호출 소프트웨어 콤포넌트(1430)는 기계 판독가능 매체에 저장될 수 있으며, 이러한 매체는 기계(예컨대, 컴퓨터 또는 다른 데이터 처리 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함한다. 예를 들어, 기계 판독가능 매체는 자기 디스크, 광 디스크, RAM(random access memory), ROM(read only memory), 플래시 메모리 디바이스 등을 포함한다.

도 15("소프트웨어 스택")에서, 예시적인 실시예, 애플리케이션은 여러 서비스 API를 이용하여 서비스 1 또는 서비스 2로의 호출을 행하고 여러 운영 체제(OS) API를 이용하여 OS로의 호출을 행할 수 있다. 서비스 1 및 서비스 2는 여러 OS API를 이용하여 OS로의 호출을 행할 수 있다.

서비스 2는 2개의 API를 갖는데, 그 중 하나(서비스 2 API 1)는 애플리케이션 1로부터 호출을 수신하고 그로 값을 리턴하며, 다른 것(서비스 2 AP 2)은 애플리케이션 2로부터 호출을 수신하고 그로 값을 리턴함에 유의한다. 서비스 1(예를 들어, 소프트웨어 라이브러리일 수 있음)은 OS API 1로의 호출을 행하고 그로부터 리턴 값을 수신하며, 서비스 2(예를 들어, 소프트웨어 라이브러리일 수 있음)는 OS API 1 및 OS API 2 둘 모두로의 호출을 행하고 그들로부터 리턴 값을 수신한다. 애플리케이션 2는 OS API 2로의 호출을 행하고 그로부터 리턴 값을 수신한다.

예시적인 데이터 처리 디바이스 및 인터페이스

도 16은 본 발명의 일부 실시예에서 사용될 수 있는 예시적인 컴퓨터 시스템을 도시하는 블록 다이어그램이다. 도 16이 컴퓨터 시스템의 다양한 콤포넌트를 예시하고 있지만, 그러한 상세사항들은 본 발명과 밀접한 관련이 있지 않기 때문에 콤포넌트들을 상호접속시키는 임의의 특정 아키텍처 또는 방식을 나타내는 것으로 의도되지 않음을 이해해야 한다. 더 적은 콤포넌트 또는 더 많은 콤포넌트를 갖는 다른 컴퓨터 시스템이 또한 본 발명과 함께 사용될 수 있음이 인식될 것이다.

도 16에 도시된 바와 같이, 데이터 처리 시스템의 형태인 컴퓨터 시스템(2300)은 처리 시스템(2320), 전원 장치(2325), 메모리(2330), 및 비휘발성 메모리(2340)(예컨대, 하드 드라이브, 플래시 메모리, 상 변화 메모리(PCM) 등)와 연결된 버스(들)(2350)를 포함한다. 버스(들)(2350)는 당업계에 공지되어 있는 바와 같이 다양한 브리지, 제어기, 및/또는 어댑터를 통해 서로 접속될 수 있다. 처리 시스템(2320)은 메모리(2330) 및/또는 비휘발성 메모리(2340)로부터 명령어(들)를 구할 수 있고, 전술된 바와 같은 동작들을 수행하도록 이 명령어를 실행시킬 수 있다. 버스(2350)는 상기 콤포넌트들을 함께 상호접속시키고, 또한 이들 콤포넌트들을 선택적 도크(2360). 디스플레이 제어기 및 디스플레이 디바이스(2370), 입력/출력 디바이스(2380)(예컨대, 네트워크 인터페이스 카드(Network Interface Card, NIC), 커서 제어부(예컨대, 마우스, 터치스크린, 터치패드 등), 키보드 등), 및 선택적 무선 송수신기(들)(2390)(예컨대, 블루투스, WiFi, 적외선 등)에 상호접속시킨다.

도 17은 본 발명의 일부 실시예에서 사용될 수 있는 예시적인 데이터 처리 시스템을 도시하는 블록 다이어그램이다. 예를 들어, 데이터 처리 시스템(2400)은 핸드헬드 컴퓨터, PDA(personal digital assistant), 휴대 전화, 휴대용 게이밍 시스템, 휴대용 미디어 플레이어, 태블릿, 또는 휴대 전화, 미디어 플레이어, 및/또는 게이밍 시스템을 포함할 수 있는 핸드헬드 컴퓨팅 디바이스일 수 있다. 다른 예로서, 데이터 처리 시스템(2400)은 다른 디바이스 내의 네트워크 컴퓨터 또는 내장형 처리 디바이스일 수 있다.

본 발명의 일 실시예에 따르면, 데이터 처리 시스템(2400)의 예시적인 아키텍처는 전술된 모바일 디바이스에 이용될 수 있다. 데이터 처리 시스템(2400)은 하나 이상의 마이크로프로세서 및/또는 시스템을 집적 회로 상에 포함할 수 있는 처리 시스템(2420)을 포함한다. 처리 시스템(2420)은 메모리(2410), 전원 장치(2425)(하나 이상의 배터리를 포함함), 오디오 입력/출력부(2440), 디스플레이 제어기 및 디스플레이 디바이스(2460), 선택적 입력/출력부(2450), 입력 디바이스(들)(2470), 및 무선 송수신기(들)(2430)와 연결된다. 도 24에 도시되지 않은 추가의 콤포넌트들이 또한 본 발명의 소정 실시예에서 데이터 처리 시스템(2400)의 일부일 수 있고, 본 발명의 소정 실시예에서 도 16에 도시된 것보다 적은 콤포넌트들이 사용될 수 있다는 것이 이해될 것이다. 또한, 도 16에 도시되지 않은 하나 이상의 버스가 당업계에 주지되어 있는 바와 같이 다양한 콤포넌트들을 상호접속시키는 데 사용될 수 있다는 것이 이해될 것이다.

메모리(2410)는 데이터 처리 시스템(2400)에 의한 실행을 위한 데이터 및/또는 프로그램을 저장할 수 있다. 오디오 입력/출력부(2440)는 마이크로폰 및/또는 스피커를 포함하여, 예를 들어 그 스피커 및 마이크로폰을 통해 음악을 재생하고/하거나 전화 기능을 제공할 수 있다. 디스플레이 제어기 및 디스플레이 디바이스(2460)는 그래픽 사용자 인터페이스(GUI)를 포함할 수 있다. 무선(예컨대, RF) 송수신기(2430)(예컨대, WiFi 송수신기, 적외선 송수신기, 블루투스 송수신기, 무선 셀룰러 전화 송수신기 등)는 다른 데이터 처리 시스템들과 통신하는 데 사용될 수 있다. 하나 이상의 입력 디바이스(2470)는 사용자가 시스템에 입력을 제공하게 한다. 이들 입력 디바이스는 키패드, 키보드, 터치 패널, 멀티 터치 패널 등일 수 있다. 선택적인 다른 입력/출력부(2450)는 도크용 커넥터일 수 있다.

본 발명의 실시예는 전술된 바와 같은 다양한 단계를 포함할 수 있다. 단계들은 범용 또는 특수 목적 프로세서가 소정 단계들을 수행하게 하는 기계 실행가능 명령어들로 구현될 수 있다. 대안적으로, 이들 단계는 그 단계들을 수행하기 위한 하드웨어 내장형 로직을 포함하는 특정 하드웨어 콤포넌트에 의해, 또는 프로그래밍된 컴퓨터 콤포넌트들과 주문형 하드웨어 콤포넌트들의 임의의 조합에 의해 수행될 수 있다.

본 발명의 요소들은 또한 기계 실행가능 프로그램 코드를 저장하기 위한 기계 판독가능 매체로서 제공될 수 있다. 기계 판독가능 매체는 플로피 디스켓, 광 디스크, CD-ROM, 및 광자기 디스크, ROM, RAM, EPROM, EEPROM, 자기 카드 또는 광학 카드, 또는 전자 프로그램 코드를 저장하는 데 적합한 다른 유형의 미디어/기계 판독가능 매체를 포함할 수 있지만 이들로 한정되지 않는다.

전술한 설명 전반에 걸쳐서, 설명을 위해, 본 발명의 완전한 이해를 제공하기 위해 많은 특정 상세사항들이 설명되었다. 그러나, 본 발명이 이들 특정 상세사항들 중 일부 없이도 실행될 수 있음이 당업자에게 자명할 것이다. 예를 들어, 본 명세서에서 설명된 기능 모듈 및 방법이 소프트웨어, 하드웨어 또는 이들의 임의의 조합으로서 구현될 수 있음이 당업자에게 명백히 자명할 것이다. 또한, 본 발명의 실시예가 모바일 컴퓨팅 환경의 맥락 내에서(즉, 모바일 디바이스(120 내지 123; 601 내지 603)를 사용하여) 본 명세서에 설명되고 있지만, 본 발명의 기본 원리는 모바일 컴퓨팅 구현으로 제한되지 않는다. 예를 들어 데스크톱 또는 워크스테이션 컴퓨터를 포함한 사실상 임의의 유형의 클라이언트 또는 피어 데이터 처리 디바이스가 일부 실시예에서 사용될 수 있다. 따라서, 본 발명의 범주 및 사상은 다음의 특허청구범위의 관점에서 판단되어야 한다.

Claims

클라이언트 디바이스 상에서 패킷 스케줄링을 관리하기 위한 컴퓨터 구현 방법으로서,
송신될 패킷을 수신하는 단계;
상기 패킷을 네트워크 스택 레벨에서 큐에 인큐잉(enqueuing)하는 단계;
패킷 스케줄링이 현재 드라이버 레벨에서 수행되고 있는지 또는 네트워킹 스택 레벨에서 수행되고 있는지를 판정하는 단계;
스케줄링이 현재 상기 네트워크 스택 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 네트워크 스택 레벨에서 상기 큐로부터 선택하는 단계; 및
스케줄링이 현재 상기 드라이버 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 드라이버 레벨에서 상기 큐로부터 선택하는 단계를 포함하는, 방법.
제1항에 있어서, 패킷 스케줄링은 소정의 Wi-Fi 네트워크 인터페이스들에 대해서는 상기 드라이버 레벨에서 수행되지만, 모든 다른 매체 액세스 제어(media access control, MAC) 인터페이스들에 대해서는 상기 네트워킹 스택 레벨에서 수행되는, 방법.
제2항에 있어서, 상기 다른 MAC 인터페이스들은 이더넷 인터페이스들 및 무선 셀룰러 인터페이스들을 포함하는, 방법.
제2항에 있어서, 패킷 스케줄링은 802.11n 데이터 트래픽에 대해서는 상기 드라이버 레벨에서 수행되지만, 802.11a, 802.11b, 또는 802.11g 데이터 트래픽에 대해서는 상기 네트워크 계층에서 수행되는, 방법.
제4항에 있어서, 상기 802.11n 드라이버는 무선 멀티미디어 확장(Wireless Multimedia Extensions, WME)을 구현하여 음성, 비디오, 베스트 에포트(best effort), 및 백그라운드의 4개의 우선순위 레벨들에 따라 네트워크 트래픽을 스케줄링하는, 방법.
제1항에 있어서,
특정 서비스 클래스에 따라 상기 패킷을 분류하는 단계; 및
상기 패킷이 분류되는 상기 서비스 클래스에 기초하여 특정 송신 큐 인스턴스에서 상기 패킷을 큐잉하는 단계를 추가로 포함하는, 방법.
제6항에 있어서, 상기 네트워킹 스택은 송신을 위한 패킷을 큐잉하고, 상기 패킷이 송신될 준비가 된 때 상기 드라이버 레벨에 통지하는, 방법.
제7항에 있어서,
상기 네트워킹 스택이 상기 드라이버에 의해 관리되는 통신 링크의 네트워킹 상황을 인지하는 것을 보장하기 위해 상기 드라이버 레벨로부터 상기 네트워킹 스택 레벨로 피드백 신호를 제공하는 단계를 추가로 포함하는, 방법.
제8항에 있어서, 상기 네트워크 레벨은 상기 통신 링크와 관련된 검출된 상기 네트워킹 상황에 기초하여 패킷 스케줄링을 수행하는, 방법.
제1항에 있어서,
상기 네트워킹 스택에 인터페이스를 연결(attaching)하는 단계; 및
인터페이스 유형, 및 패킷 스케줄링이 상기 인터페이스에 대해 상기 네트워크 스택 레벨에서 수행될 것인지 또는 상기 드라이버 레벨에서 수행될 것인지에 대한 표시를 응답식으로 선언하는 단계를 추가로 포함하는, 방법.
제10항에 있어서, 상기 인터페이스는 상기 네트워크 스택 레벨에서의 패킷 스케줄링과 상기 드라이버 레벨에서의 패킷 스케줄링을 스위칭하는, 방법.
제10항에 있어서, 상기 인터페이스 유형 및 스케줄링 모델에 기초하여, 상기 네트워크 스택은 가장 적절한 패킷 스케줄러 및 큐잉 알고리즘을 선택하는, 방법.
제6항에 있어서, 상기 네트워크 스택은 큐 크기, 흐름 제어 워터마크(flow control watermark)들, 및 드롭 임계치(drop threshold)를 포함한 상기 송신 큐와 관련되는 큐 파라미터들을 자동적으로 결정하는, 방법.
제6항에 있어서, 상기 네트워크 스택 레벨은 큐들에 걸친 링크 공유 분포를 포함한 패킷 스케줄링 파라미터들을 자동적으로 구성하는, 방법.
제1항에 있어서, 상기 수신, 판정 및 스케줄링하는 동작들은 최종 사용자에 의한 개입 없이 자동적으로 수행되는, 방법.
클라이언트 디바이스에 의해 실행될 때, 상기 클라이언트 디바이스로 하여금 동작들을 수행하게 하는 프로그램 코드가 저장된 기계 판독가능 매체로서, 상기 동작들은,
송신될 패킷을 수신하는 것;
상기 패킷을 네트워크 스택 레벨에서 큐에 인큐잉하는 것;
패킷 스케줄링이 현재 드라이버 레벨에서 수행되고 있는지 또는 네트워킹 스택 레벨에서 수행되고 있는지를 판정하는 것;
스케줄링이 현재 상기 네트워크 스택 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 네트워크 스택 레벨에서 상기 큐로부터 선택하는 것; 및
스케줄링이 현재 상기 드라이버 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 드라이버 레벨에서 상기 큐로부터 선택하는 것인, 기계 판독가능 매체.
제16항에 있어서, 패킷 스케줄링은 소정의 Wi-Fi 네트워크 인터페이스들에 대해서는 상기 드라이버 레벨에서 수행되지만, 모든 다른 매체 액세스 제어(MAC) 인터페이스들에 대해서는 상기 네트워킹 스택 레벨에서 수행되는, 기계 판독가능 매체.
제17항에 있어서, 상기 다른 MAC 인터페이스들은 이더넷 인터페이스들 및 무선 셀룰러 인터페이스들을 포함하는, 기계 판독가능 매체.
제17항에 있어서, 패킷 스케줄링은 802.11n 데이터 트래픽에 대해서는 상기 드라이버 레벨에서 수행되지만, 802.11a, 802.11b, 또는 802.11g 데이터 트래픽에 대해서는 상기 네트워크 계층에서 수행되는, 기계 판독가능 매체.
제19항에 있어서, 상기 802.11n 드라이버는 무선 멀티미디어 확장(WME)들을 구현하여 음성, 비디오, 베스트 에포트, 및 백그라운드의 4개의 우선순위 레벨들에 따라 네트워크 트래픽을 스케줄링하는, 기계 판독가능 매체.
제15항에 있어서, 상기 클라이언트 디바이스로 하여금,
특정 서비스 클래스에 따라 상기 패킷을 분류하는 것; 및
상기 패킷이 분류되는 상기 서비스 클래스에 기초하여 특정 송신 큐 인스턴스에서 상기 패킷을 큐잉하는 것의 동작들을 수행하게 하는 추가의 프로그램 코드를 포함하는, 기계 판독가능 매체.
제21항에 있어서, 패킷 스케줄링이 현재 상기 네트워킹 스택 레벨에서 수행되고 있는 경우, 상기 네트워킹 스택은 송신을 위한 패킷을 큐잉하고, 상기 패킷이 송신될 준비가 된 때 상기 드라이버 레벨에 통지하는, 기계 판독가능 매체.
제22항에 있어서, 상기 클라이언트 디바이스로 하여금,
상기 네트워킹 스택이 상기 드라이버에 의해 관리되는 통신 링크의 네트워킹 상황을 인지하는 것을 보장하기 위해 상기 드라이버 레벨로부터 상기 네트워킹 스택 레벨로 피드백 신호를 제공하는 것의 동작들을 수행하게 하는 추가의 프로그램 코드를 포함하는, 기계 판독가능 매체.
제23항에 있어서, 상기 네트워크 레벨은 상기 통신 링크와 관련된 검출된 상기 네트워킹 상황에 기초하여 패킷 스케줄링을 수행하는, 기계 판독가능 매체.
제16항에 있어서,
상기 네트워킹 스택에 인터페이스를 연결하는 것; 및
인터페이스 유형, 및 패킷 스케줄링이 상기 인터페이스에 대해 상기 네트워크 스택 레벨에서 수행될 것인지 또는 상기 드라이버 레벨에서 수행될 것인지에 대한 표시를 응답식으로 선언하는 것을 추가로 포함하는, 기계 판독가능 매체.
제25항에 있어서, 상기 인터페이스는 상기 네트워크 스택 레벨에서의 패킷 스케줄링과 상기 드라이버 레벨에서의 패킷 스케줄링을 스위칭하는, 기계 판독가능 매체.
제25항에 있어서, 상기 인터페이스 유형 및 스케줄링 모델에 기초하여, 상기 네트워크 스택은 가장 적절한 패킷 스케줄러 및 큐잉 알고리즘을 선택하는, 기계 판독가능 매체.
제21항에 있어서, 상기 네트워크 스택은 큐 크기, 흐름 제어 워터마크들, 및 드롭 임계치를 포함한 상기 송신 큐와 관련되는 큐 파라미터들을 자동적으로 결정하는, 기계 판독가능 매체.
제21항에 있어서, 상기 네트워크 스택 레벨은 큐들에 걸친 링크 공유 분포를 포함한 패킷 스케줄링 파라미터들을 자동적으로 구성하는, 기계 판독가능 매체.
제16항에 있어서, 상기 수신, 판정 및 스케줄링하는 동작들은 최종 사용자에 의한 개입 없이 자동적으로 수행되는, 기계 판독가능 매체.
프로그램 코드를 저장하기 위한 메모리 및 상기 프로그램 코드를 처리하여 동작들을 수행시키는 프로세서를 갖는 클라이언트 디바이스로서, 상기 동작들은,
송신될 패킷을 수신하는 것;
상기 패킷을 네트워크 스택 레벨에서 큐에 인큐잉하는 것;
패킷 스케줄링이 현재 드라이버 레벨에서 수행되고 있는지 또는 네트워킹 스택 레벨에서 수행되고 있는지를 판정하는 것;
스케줄링이 현재 상기 네트워크 스택 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 네트워크 스택 레벨에서 상기 큐로부터 선택하는 것; 및
스케줄링이 현재 상기 드라이버 레벨에서 수행되고 있다면, 송신을 위한 상기 패킷을 상기 드라이버 레벨에서 상기 큐로부터 선택하는 것인, 클라이언트 디바이스.
제31항에 있어서, 패킷 스케줄링은 소정의 Wi-Fi 네트워크 인터페이스들에 대해서는 상기 드라이버 레벨에서 수행되지만, 모든 다른 매체 액세스 제어(MAC) 인터페이스들에 대해서는 상기 네트워킹 스택 레벨에서 수행되는, 클라이언트 디바이스.
제32항에 있어서, 상기 다른 MAC 인터페이스들은 이더넷 인터페이스들 및 무선 셀룰러 인터페이스들을 포함하는, 클라이언트 디바이스.
제32항에 있어서, 패킷 스케줄링은 802.11n 데이터 트래픽에 대해서는 상기 드라이버 레벨에서 수행되지만, 802.11a, 802.11b, 또는 802.11g 데이터 트래픽에 대해서는 상기 네트워크 계층에서 수행되는, 클라이언트 디바이스.
제34항에 있어서, 상기 802.11n 드라이버는 무선 멀티미디어 확장(WME)들을 구현하여 음성, 비디오, 베스트 에포트, 및 백그라운드의 4개의 우선순위 레벨들에 따라 네트워크 트래픽을 스케줄링하는, 클라이언트 디바이스.
제31항에 있어서, 상기 클라이언트 디바이스로 하여금,
특정 서비스 클래스에 따라 상기 패킷을 분류하는 것; 및
상기 패킷이 분류되는 상기 서비스 클래스에 기초하여 특정 송신 큐 인스턴스에서 상기 패킷을 큐잉하는 것의 동작들을 수행하게 하는 추가의 프로그램 코드를 포함하는, 클라이언트 디바이스.
제36항에 있어서, 상기 네트워킹 스택은 송신을 위한 패킷을 큐잉하고, 상기 패킷이 송신될 준비가 된 때 상기 드라이버 레벨에 통지하는, 클라이언트 디바이스.
제37항에 있어서, 상기 클라이언트 디바이스로 하여금,
상기 네트워킹 스택이 상기 드라이버에 의해 관리되는 통신 링크의 네트워킹 상황을 인지하는 것을 보장하기 위해 상기 드라이버 레벨로부터 상기 네트워킹 스택 레벨로 피드백 신호를 제공하는 것의 동작들을 수행하게 하는 추가의 프로그램 코드를 포함하는, 클라이언트 디바이스.
제38항에 있어서, 상기 네트워크 레벨은 상기 통신 링크와 관련된 검출된 상기 네트워킹 상황에 기초하여 패킷 스케줄링을 수행하는, 클라이언트 디바이스.
제28항에 있어서,
상기 네트워킹 스택에 인터페이스를 연결하는 것; 및
인터페이스 유형, 및 패킷 스케줄링이 상기 인터페이스에 대해 상기 네트워크 스택 레벨에서 수행될 것인지 또는 상기 드라이버 레벨에서 수행될 것인지에 대한 표시를 응답식으로 선언하는 것을 추가로 포함하는, 클라이언트 디바이스.
제37항에 있어서, 상기 인터페이스는 상기 네트워크 스택 레벨에서의 패킷 스케줄링과 상기 드라이버 레벨에서의 패킷 스케줄링을 스위칭하는, 클라이언트 디바이스.
제37항에 있어서, 상기 인터페이스 유형 및 스케줄링 모델에 기초하여, 상기 네트워크 스택은 가장 적절한 패킷 스케줄러 및 큐잉 알고리즘을 선택하는, 클라이언트 디바이스.
제33항에 있어서, 상기 네트워크 스택은 큐 크기, 흐름 제어 워터마크들, 및 드롭 임계치를 포함한 상기 송신 큐와 관련되는 큐 파라미터들을 자동적으로 결정하는, 클라이언트 디바이스.
제33항에 있어서, 상기 네트워크 스택 레벨은 큐들에 걸친 링크 공유 분포를 포함한 패킷 스케줄링 파라미터들을 자동적으로 구성하는, 클라이언트 디바이스.
제40항에 있어서, 상기 수신, 판정 및 스케줄링하는 동작들은 최종 사용자에 의한 개입 없이 자동적으로 수행되는, 클라이언트 디바이스.