KR102358821B1

KR102358821B1 - 애플리케이션들에 대한 네트워크 분류

Info

Publication number: KR102358821B1
Application number: KR1020177010787A
Authority: KR
Inventors: 아메드 탈라트; 빕호 바트; 제프 신네마키; 알렉세이 알렉센코; 일리아 색슨; 제프리 씨. 풀러; 밀레나 살만; 마두수단 라비; 모하메드 카람; 닐 자인
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2014-09-25
Filing date: 2015-09-24
Publication date: 2022-02-07
Also published as: KR20170059465A; CN106716368B; WO2016049322A1; US9674099B2; EP3198434A1; US20160094464A1; CN106716368A

Abstract

운영 체제는 네트워크 스트림들의 클래스들을 구현한다. 애플리케이션들은 자신의 네트워크 스트림들을 클래스들에 할당한다. 운영 체제는 이어서 스트림들이 어떤 클래스들 내에 있는지에 따라 스트림들을 조정한다. 상태들이 변경되면, 네트워크 리소스들은, 스트림들이 어떤 클래스들에 할당되었는지에 따라 스트림들을 조정함으로써 이용가능해지거나 또는 보다 완전히 이용될 수 있다. 네트워크 리소스들은, 보다 낮은 우선순위 클래스들 내의 스트림들을 제한함으로써 보다 높은 우선순위 클래스들 내의 스트림들에 대해 아마도 빠르게 또는 선점적으로 이용가능해질 수 있다.

Description

애플리케이션들에 대한 네트워크 분류{NETWORK CLASSIFICATION FOR APPLICATIONS}

본 발명은 애플리케이션들에 대한 네트워크 분류에 관한 것이다.

컴퓨팅 디바이스 상의 다수의 애플리케이션들이 컴퓨팅 디바이스 상의 또는 컴퓨팅 디바이스 외부의 동일한 제한된 네트워크 리소스들을 공유할 때, 이 애플리케이션들의 네트워킹 수요(needs)를 균형 맞추는 것을 시도하기 위해 다양한 기술들이 사용되어 왔다. 컴퓨터 사용자들 및 애플리케이션들은 보통 네트워크 리소스들을 소비하는 애플리케이션들 사이에서의 어떤 균형(trade-off) 및 우선순위화(prioritization)를 선호한다. 그러나, 실제로, 네트워크 액세스를 공유하기 위한 종래 기술들은 종종 이 선호사항들 및 우선순위화를 최적으로 실현하지 못해 왔다. 예를 들어, 디바이스의 사용자는, 자신의 디바이스 상의 VoIP(Voice over IP) 콜들이 낮은 네트워크 레이턴시(latency)를 갖고, 디바이스 상의 웹 브라우징이 빠르고 응답성이 좋은 것을 선호할 수 있다. 사용자는 또한, 클라우드 동기화 및 운영 체제 업데이트와 같은 대량(bulk) 백그라운드 네트워크 전송들이, 만족스러운 포어그라운드 성능을 가능하게 하고 적정한 수준을 유지하는 방식으로, 디바이스의 네트워크 리소스들의 소비를 양보하는 것을 선호할 수 있다.

네트워크 액세스를 만족스럽게 공유하는 것을 종종 실패하는 것에 추가하여, 종래 액세스 공유 기술들은 종종 소프트웨어 개발자들이 액세스하거나 또는 구현하기에 편리하지 않았다. 예를 들어, QoS(Quality of Service) 설비(facilities)가 도움이 될 수 있지만, 종종 이용가능하지 않거나 또는 균일한 방식으로 구현되지 않는다. 대부분의 QoS 기술은 애플리케이션 레벨 아래에서 발생하므로 애플리케이션들에 의해 쉽게 조작가능하지 않을 수 있다. 대부분의 QoS 접근법들, 예를 들어 차별화 서비스(Differentiated Service)들은 2개의 엔드포인트(endpoint)들 사이의 네트워크의 행동방식(behavior) 및 지원에 의존한다. 그러한 지원은 모든 네트워크 경로들 상에 존재하지 않을 수 있다. 편리성과 관련하여, 네트워크 공유 행동방식은 또한 애플리케이션들 내에서 구현되어 왔지만, 이는 보통 애플리케이션들 사이의 직접적인 공동작용(coordination)이 없거나 거의 없는 복잡한(complex) 네트워크 프로그래밍을 필요로 해왔다. 상이한 애플리케이션들에 대한 그들 자신의 네트워크 공유 로직을 구현하는 것이 중복적일 뿐만 아니라, 애플리케이션들의 상이한 리소스 공유 행동방식들이 충돌(conflict)할 수 있다.

애플리케이션들이 특정한 유형들의 네트워크 소비 행동방식을 구현하도록 운영 체제들에 의해 구현되는 LEDBAT(Low Extra Delay Background Transport)와 같은 프로토콜들이 있지만, 그러한 프로토콜을 활용(leverage)하기 위한 코딩은 애플리케이션을 개발하는 비용 및 간접비(overhead)를 증가시킬 수 있고 개발자가 그러한 프로토콜을 사용할 가능성을 낮출 수 있다. 또한, LEDBAT와 같이 널리 배포된 우선순위가 낮은(low-priority) TCP(Transport Control Protocol) 메커니즘들은 결점(shortcoming)들을 갖고 종종 이상적인 사용자 경험을 제공하지 못한다[다른 예시들에 대한 IETF RFC(Internet Engineering Task Force Request For Comments) 6297을 보라]. LEDBAT 프로토콜은, 예를 들어 TCP 송신 창(send window)들만을 제한하며 수신 스트림(stream)에 영향을 주지 않지만, 대부분의 클라이언트측(client-side) 인터넷 트래픽은 인바운딩된다. LEDBAT와 같은 메커니즘이 복잡한 개발자 코딩을 필요로 하지 않고 이용가능할 때에도, 애플리케이션이 그러한 메커니즘을 사용해야 한다고 운영 체제 또는 네트워크 스택(stack)이 결정하는 것은 불가능할 수 있다. 환언하면, 네트워크 리소스 충돌들에 관한 사용자 및 애플리케이션 의중(intent)은 추론하기에 어렵고 애플리케이션들은 자신의 네트워크 우선순위를 거의 특정하지 않는다. 디바이스의 네트워크 리소스들의 공유가, “후발자(latecomer)” 현상(예를 들어, RFC 6817, 섹션 4.4를 보라)과 같은 문제들에 영향을 받지 않고 경쟁 애플리케이션들간에 일관적인 방식으로 구현되지 않아 왔다.

디바이스의 네트워크 리소스들의 편리하고 효율적인 공유에 관련된 기술들이 아래에서 논의된다.

이어지는 요약은, 아래의 상세한 설명에서 논의되는 몇몇 개념들을 소개하기 위해서만 포함된다. 이 요약은 포괄적이지 않으며, 말미에 제공되는 청구항들에 의해 제시되는 청구되는 발명 대상(subject matter)의 범위를 기술하도록 의도되지도 않는다.

수반되는 피처들 중 다수는 첨부된 도면들과 관련하여 고려되는 이어지는 상세한 설명을 참조하여 아래에서 설명될 것이다.

본 설명은, 첨부된 설명에서 동일한 참조 번호들이 동일한 부분들을 지정하는데 사용되는 첨부된 도면들을 고려하여 읽게 될 이어지는 상세한 설명으로부터 보다 잘 이해될 것이다.
도 1은 네트워크 스택을 구현하는 운영 체제를 갖는 컴퓨팅 디바이스를 도시한다.
도 2는 애플리케이션 프로그래밍 인터페이스(application programming interface; API)를 사용하는 애플리케이션의 프로세스를 도시한다.
도 3은 스트림 분류 모델의 예시를 도시한다.
도 4는 네트워크 성능 카테고리들에 관한 예시적인 스트림들을 도시한다.
도 5는 분류 모델의 다른 예시를 도시한다.
도 6은 스트림 관리자(manager)의 상세도를 도시한다.
도 7은 스트림 관리자가 그에 의해 스트림들을 조정할 수 있는 예시적인 프로세스를 도시한다.
도 8은 스트림 분류 모델의 다른 예시를 도시한다.
도 9는 총괄적(collective) 스트림 관리의 실시예에 대한 프로세스를 도시한다.
도 10은 컴퓨팅 디바이스의 추가적인 상세사항을 도시한다.

아래에서 논의되는 실시예들은, 애플리케이션들이 자신의 네트워크 스트림들을 네트워크 스택 또는 운영 체제에 분류하도록 하는 것에 관한 것이며, 네트워크 스택 또는 운영 체제는 이어서 네트워크 스트림들의 분류들에 따라 시스템 광역(system-wide) 방식으로 디바이스의 네트워크 리소스들의 공유를 조정한다. 시스템이 자신의 네트워크 행동방식을 조정할 방식을 애플리케이션들이 선택하는 방식의 시스템 개요 및 설명과 함께 논의가 시작될 것이다. 네트워크 스트림 분류 모델들 및 이들을 구현하기 위한 상세사항들의 예시들이 다음으로 설명될 것이다.

도 1은 네트워크 스택(104)을 구현하는 운영 체제(102)를 갖는 컴퓨팅 디바이스(100)를 도시한다. 네트워크 스택(104)은, 본 설명으로부터 명백한 추가사항들 또는 변경사항들을 갖는 임의의 공지된 운영 체제 네트워킹 스택으로부터 도출될 수 있다. 예를 들어, TCP/IP 네트워크 스택은 래퍼(wrapper)로 수정되거나 또는 증강될 수 있다. 일반적으로, 임의의 네트워크 프로토콜 스택의 전송 레벨에서의 구현이 편리할 것이다. 컴퓨팅 디바이스(100) 상에서, 다양한 임의의 애플리케이션들(106) 중 임의의 애플리케이션(106)이 실행되고 데이터 네트워크(108)를 통해 통신할 수 있다. 애플리케이션들(106)의 몇몇 예시들은 웹 브라우저들, 백그라운드 다운로더들, 온라인 게임들, 실시간 음성 또는 비디오 통신 프로그램들, 데이터베이스 클라언트들, 미디어 스트리밍 애플리케이션들 등이다. 원격 디바이스들(109)과 데이터를 교환하기 위해, 애플리케이션들(106)은, IP(Internet Protocol) 전달 네트워크(network carrying IP) 트래픽 또는 이들의 변형들일 수 있는 데이터 네트워크(108)를 통해 통신한다. 가상 계층(virtualization layer)(예를 들어, 하이퍼바이저)이 존재하고 애플리케이션들이 상이한 가상 머신들 상의 게스트(guest) 운영 체제들 상에서 실행되는 경우, 네트워크 통신은 컴퓨팅 디바이스(100)에 대해 전체적으로 또는 부분적으로 로컬일 수 있다.

운영 체제(102)는 다른 공지된 기능들 중에서, 각각의 네트워크 인터페이스들(112)에 패킷들을 전달하고 각각의 네트워크 인터페이스들(112)로부터 패킷들을 수신하는 하나 이상의 인터페이스 드라이버(110)(디바이스 드라이버들)를 포함할 수 있다. 애플리케이션들(106)이 사용자 공간에서 실행되고 본원에서 설명되는 운영 체제(102) 및 네트워킹 피처들이 커널 공간에서 실행된다고 가정할 수 있다. 그러나, 이는 필수적인 것은 아니다. 커널 모드 코드 또는 사용자 모드 코드는, 이들에 의해 제어되는 네트워크 스트림들에 네트워크 분류들을 할당할 수 있고, 스트림 관리자(114)는 커널 공간 또는 사용자 공간에서 실행될 수 있다. 일 실시예에서, 네트워크 스트림 관리는, 공지된 TCP/IP 네트워크 스택과 패킷들을 교환하는 사용자 모드 래퍼로 구현될 수 있다.

스트림 관리자(114)는 애플리케이션들(106)에 대한 네트워크 스트림들(116)을 관리하고 조정한다. 네트워크 스트림들(116)(이후부터 “스트림들”로 칭해짐)은, 컴퓨팅 디바이스(100)와 원격 디바이스들(109) 사이의 각각의 네트워크 연결들[예를 들어, IP 5 튜플(IP 5-tuple)들]에 대응하는 운영 체제 객체(object)들이다. 일반적으로, 각 스트림은, 스트림 상에서 동작들을 수행할 때 스트림을 식별하기 위해 운영 체제 및 스트림들의 애플리케이션에 의해 사용되는 FIFO 버퍼 및 또는 서술자(descriptor) 또는 핸들을 갖는다. 네트워크 스택(104)은 스트림들(116)을 대신하여 전송 프로토콜을 구현하는 전송 계측 모듈(예를 들어, TCP 모듈)을 제공할 수 있다. 운영 체제(102)는, 스트림 객체를 인스턴스화(instantiating)하고, 스트림 파라미터들을 설정하며, 스트림과의 네트워크 연결을 개시하고, 스트림을 클로징(closing)하며, 연결될 네트워크 주소, 사용될 원격 및 로컬 포트, 사용될 프로토콜, 네트워킹 파라미터들 등과 같은 스트림의 속성(property)값들을 얻고 설정하는 것과 같은 스트림 관련 동작들을 수행하기 위해 애플리케이션들(106)이 사용하는 애플리케이션 프로그래밍 인터페이스(API, 118)를 제공한다. API(118)로서의 사용을 위해, 본원에서 설명되는 바와 같이 확장되거나 수정될 때, 윈속(Winsock) API, 버클리 소켓(Berkeley sockets) API, 및 다른 유사한 API들이 모두 적절하다.

도 2는 특정 스트림과 연관될 스트림 클래스 또는 카테고리를 네트워크 스택(104)에게 통지하기 위해 API(118)를 사용하는 애플리케이션의 프로세스를 도시한다. 단계(140)에서, 애플리케이션은 스트림을 형성하거나 또는 획득한다. 스트림은 네트워크 연결을 갖거나 또는 갖지 않을 수 있다. 스트림은, 애플리케이션의 실행 코드에서 서술자, 핸들, 객체 등으로서 참조될 수 있다. 애플리케이션은 다른 애플리케이션 또는 프로세스로부터 스트림을 획득할 수 있거나 또는 스트림을 새로운 객체로서 개시할 수 있다. 후자의 경우, 스트림의 다양한 파라미터들 또는 속성들은, 네트워크 연결을 형성하기 위해 스트림의 사용 전에 애플리케이션에 의해 설정될 수 있다. 위에서 언급된 바와 같이, 그러한 파라미터들은, 예를 들어 원격 네트워크 주소, [다수의 네트워크 인터페이스들(112)이 컴퓨팅 디바이스(100) 상에서 이용가능할 때] 로컬 네트워크 주소, 로컬 및 원격 포트들, 프로토콜 설정들 등일 수 있다.

단계(142)에서 애플리케이션은 스트림 클래스 또는 카테고리(이후부터 “클래스”)를 스트림에 특정하게 할당하기 위해 API(118)를 사용한다. 애플리케이션은 다른 클래스들을 다른 애플리케이션들의 스트림들에 할당할 수 있다. 단계(142)는, 스트림이 인스턴스화될 때, 스트림에 대한 네트워크 연결이 형성되기 전에, 스트림이 연결되고 아마도 트래픽을 전달한 후에, 스트림이 트래픽을 전달했을 때 등을 포함하여, 스트림의 수명(life) 동안 언제든 수행될 수 있다. 또한, 단계(142)는, 스트림에 현재 할당된 클래스를 변경하기 위해 동일한 스트림 상에서 반복적으로 수행될 수 있으므로, 다음에 논의되는 바와 같이, 스트림 관리자(114)가 스트림을 통한 패킷들의 흐름을 조정하는 방식을 대응하여 변경한다.

단계(144)에서, 운영 체제, 특히 스트림 관리자(114)는 네트워크 스트림에 의한 네트워크 리소스 사용량(usage)을 제어한다. 스트림 관리자(114)는, 운영 체제에 의해 관리되고 있는 다수의 (아마도 모든) 스트림들의 네트워크 행동방식을 조정하는 중앙 조정자(coordinator)로서 기능한다. 스트림 관리자(114)는, 특히 레이턴시 및 대역폭[스루풋(throughput)] 성능 및 가능하다면 상이한 크기의 시간 창(time window)들에 걸친 평균 스루풋에 관하여, 스트림들의 실제 네트워크 성능을 추적하고 그들의 행동방식을 조정할 수 있다. 스트림 관리자(114)는 또한, 예를 들어 프로브(probe) 패킷들의 리턴 트립 시간(return trip time; RTT)들을 분석하는 것에 의해, 스트림들의 네트워크 경로들을 따라 다양한 디바이스들의 큐(queue) 크기들에 관한 정보를 수신하는 것 등에 의해, 네트워크 상태들에 관한 신호들을 수신할 수 있다. 특히, 스트림 관리자(114)는 각 스트림에 대한 최근의 및/또는 현재의 대역폭, 레이턴시, 또는 이들 둘 다를 결정할 수 있어야 한다. 일 실시예에서, 모든 스트림들이 명확한(explicit) 애플리케이션 할당 클래스를 갖는 것은 아니다. 그러나, 스트림 관리자(114)는 또한 이들 스트림들을 가능하다면, 디폴트 클래스를 갖는 것으로서 처리함으로써 관리할 수 있다. 일 실시예에서, 스트림 관리자(114)는 별개의(distinct) 모듈 또는 컴포넌트는 아니지만, 오히려 운영 체제(102) 및/또는 네트워크 스택(104)에 걸쳐 분산되는 로직이다(본원에서 사용되는 바와 같은 용어 “스트림 관리자”는 두 설계 모두를 지칭함). 환언하면, 스트림 관리 로직의 배치(placement)는 중요하지 않다.

도 3은 스트림 분류 모델(180A)의 예시를 도시한다. 도 3은 또한 클래스를 스트림에 할당하는 코드(182)의 샘플을 도시한다. 분류 모델(180A)은 8개의 클래스들을 갖고, 4개는 대역폭에 대한 것이며 4개는 레이턴시에 대한 것이다. 이 예시적인 분류 모델(180A)에서, 2개의 클래스들은 동일한 스트림에 할당될 수 있다(대역폭에 대한 하나의 클래스 및 레이턴시에 대한 하나의 클래스). 샘플 코드(182)에 보여지는 바와 같이, “높은” 대역폭 및 “낮은” 레이턴시 클래스들이 “socket s”로 나타내어지는 스트림에 할당된다. 다른 실시예들에서, 분류 모델(180A)은, 도 5에 도시된 바와 같이 대역폭 클래스들만을, 또는 레이턴시 클래스들만을, 또는 성능 측정기준(dimension)들 둘 다를 갖는 개별 클래스들을 가질 수 있다. 도 4는 네트워크 성능 카테고리들에 관한 예시적인 스트림들(190)을 도시한다. 스트림들(190)은 API(116)를 통해 할당된 식별자들 및 클래스들(192)을 가질 수 있다. 일 실시예에서, 각각의 스트림들의 분류들은, 운영 체제(102)가 스트림들을 나타내는데 사용하는 각각의 데이터 구조들 또는 객체들의 플래그(flag)들 또는 속성들이다.

도 5는 분류 모델(108B)의 다른 예시를 도시한다. 분류 모델(180B)은 6개의 클래스들(A 내지 F): 실시간 클래스, 응답(상호작용) 클래스, 스트리밍 클래스, 노멀 클래스, 이벤트 클래스, 및 인비저블(invisible) 클래스를 갖는다. 이 분류 모델(180B)은, 개별 클래스들이 공통(common) 타입들의 네트워크 소비 애플리케이션들에 밀접하게 대응하므로, 개발자들에게 편리할 수 있다. 각 클래스는, 스트림 관리자(114)의 로직에 구현된 바와 같이, 네트워크 성능의 하나 이상의 측정기준에서의 각각의 성능 범위들, 하한(floor)들, 상한(ceiling)들 등을 가질 수 있다. 예를 들어, 클래스들은 다음과 같이 구현될 수 있다[초당 메가비트(megabits per second; MBS) 단위의 대역폭, 밀리초(milliseconds; ms) 단위의 레이턴시]:

실시간: 1 MBS, 200 ms,

응답: 0.1 MBS, 50 ms,

스트리밍: 3 MBS, 1500 ms,

노멀: 0.2 MBS, 5000ms, 및

이벤트, 인비저블: 0 MBS, 0 ms.

이 숫자들은 예시적일 뿐이며; 임의의 값들이 사용될 수 있고, 몇몇 클래스들은 대역폭 및/또는 레이턴시 사양(specification)을 갖지 않을 수 있다.

스트림 관리자(114)는, 요청(demand)이 스트림들 사이에 충돌을 생성할 때 스트림들의 성능 타겟들이 그들의 클래스별로 달성되는 방식에 대해 정책들 또는 룰들(202)을 구현하기 위한 제어 로직(200)(도 6)을 가질 수 있다. 예를 들어, 룰들(202)은 대역폭에 대한 서열(precedence)을 특정할 수 있어서, 스트리밍 클래스 스트림들이 자신의 제한들에 있거나 자신의 제한들 근방에 있을 때 대역폭은 자신의 클래스들에 따라 다른 스트림들을 스로틀링(throttling)함으로써 이용가능해진다. 예를 들어, 카테고리 A 스트림이 네트워킹 리소스들을 필요로 할 때, 제일 먼저 인비저블 스트림들, 이어서 이벤트, 이어서 노멀, 이어서 응답이 스로틀링될 수 있다. 클래스들은 또한 스로틀링될 대역폭(또는 레이턴시)의 관련 부분들을 특정하기 위한 각각의 가중치(weight)들을 가질 수 있으므로, 보다 높은 우선순위 클래스 내의 스트림이, 낮은 우선순위 스트림들로부터 해방된 큰 부분의 대역폭 및 중간 우선순위 스트림들로부터 해방된 작은 부분의 대역폭을 획득하도록 한다. 다른 실시예에서, 네트워크 리소스들의 사용은 스트림들의 클래스들에 따라 우선순위화되거나 또는 배분된다. 응답 스트림이 추가적인 대역폭을 필요로 하면, 그 대역폭은 (예를 들어, 스로틀링에 의해) 드로윙될 수 있고 이로부터 어떤 스트림들도 대역폭을, 아마도 가장 낮은 우선순위 클래스 스트림들로부터 시작하여 그들의 성능 사양들 내에 유지하면서 할애(spare)할 수 있다. 요약하면, 스트림들에 의한 그들의 클래스들에 따른 네트워크 리소스 소비의 총괄적 관리는, 광범위한 알고리즘들, 룰들/속성들, 성능 값들 등에 의해 구현될 수 있다.

애플리케이션 특정 클래스들에 따른 스트림들의 중앙집중형(centralized) 전역적(global) 관리의 잠재적 이점은, 사용자의 경험이 향상될 수 있다는 점이다. 예를 들어, 사용자의 디바이스가 “스트리밍”으로서 분류된 네트워크 스트림으로 멀티미디어 스트리밍 애플리케이션을 실행하고 있다고 가정한다. 또한, 사용자가 HTTP 브라우징 스트림들을 “응답”으로서 분류하고 다운로드 스트림들을 “노멀”로서 분류한 웹 브라우저 애플리케이션을 시작한다고 가정한다. 사용자가 웹 페이지를 요청할 때, 대응하는 응답 클래스 스트림이 스트리밍 클래스 스트림보다 더 높은 레이턴시 우선순위를 갖기 때문에, 스트리밍 클래스 스트림이 일시적으로 (예를 들어, 50 ms 동안) 스로틀링되어 응답 클래스 스트림이 레이턴시 요건을 충족시키게 할 수 있다. (버퍼링으로 인한) 스트리밍 클래스 스트림의 잠시 동안의 둔화(brief slowdown)는 사용자가 알아차리지 못할 가능성이 높고, 웹 페이지는 빠르게 다운로드될 것이다. 사용자가 파일 다운로드를 개시하면, 대역폭은 자신의 대역폭 하한이 도달될 때까지 스트리밍 클래스 스트림으로부터 “차용(borrow)”될 수 있으므로, 노멀 클래스 다운로드 스트림이 스트리밍 클래스 스트림으로부터의 미디어 재생을 방해하지 않고 자신의 대역폭을 최대화하는 방식으로 진행되도록 한다.

도 6은 스트림 관리자(114)의 상세도를 도시한다. 스트림들(190)은 각각, 패킷들이 대응하는 네트워크 인터페이스에 의한 전송을 위해 디바이스 드라이버를 통과하기 전에, 또는 디바이스 드라이버로부터 수신된 후 큐잉되는 각각의 큐(240)를 갖는다. 제어 로직(200)은 위에서 설명된 바와 같이 스트림들(190)의 네트워크 성능을 관리한다. 제어 로직(200)은 대역폭 및 레이턴시에 관한 업데이트들을 반복적으로 수신할 수 있다. 업데이트들은 인터페이스 드라이버들(110), 네트워크 스택(104), 또는 외부 소스들로부터 올 수 있다. 그러한 업데이트들은, 컴퓨팅 디바이스(100)에 대한 또는 개별 네트워크 인터페이스들(112)에 대한 현재 대역폭 가용성(availability), 현재 또는 예상되는 레이턴시 정보, 네트워크 혼잡도(congestion) 등과 같은 다양한 네트워크 상태들 및 통계(statistic)들을 나타낼 수 있다. 제어 로직(200)은 네트워크 리소스들이 스트림들에 의해 소비되는 방식을 조정하기 위해 이 정보를 사용할 수 있다.

도 7은 제어 로직(200)이 그에 의해 스트림들을 조정할 수 있는 예시적인 프로세스를 도시한다. 규칙적인 간격(regular interval)으로, 스트림 관리자(114)는 단계(260)에서 활성 스트림들에 대한 반복을 시작할 수 있다(이 단락에서의 “스트림”은 현재 반복되는 스트림을 지칭함). 단계(262)에서 스트림의 현재 성능 통계들이 획득된다. 예를 들어, 현재 또는 추정되는 대역폭 및 레이턴시가 획득된다. 이 정보는, 큐잉되는 패킷들의 양, 들어오는(incoming) 패킷들의 속도(rate), 다른 공지된 기술들에 기반하여, 현재 트래픽 통계들에 따라 투영(project)된 최근 스루풋으로부터 추정될 수 있다. 스트림의 클래스는 반복적으로 평가(evaluate)되는 빈도에 영향을 줄 수 있다.

단계(264)에서, 스트림 관리자(114)는 스트림의 클래스 또는 카테고리를 결정하고, 특정된 카테고리에 따라 스트림이 수행되고 있는지(또는 예정되어 있는지)를 결정한다. 단계(266)에서, 스트림이 특정된대로 수행되고 있지 않으면, 이어서 스트림 관리자(114)는 스트림의 클래스 사양들을 충족시키도록 의도된 적응(adaptation)을 구현한다. 예를 들어, 클래스들을 고려하여, 다른 스트림들은 스로틀링, 일시정지 등 될 수 있다. 이는, 스트림들의 수신 창들 및/또는 송신 창들을 조절하고, 스트림 버퍼들을 확장시키거나 또는 축소시키거나, 스트림을 통하는 패킷 흐름을 일시정지함으로써 달성될 수 있다. 애플리케이션 또는 다른 컴포넌트들이 패킷들을 태깅(tagging)할 필요는 없고, 애플리케이션들이 프로토콜 레벨 QoS 피처들을 사용할 필요도 없다. 애플리케이션의 관점으로부터, 스트림들은 일반(ordinary) TCP(또는 이와 유사한) 스트림들이다. 단계(268)에서, 만약 있다면, 다음 스트림이 프로세싱된다.

각각의 클래스들의 사양들에 따라 수행하지 않는 스트림의 본원의 언급들과 관련하여, 성능 준수(compliance)의 결정들 또는 성능 조절들을 야기하는 결정들은, 호스트 머신 상의 다른 연결들에 대한 단순한 성능 이상을 포괄하는 것으로서 이해되어야 한다. 예를 들어, LEDBAT 프로토콜과 같은 프로토콜들은, 스트림들의 네트워크 연결이, 연결이 경험한 최저 일방향(one-way) 딜레이보다 100 ms 더 높은 일방향 딜레이들을 경험하고 있으면, 스트림을 특정된대로 수행하지 않고 있다고 간주한다. LEDBAT 연결이 증가된 딜레이를 유발하는 요인(factor)일 수 있으며, 그 연결들의 창들을 제한하는 것이 동일한 공유 네트워크 리소스들을 경유하는 다른 연결들에 대한 딜레이를 감소시킬 수 있다는 것이 가정이다. 환언하면, 스트림 클래스들의 사양들은, 서로에 대해 상대적이거나 성능 값들에 대해 절대적이거나 또는 이 둘의 조합일 수 있다. 또한, 형식 언어(formal language) 또는 구문(syntax)은, 복합 사양들, 예를 들어 불 연산자(Boolean operator)들, 조건문(conditional statement)들 등의 구문을, 아마도 마크업 기반[예를 들어, 확장가능(extensible) 마크업 파일들] 선언(declarative) 언어의 형식으로 표현하기 위해 제공될 수 있다. 또는, 그러한 복합 로직은 스트림 관리자, 네트워크 스택 등의 프로그래밍으로 “하드코딩(hardcoding)”될 수 있다.

도 8은 스트림 분류 모델(180C)의 다른 예시를 도시한다. 각 카테고리는 레이턴시 컴포넌트 및 대역폭 컴포넌트를 갖는다. 카테고리들은 두 측정기준을 따라 오버랩될 수 있다. 이 예시에서, 스트림의 분류는 대역폭 및 레이턴시 성능 타겟 둘 다를 스트림에 할당한다. 하나의 클래스, 예를 들어 클래스 E가 대응하는 스트림들 상에, 실시간 또는 빠른 응답에 대응하는 레이턴시 사양을 부과하도록 의도된다고 가정하면(즉, 네트워크 트래픽이 사용자 요청에 응답하여 최소한의 명백한 딜레이로 흐르는 것을 시작함), 스트림 관리자 로직은 클래스 D 스트림들(또는 모든 다른 스트림들, 또는 모든 다른 활성 스트림들 등)과 같은 다른 스트림들을 “백오프(backoff)” 또는 하향 조정(down-regulate)하기 위해 로컬 운영 체제의 다양한 네트워크에 영향을 주는 메커니즘들을 사용할 수 있다. 즉, 레이턴시에 민감한 것으로서 분류된 새로운 연결 또는 새로운 트래픽이 시작될 때, 낮은 우선순위 연결들은 로컬로 즉시 약화될 수 있다. 예를 들어, 사용자에 의해 개시된 웹 브라우저가 웹 객체들을 요청하려고 하면, 백그라운드 파일이 우선적으로(pre-emptively) 약화될 수 있어서 다가올(upcoming) 브라우저 트래픽이 깨끗한(clean) 네트워크로 시작한다. 이전의 접근법들은 보통 새로운 트래픽에 즉각적으로 도움이 되지 않는 경쟁 트래픽에 기반하여 행해지는 QoS 결정들에 종종 의존한다. 대역폭 성능에 대해 또는 네트워크 성능 특성(characteristic)들의 조합들에 대해 유사한 접근법이 사용될 수 있다. 로컬 트래픽 약화는, 애플리케이션들로부터 네트워크 연결들로의 데이터의 흐름을 일시정지하거나, 버퍼링된 패킷들의 전송을 일시정지하거나, 네트워킹 창 크기들을 조절하거나, 스트림 트래픽을 처리하는 스레드들을 중단하거나 다운그레이딩함으로써, 또는 네트워크 리소스들의 스트림들의 소비에 잠재적으로 영향을 줄 수 있는 스트림의 다른 동작 파라미터들을 조절함으로써 달성될 수 있다는 점을 유념한다.

도 9는 총괄적 스트림 관리의 실시예에 대한 프로세스를 도시한다. 이 실시예에서, 스트림 관리자(114)는 다음과 같이 네트워크 리소스들의 재할당을 실시할 수 있다. 단계(280)에서, 타겟 스트림이 추가적인 네트워크 리소스, 예를 들어 클래스에 따라 대역폭 또는 레이턴시 또는 둘 다를 필요로 한다고 결정된다. 설명을 위한 예시에 대해, 분류 모델(180C)의 클래스 A 스트림이 추가적인 대역폭을 필요로 한다고 가정될 것이다. 단계(282)에서, 종합적인(aggregate) 통계들이 스트림들의 각 클래스에 대해 획득된다. 단계(284)에서, 이 종합적인 통계들은 클래스에 적절한 순서(class-appropriate order)로 평가되고, 단계(286)에서 이 종합적인 통계들은 필요에 따라 조절된다. 네트워크 요구에 따른 가장 낮은 우선순위 클래스, 즉 클래스 E의 스트림들이 가장 먼저 평가된다. 클래스 E 스트림들의 종합적인 대역폭이 전체적으로 여분의 대역폭을 가지면, 클래스 E 스트림들이 스로틀링되어 추가 대역폭을 제공한다. 클래스 E 스트림들이 양보하기에 불충분한 대역폭을 가지면 다음 우선순위 클래스 - 클래스 C - 의 종합적인 통계가 평가된다. 즉, 클래스 E 스트림들을 스로틀링하는 것이 충분한 대역폭을 해방시키지 않으면, 클래스 C 스트림들의 종합적인 대역폭이 평가되고 그 클래스 내의 스트림들이 필요에 따라 스로틀링된다. 클래스 C 스트림 및 클래스 E 스트림 둘 다가 그들의 클래스 요건들을 충족시키면서 충분한 대역폭을 넘겨 줄 수 없으면, 보다 낮은 우선순위 클래스 - 클래스 E - 의 스트림들은 보다 높은 우선순위 클래스 A 스트림들의 대역폭 요건을 충족시키는 것을 돕도록 자신의 클래스들의 대역폭 타겟들 아래로 푸싱(pushing)될 수 있다.

위의 예시에서의 스트림이, 추가된 대역폭 대신에 또는 추가된 대역폭에 추가하여 향상된 레이턴시를 필요로 하면, 유사하 프로세스가 수행되지만, 각 클래스의 종합적인 통계들의 평가 및 내부 스트림들에 대한 임의의 조절들은 클래스들의 레이턴시 특성들에 따른 순서로 수행된다.

이 설명이 곳곳에서 네트워크 리소스들이 할당되거나 또는 재할당되는 것으로서 지칭할 수 있지만, 리소스들의 “할당”은 스트림 클래스들의 사양들을 충족시키는 것을 시도하도록 (위에서 설명된) 임의의 다양한 네트워크에 영향을 미치는(network-affecting) 메커니즘들을 사용하는 것의 부작용(side effect)의 개념적 특성이다. 또한, 스트림 클래스들에 기반하여 취해진 우선순위화 또는 스트림 조정 방안(measures)은 대응하는 스트림들에 의한 네트워크 리소스들의 소비에 있어서의 즉각적 증가들 또는 감소들을 반드시 포함하는 것을 아니다. 예를 들어, (스트림 클래스들을 제공하기 위해 수정될 수 있는) LEDBAT 프로토콜과 같은 프로토콜들은, LEDBAT가 낮은 우선순위 연결이 “제한”될 필요가 있다고 결정했을 때 낮은 우선순위 연결의 대역폭 또는 레이턴시를 반드시 손상시키는 것은 아니다. 예를 들어, 연결의 송신 창의 크기를 감소시키는 것은 스루풋 또는 레이턴시에 즉각적인 영향을 주지 않을 수 있고; 이어서 많은 가능한 이유들로 인해 연결은 더 나은 스루풋 또는 레이턴시를 얻을 수 있다.

도 10은, 위에서 설명된 실시예들이 구현될 수 있는 일반적인 컴퓨팅 디바이스(100)의 추가적인 상세사항을 도시한다. 컴퓨팅 디바이스(100)는, 프로세싱 하드웨어(304)는, 임의의 하나 이상의 중앙 프로세싱 유닛, 그래픽 프로세싱 유닛, 아날로그 대 디지털 컨버터, 버스 칩, FPGA(Field-programmable Gate Array), ASIC(Application-specific Integrated Circuit), ASSP(Application-specific Standard Product), 또는 CPLD(Complex Programmable Logic Device) 등의 조합일 수 있는 프로세싱 하드웨어(304) 및 스토리지(302)뿐만 아니라 디스플레이(300)를 가질 수 있다. 스토리지(302)는 자기 스토리지, 정적(static) 메모리, 휘발성 메모리 등의 임의의 조합일 수 있다. 용어 “스토리지”의 의미는, 본원에서 사용되는 바와 같이 신호들 또는 에너지 자체를 지칭하는 것은 아니고, 오히려 (자기 스토리지 매체, 광학 스토리지 매체, 정적 메모리 디바이스 등을 포함하지만 신호들 자체를 포함하지 않는) 물리적 장치(apparatus)들을 지칭한다. 컴퓨팅 디바이스(100)의 하드웨어 엘리먼트들은 컴퓨팅 분야에서 잘 이해되는 방식으로 함께 동작할 수 있다. 또한, 입력 디바이스들(306)은 컴퓨팅 디바이스(100)와 통합되거나 또는 컴퓨팅 디바이스(100)와 통신할 수 있다. 컴퓨팅 디바이스(100)는 임의의 폼 팩터(form factor)를 가질 수 있거나 또는 임의의 유형의 포괄적(encompassing) 디바이스에서 사용될 수 있다. 컴퓨팅 디바이스(100)는 스마트폰, 태블릿 컴퓨터, 게이밍 디바이스, 서버, 랙 장착형(rack-mounted) 또는 백플레인 내장 컴퓨터(backplaned computer-on-a-board), 시스템 온 칩(system-on-a-chip) 등과 같은 핸드헬드 디바이스의 형식일 수 있다. 일반적으로, 컴퓨팅 디바이스(100)는 이산(discrete) 네트워크 노드 또는 또는 디바이스일 것이다.

위에서 논의된 실시예들 및 피처들은 휘발성 또는 비휘발성 컴퓨터 또는 디바이스 판독가능(readable) 장치들 내에 저장되는 정보의 형식으로 실현될 수 있고, 그러한 정보는 본원에서 설명된 실시예들을 수행하기 위해 컴퓨팅 디바이스(100)를 구성할 수 있다. 이 장치들은, 디지털 정보를 저장하기 위한 광학 스토리지[예를 들어, CD-ROM(compact-disk read-only memory)], 자기 매체, 홀로그래픽 스토리지, 플래시 ROM(read-only memory), 또는 다른 디바이스들과 같은 장치들을 포함할 수 있다. 저장되는 정보는, 본원에서 설명된 실시예들을 수행하기 위한 컴퓨팅 디바이스들을 인에이블하거나 또는 구성하는데 사용될 수 있는 머신 실행가능 명령어들(예를 들어, 컴파일된 실행가능 바이너리 코드), 소스 코드, 바이트코드, 또는 다른 정보의 형식일 수 있다. 이는 또한, 실시예를 실행하는 소프트웨어의 실행 동안의 CPU(central processing unit) 명령어들과 같은 정보를 저장하는 RAM(random-access memory) 및/또는 가상 메모리와 같은 적어도 휘발성 메모리 뿐만 아니라 프로그램 또는 실행가능한 것이 로딩되고 실행되도록 하는 정보를 저장하는 비휘발성 디바이스들을 포함하는 것으로 간주된다.

Claims

스토리지, 프로세싱 하드웨어, 네트워크 인터페이스, 및 상기 스토리지 내에 저장된 운영 체제를 포함하는 컴퓨팅 디바이스에 의해 수행되는 방법 - 상기 방법은 상기 운영 체제가 상기 프로세싱 하드웨어에 의해 실행될 때 수행됨 - 에 있어서,
상기 프로세싱 하드웨어에 의해, 네트워크 스트림 분류 모델(network stream classification model)을 구현하는 상기 운영 체제의 네트워크 모듈을 실행하는 단계 - 상기 네트워크 스트림 분류 모델은 상기 네트워크 모듈에 의해 구현되고 각자의 상이한 대역폭 및 레이턴시 속성(latency property)들에 대응하는 복수의 미리 규정된 네트워크 스트림 클래스들을 포함하고, 각각의 네트워크 스트림 클래스는 대응하는 네트워크 성능 사양(network performance specification)을 각각 가져서, 일부 네트워크 스트림 클래스들은 상기 네트워크 스트림 클래스들 중 다른 네트워크 스트림 클래스들보다 상기 네트워크 성능 사양에 대해 더 높은 우선순위(priority)를 가짐 - ;
상기 컴퓨팅 디바이스 상에서 실행되는 사용자 모드 코드에 액세스가능한 애플리케이션 프로그래밍 인터페이스(application programming interface; API)를 제공하는 단계 - 상기 컴퓨팅 디바이스 상의 애플리케이션들은 상기 운영 체제에 의해 제공되는 네트워크 스트림들에 네트워크 스트림 클래스들을 할당하기 위해 상기 API를 사용하고, 이에 의해 어떤 네트워크 스트림 클래스들이 어떤 네트워크 스트림들과 연관될지를 결정하고, 상기 네트워크 스트림들은 상기 운영 체제의 네트워크 모듈을 통해 상기 애플리케이션들로/상기 애플리케이션들로부터 데이터를 전달하기 위한 것이고, 애플리케이션이 상기 운영 체제와 통신함으로써 네트워크 스트림의 생성(creation)을 요청하고 상기 API를 사용하여 상기 네트워크 스트림에 네트워크 스트림 클래스를 할당하며, 상기 API를 사용하는 상기 애플리케이션들에 의한 할당에 따라 어떤 특정 네트워크 스트림들이 어떤 특정 네트워크 스트림 클래스들과 연관되는지를 나타내기 위해 연관성들이 유지됨 - ;
상기 네트워크 모듈에 의해, 상기 컴퓨팅 디바이스 상의 상기 네트워크 스트림들의 레이턴시 및 대역폭 성능 중 적어도 하나에 관한 업데이트들을 반복적으로 수신하는 단계; 및
상기 네트워크 모듈에 의해, 상기 네트워크 스트림들의 레이턴시 및 대역폭 성능 중 적어도 하나에 관한 업데이트들에 따라, 상기 네트워크 스트림들과 연관된 상기 각자의 네트워크 스트림 클래스들의 네트워크 성능 사양들에 따라, 그리고 상기 네트워크 성능 사양들에 대한 상기 네트워크 스트림 클래스들의 관련된 우선순위들에 따라 상기 컴퓨팅 디바이스로부터의 상기 네트워크 스트림들의 패킷들의 전송의 타이밍을 조정(regulate)하는 단계 - 네트워크 스트림에 대한 패킷의 전송의 타이밍은, 상기 유지되는 연관성들이 어떤 네트워크 스트림 클래스가 상기 네트워크 스트림과 연관되는지를 나타내는지에 의존함 -
를 포함하는, 컴퓨팅 디바이스에 의해 수행되는 방법.
제 1 항에 있어서, 애플리케이션이 네트워크 스트림의 식별자 및 네트워크 스트림 클래스의 식별자를 상기 API를 통해 상기 운영 체제에 제공하고, 이에 응답하여 상기 운영 체제가 상기 네트워크 스트림과 네트워크 스트림 클래스 사이의 연관성을 저장하며, 상기 네트워크 스트림의 조정은 상기 네트워크 스트림 클래스와 상기 네트워크 스트림 사이의 상기 연관성에 따라 그리고 상기 네트워크 스트림 클래스의 네트워크 성능 사양에 따라 수행되는 것인, 방법.
제 1 항에 있어서, 애플리케이션은 제 1 네트워크 스트림 및 제 2 네트워크 스트림을 갖고, 상기 방법은, 상기 API를 사용하는 상기 애플리케이션에 의해, 제 1 네트워크 스트림 클래스를 상기 제 1 네트워크 스트림에 할당하고 제 2 네트워크 스트림 클래스를 상기 제 2 네트워크 스트림에 할당하는 단계를 더 포함하고, 상기 네트워크 모듈은 상기 제 1 네트워크 스트림 클래스에 따라 상기 제 1 네트워크 스트림의 동작 파라미터를 조절(adjust)하고, 상기 네트워크 모듈은 상기 제 2 네트워크 스트림 클래스에 따라 상기 제 2 네트워크 스트림의 동작 파라미터를 조절하며, 상기 동작 파라미터는 상기 컴퓨팅 디바이스에 의해 패킷들의 송신을 제어하기 위해 상기 컴퓨팅 디바이스에 의해 사용되는 것인, 방법.
제 1 항에 있어서, 연관된 주어진 네트워크 스트림 클래스로의 주어진 네트워크 스트림의 조정은 상기 네트워크 스트림들 중 다른 네트워크 스트림들을 스로틀링(throttling)하는 것을 포함하고, 상기 네트워크 스트림들 중 다른 네트워크 스트림들은 서로에 관련된 상기 네트워크 스트림 클래스들의 우선순위들에 대응하는 우선순위의 순서로 스로틀링되는 것인, 방법.
제 1 항에 있어서, 상기 조정은, 상기 네트워크 스트림 클래스들 중 어떤 네트워크 스트림 클래스들이 상기 네트워크 스트림들에 할당되었는지에 따라 상기 네트워크 스트림들의 대역폭 및 레이턴시 성능 사양들을 충족시키는 것을 시도하는 것인, 방법.
제 1 항에 있어서, 상기 조정은, 주어진 네트워크 스트림에 추가 대역폭을 제공하기 위해 상기 네트워크 스트림들 중 어떤 네트워크 스트림들을 스로틀링할지를 결정하는 것을 포함하고, 상기 결정하는 것은, 상기 결정된 네트워크 스트림들이 어떤 네트워크 스트림 클래스들과 연관되었는지에 따라 수행되는 것인, 방법.
제 6 항에 있어서, 상기 네트워크 스트림들 중 어떤 네트워크 스트림들을 스로틀링할지를 결정하는 것은, 상기 주어진 네트워크 스트림이 어떤 네트워크 스트림 클래스와 연관되었는지에 적어도 부분적으로 의존하는 것인, 방법.
컴퓨팅 디바이스에 있어서,
프로세싱 하드웨어;
네트워크 인터페이스;
상기 컴퓨팅 디바이스가 동작 중일 때, 상기 프로세싱 하드웨어에 의해, 임의의 애플리케이션들의 스트림들을 제공하고 실행을 관리하도록 구성된 운영 체제를 실행하도록 상기 프로세싱 하드웨어를 인에이블시키는 정보를 저장하는 스토리지 하드웨어
를 포함하고,
상기 프로세싱 하드웨어는, 상기 컴퓨팅 디바이스가 동작 중일 때, 스트림 클래스들의 규정들을 저장하고, 각각의 스트림 클래스는 다른 스트림 클래스들 중 하나 이상의 스크림 클래스에 관련된 상이한 우선순위를 갖도록 규정되며, 상기 관련된 우선순위들은 상기 스트림 클래스들 간의 네트워크 성능 특성을 우선순위화하여 일부 스트림 클래스들이 상기 스트림 클래스들 중 다른 스트림 클래스들보다 상기 네트워크 성능 특성에 대해 더 높은 우선순위를 갖고;
상기 프로세싱 하드웨어는, 상기 컴퓨팅 디바이스가 동작 중일 때, 상기 컴퓨팅 디바이스 상에서 실행되는 상기 임의의 애플리케이션들이 상기 애플리케이션들에 의해 식별된 스트림 클래스들과 상기 애플리케이션들에 의해 식별된 스트림들 사이의 연관성들을 할당하도록 인에이블링시키고, 상기 연관성들은 상기 컴퓨팅 디바이스에 의해 유지되고, 상기 연관성들은 상기 애플리케이션들에 의해 할당된 연관성들에 따라 어떤 특정 스트림들이 어떤 특정 스트림 클래스들과 연관되었는지를 나타내며;
상기 프로세싱 하드웨어는, 상기 컴퓨팅 디바이스가 동작 중일 때, 상기 유지되는 연관성들에 따라 상기 스트림들에 할당된 각자의 스트림 클래스들에 따라 상기 스트림들에 의한 상기 컴퓨팅 디바이스의 네트워크 리소스들의 사용을 제어하고, 상기 제어는, 상기 운영 체제에 의해 수행되고, 스트림 클래스에 대해, 상기 유지되는 연관성들에 따라 상기 스트림 클래스와 연관된 상기 스트림들에 대한 종합적 네트워크 성능 통계(aggregate network performance statistic)를 계산하는 것과, 상기 종합적 네트워크 성능 통계에 따라 그리고 상기 네트워크 성능 특성에 대한 상기 스트림 클래스들의 관련된 우선순위들에 따라 상기 스트림 클래스의 스트림들에 대한 패킷들의 전송의 타이밍을 제어하는 것을 포함하고, 스트림에 대한 패킷의 전송의 타이밍은, 상기 유지되는 연관성들이 어떤 스트림 클래스가 상기 스트림과 연관되는지를 나타내는지에 의존하는 것인, 컴퓨팅 디바이스.
제 8 항에 있어서, 상기 네트워크 인터페이스에 의한 스트림의 패킷들의 전송은, (i) 다른 스트림과 연관된 이벤트에 기반하여 그리고 (ii) 상기 스트림 및 상기 다른 스트림 중 적어도 하나의 스트림 클래스에 기반하여 우선적으로(preemptively) 제한되는 것인, 컴퓨팅 디바이스.
제 9 항에 있어서, 상기 이벤트는, 상기 다른 스트림에 대한 네트워크 연결의 형성 또는 상기 다른 스트림 상의 네트워크 트래픽의 발생(occurrence)을 포함하는 것인, 컴퓨팅 디바이스.
제 8 항에 있어서, 액션들을 조정하는 것은, 상기 스트림들에 대응하는 상기 스트림 클래스들의 관련된 우선순위에 대응하는 순서로 상기 스트림들에 대해 수행되는 것인, 컴퓨팅 디바이스.
제 8 항에 있어서, 상기 운영 체제는, 상기 스트림 클래스들의 식별자들 및 상기 스트림들의 식별자들을, 애플리케이션 프로그래밍 인터페이스를 통해 제공함으로써 상기 스트림들에 상기 스트림 클래스들을 할당하기 위해 상기 애플리케이션들이 사용하는 상기 애플리케이션 프로그래밍 인터페이스를 제공하는 것인, 컴퓨팅 디바이스.
제 8 항에 있어서, 상기 네트워크 인터페이스에 의한 상기 스트림들의 전송의 타이밍 및 양 중 적어도 하나는, 상기 스트림들에 할당된 상기 스트림 클래스들에 따라 우선순위화되는 것인, 컴퓨팅 디바이스.
제 13 항에 있어서, 상기 성능 특성에 대한 상기 스트림들의 성능이 상기 스트림들에 할당된 상기 스트림 클래스들에 따라 평가되고, 상기 스트림에 할당된 상기 스트림 클래스에 따라 스트림이 수행되지 않거나, 또는 수행되지 않을 것이라고 결정되었을 때, 다른 스트림들이 상기 스트림들에 할당된 상기 스트림 클래스들에 따라 조정되는 것인, 컴퓨팅 디바이스.
컴퓨팅 디바이스가 동작 중일 때 프로세스를 수행하도록 인에이블하는 정보를 저장하는 하나 이상의 스토리지 장치에 있어서, 상기 프로세스는,
운영 체제에 의해 실행되고 있는 애플리케이션들에 네트워크 스트림들을 제공하는 상기 운영 체제를 실행하는 것 - 상기 운영 체제는 미리 규정된 네트워크 스트림 클래스들을 구현하고, 상기 네트워크 스트림들은, 상기 애플리케이션들이 네트워크에 데이터를 송신하기 위해 기록하고 상기 네트워크로부터 데이터를 수신하기 위해 판독하는 운영 체제 객체들을 포함하고, 저장된 규정들은 상기 네트워크 스트림 클래스들을 규정하고, 각각의 네트워크 스트림 클래스는 다른 네트워크 스트림 클래스들 중 하나 이상의 네트워크 스트림 클래스에 관련된 상이한 우선순위를 갖도록 규정되고, 상기 관련된 우선순위들은 상기 네트워크 스트림 클래스들 간의 네트워크 성능 특성을 우선순위화하여 일부 네트워크 스트림 클래스들이 상기 네트워크 스트림 클래스들 중 다른 네트워크 스트림 클래스들보다 상기 네트워크 성능 특성에 대해 더 높은 우선순위를 가짐 - ;
네트워크 통신 프로토콜을 구현하는 상기 운영 체제의 네트워크 스택(network stack)을 실행하는 것 - 상기 애플리케이션들의 스트림들은 상기 네트워크 스택을 통해 네트워크 패킷들을 송신하고 수신하며, 상기 패킷들은 상기 네트워크 통신 프로토콜을 준수함 - ;
상기 운영 체제에 애플리케이션 프로그래밍 인터페이스(API)를 제공하는 것 - 상기 API는 애플리케이션에 의해 사용될 때, 상기 애플리케이션으로 하여금 스트림, 네트워크 스트림 클래스를 특정하고 상기 특정된 스트림과 상기 특정된 네트워크 스트림 클래스 사이의 연관성을 특정함으로써 상기 스트림에 상기 네트워크 스트림 클래스를 할당하게 하고, 상기 네트워크 스택은, 상기 네트워크 스트림 클래스들에 상기 스트림들을 할당하기 위해 상기 애플리케이션들에 의해 상기 API의 호출(invocation)들에 따라 상기 스트림들 중 어떤 스트림들이 상기 네트워크 스트림 클래스들 중 어떤 네트워크 스트림 클래스에 할당되었는지는 나타내는 연관성 정보를 유지함 - ; 및
상기 스트림들의 네트워크 통계에 따라, 상기 유지되는 연관성 정보에 따라 상기 스트림들에 할당된 상기 네트워크 스트림 클래스들에 따라, 그리고 상기 네트워크 성능 특성에 대한 상기 네트워크 스트림 클래스들의 관련된 우선순위들에 따라 상기 컴퓨팅 디바이스로부터의 상기 스트림들의 패킷들의 송신의 타이밍을 제어하는 것 - 스트림에 대한 패킷의 전송의 타이밍은 상기 유지되는 연관성 정보가 어떤 네트워크 스트림 클래스가 상기 스트림과 연관되는지를 나타내는지에 의존함 -
을 포함하는 것인, 하나 이상의 스토리지 장치.
제 15 항에 있어서, 상기 네트워크 통신 프로토콜은, 네트워크 전송층에서의 전송 제어 프로토콜을 포함하는 것인, 하나 이상의 스토리지 장치.
제 15 항에 있어서, 상기 운영 체제는, 상기 스트림들에 할당된 상기 네트워크 스트림 클래스들에 따라 상기 스트림들의 네트워크 성능을 평가하고 상기 평가에 따라 상기 스트림들의 동작 파라미터들을 조절하며, 주어진 스트림의 동작 파라미터의 조절은 어떤 네트워크 스트림 클래스가 상기 주어진 스트림에 할당되었는지에 의존하는 것인, 하나 이상의 스토리지 장치.
제 17 항에 있어서, 각각의 네트워크 스트림 클래스는 각자의 대역폭 및 레이턴시 사양에 대응하고, 상기 평가하는 것은 상기 네트워크 스트림 클래스들의 대역폭 및 레이턴시 사양들에 대하여 상기 스트림들의 대역폭 및 레이턴시 성능을 평가하는 것을 포함하는 것인, 하나 이상의 스토리지 장치.
제 15 항에 있어서, 상기 스트림들의 패킷들은, 상기 컴퓨팅 디바이스로부터 전송될 때 서비스 태그(service tag)들의 품질을 포함하지 않는 것인, 하나 이상의 스토리지 장치.
제 15 항에 있어서, 네트워크 스트림 클래스는 성능 하한(performance floor) 또는 상한(ceiling)에 대응하고, 스트림의 동작 파라미터는 상기 성능 하한 또는 상한에 기반하여 조절되는 것인, 하나 이상의 스토리지 장치.