KR102392442B1

KR102392442B1 - 분류된 네트워크 스트림의 관리

Info

Publication number: KR102392442B1
Application number: KR1020177011105A
Authority: KR
Inventors: 아메드 탈라트; 비호르 바트; 제프 신네마키; 알렉세이 알렉센코; 일리아 색슨; 제프리 씨 풀러; 밀레나 샐먼; 마드후수드한 라비; 모하메드 엠 카람; 닐 제인
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2014-09-25
Filing date: 2015-09-24
Publication date: 2022-04-28
Also published as: EP3198842B1; EP3198842A1; US20160094427A1; CN106716971A; WO2016049321A1; KR20170060118A; CN106716971B; US10038616B2

Abstract

실시예들은 네트워크 스트림들을 분류하고 스트림들의 거동을 그들의 각자의 클래스들에 기초하여 조정하는 것에 관한 것이다. 스트림들을 관리하는 하나의 기법은, 애플리케이션들을 분석하는 것, 애플리케이션들의 특징들의 표식들을 획득하는 것, 그리고 애플리케이션들의 스트림들이 할당될 수 있는 클래스들을 추론하기 위해 그 특징들을 사용하는 것을 수반한다. 다른 기법은 네트워크의 에지(edge)에 비콘 노드(beacon node)들을 설치하는 것을 수반한다. 비콘 노드들은, 네트워크 경계들 또는 영역들과 관련한 지연시간들과 같은, 네트워크 상태에 관해 스트림 관리자에게 통보한다. 스트림들의 관리를 용이하게 하기 위한 또 다른 실시예는 UDP 애플리케이션들에 대한 가입 서비스를 수반한다. UDP 애플리케이션은, 애플리케이션을 호스팅하는 운영 체제에 의해 제공될 수 있는, 서비스에 가입할 수 있다. 네트워킹 상태의 변화들을 UDP 애플리케이션들에 통보하기 위해 이벤트들이 임의의 가입된 UDP 애플리케이션들에 게시된다. UDP 애플리케이션들은, 차례로, 그들의 내부 전송 제어 논리를 적합(adapt)하게 할 수 있다.

Description

분류된 네트워크 스트림의 관리{MANAGING CLASSIFIED NETWORK STREAMS}

컴퓨팅 디바이스 상의 다수의 애플리케이션들이 컴퓨팅 디바이스 상의 또는 컴퓨팅 디바이스의 외부에 있는 동일한 제한된 네트워크 자원들을 공유할 때, 그 애플리케이션들의 네트워킹 요구들을 균형을 이루게 하기 위해 다양한 기법들이 사용되어 왔다. 컴퓨터 사용자들 및 애플리케이션들은 보통 네트워크 자원들을 소비하는 애플리케이션들 간의 특정 절충 및 우선순위 부여를 선호한다. 그렇지만, 실제로는, 네트워크 액세스를 공유하기 위한 종래의 기법들은 종종 그 선호도(preference) 및 우선권(priority)을 최적으로 실현하지 않았다. 예를 들어, 디바이스의 사용자는 그의 디바이스 상에서의 VoIP(Voice over IP) 통화가 낮은 네트워크 지연 시간(latency)을 갖는 것과 디바이스 상에서의 웹 브라우징이 재빠르고 응답성이 좋은 것을 선호할 수 있다. 사용자는 또한, 클라우드 동기화 및 운영 체제 업데이트와 같은, 백그라운드 벌크 네트워크 전송이 만족스러운 포어그라운드(foreground) 성능을 가능하게 하고 무리 없는(reasonable) 진행을 유지하는 방식으로 디바이스의 네트워크 자원들을 소비하는 것을 선호할 수 있다.

종종 네트워크 액세스를 만족스럽게 공유하지 못하는 것에 부가하여, 종래의 액세스 공유 기법들은 소프트웨어 개발자들이 액세스하거나 구현하는 데 종종 편리하지 못하였다. 예를 들어, QoS(Quality of Service) 기능들이 도움이 될 수 있지만, 그들이 종종 이용가능하지 않거나 균일한 방식으로 구현되지 않는다. 대부분의 QoS 기술은 애플리케이션 레벨 아래쪽에서 행해지고, 따라서 애플리케이션들에 의해 신뢰성 있게 조작가능하지 않을 수 있다. 대부분의 QoS 접근법들, 예를 들어, 차별화된 서비스(Differentiated Services)는 2개의 종단점들 사이의 네트워크의 거동(behavior) 및 지원에 의존한다. 이러한 지원이 모든 네트워크 경로들에 존재하지는 않을 수 있다. 편의성과 관련하여, 네트워크 공유 거동이 또한 애플리케이션들 내에서 구현되었지만, 이것은 보통 애플리케이션들 간의 직접적인 조율이 거의 또는 전혀 없는 복잡한 네트워크 프로그래밍을 필요로 하였다. 상이한 애플리케이션들이 그 자신의 네트워크 공유 논리를 구현하는 것이 중복적일 뿐만 아니라, 애플리케이션들의 상이한 자원 공유 거동들이 충돌할 수도 있다.

애플리케이션들이 특정 유형들의 네트워크 소비 거동을 구현할 수 있게 하기 위해 운영 체제들에 의해 구현되는 LEDBAT(Low Extra Delay Background Transport)와 같은 프로토콜들이 있지만, 이러한 프로토콜을 이용하는 코딩은 애플리케이션을 개발하는 것의 비용 및 오버헤드를 증가시킬 수 있고, 개발자가 이러한 프로토콜을 사용할 가능성을 보다 적어지게 만들 수 있다. 그에 부가하여, LEDBAT와 같은 널리 배포된 저 우선순위 TCP(Transport Control Protocol) 메커니즘들은 단점들을 가지며, 이상적인 사용자 경험을 종종 제공하지 않는다(다른 예들에 대해서는 Internet Engineering Task Force Request for Comments 6297을 참조). 예를 들어, LEDBAT 프로토콜은 TCP 송신 윈도우(TCP send window)만을 제한하고 수신 스트림에 어떤 효과도 없으나, 대부분의 클라이언트측 인터넷 트래픽은 인바운드(inbound)이다. LEDBAT와 같은 메커니즘이 복잡한 개발자 코딩을 필요로 함이 없이 이용가능할 때에도, 운영 체제 또는 네트워크 스택(network stack)이 애플리케이션이 이러한 메커니즘을 사용해야 한다고 결정하는 것이 가능하지 않을 수 있다. 환언하면, 네트워크 자원 충돌에 관한 사용자와 애플리케이션 의도가 추론하기 어려웠고 애플리케이션들은 그들의 네트워크 우선권들을 거의 명시하지 않았다. 디바이스의 네트워크 자원들의 공유가, "후발자(latecomer)" 현상(예컨대, Request For Comments 6817, section 4.4를 참조)에 영향을 받지 않고, 경쟁하는 애플리케이션들 간에 일관성 있는 방식으로 구현되지 않았다.

분류된 네트워크 스트림들을 구현하고 이용하는 것에 관한 기법들이 이하에서 논의된다.

이하의 발명의 내용은 이하의 발명을 실시하기 위한 구체적인 내용에서 논의되는 일부 개념들을 소개하기 위해서만 포함되어 있다. 이 발명의 내용은 포괄적인 것이 아니며, 끝부분에 제시된 청구항들에 의해 기재되는, 청구된 발명 요지의 범주를 확정하려는 것으로 의도되어 있지 않다.

본원에 기술되는 실시예들은 네트워크 스트림들을 분류하고 스트림들의 거동을 그들의 각자의 클래스들에 기초하여 조정하는 것에 관한 것이다. 스트림들을 관리하는 하나의 기법은 애플리케이션들을 분석하는 것, 애플리케이션들의 특징들의 표식들을 획득하는 것, 그리고 애플리케이션들의 스트림들이 할당될 수 있는 클래스들을 추론하기 위해 그 특징들을 사용하는 것을 포함한다. 다른 기법은 네트워크의 에지(edge)에 비콘 노드(beacon node)들을 설치하는 것을 포함한다. 비콘 노드들은, 네트워크 경계들 또는 영역들과 관련한 지연시간들과 같은, 네트워크 상태에 관해 스트림 관리자에게 통보한다. 스트림들의 관리를 용이하게 하기 위한 다른 실시예는 UDP 애플리케이션들에 대한 가입 서비스를 포함한다. UDP 애플리케이션은, 애플리케이션을 호스팅하는 운영 체제에 의해 제공될 수 있는, 서비스에 가입할 수 있다. 네트워킹 상태의 변화들을 UDP 애플리케이션들에 통보하기 위해 이벤트들이 임의의 가입된 UDP 애플리케이션들에 게시된다. UDP 애플리케이션들은, 차례로, 그들의 내부 전송 제어 논리를 적응시킬 수 있다.

다른 실시예들에서, 운영 체제는 네트워크 스트림들의 클래스들을 구현한다. 애플리케이션들은 그들의 네트워크 스트림들을 클래스들에 할당한다. 운영 체제는, 차례로, 스트림들이 어느 클래스들에 속해 있는지에 따라 스트림들을 조정한다. 상태가 변할 때, 스트림들이 어느 클래스들에 할당되었는지에 따라 스트림들을 조정하는 것에 의해 네트워크 자원들이 이용가능하게 되거나 보다 충분히 이용될 수 있다. 하위 우선순위 클래스들에 있는 스트림들을 제한하는 것에 의해 상위 우선순위 클래스들에 있는 스트림들을 위해 네트워크 자원들이, 아마도 신속하게 또는 선제적으로, 이용가능하게 될 수 있다.

부수적인 특징들 중 다수의 특징들이 첨부 도면들과 관련하여 고려된 이하의 발명을 실시하기 위한 구체적인 내용을 참조하여 이하에서 설명될 것이다.

본 설명이, 유사한 참조 번호들이 부속 설명에서 유사한 부분들을 가리키는 데 사용되는, 첨부 도면들을 고려하여 읽어보면 이하의 발명을 실시하기 위한 구체적인 내용으로부터 더 잘 이해될 것이다.
도 1은 애플리케이션들 또는 스트림들을 자동으로 또는 암시적으로 분류하는 구성을 나타낸 도면.
도 2는 프로파일-클래스 매핑들 및 애플리케이션-클래스 매핑들의 예들을 나타낸 도면.
도 3은 프로파일-클래스 매핑들 및 애플리케이션-클래스 매핑들을 사용하여 스트림 클래스를 선택하는 프로세스를 나타낸 도면.
도 4는 스트림들의 클래스들과 부합하도록 스트림들을 조정하는 데 도움을 주기 위해 스트림 관리자에 의해 사용가능한 네트워크 정보를 제공할 수 있는 비콘 노드들을 나타낸 도면.
도 5는 UDP(user datagram protocol) 애플리케이션들이 그들의 네트워크 거동을 개선시키는 데 도움을 주기 위한 일 실시예를 나타낸 도면.
도 6은 스트림들을 그들의 클래스들에 따라 조정하기 위해 TCP 송신 및 수신 윈도우 크기들이 스트림 관리자에 의해 사용되는 일 실시예를 나타낸 도면.
도 7은 네트워크 스택을 구현하는 운영 체제를 갖는 컴퓨팅 디바이스를 나타낸 도면.
도 8은 애플리케이션이 API(application programming interface)를 사용하는 프로세스를 나타낸 도면.
도 9는 스트림 분류 모델의 일 예를 나타낸 도면.
도 10은 각자의 네트워크 성능 카테고리들을 갖는 예시적인 스트림들을 나타낸 도면.
도 11은 분류 모델의 다른 예를 나타낸 도면.
도 12는 스트림 관리자의 상세도.
도 13은 스트림 관리자가 스트림들을 관리할 수 있는 예시적인 프로세스를 나타낸 도면.
도 14는 스트림 분류 모델의 다른 예를 나타낸 도면.
도 15는 총체적 스트림 관리의 일 실시예에 대한 프로세스를 나타낸 도면.
도 16은 컴퓨팅 디바이스의 부가 상세들을 나타낸 도면.

분류된 스트림들의 관리

이하에서 "네트워크 스트림 분류 모델들 및 그의 구현들"이라는 제목의 섹션은 네트워크 스트림들을 분류하고 그에 따라 네트워크 자원들의 사용을 조정하는 기법들을 기술한다. "분류된 스트림들의 관리"라는 제목의 이 섹션은 분류된 스트림들을 관리하기 위한 관련 방법들을 기술한다. 이 섹션은 애플리케이션이 그의 스트림들을 명시적으로 분류하지 않을 때 애플리케이션의 스트림들이 어떻게 암시적으로 분류될 수 있는지의 설명으로 시작할 것이다. 네트워크 자원 할당을 개선시키기 위해 네트워크 에지 신호(network-edge signal)들을 사용하는 것의 기법이 그 다음에 논의된다. UDP(User Datagram Protocol) 애플리케이션들에 대한 통지 서비스를 어떻게 제공해야 하는지, 스트림들을 조정하는 것을 돕기 위해 송신 및 수신 윈도우들을 어떻게 사용해야 하는지, 및 다른 것들을 비롯한, 다양한 다른 기법들이 이어서 논의된다.

이하에서 "네트워크 스트림 분류 모델들 및 그의 구현들"이라는 제목의 섹션은 네트워크 트래픽을 전달하기 위한 스트림들이, 예를 들어, 운영 체제에 의해 제공되는 API(application programming interface)를 사용함으로써, 애플리케이션들에 의해 어떻게 명시적으로 분류될 수 있는지를 기술한다. 애플리케이션으로 하여금 그의 네트워크 스트림들을 명시적으로 분류하게 하는 접근법이 애플리케이션의 선호사항들을 네트워크 자원들의, 운영 체제에 의한, 관리에 맞춰 조정하는 데 효과적이지만, 이 명시적 분류 접근법이 항상 실용적인 것은 아닐 수 있다. 예를 들어 스트림 분류 기능들을 이용함이 없이 이미 코딩되고 컴파일되어 있는 애플리케이션 또는 프로그램은, 쉼(shim) 또는 다른 차선책(work-around)이 없으면, 아마도 재작성, 재컴파일, 재테스트, 및 재배포될 필요가 있을 것이다. 많은 이유들로 인해, 애플리케이션을 수정하는 것이 가능하지 않거나 실용적이지 않을 수 있다.

도 1은 애플리케이션들 또는 스트림들을 자동으로 또는 암시적으로 분류하는 구성을 나타내고 있다. 컴퓨팅 디바이스 상에서 실행 중인 애플리케이션(100)은 전형적으로 컴퓨팅 디바이스(도 16을 참조) 또는 그의 운영 체제의 다양한 자원들을 사용한다. 애플리케이션의 이 특성(trait)들이, 그 중에서도 특히, 애플리케이션에 대한 디폴트 스트림 분류(default stream classification)를 결정하려고 시도하기 위해 애플리케이션 프로파일러(application profiler)(102)에 의해 사용될 수 있다. 이 설명을 위해, 애플리케이션(100)은 컴퓨팅 디바이스 상에 실행 중일 수 있는 임의의 코드 또는 소프트웨어를 나타낸다. 애플리케이션(100)은 운영 체제에 의해 관찰가능한 다양한 정적 및 동적 특징들을 가질 수 있다. 예를 들어, 애플리케이션(100)은 라이브러리들(106)을 호출(invoke)하거나 링크(link)시키기 위해, 시스템 또는 애플리케이션 구성 설정들(108)에 액세스하기 위해, 운영 체제 서비스들(110)과 상호작용하기 위해, 네트워크 스택(112)과 상호작용하기 위해, 그리고 기타를 위해, API(application programming interface) 호출(call)들(104)을 발행할 수 있다.

애플리케이션 프로파일러(102)는 정적 분석기(114) 및/또는 동적 런타임 분석기(116)를 가질 수 있다. 이 컴포넌트들 중 어느 하나 또는 둘 다는 어느 API 호출들(104)이 애플리케이션(100)에 의해 발행되는지를 결정하는 데 사용될 수 있다. 런타임 API 호출들(104)은 후크(hook)들, 이벤트 리스너(event listener)들, 또는 다른 런타임 가로채기(run-time intercept)들에 의해 식별될 수 있고, 런타임 분석기(116)는 통지받는다. API 호출들(104)은 또한, 애플리케이션을 실행하기 직전에, 애플리케이션을 설치할 때, 주기적인 유지보수 절차 동안, 기타에서, 정적 분석기(114)에 의해 수행되는 정적 분석에 의해 식별될 수 있다. 정적 분석은 링크된 라이브러리(linked-to library)들(106)(아마도 애플리케이션 매니페스트(application manifest)에서 또는 실행가능 파일의 특별 섹션에서 식별됨), 기지의 운영 체제 파일들에 대한 의존관계들을 식별하는 것, 구성 파일들 또는 설정들을 파싱하는 것 등을 포함할 수 있다.

애플리케이션(100)의 다른 특징들이 또한 애플리케이션 프로파일러(102)에 의해 수집될 수 있다. 예를 들어, 애플리케이션 프로파일러(102)는 애플리케이션이, 예를 들어, 단말이 애플리케이션과 연관되어 있는지에 기초하여, 백그라운드 또는 포어그라운드 프로세스로서 실행하도록 구성되어 있는지; 애플리케이션이 그의 호스트 컴퓨팅 디바이스 상에서 이용가능한 멀티미디어 하드웨어에 액세스하는지(따라서 스트림 클래스를 암시함); 애플리케이션 내로 흘러들어가는 콘텐츠의 유형들(예컨대, 멀티미디어 하이퍼링크 또는 콘텐츠를 포함하는 HTML(hypertext markup language) 코드), 운영 체제의 멀티미디어 스케줄러에의 등록, 스트림과 연관된 네트워크 포트 또는 프로토콜 등을 결정할 수 있다. 애플리케이션(100)에 관해 확인가능한 임의의 정보는, 있는 경우, 애플리케이션에 대해 어떤 네트워크 분류들이 적절할 것인지에 관한 힌트로서 역할할 수 있다. 일 실시예에서, 원격 네트워크 서비스는 분류들을 제공할 수 있을 것이다. 예를 들어, 애플리케이션 프로파일러(102)는 애플리케이션의 식별자를 서비스로 송신할 수 있고, 그에 응답하여, 관리되는 소프트웨어 배포 서비스(즉, 온라인 소프트웨어 "스토어")로부터 획득된 애플리케이션에 관한 메타데이터에 기초하여 제공되는 분류를 수신할 수 있다. 어쨋든, 수집된 애플리케이션 특징들(118)은 애플리케이션 프로파일러(102)에 의해 수신되고, 애플리케이션(100)에 대한 클래스를 결정하려고 시도하는 데 사용된다.

일 실시예에서, 애플리케이션 프로파일러(102)는 애플리케이션(100)과 연관되어야 하는 가장 적합한 네트워크 스트림 클래스를 결정하는 알고리즘을 수행할 수 있다. 애플리케이션 프로파일러(102)는 애플리케이션 특징들을 한 세트의 미리 정의된 클래스들에 매핑하는 한 세트의 프로파일-클래스 매핑들(120)을 가질 수 있다. 즉, 프로파일-클래스 매핑들(120)은 어느 특징들이 어느 클래스들에 대응하는지를 표시할 수 있다. 도 2는 프로파일-클래스 매핑들(120) 및 애플리케이션-클래스 매핑들(122)의 예들을 나타내고 있다. 이 예에서, 애플리케이션 특징들은 상이한 스트림 클래스들에 대한 가중치들을 할당받는다. 애플리케이션 프로파일러(102)는 또한 어느 애플리케이션들이 어느 스트림 클래스들과 연관되는지를 추적하기 위해 애플리케이션-클래스 매핑들(122)을 유지할 수 있다. 이 매핑들 둘 다는 도 3을 참조하여 논의될 것이다.

도 3은 프로파일-클래스 매핑들(120) 및 애플리케이션-클래스 매핑들(122)을 사용하여 스트림 클래스를 선택하는 프로세스를 나타내고 있다. 단계(180)에서, 애플리케이션 프로파일러(102)는 대상 애플리케이션 또는 그의 스트림을 분류하라는 요청을 수신한다. 요청은, 애플리케이션이 실행을 시작하는 것, 애플리케이션이 설치되는 것, 백그라운드 유지보수 프로세스의 반복, 애플리케이션과 스트림 간의 상호작용, 트래픽이 스트림을 통해 흐르기 시작하는 것, 스트림을 형성하거나 스트림을 위한 네트워크 연결을 개시하는 것, 네트워크 자원들이 충분히 제약되어 있다는 결정, 또는 다른 것들과 같은, 임의의 유형의 이벤트에 의해 개시될 수 있다. 요청이 네트워크 스트림들을 관리하는 스트림 관리자에 의해, 예를 들어, 관리되는 스트림들을 재교정(recalibrate)할 때, 개시될 수 있다. 일 실시예에서, 스트림 분류 API를 사용하지 않는 것으로 결정되는 애플리케이션들만이 암시적으로 분류된다.

단계(180)에서, 대상 애플리케이션이 특정의 클래스와 이미 연관되어 있는지를 결정하기 위해 애플리케이션-클래스 매핑들(122)이 참조되고, 그러면 단계(182)에서, 그 클래스가 대상 애플리케이션의 스트림들에 대한 디폴트 클래스(default class)로서 사용된다. 즉, 대상 애플리케이션의 스트림들은 애플리케이션-클래스 매핑들(122)에 표시된 바와 같이 대상 애플리케이션과 이미 연관되어 있는 클래스에 따라 스트림 관리자에 의해 (상세하게는, 로컬 네트워크 자원들의 소비의 조정과 관련하여) 관리될 것이다.

단계(180)에서, 대상 애플리케이션이 스트림 클래스와 아직 연관되어 있지 않다고 결정되면, 대상 애플리케이션을 암시적으로 분류하기 위해 부가의 단계들이 수행된다. 단계(184)에서, 애플리케이션 특징들이 앞서 기술된 바와 같이 수집된다. 단계(186)에서, 대상 애플리케이션의 특징들인 프로파일-클래스 매핑들(120) 내의 임의의 특징들을 식별하기 위해 프로파일-클래스 매핑들(120)이 조회된다. 예를 들어, 대상 애플리케이션이 TCP(transmission control protocol) 포트 8080를 사용하면, 프로파일-클래스 매핑들의 첫 번째 행이 사용될 수 있다. 일 실시예에서, 분류 모델로부터 선택될 수 있을 잠재적인 클래스들 각각에 대해 현재 점수(running score)가 유지된다. 대상 애플리케이션의 특징들이 프로파일-클래스 매핑들에서 일치될 때, 대응하는 가중치들이 대응하는 클래스 점수들에 가산된다. 대상 애플리케이션의 특징들 모두가 처리되었을 때, 단계(190)에서, 최고 결과 점수를 가지는 클래스가 대상 애플리케이션에 대한 디폴트 클래스로서 선택된다. 최고 점수를 갖는 클래스가 아마도 대상 애플리케이션의 거동 또는 성능 선호사항들과 가장 잘 일치하는 클래스이다. 환언하면, 각자의 클래스들의 점수들은 대상 애플리케이션의 특징들이 운영 체제에 의해 제공되는 다양한 스트림 클래스들의 프로파일들에 얼마나 잘 들어맞는지를 나타낸다. 점수 부여(scoring) 이외의 접근법들이 사용될 수 있다. 예를 들어, 특징들에 우선순위를 부여하는 시스템이 사용될 수 있고(예컨대, 라이브러리Z의 사용은 항상 클래스 C임), 점수 부여와 부울 논리 규칙들의 조합이 사용될 수 있으며, 기타이다. 하나 이상의 대상 애플리케이션 특징들 또는 특성들이 클래스에 어떻게 매핑되는지에 관계없이, 애플리케이션에 대해 선택된 디폴트 클래스가, 단계(192)에서, 애플리케이션-클래스 매핑들(122)에 저장될 수 있다. 다음에 대상 애플리케이션이 처리될 때, 애플리케이션-클래스 매핑들(122)은 애플리케이션 프로파일러(102)로 하여금 동일한 디폴트 클래스를 또다시 사용하게 할 것이다.

암시적 애플리케이션 또는 스트림 분류를 위한 다른 방법들이 사용될 수 있다. 예를 들어, 사용자 설정들의 리스트가 운영 체제에 의해 유지될 수 있고, 사용자 인터페이스는 사용자가 클래스들을 특정 애플리케이션들과 연관시킬 수 있게 할 것이다. 다른 실시예에서, 애플리케이션들이 가져야만 하는 클래스들을 결정하기 위해 애플리케이션들의 네트워크 거동이 추적되고 분석될 수 있다. 예를 들어, 통신 패턴들(예컨대, 버스티함(bursty), 긴 지속시간(long-duration))이 특정의 클래스들에 일치될 수 있다. 또 다른 실시예에서, 암시적 클래스-애플리케이션 연관들이 저장되고 재사용되는 경우, 이러한 연관들은, 어떤 기간이 경과한 후에, 재평가되거나 삭제될 수 있다. 더욱이, 이전에 분류된 애플리케이션이 스트림 분류를 위해 명시적 API를 사용하기 시작하면, 클래스와의 임의의 이전의 암시적 연관이 제거되거나 번복될 수 있다.

도 4는 스트림들의 클래스들과 부합하도록 스트림들을 조정하기 위해 스트림 관리자에 의해 사용가능한 네트워크 정보를 제공할 수 있는 비콘 노드들(220)을 나타내고 있다. 앞서 언급된 관련 특허 출원에서 논의되는 바와 같이, 스트림 관리자는 로컬 호스트의 네트워크 자원들의, 스트림들에 의한, 소비를 조정하기 위해 운영 체제에서 구현될 수 있다. 비콘 노드들(220)은 네트워크에 관한 로컬 운영 체제의 가시성(visibility)을 확장하는 것으로서 생각될 수 있다.

일 실시예에서, 스트림 관리자가 로컬 네트워크 상태, 그리고 특히 연결의 "라스트 마일(last mile)"에 관한 정보를 갖는 것이 도움이 될 수 있다. 환언하면, 스트림 관리자는, 에지 네트워크 정보에 기초하여 스트림들을 스로틀링(throttle)하는 것에 의해, 개선된 효율 또는 결과로 스트림들 및 스트림들 간의 경쟁을 조정할 수 있다. 이 실시예에서, 대규모 엔터티에 의해 운영되는 네트워크, 예를 들어, 제1 네트워크(222)는 제1 네트워크(222)의 에지에 비콘 노드들(220)을 가질 수 있다. 비콘 노드들(220)은 경계 게이트웨이들 상에서 또는 네트워크 에지 근방에 존재하는 서버들 상에서 실행 중인 새로운 프로세스들로서, 네트워크 에지 근방에 있는 전용 서버 머신들로서, 기타로서 구현될 수 있다. 비콘 노드들(220)은 네트워크 상태를 기록하고 그 상태를 다시 수집 서비스(collecting service)(224)에 보고할 수 있다. 상세하게는, 제1 네트워크(222) 내의 노드들 사이의 지연시간들은 물론, 제1 네트워크(222) 밖에 있는 노드들까지의 지연시간들이 관찰되고 보고될 수 있다. 일 실시예에서, 외부 네트워크들 상의 노드들과의 통신에 의해 야기되는 부가된 지연시간을 추정하기 위해 기지의 외부 노드들이 폴링될 수 있다. 더욱이, 지연시간 정보는 제1 네트워크(222)의 상이한 에지들에서 상이한 지연시간들을 나타낼 수 있다. 어느 트래픽이 인터넷을 거치는지를 식별하는 데 도움을 주는 것이 또한 도움이 될 수 있다. 비인터넷 트래픽은 낮은 지연시간을 가질 수 있는 반면, 인터넷 트래픽은 높은 지연시간을 가질 수 있다.

에지에 의해 제공된 지연시간 정보(edge-provided latency information)는 스트림들을 조정하기 위해 로컬 스트림 관리자에 의해 다양한 방식들로 사용될 수 있다. 로컬 스트림 관리자는 수집 서비스(224)로부터 지연시간 정보를 획득하고, 스트림들을 조정하기 위해, 그 지연시간 정보를 사용할 수 있다. 상세하게는, 새로운 스트림이 개시될 때, 기준 네트워크 지연시간(baseline network latency)(또는 다른 속성)이 획득될 수 있다. 에지에 관련된 지연시간 정보(edge-related latency information)는 초기 스트림 기준(initial stream baseline)들을, 보다 나은 스트림 관리를 용이하게 하는, 값들로 설정하는 데 사용될 수 있다. 지연시간 정보는 또한 혼잡 윈도우(congestion window)들의 초기 또는 진행 중인 크기들을 설정하는 데 또는 윈도우들을 송신하고 수신하는 데 사용될 수 있다. 에지에 관련된 지연시간 정보가 lEDBAT 유사 프로토콜들에서 어떻게 사용될 수 있는지에 관해 상세히 설명하기 위해, lEDBAT 프로토콜이, 예를 들어, 전역 베이스 지연시간(global base latency), 또는 네트워크를 통해 가능한 최소 지연시간에 의존한다. lEDBAT 프로토콜은 스트림들 간에 정보를 혼합하지 않고; 모든 스트림들이 베이스 지연시간(base latency)에 기초하여 관리된다. 상이한 네트워크들 또는 게이트웨이들을 통해 가는 스트림들을 명확히 하기 위해 에지 지연시간 정보가 사용될 수 있는데, 그 이유는 스트림들이 상당히 다양한 베이스 지연시간들을 가질 수 있기 때문이다. 에지에 의해 제공된 지연시간 정보는, 기지의 원격 종단점 및 게이트(로컬 머신의 인터넷 서비스 공급자를 통해 가는 인터넷 서버 등)를 사용해 스트림을 제공하는 것에 의해, 명확히 하는 것을 도울 수 있다.

도 5는 UDP 애플리케이션들이 그들의 네트워크 거동을 개선시키는 데 도움을 주기 위한 일 실시예를 나타내고 있다. UDP 프로토콜을 사용하는 애플리케이션들은 종종, 패킷 시퀀싱(packet sequencing), 재전송, 및 오류 검사와 같은, 그 자신의 전송 제어들을 구현한다. 일부 구현들에서, UDP 스트림들을 분류된 스트림들로서 관리하는 것이 실용적이지 않을 수 있다. 그렇지만, 애플리케이션들은 종종, 네트워크 성능 및 네트워크 자원들의 사용에 관한 상태를 통보받는 것으로부터 이득을 볼 수 있는, 트래픽 조정 논리(traffic regulating logic)를 갖는다. 컴퓨팅 디바이스(250)는 이벤트 게시 서비스(252)를 구비하고 있을 수 있다. 이벤트 게시 서비스(252)는, 적절한 API 호출에 의해 게시 서비스에 가입할 수 있는, 애플리케이션들(254)에 의해 이용가능한 운영 체제 서비스일 수 있다.

이벤트 게시 서비스(252)는 프로세스(256)를 수행할 수 있다. 프로세스(256)는 네트워크 자원 상태에 관한 신호들을 수신하는 것을 포함할 수 있다. 사실상, 스트림 관리자(257)가 스트림들을 관리하기 위해 사용할 수 있는 임의의 유형의 정보가 어쩌면 게시를 위해 이벤트 게시 서비스로 전달될 수 있다. 일 실시예에서, 이벤트 게시 서비스(252)는 네트워크 스택(253)으로부터 네트워크 성능 정보를 수집하고, 네트워크 상태가 가입된 애플리케이션들(254)에 통지할 만한 가치가 있는 방식으로 변했을 때에 관한 그 자신의 결정을 할 수 있다. 다른 실시예에서, 스트림 관리자(257)는 컴퓨팅 디바이스(250)의 현재 지연시간 및 대역폭 성능에 관한 업데이트들을 주기적으로 푸시 아웃(push out)할 수 있다.

차례로, 애플리케이션(254)은 이벤트 게시 서비스로부터의 통지들을 핸들링하는 커스텀 논리(custom logic)(258)를 가질 수 있다. 예를 들어, 이벤트 게시 서비스에 가입한 후에, 애플리케이션은 이벤트를 수신할 수 있다. 어떤 형태의 프로세스간 통신(interprocess-communication)에 의해 전달될 수 있는, 이벤트가 단지 네트워크 상태가 변했고 재교정(recalibration)이 요구된다는 것을 나타낼 수 있다. 이벤트는 또한, 현재 대역폭 또는 지연시간 성능, 현재 혼잡 레벨들, 추천된 윈도우 크기들 등과 같은, 네트워크 상태에 관한 특정 정보를 가질 수 있다. 수신측 애플리케이션은 이어서 그의 네트워크 거동을 재교정하기 위한 커스텀 코드(custom code)를 호출할 것이다. 예를 들어, 이벤트가 하나 이상의 스트림 클래스들이 과소 성능을 나타내거나(underperform) 과대 성능을 나타내고(overperform) 있다는 것을 나타내는 경우, 애플리케이션은, 그에 대응하여, 그의 현재 트래픽 처리율을 증가 또는 감소시키기로, 통신을 보류하기로, 또는 그 자신의 거동을 개선시키도록 또는 스트림 관리자(257)에 의한 스트림들의 보다 나은 관리를 가능하게 하는 데 도움을 주도록 설계된 다른 조절들을 행하기로 결정할 수 있다. 애플리케이션이, 송신 윈도우, 수신 윈도우, 혼잡 윈도우 등과 같은, 그 자신의 전송 유형 특징들을 구현하는 경우에, 애플리케이션은 게시된 이벤트에 응답하여 그 특징들을 조절할 수 있다.

도 6은 스트림들을 그들의 클래스들에 따라 조정하기 위해 TCP 송신 및 수신 윈도우 크기들이 스트림 관리자에 의해 사용되는 일 실시예를 나타내고 있다. 앞서 언급한 특허 출원은 스트림 관리자가 네트워크 스트림들을 그들의 클래스들에 따라 조정하는 것을 논의하고 있다. 스트림 조정을 위한 하나의 메커니즘은 TCP 스트림과 연관되어 있는 TCP 송신 및 수신 윈도우들(270, 272)의 크기들을 수정하는 것이다. 컴퓨팅 디바이스(250)가 네트워크(276)를 통해 원격 디바이스(278)와 통신하고 있을 때, TCP 연결의 양 단부들은 송신 및 수신 윈도우를 가질 수 있다. 그렇지만, 로컬 네트워크 자원들, 상세하게는 지연시간을 조정하기 위해, 수신 윈도우가 수신측 디바이스에 의해 사용되지 않았다. 전형적으로, 일부 LEDBAT(low-delay extra bandwidth) 구현들은 원격 노드들이 또한 LEDBAT 또는 동등한 대역폭/지연시간 조정 방식을 구현하고 있는 것으로 가정하였다. 따라서, 이 구현들은 전형적으로 트래픽을 조정하기 위해 혼잡 윈도우를 사용할 뿐이고; 양측은 상대방측이 트래픽을 조정하기 위해 그의 역할을 행할 것으로 가정한다. 컴퓨팅 디바이스(250)에서 로컬 송신 및 수신 윈도우들(270, 272) 의 크기들을 조절하는 것은, (예컨대, 제2의 상위 우선순위 지연시간 클래스에 있는) 다른 스트림들이 부가의 응답성을 필요로 할 때, 스트림 관리자(256)에게 (예컨대, 제1 클래스에 있는) 일부 스트림들을 백오프(back-off)하는 것에 대해 더 많은 제어를 부여한다.

구체적으로는, 스트림 관리자(256)는, 스트림을 관리할 때, 네트워크 자원 요구사항 또는 로컬 상태의 변화의 표시들을 수신하는 프로세스(280)를 수행할 수 있다. 예를 들어, 스트림이 고 우선순위 지연시간 클래스에 있을 수 있고, 스트림 관리자(256)는 스트림이 지연시간 요구사항 또는 문턱값에 있거나 그에 접근하고 있다고 결정할 수 있다. 스트림의 클래스에 대한 지연시간 우선순위 또는 지연시간 하한(latency floor)이 유지되도록 보장하기 위해, 스트림 관리자는 이어서 다른 스트림들의 송신 및 수신 윈도우들(270, 272) 둘 다를, 그들의 클래스들에 따라, 조절한다. 이것은 스트림 관리자(256)가 그 다른 스트림들(상세하게는, 저 우선순위 클래스)을 신속하게 스로틀링할 수 있게 하고, 고 우선순위 지연시간 클래스에 있는 스트림이 저 지연시간으로 신속히 동작할 수 있게 할 것이다. 일 실시예에서, 송신 및 수신 윈도우들(270, 272)의 크기들이 지연에 관한 정보에 따라 결정될 수 있다. 예를 들어, 단방향 지연이 TCP 타임스탬프들을 사용하여 측정될 수 있다. 유의할 점은, 혼잡 윈도우(274)의 크기가 또한 스트림들을 그들의 클래스들에 따라 조정하기 위해 조작될 수 있다는 것이다. 또한 유의할 점은, 스트림 관리자(256)가 윈도우들을 직접 관리할 필요가 없다는 것이다. 스트림 관리자(256)는 네트워크 스택과 통신하고, 윈도우 크기들이 얼마이어야 한다는 것을 네트워크 스택에 통보할 수 있고, 이어서 네트워크 스택은 그 크기들을 구현한다.

윈도우 조작을 위한 알고리즘은 다음과 같이 구현될 수 있다. 첫째, 스트림이 그의 스트림 클래스의 지연시간 목표로부터 멀리 떨어져 있을수록, 스트림의 윈도우 크기가 보다 신속하게 크기 재조정될 수 있다. 예를 들어, 스트림의 클래스가 100 ms 미만의 지연시간을 목표로 하고 현재 측정된 지연시간이 400 ms인 경우, (아마도 클래스에 의해 우선순위를 부여받는) 다른 스트림들의 윈도우 크기들이 신속하게 낮춰진다. 현재 측정된 지연시간이 150 ms이면, 윈도우 크기들이 점진적으로 감소된다. 환언하면, 윈도우 크기 수정의 레이트는 현재 지연시간과 스트림의 목표 지연시간 사이의 차이의 함수일 수 있다. 보다 간단한 크기 재조정 접근법, 예를 들어, 윈도우 크기를 정적인 크기만큼 변경하는 것은 목표 지연시간을 오버슈트하는 극심한 변동들을 야기할 수 있다.

둘째, 이전에 광고된 윈도우 크기가 철회되지 않는다. 원격 송신자는 이전에 광고된 임의의 윈도우 크기를 완전히 사용하도록 허용되지만, 장래의 윈도우 크기 광고들은 제한될 수 있다. 이것은 이전에 광고된 변화들에 부합하지 않는 원격 송신자에서의 임의의 호환성 문제들을 피하는 데 도움을 줄 수 있다.

셋째, 하드 최소 윈도우 크기(hard minimum window size)가 유지될 수 있다. 일부 시나리오들에서, 이것은 몇 가지 이유들로 적절할 수 있다. 첫째, TCP 스트림의 윈도우 크기가 2 MSS(maximum segment size)보다 낮아지게 되면, TCP 스트림은 지연된 ACK들 및 그에 따른 증가된 지연시간에 봉착할 수 있다. 그에 부가하여, 낮은 처리율로 인한 스트림의 연결의 어느 한쪽 단부에 의한 연결 해제를 피하기 위해 최소 처리율 논리(minimum throughput logic)가 구현될 수 있다. 예를 들어, 처리율이 몇 분 동안 극히 낮으면, 순방향 진행(forward progress)이 행해지고 있더라도, 일부 HTTP(hypertext transfer protocol) 서버들은 HTTP 세션을 연결 해제할 것이다. 이것은 부분적으로는 자원들을 이용되는 채로 두는 것에 의해 달성되는 서비스 거부를 피하기 위한 것이다. 이 최소 처리율을 달성하기 위해, 휴리스틱(heuristic)이 처리율의 이동 평균을 유지하기 위해 사용될 수 있고, 처리율이 명시된 최소 처리율 미만인 동안 네트워크 손상이 디스에이블될 수 있다. 이것은 어떤 이전의 값들로 즉각 복귀하기보다는 윈도우 크기들이 점진적으로 늘어날 수 있게 할 것이다.

본원에 기술되는 실시예들과 관련하여 그리고 앞서 언급한 관련 특허 출원에서 다른 기법들이 또한 사용될 수 있다. 트래픽 조정에 관해, 지연시간 용량(latency capacity)을 해제하는 것(스트림들의 응답성을 증가시키는 것)을 돕기 위해, TCP 확인 응답(ACK)을 송신하기 전에 대기 시간(wait time)을 유입시키는 것에 의해 하위 클래스 스트림들에서 보다 긴 지연들이 유발될 수 있다. 즉, 다른 스트림들에 대한 응답성(지연시간)을 개선시키기 위해 일부 스트림들에 대한 ACK 지연들이 의도적으로 연장될 수 있다. 이와 유사하게, 업스트림 트래픽에 대해, ACK-수신 문턱값(ACK-receive threshold)이 연장될 수 있고, 그로써 ACK들에 대한 타이밍 아웃(timing-out) 이전에 더 긴 대기들을 제공하고 어쩌면 TCP 재전송을 피할 수 있다.

그에 부가하여, 하나 이상의 계층화된 네트워크 요구사항들의 매니페스트(manifest)를 노출시키는 것에 의해 애플리케이션 네트워크 사용 계약들이 지원될 수 있다. 예들은, 중앙 제어기가 변하는 네트워크 상태에 따라 상이한 계층들을 통해 (상하로) 스로틀링할 수 있도록, 애플리케이션이 비디오 스트리밍 애플리케이션들에 대해 SD(Standard Definition) 비디오 계층(video tier)에 대한 네트워크 대역폭 및 지연시간 요구사항들(또는 클래스들)과 HD(High Definition) 비디오 계층에 대한 상이한 일단의 대역폭 및 지연시간 요구사항들(또는 클래스들)은 물론, VOIP(voice over Internet Protocol) 통화들에서의 상이한 충실도 레벨들을 갖는 매니페스트를 선언적으로 명시하는 것을 포함한다.

스트림 우선순위 힌트들을 광대역 공급자들에게 노출시키는 것이 또한 가능할 수 있다. 공급자들은 애플리케이션 트래픽이 보다 긴 지연들을 허용하면 보다 낮은 비용을 제안하기 위해 힌트들을 사용할 수 있고, 이와 달리 적절하게 표시(mark)되어 있는 트래픽은 신속 처리(fast track)할 수 있다.

마지막으로, (스트림 클래스별) 네트워크 트래픽 우선순위가 전력 관리를 위해 사용될 수 있다. 하위 우선순위 트래픽은 전력을 절감하기 위해 지연/드롭될 수 있다. 즉, 트래픽이 지연된 전송을 하도록 스케줄링될 수 있고, 이는 배터리 전력이 절감될 수 있게 할 것이다. 예를 들어, 스트림 관리자는 구체적으로는 특정의 스트림의 연결을 위한 무선부에 대한 전력을 유지할 필요가 없거나 무선부에 전력을 제공하기 시작할 필요가 있다고 전력 관리 모듈에 통보할 수 있다.

네트워크 스트림 분류 모델들 및 그의 구현들

이하에서 논의되는 실시예들은 애플리케이션들이 네트워크 스택 또는 운영 체제로의 그들의 네트워크 스트림들을 분류할 수 있게 하는 것 - 네트워크 스택 또는 운영 체제는 차례로 네트워크 스트림들의 분류들에 따라 시스템 전체에 걸쳐 디바이스의 네트워크 자원들의 공유를 오케스트레이션(orchestrate)함 - 에 관한 것이다. 논의는 시스템 개요 및 시스템이 애플리케이션들의 네트워크 거동을 어떻게 조정할 것인지를 애플리케이션들이 어떻게 선택할 수 있는지의 설명으로 시작할 것이다. 네트워크 스트림 분류 모델들의 예들 및 이들을 구현하는 것에 대한 상세들이 그 다음에 기술될 것이다.

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

운영 체제(1102)는, 공지된 기능들 중에서도 특히, 각자의 네트워크 인터페이스들(1112)로 패킷들을 전달하고 그들로부터 패킷들을 수신하는 하나 이상의 인터페이스 드라이버들(1110)(디바이스 드라이버들)을 포함할 수 있다. 애플리케이션들(1106)이 사용자 공간에서 실행되고 본원에 기술되는 운영 체제(1102) 및 네트워킹 특징들이 커널 공간에서 실행되는 것으로 가정될 수 있다. 그렇지만, 이것이 요구사항은 아니다. 커널 모드 코드 또는 사용자 모드 코드는 네트워크 분류들을 그에 의해 제어되는 네트워크 스트림들에 할당할 수 있고, 스트림 관리자(1114)는 커널 공간 또는 사용자 공간에서 실행될 수 있다. 일 실시예에서, 네트워크 스트림 관리는 공지된 TCP/IP 네트워크 스택과 패킷들을 교환하는 사용자 모드 래퍼에 의해 구현될 수 있다.

스트림 관리자(1114)는 애플리케이션들(1106)에 대한 네트워크 스트림들(1116)을 관리하고 조정한다. 네트워크 스트림들(1116)(이후부터 "스트림들"이라고 지칭됨)은 컴퓨팅 디바이스(1100)와 원격 디바이스들(1109) 사이의 각자의 네트워크 연결들(예컨대, IP 5 튜플들)에 대응하는 운영 체제 객체들이다. 전형적으로, 각각의 스트림은 FIFO 버퍼와 스트림에 대해 동작들을 수행할 때 스트림을 식별하기 위해 운영 체제 및 스트림의 애플리케이션에 의해 사용되는 기술자(descriptor) 또는 핸들(handle)을 갖는다. 네트워크 스택(1104)은 스트림들(1116)을 위해서 전송 프로토콜을 구현하는 전송 계층 모듈(예컨대, TCP 모듈)을 제공할 수 있다. 운영 체제(1102)는 애플리케이션들(1106)이, 스트림 객체를 인스턴스화하는 것, 스트림 파라미터들을 설정하는 것, 스트림과의 네트워크 연결을 개시하는 것, 스트림을 닫는 것, 연결될 네트워크 주소, 사용될 원격 및 로컬 포트, 사용될 프로토콜, 네트워킹 파라미터들 등과 같은 스트림의 속성들의 값들을 가져오는 것 및 설정하는 것과 같은, 스트림 관련 동작들을 수행하기 위해 사용하는 API(application programming interface)(1118)를 제공한다. Winsock API, Berkeley 소켓들 API, 및 다른 유사한 API들 모두가, 본원에 기술되는 바와 같이 확장되거나 수정될 때, API(1118)로서 사용하는 데 적당하다.

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

단계(1142)에서, 애플리케이션은 스트림 클래스 또는 카테고리(이후부터 "클래스"라고 함)를 구체적으로는 스트림에 할당하기 위해 API(1118)를 사용한다. 애플리케이션은 애플리케이션의 스트림들의 다른 스트림들에 다른 클래스들을 할당할 수 있다. 단계(1142)는, 스트림이 인스턴스화될 때, 스트림에 대한 네트워크 연결이 형성되기 전에, 스트림이 연결되고 아마도 트래픽을 전달하고 있는 후에, 스트림이 트래픽을 전달하고 있는 때 등을 비롯하여, 스트림의 수명 동안 언제라도 수행될 수 있다. 더욱이, 단계(1142)는 스트림에 현재 할당되어 있는 클래스를 변경하기 위해 동일한 스트림에 대해 반복하여 수행될 수 있고, 따라서 다음에 논의되는 바와 같이, 그에 대응하여 스트림 관리자(1114)가 스트림을 통한 패킷들의 흐름을 어떻게 조정하는지를 변경한다.

단계(1144)에서, 운영 체제, 구체적으로는, 스트림 관리자(1114)는 네트워크 스트림에 의한 네트워크 자원 사용을 제어한다. 스트림 관리자(1114)는 운영 체제에 의해 관리되고 있는 다수의(아마도 모든) 스트림들의 네트워크 거동을 오케스트레이션하는 중앙 코디네이터(central coordinator)로서 기능한다. 스트림 관리자(1114)는 스트림들의 실제 네트워크 성능을 추적하고 그들의 거동을, 상세하게는 지연시간 및 대역폭(처리율) 성능과 관련하여, 그리고 아마도 상이한 크기 시간 윈도우들에 걸친 평균 처리율을 조정할 수 있다. 스트림 관리자(1114)는 또한 네트워크 상태에 관한 신호들을, 예를 들어, 프로브 패킷(probe packet)들의 RTT(return trip time)들을 분석하는 것에 의해, 스트림들의 네트워크 경로들을 따라 있는 다양한 디바이스들의 큐 크기(queue size)들에 관한 정보를 수신하는 것에 의해, 기타에 의해 수신할 수 있다. 주목할 만한 점은, 스트림 관리자(1114)가 각각의 스트림에 대한 최근의 그리고/또는 현재 대역폭, 지연시간, 또는 둘 다를 결정할 수 있어야만 한다는 것이다. 일 실시예에서, 모든 스트림들이 명시적 애플리케이션-할당 클래스(explicit application-assigned class)를 갖는 것은 아니다. 그렇지만, 스트림 관리자(1114)는 또한 이 스트림들을, 어쩌면 그들을 디폴트 클래스를 가지는 것으로 취급하는 것에 의해, 관리할 수 있다. 일 실시예에서, 스트림 관리자(1114)는 별개의 모듈 또는 컴포넌트가 아니라, 오히려 운영 체제(1102) 및/또는 네트워크 스택(1104) 전체에 걸쳐 분산되어 있는 논리이다(용어 "스트림 관리자"는, 본 명세서에서 사용되는 바와 같이, 양 설계를 지칭한다). 환언하면, 스트림 관리 논리의 배치는 중요하지 않다.

도 9는 스트림 분류 모델(1180A)의 일 예를 나타내고 있다. 도 9는 또한 스트림에 클래스를 할당하는 코드(1182)의 한 샘플을 나타내고 있다. 분류 모델(1180A)은 8개의 클래스들을 가지며, 4개는 대역폭에 대한 것이고 4개는 지연시간에 대한 것이다. 이 예시적인 분류 모델(1180A)에서, 2개의 클래스들이 동일한 스트림에 할당될 수 있고; 하나의 클래스는 대역폭에 대한 것이고 하나의 클래스는 지연시간에 대한 것이다. 샘플 코드(1182)에서 보는 바와 같이, "높은" 대역폭 및 "낮은" 지연시간 클래스들은 "socket_s"로 표현된 스트림에 할당된다. 다른 실시예들에서, 도 9에 도시된 바와 같이, 분류 모델(1180A)은 대역폭 클래스들만, 또는 지연시간 클래스들만, 또는 양 성능 차원(performance dimension)을 가지는 개별 클래스들을 가질 수 있다. 도 10은 각자의 네트워크 성능 카테고리들을 갖는 예시적인 스트림들(1190)을 나타내고 있다. 스트림들(1190)은 API(1118)를 통해 할당되는 바와 같은 식별자들 및 클래스들(1192)을 가질 수 있다. 일 실시예에서, 각자의 스트림들의 분류들은 운영 체제(1102)가 스트림들을 표현하기 위해 사용하는 각자의 데이터 구조들 또는 객체들의 플래그들 또는 속성들이다.

도 11은 분류 모델(1180A)의 다른 예를 나타내고 있다. 분류 모델(1180A)은 6개의 클래스들(A 내지 F): 실시간(realtime) 클래스, 응답적(responsive)(상호작용적(interactive)) 클래스, 스트리밍(streaming) 클래스, 일반(normal) 클래스, 우발적(eventual) 클래스, 및 비가시(invisible) 클래스를 갖는다. 이 분류 모델(1180A)은 개발자들에게 편리할 수 있는데, 그 이유는 개별 클래스들이 통상적인 유형들의 네트워크 소비 애플리케이션들에 밀접하게 대응하기 때문이다. 각각의 클래스는, 스트림 관리자(1114)의 논리에 구현되는 바와 같이, 네트워크 성능의 하나 이상의 차원들에서, 각자의 성능 범위들, 하한(floor)들, 상한(ceiling)들 등을 가질 수 있다. 예를 들어, 클래스들은 다음과 같이(MBS(megabits per second)의 단위로 된 대역폭, 밀리초(ms)의 단위로 된 지연시간) 구현될 수 있다:

실시간: 1 MBS, 200 ms,

응답적: 0.1 MBS, 50 ms,

스트리밍: 3 MBS, 1500 ms,

일반(normal): 0.2 MBS, 5000ms, 및

우발적, 비가시(invisible): 0 MBS, 0 ms.

이 숫자들은 예들에 불과하고; 임의의 값들이 사용될 수 있으며, 일부 클래스들은 대역폭 및/또는 지연시간 규격을 갖지 않을 수 있다.

스트림 관리자(1114)는, 요구가 스트림들 간의 충돌을 야기할 때, 스트림들의 성능 목표들이, 그들의 클래스들별로, 어떻게 달성되어야 하는지에 대한 정책들 또는 규칙들(1202)을 구현하는 제어 논리(1200)(도 12)를 가질 수 있다. 예를 들어, 스트리밍-클래스 스트림들이 그들의 한계에 있거나 그 근방에 있을 때, 그들의 클래스들에 따라 다른 스트림들을 스로틀링하는 것에 의해 대역폭이 이용가능하게 되도록, 규칙들(1202)은 대역폭에 대한 우선순위(precedence)를 명시할 수 있다. 예를 들어, 카테고리-A 스트림이 네트워킹 자원들을 필요로 할 때, 비가시 스트림들이 먼저 스로틀링되고, 이어서 우발적 스트림들이 스로틀링되며, 이어서 일반 스트림들이 스로틀링되고, 이어서 응답적 스트림들이 스로틀링될 수 있다. 클래스들은 또한 스로틀링될 대역폭(또는 지연시간)의 상대적 부분들을 명시하기 위해 각자의 가중치들을 가질 수 있고, 따라서 상위 우선순위 클래스에 있는 스트림이 저 우선순위 스트림들로부터 해제된 큰 부분의 대역폭 및 중간 우선순위 스트림들로부터 해제된 작은 부분의 대역폭을 획득할 수 있게 한다. 다른 실시예에서, 네트워크 자원들의 사용이 스트림들의 클래스들에 따라 우선순위가 부여되거나 배분된다. 응답적 스트림이 부가의 대역폭을 필요로 하는 경우, 그 대역폭이, 대역폭을 할애해줄 수 있는 어느 스트림들로부터라도 그들의 성능규격들 내에 남아 있는 동안, 아마도 최저 우선순위 클래스 스트림들로부터 시작하여, (예를 들어, 스로틀링에 의해) 얻어질 수 있다. 요약하면, 스트림들의 클래스들에 따라 스트림들에 의한 네트워크 자원 소비의 총체적 관리가 광범위한 알고리즘들, 규칙들/우선순위들, 성능 값들 등에 의해 구현될 수 있다.

애플리케이션에 의해 명시된 클래스(application-specified class)들에 따라 스트림들의 중앙집중식 전역적 관리의 잠재적인 이점은 사용자의 경험이 개선될 수 있다는 것이다. 예를 들어, 사용자의 디바이스가 "스트리밍"으로서 분류된 네트워크 스트림에 대해 멀티미디어 스트리밍 애플리케이션을 실행하고 있다고 가정하자. 또한 사용자가 웹 브라우저 애플리케이션 - 그의 HTTP 브라우징 스트림들을 "응답적"으로서 분류하고 그의 다운로드 스트림들을 "일반"으로 분류함 - 을 시작한다고 가정하자. 사용자가 웹 페이지를 요청할 때, 대응하는 응답적-클래스 스트림이 스트리밍-클래스 스트림보다 더 높은 지연시간 우선순위를 갖기 때문에, 응답적-클래스 스트림이 그의 지연시간 요구사항을 충족시킬 수 있게 하기 위해 스트리밍-클래스 스트림이 일시적으로 (예컨대, 50 ms 동안) 스로틀링될 수 있다. 스트리밍-클래스 스트림의 잠시동안의 속도 저하(slowdown)는 (버퍼링으로 인해) 사용자가 알아채지 못할 가능성이 있을 것이고, 웹 페이지가 빠르게 다운로드될 것이다. 사용자가 파일 다운로드를 개시하면, 대역폭이 스트리밍-클래스 스트림의 대역폭 하한에 도달될 때까지, 스트리밍-클래스 스트림으로부터 "차용(borrow)"될 수 있고, 따라서 일반-클래스 스트림이 스트리밍-클래스 스트림으로부터의 미디어의 재생을 방해함이 없이 그의 대역폭을 최대화하는 방식으로 계속될 수 있게 한다.

도 12는 스트림 관리자(1114)의 상세도를 나타내고 있다. 스트림들(1190) 각각은 패킷들이, 대응하는 네트워크 인터페이스에 의한 전송을 위해 디바이스 드라이버로 전달되기 전에 또는 디바이스 드라이버로부터 수신된 후에, 큐잉되는 각자의 큐(1240)를 갖는다. 제어 논리(1200)는 앞서 기술된 바와 같이 스트림들(1190)의 네트워크 성능을 관리한다. 제어 논리(1200)는 대역폭 및 지연시간에 관한 업데이트들을 반복하여 수신할 수 있다. 업데이트들은 인터페이스 드라이버들(1110), 네트워크 스택(1104), 또는 외부 소스들로부터 올 수 있다. 이러한 업데이트들은, 컴퓨팅 디바이스(1100)에 대한 또는 개개의 네트워크 인터페이스들(1112)에 대한 현재 대역폭 이용가능성, 현재 또는 예상된 지연시간 정보, 네트워크 혼잡 등과 같은, 각종의 네트워크 상태들 및 통계들을 표시할 수 있다. 제어 논리(1200)는 네트워크 자원들이 스트림들에 의해 어떻게 소비되는지를 조정하기 위해 이 정보를 사용할 수 있다.

도 13은 제어 논리(1200)가 스트림들을 관리할 수 있는 예시적인 프로세스를 나타내고 있다. 규칙적인 간격으로, 스트림 관리자(1114)는, 단계(1260)에서, 활성 스트림들("스트림"은, 이 단락에서, 현재 반복의 스트림을 지칭함)에 걸쳐 반복하기 시작할 수 있다. 단계(1262)에서, 스트림의 현재 성능 통계들이 획득된다. 예를 들어, 현재 또는 추정된 대역폭 및 지연시간이 획득된다. 이 정보는, 큐잉된 패킷들의 양, 들어오는 패킷들의 레이트, 및 다른 공지된 기법들에 기초하여, 현재 트래픽 통계들에 따라 예상되는, 최근의 처리율로부터 추정될 수 있다. 스트림의 클래스는 그것이 얼마나 자주 반복적으로 평가되는지에 영향을 미칠 수 있다.

단계(1264)에서, 스트림 관리자(1114)는 스트림의 클래스 또는 카테고리를 결정하고, 스트림이 그의 명시된 카테고리에 따라 작동되고 있는지(또는 그럴 것으로 예상되는지)를 결정한다. 단계(1266)에서, 스트림이 명시된 대로 작동되고 있지 않으면, 스트림 관리자(1114)는 스트림의 클래스 규격들을 충족시키도록 의도된 적응들(adaptations)을 구현한다. 예를 들어, 다른 스트림들이, 그들의 클래스들을 고려하여, 스로틀링되고, 일시 중지되며, 기타일 수 있다. 이것은 스트림들의 수신 윈도우들 및/또는 송신 윈도우들을 조절하는 것, 스트림 버퍼들을 확장 또는 축소시키는 것, 스트림을 통한 패킷 흐름을 일시 중지시키는 것 등에 의해 달성될 수 있다. 애플리케이션들 또는 다른 컴포넌트들이 패킷들에 태깅할 필요가 없고, 애플리케이션들이 프로토콜-레벨 QoS 특징들을 사용할 필요가 없다. 애플리케이션의 관점에서 볼 때, 스트림들은 평범한 TCP(또는 유사한) 스트림들이다. 단계(1268)에서, 다음 스트림이, 있는 경우, 처리된다.

스트림들이 그들의 각자의 클래스들의 규격들에 따라 작동되고 있지 않다는 본원에서의 언급과 관련하여, 성능 부합의 결정들 또는 성능 조절들을 주도하는 결정들이 호스트 머신 상에서의 다른 연결들에 대한 단순한 성능 이상의 것을 포괄하는 것으로서 이해되어야만 한다. 예를 들어, LEDBAT 프로토콜과 같은 프로토콜들은, 스트림의 네트워크 연결이, 그 연결이 경험했던 최저 단방향 지연보다, 100 ms 더 높은 단방향 지연들을 경험하고 있는 경우, 스트림을 명시된 대로 작동되고 있지 않는 것으로 간주한다. 가정은 LEDBAT 연결이 증가된 지연을 야기하는 인자일 수 있다는 것이고, 그 연결의 윈도우들을 제한하는 것은 동일한 공유된 네트워크 자원들을 거쳐 가는 다른 연결들에 대한 지연을 감소시킬 수 있다. 달리 말하면, 스트림 클래스들의 규격들이 서로에 대해 상대적일 수 있거나, 성능 값들에 대해 절대적일 수 있거나, 이 둘의 조합일 수 있다. 그에 부가하여, 복잡한 규격들, 예를 들어, 부울 연산자들의 구문(syntax), 조건문들 등을, 어쩌면 마크업 기반(예컨대, 확장가능 마크업 파일들) 선언적 언어의 형태로 표현하기 위해 정식 언어 또는 구문이 제공될 수 있다. 또는, 이러한 복잡한 논리가 스트림 관리자, 네트워크 스택 등의 프로그래밍 내에 "하드코딩"될 수 있다.

도 14는 스트림 분류 모델(1180C)의 다른 예를 나타내고 있다. 각각의 카테고리는 지연시간 성분 및 대기시간 성분을 갖는다. 카테고리들이 어느 한 차원을 따라서 중복될 수 있다. 이 예에서, 스트림의 분류는 대역폭 및 지연시간 성능 목표 둘 다를 스트림에 할당한다. 하나의 클래스, 예를 들어, 클래스-E가 대응하는 스트림들에 실시간 또는 빠른 응답성에 대응하는 지연시간 규격을 부여하도록 의도되어 있다고 가정되면(즉, 네트워크 트래픽이 사용자 요청에 응답하여 최소 겉보기 지연(minimal apparent delay)으로 흐르기 시작할 것임), 스트림 관리자 논리는, 클래스-D 스트림들과 같은, 다른 스트림들(또는 모든 다른 스트림들, 또는 모든 다른 활성 스트림들, 기타)을 "백오프 또는 하향 조정(down-regulate)"하기 위해 로컬 운영 체제의 다양한 네트워크에 영향을 미치는 메커니즘(network-affecting mechanism)들을 사용할 수 있다. 즉, 지연시간에 민감한 것으로서 분류되는 새로운 연결 또는 새로운 트래픽이 시작될 때, 저 우선순위 연결들이 즉각 로컬적으로 손상될 수 있다. 예를 들어, 사용자에 의해 개시된 웹 브라우저가 웹 객체들을 요청하려는 중인 경우, 앞으로 있을 브라우저 트래픽들이 클린 네트워크(clean network)로 시작되도록 백그라운드 파일 전송들이 선제적으로 손상될 수 있다. 종래의 접근법들은 새로운 트래픽에 대해 보통은 즉각 도움이 되지 않는 경쟁하는 트래픽에 기초하여 행해지는 서비스 품질 결정들에 종종 의존한다. 유사한 접근법이 대역폭 성능을 위해 또는 네트워크 성능 특성들의 조합들을 위해 사용될 수 있다. 유의할 점은, 애플리케이션들로부터 그들의 네트워크 연결들로의 데이터의 흐름을 일시 중지시키는 것, 버퍼링된 패킷들의 전송을 일시 중지시키는 것, 네트워킹 윈도우 크기들을 조절하는 것, 스트림 트래픽을 핸들링하는 스레드들을 보류하거나 다운그레이드(downgrade)하는 것에 의해, 또는 스트림에 의한 네트워크 자원들의 소비에 어쩌면 영향을 미칠 수 있는 스트림의 다른 동작 파라미터들을 조절하는 것에 의해, 로컬 트래픽 손상이 달성될 수 있다는 것이다.

도 15는 총체적 스트림 관리의 일 실시예에 대한 프로세스를 나타내고 있다. 이 실시예에서, 스트림 관리자(1114)는 다음과 같이 네트워크 자원들의 재할당을 실시할 수 있다. 단계(1280)에서, 대상 스트림이, 그의 클래스에 따라, 부가의 네트워크 자원들, 예를 들어, 대상 스트림 또는 지연시간 또는 둘 다를 필요로 한다고 결정된다. 설명적 예를 위해, 분류 모델(1180A)의 클래스-A 스트림이 부가의 대역폭을 필요로 하는 것으로 가정될 것이다. 단계(1282)에서, 각각의 클래스의 스트림들에 대해 집계 통계(aggregate statistics)가 취득된다. 단계(1284)에서, 그 집계 통계가 클래스에 적절한 순서로(in class-appropriate order) 평가되고, 단계(1286)에서, 그들이 필요에 따라 조절된다. 네트워크 요구에 따라 최저 우선순위 클래스의 스트림들, 즉 클래스-E가 먼저 평가된다. 클래스-E 스트림들의 총 대역폭이, 전체로서, 여분의 대역폭을 가지면, 부가의 대역폭을 제공하기 위해 클래스-E 스트림들이 스로틀링된다. 클래스-E 스트림들이 넘겨주기에 불충분한 대역폭을 가지면, 다음 우선순위 클래스 - 클래스-C - 의 집계 통계가 평가된다. 즉, 클래스-E 스트림들을 스로틀링하는 것이 충분한 대역폭을 해제하지 못했으면, 클래스-C 스트림들의 총 대역폭이 평가되고 그 클래스에 있는 스트림들이 필요에 따라 스로틀링된다. 클래스-C 및 클래스-E 스트림들 둘 다가 그들의 클래스 요구사항들을 만족시키면서 충분한 대역폭을 넘겨줄 수 없다면, 하위 우선순위 클래스의 스트림들 - 클래스-E - 은, 상위 우선순위 클래스-A 스트림의 대역폭 요구사항을 충족시키는 데 도움을 주기 위해, 그들의 클래스의 대역폭 목표들 미만으로 밀려날 수 있다.

이상의 예에서의 스트림이, 부가된 대역폭 대신에 또는 그에 부가하여, 개선된 지연시간을 필요로 하면, 유사한 프로세스가 수행되지만, 각각의 클래스의 집계 통계의 평가, 그리고 그 클래스 내의 스트림들에 대한 임의의 조절들이 클래스들의 지연시간 특성들에 의존하는 순서로 수행된다.

본 설명이 여러 곳들에서 네트워크 자원들을 할당 또는 재할당되는 것으로 언급할 수 있지만, 자원들의 "할당"은 스트림 클래스들의 규격들을 충족시키려고 시도하기 위해 (앞서 기술된) 각종의 네트워크에 영향을 미치는 메커니즘들 중 임의의 것을 사용하는 것의 부수 효과의 개념적 특성화이다. 더욱이, 스트림 클래스들에 기초하여 취해지는 우선순위 부여 또는 스트림 조정 조치들이 대응하는 스트림들에 의한 네트워크 자원들의 소비의 즉각적인 증가 또는 감소를 꼭 포함하지는 않을 수 있다. 예를 들어, (스트림 클래스들을 제공하기 위해 수정될 수 있는) LEDBAT 프로토콜과 같은 프로토콜들이, LEDBAT가 저 우선순위 연결이 "제한"될 필요가 있는 것으로 결정했을 때, 저 우선순위 연결의 대역폭 또는 지연시간에 꼭 해를 끼치는 것은 아닐 수 있다. 예를 들어, 연결의 송신 윈도우의 크기를 감소시키는 것이 그의 처리율 또는 지연시간에 즉각적인 영향을 미치지 않을 수 있고; 많은 가능한 이유들로 인해, 연결이 차후에 더 나은 처리율 또는 지연시간을 가질 수 있다.

도 16은 앞서 기술된 실시예들이 구현될 수 있는 범용 컴퓨팅 디바이스(1100)의 부가 상세들을 나타내고 있다. 컴퓨팅 디바이스(1100)는 디스플레이(1300)는 물론 저장소(1302) 및 처리 하드웨어(1304) - 임의의 하나 이상의 중앙 처리 유닛들, 그래픽 처리 유닛들, 아날로그-디지털 변환기들, 버스 칩들, FPGA(Field-programmable Gate Array)들, ASIC(Application-specific Integrated Circuit)들, ASSP(Application-specific Standard Product)들, 또는 CPLD(Complex Programmable Logic Device)들 등의 조합일 수 있음 - 를 가질 수 있다. 저장소(1302)는 자기 저장소, 정적 메모리, 휘발성 메모리 등의 임의의 조합일 수 있다. 용어 "저장소"의 의미는, 본원에서 사용되는 바와 같이, 신호들 또는 에너지 자체를 지칭하지 않고, 오히려 (신호들 자체가 아니라 자기 저장 매체, 광학 저장 매체, 정적 메모리 디바이스 등과 같은 물리적 매체를 포함하는) 물리적 장치들을 지칭한다. 컴퓨팅 디바이스(1100)의 하드웨어 요소들은 컴퓨팅 기술 분야에서 잘 이해되는 방식들로 협력할 수 있다. 그에 부가하여, 입력 디바이스들(1306)은 컴퓨팅 디바이스(1100)와 통합되거나 그와 통신할 수 있다. 컴퓨팅 디바이스(1100)는 임의의 폼 팩터를 가질 수 있거나, 임의의 유형의 포괄하는 디바이스(encompassing device)에서 사용될 수 있다. 컴퓨팅 디바이스(1100)는 스마트폰, 태블릿 컴퓨터, 게임 디바이스, 서버, 랙 장착형(rack-mounted) 또는 백플레인형(backplaned) 컴퓨터 온 보드(computer-on-a-board), 시스템 온 칩(System-on-a-chip), 또는 다른 것들과 같은, 핸드헬드 디바이스의 형태로 되어 있을 수 있다. 일반적으로, 컴퓨팅 디바이스(1100)는 개별 네트워크 노드 또는 디바이스일 것이다.

앞서 논의된 실시예들 및 특징들은 휘발성 또는 비휘발성 컴퓨터 또는 디바이스 판독가능 장치들에 저장된 정보의 형태로 실현될 수 있고, 이러한 정보는 본원에 기술되는 실시예들을 수행하도록 컴퓨팅 디바이스(1100)를 구성할 수 있다. 이 장치들은, 광학 저장소(예컨대, CD-ROM(compact-disk read-only memory)), 자기 매체, 홀로그래픽 저장소, 플래시 ROM(read-only memory), 또는 디지털 정보를 저장하기 위한 다른 디바이스들과 같은, 장치들을 포함할 수 있다. 저장된 정보는 컴퓨팅 디바이스들을 본원에 기술되는 실시예들을 수행하도록 구성하거나 컴퓨팅 디바이스들이 본원에 기술되는 실시예들을 수행할 수 있게 하는 데 사용될 수 있는 머신 실행가능 명령어들(예컨대, 컴파일된 실행가능 이진 코드), 소스 코드, 바이트코드, 또는 다른 정보의 형태로 되어 있을 수 있다. 이것은 또한 일 실시예를 수행하는 소프트웨어의 실행 동안 CPU(central processing unit) 명령어들과 같은 정보를 저장하는 RAM(random access memory) 및/또는 가상 메모리와 같은 휘발성 메모리는 물론, 프로그램 또는 실행 파일(executable)이 로딩되고 실행될 수 있게 하는 정보를 저장하는 비휘발성 디바이스들을 적어도 포함하는 것으로 생각될 수 있다.

Claims

저장소, 처리 하드웨어, 및 네트워크 인터페이스를 포함하는 단일 컴퓨터에 의해 수행되는 방법에 있어서,
컴퓨팅 디바이스 상에 설치된 애플리케이션을 실행하는 단계 - 상기 애플리케이션은 상기 컴퓨터 상에 설치된 실행 파일(executable files) 및 상기 컴퓨터 상에 저장된 구성 설정(configuration settings)을 포함하고, 상기 애플리케이션은 상기 컴퓨터의 운영 체제에 의해 관리되는 각자의 네트워크 스트림을 가짐 - ;
각각 상기 애플리케이션의 제1 특징(feature)을 자동으로 결정하는 단계 및 각각 상기 애플리케이션의 제2 특징을 자동으로 결정하는 단계 중 적어도 하나의 단계 - 상기 결정하는 단계는 상기 컴퓨터 상에서 실행되는 애플리케이션 프로파일러(application profiler)에 의해 수행되고, 상기 제1 특징을 자동으로 결정하는 단계는 상기 애플리케이션 프로파일러가 상기 실행 파일 및 상기 구성 설정 중의 적어도 하나를 파싱하는 단계를 포함하고, 상기 제2 특징을 자동으로 결정하는 단계는 상기 애플리케이션 프로파일러가 상기 애플리케이션의 실행을 모니터링하는 단계를 포함하고, 각자의 애플리케이션의 각각에 대하여 제1 및 제2 특징 중의 적어도 하나가 결정됨 - ;
상기 저장소 내의 매핑에 액세스하는 단계 - 상기 매핑은 미리 정의된 애플리케이션 특징 및 상기 컴퓨터의 운영 체제에 의해 구현되는 네트워크 스트림 클래스들의 표식(indicia)을 포함하고, 상기 매핑은 상기 미리 정의된 애플리케이션 특징 중의 어느 것이 상기 네트워크 스트림 클래스 중의 어느 것과 연관되는지 표시하며, 상기 매핑은 상기 제1 및 제2 특징 중의 적어도 하나를 결정하는 단계 전에 저장되고, 상기 미리 정의된 애플리케이션 특징은 상기 제1 및 제2 특징 중의 적어도 하나의 적어도 일부를 포함함 - ;
상기 애플리케이션의 각각에 대하여, 상기 애플리케이션 프로파일러에 의해 결정된 각자의 제1 및 제2 특징 중의 적어도 하나 중의 어느 것이 상기 매핑에서 상기 미리 정의된 애플리케이션 특징 중의 어느 것과 매칭되는지 결정하고, 상기 매핑이 표시하는 어느 네트워크 스트림 클래스가 각자 매칭된 미리 정의된 애플리케이션 특징과 연관되는지에 기초하여 상기 애플리케이션의 각각에 대한 네트워크 스트림 클래스를 선택하는 단계;
상기 네트워크 스트림 클래스의 어느 것이 각자의 애플리케이션에 대하여 선택되었는지 표시하는 애플리케이션 분류 정보를 저장하는 단계; 및
상기 컴퓨팅 디바이스의 운영 체제에 의해, 상기 네트워크 인터페이스에 의해 상기 스트림의 패킷의 전송을 조정하는(regulating) 단계 - 각각의 스트림의 조정은, 상기 애플리케이션 분류 정보가 표시하는 어느 네트워크 스트림 클래스가 대응 애플리케이션에 대하여 선택되었는지에 따라 수행됨 -
를 포함하는, 단일 컴퓨터에 의해 수행되는 방법.
제1항에 있어서,
상기 조정하는 단계는, 주어진 네트워크 스트림 클래스와 연관된 주어진 네트워크 스트림에 대하여, 대역폭의 측정치, 대응 대역폭을 갖는 상기 주어진 네트워크 스트림의 지연(latency) 성능, 및 상기 주어진 네트워크 스트림 클래스의 지연 사양, 중의 적어도 하나를 비교하는 것에 의해 수행되는 것인, 단일 컴퓨터에 의해 수행되는 방법.
제1항에 있어서,
상기 제1 특징은, 상기 애플리케이션 프로파일러에 의해, 상기 애플리케이션에 의해 참조되는 것으로 결정된 상기 운영 체제의 컴포넌트들을 포함하는 것인, 단일 컴퓨터에 의해 수행되는 방법.
제1항에 있어서,
상기 제2 특징은 상기 애플리케이션의 실행 동안 그리고 상기 애플리케이션의 실행의 결과로서 생기는 애플리케이션의 특징을 포함하는 것인, 단일 컴퓨터에 의해 수행되는 방법.
제1항에 있어서, 상기 매핑의 미리 정의된 애플리케이션 특징은, 상기 네트워크 스트림 클래스 중의 어느 것이 애플리케이션의 식별된 특징과 가장 잘 매칭되는지 결정하는데 사용되는 각자의 가중치를 갖는 것인, 단일 컴퓨터에 의해 수행되는 방법.
제1항에 있어서,
상기 제1 및 제2 특징 중의 적어도 하나를 자동으로 결정하는 단계는, 상기 분류 정보로부터, 애플리케이션이 상기 매핑에 포함되는 어떠한 네트워크 스트림 클래스와도 아직 연관되어 있지 않다고 결정한 것에 응답하여, 상기 애플리케이션에 대해 수행되는 것인, 단일 컴퓨터에 의해 수행되는 방법.
제6항에 있어서,
상기 애플리케이션 프로파일러에 의해 결정된 상기 애플리케이션의 특징을 사용하여 상기 애플리케이션에 대한 네트워크 스트림 클래스를 자동으로 선택하는 단계, 및 상기 애플리케이션과 그에 대하여 선택된 네트워크 스트림 클래스 간의 연관을 표시하도록 상기 분류 정보를 업데이트하는 단계를 더 포함하는, 단일 컴퓨터에 의해 수행되는 방법.
제7항에 있어서,
상기 애플리케이션과 상기 선택된 네트워크 스트림 클래스 간의 표시된 연관에 기초하여 상기 애플리케이션의 스트림이 상기 네트워크 스트림 클래스를 갖는다는 표시를 저장하는 단계를 더 포함하는, 단일 컴퓨터에 의해 수행되는 방법.
컴퓨팅 디바이스에 있어서,
상기 컴퓨팅 디바이스가 동작 중일 때 프로세서가 운영 체제를 실행할 수 있게 하는 정보를 저장한 저장 하드웨어;
네트워크 인터페이스;
상기 컴퓨팅 디바이스가 동작 중일 때 상기 운영 체제를 실행하도록 메모리와 결합된 상기 프로세서; 및
상기 운영 체제를 포함하고,
상기 운영 체제는 실행 중일 때, 상기 컴퓨팅 디바이스 상에 설치되며 상기 운영 체제에 의해 실행되는 애플리케이션과 네트워크 사이에 전송 제어 프로토콜(TCP; transmission control protocol) 패킷을 제공하는 네트워크 스트림을 관리하는 스트림 관리자를 포함하며, 상기 스트림 관리자는 스트림 클래스의 미리 정의된 세트를 구현하고, 각각의 네트워크 스트림은 상기 스트림 클래스와 상기 스트림 간의 연관에 기초하여 상기 스트림 클래스 중의 하나와 연관되고,
상기 저장 하드웨어는,
(i) 애플리케이션의 구성 설정 및 실행 파일 중의 적어도 하나를 파싱함으로써 상기 애플리케이션의 제1 애플리케이션 특징을 결정하고, 또는 (ii) 상기 애플리케이션의 실행을 모니터링함으로써 상기 애플리케이션의 제2 애플리케이션 특징을 결정하는, 애플리케이션 프로파일링 코드를 실행하는 것;
미리 정의된 애플리케이션 특징과 상기 스트림 클래스 간의 연관을 포함하는 매핑에 액세스하는 것 - 상기 매핑은 어느 미리 정의된 애플리케이션 특징이 어느 스트림 클래스와 연관되는지 표시하며, 상기 매핑은 상기 스트림 클래스와 상기 네트워크 스트림 간의 연관을 형성하기 전에 존재함 - ;
상기 애플리케이션 프로파일링 코드에 의해 결정된 상기 애플리케이션의 제1 및 제2 애플리케이션 특징 중의 적어도 하나와의 매핑에서 미리 정의된 애플리케이션 특징을 매칭함으로써 상기 애플리케이션의 스트림 클래스와 네트워크 스트림 간의 연관을 형성하고, 상기 매칭된 미리 정의된 애플리케이션 특징과 상기 스트림 클래스 간의 연관을 갖는 매핑에 기초하여 상기 스트림 클래스를 선택하는 것;
상기 스트림 클래스와 상기 네트워크 스트림 간의 연관을 저장하는 것; 및
상기 운영 체제에 의해, 상기 네트워크 인터페이스에 의한 상기 네트워크 스트림의 전송을 조정하는 것 - 상기 조정하는 것은 상기 스트림 클래스와 상기 네트워크 스트림 간의 저장된 연관에 기초하여 수행됨 -
에 의해, 상기 애플리케이션의 스트림 클래스와 네트워크 스트림 간의 연관을 형성하도록 구성된 명령어를 저장한 것인, 컴퓨팅 디바이스.
제9항에 있어서,
상기 스트림 관리자는, 상기 컴퓨팅 디바이스의 네트워크 조건이 변했다는 결정에 응답하여 그에 가입한 애플리케이션에 대한 업데이트를 제공하는 이벤트 게시 서비스(event publication service)를 제공하고, 상기 네트워크 조건의 표식은 상기 네트워크 스트림의 거동을 조정하도록 상기 스트림 관리자에 의해 사용되는 것인, 컴퓨팅 디바이스.
제9항에 있어서,
상기 네트워크 스트림과 연관된 스트림 클래스에 따라 라디오의 전원공급을 제어하는 상기 운영 체제의 전력 관리 모듈을 더 포함하는, 컴퓨팅 디바이스.
제9항에 있어서,
상기 운영 체제는 상기 네트워크 스트림과 각자 연관된 스트림 클래스에 따라 상기 네트워크 스트림에서의 지연을 유도하고, 상기 유도하는 것은, 전송 제어 프로토콜(TCP; transmission control protocol) 재전송을 피하도록 TCP 확인응답을 인위적으로 지연시키는 것 및 수신-확인응답 문턱치를 연장하는 것 중의 적어도 하나를 포함하며, 상기 수신-확인응답 문턱치는 재전송 요청이 발행되기 이전까지의 기간을 포함하는 것인, 컴퓨팅 디바이스.
제9항에 있어서,
상기 네트워크 스트림과 상기 스트림 클래스 간의 연관은, 어느 애플리케이션이 상기 스트림 클래스 중의 어느 것과 연관되는지 표시하는 애플리케이션-클래스 연관 정보에 기초하는 것인, 컴퓨팅 디바이스.
컴퓨팅 디바이스가 프로세스를 수행할 수 있게 하도록 구성된 정보를 저장하는 컴퓨터 판독가능 저장 디바이스에 있어서,
상기 프로세스는,
상기 컴퓨팅 디바이스 상에 설치된 애플리케이션을 저장하는 것 - 상기 애플리케이션은 저장 하드웨어에 의해 저장된 실행 파일 및 구성 설정을 포함함 - ;
각각의 애플리케이션에 대하여, (i) 각자의 대응 애플리케이션의 실행 파일 및 대응 구성 설정 중의 적어도 하나를 파싱함으로써 제1 특징을 결정하고, 또는 (ii) 각자의 대응 애플리케이션의 실행을 모니터링함으로써 제2 특징을 결정하는, 애플리케이션 프로파일러를 실행함으로써, 각자의 제1 및 제2 애플리케이션 특징 중의 적어도 하나를 자동으로 결정하는 것 - 상기 각자의 애플리케이션 각각에 대하여 제1 및 제2 애플리케이션 특징 중의 적어도 하나가 결정됨 - ;
각자의 애플리케이션의 각각에 대하여 상기 제1 및 제2 애플리케이션 특징 중의 적어도 하나를 자동으로 결정하기 전에, 상기 저장 하드웨어에 의해 저장되어 있는 특징-클래스 매핑에 액세스하는 것 - 상기 특징-클래스 매핑은, 미리 정의된 애플리케이션 특징의 제1 표식 및 네트워크 애플리케이션 클래스의 제2 표식을 포함하고, 상기 특징-클래스 매핑은 상기 애플리케이션 특징 중의 어느 것이 상기 네트워크 애플리케이션 클래스 중의 어느 것과 연관되는지를 표시하며, 상기 미리 정의된 애플리케이션 특징은 상기 제1 및 제2 애플리케이션 특징 중의 적어도 하나의 적어도 일부를 포함함 - ;
상기 애플리케이션의 각각에 대하여, 상기 각자의 대응 제1 및 제2 애플리케이션 특징 중의 적어도 하나 중의 어느 것이 상기 특징-클래스 매핑의 미리 정의된 애플리케이션 특징 중의 어느 것에 대응하는지 결정하는 것;
상기 애플리케이션의 각각에 대하여, 상기 각자의 대응 애플리케이션의 상기 제1 및 제2 애플리케이션 특징 중의 적어도 하나에 대응하도록 결정된 상기 미리 정의된 애플리케이션 특징과 연관되어 있는, 상기 특징-클래스 매핑이 표시하는 네트워크 애플리케이션 클래스를 선택하는 것;
각각 상기 네트워크 애플리케이션 클래스 중의 어느 것이 상기 애플리케이션에 대하여 선택되었는지 표시하는 애플리케이션 분류 정보를 저장하는 것; 및
상기 컴퓨팅 디바이스의 운영 체제에 의해, 네트워크 인터페이스에 의한 상기 애플리케이션의 스트림의 패킷의 전송을 조정하는 것 - 각각의 스트림의 조정은, 상기 애플리케이션 분류 정보가 표시하는 어느 네트워크 애플리케이션 클래스가 상기 각자의 대응 애플리케이션에 대하여 선택되었는지에 따라 수행됨 -
을 포함하는 것인, 컴퓨터 판독가능 저장 디바이스.
제14항에 있어서, 상기 제1 또는 제2 특징 중의 적어도 하나는, 상기 애플리케이션과 연관된 프로세스 이름, 상기 애플리케이션에 링크된 라이브러리, 상기 애플리케이션의 백그라운드 실행 상태, 상기 애플리케이션과 연관된 포트 번호, 상기 애플리케이션에 의해 사용된 프로토콜, 및 상기 애플리케이션의 API(application programming interface) 호출 중의 적어도 하나를 포함하는 것인, 컴퓨터 판독가능 저장 디바이스.
제14항에 있어서, 상기 프로세스는, 각각 상기 미리 정의된 애플리케이션 특징의 가중치에 따라 애플리케이션에 대한 점수를 계산하는 것을 더 포함하는 것인, 컴퓨터 판독가능 저장 디바이스.
제14항에 있어서, 상기 조정하는 것은, 상기 컴퓨팅 디바이스가 상기 스트림들 상의 서비스 품질(Quality of Service) 마킹을 수행하는 일 없이, 수행되는 것인, 컴퓨터 판독가능 저장 디바이스.
제14항에 있어서, 상기 프로세스는, 각각 상기 네트워크 애플리케이션 클래스의 네트워크 성능 파라미터를 저장하는 것, 및 상기 애플리케이션과 연관되어 있는, 상기 애플리케이션 분류 정보가 표시하는 상기 네트워크 애플리케이션 클래스의 성능 파라미터에 따라 애플리케이션의 스트림에 대하여 상기 조정하는 것을 수행하는 것을 더 포함하는 것인, 컴퓨터 판독가능 저장 디바이스.