HFSC와 그 사촌에 관한 논문을 읽는 것은 그것을 이해하는 좋은 방법이 아닙니다. HFSC 논문의 주요 목표는 작동 원리를 설명하지 않고 주장에 대한 엄격한 수학적 증거를 제공하는 것입니다. 실제로 HFSC 용지에서만 작동하는 방식을 이해할 수 없으므로 참조하는 용지도 읽어야합니다. 당신이 주장이나 그 증거에 문제가 있다면 논문의 저자에게 연락하는 것이 좋습니다. 그렇지 않으면 그들이 당신의 의견에 관심이있을 것입니다.

HFSC에 대한 자습서를 작성했습니다 . 아래 설명이 명확하지 않은 경우 읽으십시오.

실시간 곡선이 필요합니까? A1, A2, B1, B2가 모두 128 kbit / s 링크 공유라고 가정하면 (둘 중 하나에 대한 실시간 곡선이 없음) 루트에 512 kbit / s가 분배되면 각각이 128 kbit / s를 얻습니다. A와 B는 모두 256 kbit / s입니다). A1과 B1에 128kbit / s의 실시간 곡선을 추가로 제공하는 이유는 무엇입니까? 이것이 무엇에 좋을까요? 이 두 가지에 우선 순위를 부여하려면? 원본 논문에 따르면 곡선을 사용하여 더 높은 우선 순위를 부여 할 수 있습니다 .HFSC가 결국 중요합니다. 두 클래스에 [256kbit / s 20ms 128kbit / s]의 곡선을 제공하면 둘 다 자동으로 A2 및 B2보다 두 배의 우선 순위를 갖습니다 (여전히 평균 128kbit / s 만 얻음).

실시간 곡선과 링크 공유 곡선은 다른 방식으로 평가됩니다. 실시간 곡선은 전체 역사에서 클래스가 수행 한 작업을 고려합니다. 정확한 대역폭 및 대기 시간 할당을 제공하기 위해 그렇게해야합니다. 단점은 대부분의 사람들이 직관적으로 공정하다고 생각하는 것이 아닙니다 . 실시간으로 클래스가 다른 사람이 원치 않을 때 대역폭을 빌리면 나중에 다른 사람이 원할 때 불이익을받습니다. 이는 실시간으로 클래스가 원치 않을 때 이전에 클래스를 사용했기 때문에 오랫동안 대역폭을 확보 할 수 없음을 의미합니다.

링크 공유는 여유 대역폭을 사용하는 클래스에 불이익을주지 않기 때문에 공정합니다. 그러나 이는 강력한 대기 시간 보장을 제공 할 수 없음을 의미합니다.

대기 시간 보장을 제공하는 것과 링크 공유를 분리하는 것이 HFSC가 표에 가져 오는 새로운 것입니다 . 그리고이 논문 은 개막 문장에 대해 다음과 같이 말합니다. 지연된 지연 (우선 순위) 및 대역폭 할당을 통한 실시간 서비스. 그 문장의 핵심어는 분리되어 있습니다. 즉, 사용되지 않은 대역폭을 ls와 공유하는 방법을 말하고 RT에 필요한 실시간 보증 (일명 대기 시간 보장)을 지정해야합니다. 둘은 직교입니다.

실시간 대역폭은 링크 공유 대역폭에 포함됩니까?

예. HFSC 논문에서는 클래스가 백 로그 된 이후 (즉, 패킷 전송 대기 중) 클래스가 전송 한 대역폭을 정의합니다. rt와 ls의 유일한 차이점은 rt는 클래스가 백 로그 될 때마다 rt 기대하고 해당 세트에서 보장 된 최저 대역폭을 계산하는 반면 링크 공유는 클래스가 백 로그 된 마지막 시점에서만 보입니다. 따라서 rt는 ls보다 많은 바이트를 고려하지만 ls가 고려하는 모든 바이트는 rt에서도 고려됩니다.

상한 곡선이 실시간, 링크 공유에만 적용됩니까, 아니면 둘 다에 적용됩니까?

상한은 실시간 조건을 만족시키기 위해 패킷이 전송되는 것을 막지 않습니다. 실시간 조건 하에서 전송 된 패킷은 여전히 ​​상한에 포함되므로, 링크 공유 조건 하에서 전송되는 패킷은 나중에 지연 될 수 있습니다. 이것이 실시간 공유와 링크 공유의 또 다른 차이점입니다.

A2와 B2가 모두 128kbit / s라고 가정하고 A1과 B1이 128kbit / s 링크 공유 만이거나 64kbit / s 실시간 및 128kbit / s 링크 공유이면 차이가 있습니까? 무슨 차이가 있습니까?

그렇습니다. 위에서 설명한대로 실시간을 사용하는 경우 지연 시간이 보장되지만 링크가 공평하게 공유되지 않으며 (특히 클래스에 대역폭이 고갈 될 수 있음) 상한이 적용되지 않습니다. 링크 공유를 사용하면 대기 시간이 보장되지 않지만 링크 공유가 공정한 경우 기아의 위험이 없으며 상한이 적용됩니다. 링크 공유 전에 실시간을 항상 확인하지만 반드시 링크 공유가 무시되는 것은 아닙니다. 패킷이 다르게 계산되기 때문입니다. 히스토리는 실시간으로 고려되므로 패킷이 히스토리에 포함 된 것으로 인해 실시간 보증을 충족 할 필요는 없지만 히스토리 패킷을 무시하므로 링크 공유를 충족시켜야합니다.

수업의 우선 순위를 높이기 위해 별도의 실시간 곡선을 사용한다면 왜 “곡선”이 필요할까요? 실시간이 고정 가치와 링크 공유도 고정 가치가 아닌 이유는 무엇입니까? 왜 두 커브가 다릅니 까? 클래스 당 하나의 속성 만 있기 때문에 원본 논문에서 커브가 필요합니다. 그러나 이제 세 가지 속성 (실시간, 링크 공유 및 상한)이 있는데 각각에 대한 곡선이 여전히 필요합니까? 실시간 및 링크 공유 트래픽에서 곡선 모양 (평균 대역폭이 아니라 기울기)이 다른 이유는 무엇입니까?

실시간 제어 곡선을 사용하면 특정 트래픽 클래스 (예 : VOIP)에 대한 긴 대기 시간을 다른 트래픽 클래스 (예 : 전자 메일)에 대한 지연 시간이 짧게 거래 할 수 있습니다. 실시간 제약 조건에서 전송할 패킷을 결정할 때 HFSC는 먼저 전송을 완료 할 패킷을 선택합니다. 그러나이를 계산하기 위해 링크의 대역폭을 사용하지 않고 실시간 곡선에 의해 할당 된 대역폭을 사용합니다. 따라서 우리가 동일한 길이의 VOIP 및 이메일 패킷을 가지고 있고 VOIP 패킷에 볼록한 곡선이 있으면 이메일의 오목한 곡선보다 10 배 향상되면 첫 번째 이메일 패킷 전에 10 개의 VOIP 패킷이 전송됩니다. 그러나 이것은 버스트 시간에만 발생하며, 이는 몇 패킷 (즉, 밀리 초)을 보내는 데 걸리는 시간입니다. 그 후 VOIP 곡선이 평평 해져야합니다. VOIP는 잠시 후퇴하지 않는 한 미래의 부스트를 얻지 못할 것입니다. 이 모든 것의 최종 결과는 첫 번째 VOIP 패킷 몇 개가 다른 것보다 더 빨리 전송되도록하여 이메일 대기 시간이 길어지면서 이메일 대기 시간이 줄어든다는 것입니다.

앞에서 말했듯이 링크 공유는 기록을 보지 않기 때문에 대기 시간을 보장 할 수 없습니다. VOIP와 같은 실시간 트래픽에는 확실한 보증이 필요합니다. 그러나 평균적으로 링크 공유 볼록 곡선은 트래픽에 대한 대기 시간 향상을 제공합니다. 보장되지 않습니다. 이메일을 통한 웹 트래픽과 같은 대부분의 경우에 좋습니다.

이용 가능한 작은 문서에 따르면 실시간 곡선 값은 내부 클래스 (클래스 A 및 B)에 대해 완전히 무시되며 리프 클래스 (A1, A2, B1, B2)에만 적용됩니다. 이것이 사실이라면 왜 ALTQ HFSC 샘플 구성 (3.3 샘플 구성 검색)이 내부 클래스에 실시간 곡선을 설정하고 내부 클래스의 보장 속도를 설정한다고 주장합니까? 완전히 무의미하지 않습니까? (참고 : pshare는 ALTQ에서 링크 공유 곡선을 설정하고 실시간 곡선을 생성합니다. 샘플 구성 위의 단락에서 확인할 수 있습니다).

설명서가 정확합니다. 계층 구조 (및 내부 노드)는 실시간 계산에 영향을 미치지 않습니다. ALTQ가 왜 그렇게 생각하는지 알 수 없습니다.

일부 자습서에서는 모든 실시간 곡선의 합이 회선 속도의 80 %보다 높지 않을 수 있다고 말하고 다른 자습서에서는 회선 속도의 70 %보다 높지 않아야한다고 말합니다. 어느 것이 옳거나 둘 다 틀릴 수 있습니까?

둘 다 잘못되었습니다. 트래픽의 70 % 또는 80 %에 실시간으로 지정해야하는 지연 시간 요구 사항이있는 경우 실제로는 사용중인 링크로는이를 충족시킬 수 없습니다. 더 빠른 링크가 필요합니다.

트래픽의 80 %를 실시간으로 지정해야하는 유일한 방법은 실시간 우선 순위를 높이는 것입니다. 예, 지연 시간을 보장하기 위해 일부 패킷의 우선 순위를 높이는 데 효과적입니다. 그러나 그것은 밀리 초 동안이어야합니다. 이것이 링크가 대처할 수 있고 레이턴시 보장을 제공 할 수있는 전부입니다.

대기 시간 보장이 필요한 트래픽은 거의 없습니다. VOIP는 하나, NTP는 다른 하나입니다. 나머지는 모두 링크 공유로 수행해야합니다. 웹 속도가 빠르기를 원한다면 대부분의 링크 용량을 할당하여 웹 속도를 높이십시오. 그 점유율 은 장기적으로 보장됩니다. 대기 시간이 짧고 (평균) 링크 공유시 볼록한 곡선이됩니다.

한 튜토리얼은 모든 이론을 잊어 버릴 것이라고 말했다. 실제로 작동하는 방식 (스케줄러 및 대역폭 분포)에 관계없이 다음 “간단한 마인드 모델”에 따라 세 가지 곡선을 상상해보십시오. 실시간은이 클래스가 항상 얻을 수있는 보장 된 대역폭입니다. 링크 공유는이 클래스가 완전히 만족하기를 원하는 대역폭이지만 만족을 보장 할 수는 없습니다. 초과 대역폭이있는 경우 클래스는 만족하는 데 필요한 것보다 더 많은 대역폭을 제공받을 수 있지만 상한값 이상을 사용하지는 않을 것입니다. 이 모든 것이 작동하려면 모든 실시간 대역폭의 합이 회선 속도의 xx %를 초과 할 수 없습니다 (위의 질문 참조, 백분율이 다름). 질문 : 이것이 HSFC에 대해 다소 정확하거나 완전히 오해 되었습니까?

좋은 설명 상한입니다. 링크 공유 설명은 엄격하지만 오해의 소지가 있습니다. 진정한 링크 공유는 실시간처럼 하드 레이턴시 보장을 제공하지는 않지만 CBQ 및 HTB와 같은 경쟁 업체보다 클래스에 대역폭을 할당하는 것이 더 좋습니다. 따라서 링크 공유는 “보증을 제공하지 않습니다”라고 말하면 다른 스케줄러가 제공 할 수있는 표준보다 높은 수준으로 유지됩니다.

실시간 설명은 둘 다 정확하지만 오해의 소지가 있습니다. 이름에서 알 수 있듯이 실시간 목적은 보장 된 대역폭을 제공하지 않는 것입니다. 이는 보장 된 대기 시간을 제공하는 것입니다. 즉, 링크 사용 방법에 따라 나중에 임의의 시간이 아닌 패킷이 지금 전송됩니다. 대부분의 트래픽은 보장 된 대기 시간이 필요하지 않습니다.

즉, 실시간은 완벽한 대기 시간 보장을 제공하지 않습니다. 링크를 링크 공유로 관리하지 않으면 대부분의 사용자는 추가 유연성을 원하며 무료로 제공되지 않습니다. 실시간으로 하나의 MTU 패킷을 보내는 데 걸리는 시간이 지연 될 수 있습니다. (만일 발생하는 경우, 즉시 전송해야하는 짧은 기한이있는 패킷이 제공된 경우 링크를 유휴 상태로 유지하면서 실시간으로 링크를 유휴 상태로 유지하는 것이 MTU 패킷 링크 공유이기 때문입니다. 이는 링크 공유의 또 다른 차이점입니다. 보장을 제공하기 위해 보낼 패킷이 있어도 실시간으로 의도적으로 회선을 유휴 상태로 유지하여 100 % 미만의 링크 사용률을 제공 할 수 있습니다 링크 공유는 항상 100 %의 링크 사용 가능한 용량을 사용합니다. ,

지연 시간이 제한되어 있기 때문에 실시간으로 하드 레이턴시 보장을 제공 할 수있는 이유는 다음과 같습니다. 따라서 1Mbit / sec 링크에서 20ms 대기 시간 보장을 제공하려고하고 링크 공유가 MTU 크기 (1500 바이트) 패킷을 전송하는 경우 해당 패킷 중 하나가 전송하는 데 12ms가 걸린다는 것을 알고 있습니다. 따라서 실시간으로 8ms 대기 시간을 원한다고해도 절대 보장으로 20ms 마감 시간을 충족시킬 수 있습니다.

위의 가정이 실제로 정확한 경우 해당 모델의 우선 순위는 어디에 있습니까? 예를 들어 모든 클래스에는 실시간 대역폭 (보장), 링크 공유 대역폭 (보증되지 않음) 및 상한이있을 수 있지만 일부 클래스는 다른 클래스보다 우선 순위가 더 높습니다. 이 경우 클래스의 실시간 트래픽 중에서도 우선 순위를 정해야합니다. 커브의 기울기로 우선 순위를 정합니까? 그렇다면 어떤 곡선입니까? 실시간 곡선? 링크 공유 곡선? 상한 곡선? 그들 모두? 그들 모두에게 같은 경사를 주거나 다른 경사를 주겠습니까?

우선 순위 모델이 없습니다. 진심으로. 트래픽에 절대 우선 순위를 부여하려면 pfifo를 사용하십시오. 그것이 바로 그런 것입니다. 또한 웹 트래픽에 전자 메일 트래픽보다 절대 우선 순위를 부여하면 웹 트래픽이 링크를 포화시켜 전자 메일 패킷이 전혀 통과되지 않도록 해야 합니다. 그런 다음 모든 이메일 연결이 종료됩니다.

실제로 아무도 그런 종류의 우선 순위를 원하지 않습니다. 그들이 원하는 것은 HFSC가 제공하는 것입니다. 실제로 실시간 트래픽이있는 경우 HFSC가이를 제공합니다. 그러나 그것은 모든 것이 될 것입니다. 나머지는 HFSC를 사용하면 “혼잡 한 링크에서 웹에 90 %를 할당하고 10 %로 전자 메일을 전송하고 이상한 DNS 패킷을 빨리 보내지 만 다른 사람이 저를 DOS에 보내지 못하게하십시오”라고 말할 수 있습니다.

답변