'Network/Netowrk_link'에 해당되는 글 28건
- 2009.01.18 voip - jitter 정의
- 2009.01.18 MTU란? 1
- 2009.01.18 MTU
- 2009.01.18 802.11e MAC 프로토콜 동작 메커니즘
- 2009.01.18 Back-Off Algorithm in Slotted CSMA/CA
- 2009.01.18 QoS -1-
- 2009.01.18 QoS (6) _ Congestion Avoidance (혼잡 회피)
- 2009.01.18 QoS에서의 혼잡 회피 적용과 이해 (1)
- 2009.01.18 MAC frame
- 2009.01.18 ethereal packet analysis - nateon
* 이 문서에 대한 권한은 저자에게 있습니다.
퍼 가실때는 출처를 표시하여 주시고 메일로 연락을 주십시오. dif001@hamail.net
Jitter는 네트웍 구간에서 Packet의 전송 지연 편차( delay variation) 이다.
참고.2에 나타난 수치들을 기준으로 값을 낸다.
RTP3-RTP4 delay
Local delay(codec delay) : 46744(5843) - 46504(5813) = 240 (codec delay:30ms)
값 240은 30msec으로 환산할 수 있다.
Local delay는 codec처리를 하는 시간으로서 codec의 종류에 따라 다른 일정한 시간을 가진다. 기본적으로 160(20ms) 와 240(30ms) 두가지 값을 가지게 된다.
Capture delay : 20.508 – 20.478 = 0.030 (30ms)
Packet을 수집하고 packet간의 딜레이를 측정한 것이다.
이 값은 msec까지만 측정한 것으로 실측에서는 usec에서의 오차가 있는 것으로 나타났다.
이상의 값으로 측정하였을 때
Network delay
Tn'' = T1'-T1
이상의 식으로 값을 내었을 때 아래와 같다.
RTP3-RTP4 delay
30ms(capture delay) – 30ms(local delay) = 0
RTP4-RTP5 delay
46984 – 46744 = 240 (30ms)
20.540 – 20.508 = 0.032 (32ms)
32ms – 30ms = 2ms
RTP5-RTP6 delay
47224 – 46984 = 240 (30ms)
20.569 – 20.540 = 0.029 (29ms)
29ms – 30ms = -1
Jitter = (RTP4-RTP5) - (RTP3-RTP4)
= |2 – 0| = 2
= (RTP5-RTP6) - (RTP4-RTP5)
= |2 + 1| = 3
= (2+3)/2
= 2.5ms
이상의 네트워크상의 Packet 전송 지연 편차를 구하는 방법이다.
End-To-End delay는 유저간의 전송시간을 측정하는 것이다.
그림에서 나타난 굵은색 부분이 총 one round trip 이다.
프로젝트에서 필요한 부분은 half round trip으로서 이값은 one round trip 값을 2로 나눈 값이다.
구하는 방법은 아래와 같다.
최초 RTCP 전송이 user1에서 user2로 전송될 때의 패킷 (Sender Report)
NTP reference timestamp
NTP second : 00 05 05 77
NTP fraction : f3 00 00 00
이 값은 user1측에서 데이터를 전송할 때의 시간이다.
이 값을 받은 user2는 일정시간(실측시간 5sec) 이 지난후에 RR(Receiver Report)메시지를 전송한다.
LSR (Last Send Report timestamp) : 05 77 f3 00
DLSR (delay since last SR) : 00 03 93 00
LSR은 SR메시지 상의 NTP timestamp의 일정부분을 추출한 값이다.
이 값은 timeval(msec, usec)으로 이루어진 값으로써 이값에서
msec부분의 하위 2byte 와 usec부분의 상위 2바이트를 추출하여 Round-trip값을 구하기 위한 지표값으로 사용한다.
DLSR은 SR메시지를 전달받고 RR메시지를 전송하기까지의 Local Processing Delay를 나타낸다 이 값은 timeval(msec, usec)형태로 이루어 져 있다.
위의 기본지식을 바탕으로 실측데이터를 가지고 End-To-End delay를 측정한다.
1. user1-SR (NTP timestamp)
NTP second : 00 05 05 77
NTP fraction : f3 00 00 00
2. agent-SR 수집 시간(Agent)
20.224(sec)
3. user2-RR-LSR,DLSR
LSR : 05 77 f3 00
DLSR : 00 03 93 00
4. Agent-RR수집시간
23.793(sec)
5. End-To-End delay
23.793-20.224-3.376 (반올림) = 0.193 (one round trip)
0.193/2 = 0.096 == 96ms
[출처] [본문스크랩] voip - jitter 정의|작성자 문수
'Network > Netowrk_link' 카테고리의 다른 글
MTU란? (1) | 2009.01.18 |
---|---|
MTU (0) | 2009.01.18 |
802.11e MAC 프로토콜 동작 메커니즘 (0) | 2009.01.18 |
Back-Off Algorithm in Slotted CSMA/CA (0) | 2009.01.18 |
QoS -1- (0) | 2009.01.18 |
1. 윈도우 [시작]메뉴버튼을 클릭 후 리스트에서 [실행]을 클릭합니다.
2. 실행창이 뜨면 “regedit”를 입력하고 엔터를 눌러 [레지스트리 편집기(registry editor)]를 실행시킵니다
[출처] MTU란?|작성자 ldbina

3. [레지스트리 편집기]에서 다음 항목을 찾아 갑니다.

4. “Interfaces”안의 각각의 숫자로 된 어댑터를 클릭하고 만일 기존에 MaxMTU란 항목이 존재한다면 이 항목을 더블클릭하여 나오는 [값 데이터]란에다 1400을 넣습니다. 그리고 단위는 “10진수”에 채크합니다.
5. 그리고 반드시 재부팅을 하여 값이 정상적으로 인식되게 합니다.
6. 재부팅 후 속도가 느리거나 열리지 않는 인터넷 사이트를 열어봅니다. 이렇게 하여도 열리지 않거나 속도가 늦다 면 다시 위와 같이 실행하여 [값 데이터]의 값을 1450~1400 사이에서 조정하여 가장 최적의 속도를 낼 수 있는 값 을 선택합니다.
'Network > Netowrk_link' 카테고리의 다른 글
voip - jitter 정의 (0) | 2009.01.18 |
---|---|
MTU (0) | 2009.01.18 |
802.11e MAC 프로토콜 동작 메커니즘 (0) | 2009.01.18 |
Back-Off Algorithm in Slotted CSMA/CA (0) | 2009.01.18 |
QoS -1- (0) | 2009.01.18 |
MTU 란 TCP/IP네트웍 등과 같이 패킷 또는 프레임 기반의 네트웍에서 전송될 수 있는 최대 크기의 패킷 또는 프레임을 말합니다. 한번에 전송할 수 있는 최대 전송량(Byte)인 MTU 값은 매체에 따라 달라집니다. 예를 들어 Ethernet 환경이라면 MTU default 값은 1500 이고 FDDI 인 경우 FDDI는 4000 정도 되고, X.25는 576, Gigabit MTU는 9000 정도 등 매체 특성에 따라 한번에 전송량이 결정됩니다.
ADSL에서의 MTU값
ADSL 은 PPPOE와 PPPOA를 사용합니다. 외장형모뎀과 PC Lan 카드를 사용하는 형태는 PPPOE(PPP over Ethernet)라고 합니다. PC에서 만들어진 Ethernet frame 이 ADSL serial 구간을 그냥 통과하지 못하기 때문에 이더넷 Frame 안에 PPP frame을 포함해서 전송하기 때문에 1500 보단 작아야 합니다. 참고로 접속프로그램중 Winpoet은 MTU를 1420으로 설정하고 Ethernet 프로그램은 MTU를 1416 정도로 설정합니다.
<일반적인 Ethernt 에서의 TCP/IP 패킷 >
Ethernet Header IP Header TCP Header Data
< PPPOE 에서의 TCP/IP 패킷 >
Ethernet Header PPPoE Header IP Header TCP Header Data
MTU값 계산
MTU 는 Ethernet Frame을 제외한 IP datagram 의 최대 크기를 의미합니다. 즉 MTU 가 1500 이라고 할 때 IP Header의 크기 20 byte 와 TCP Header의 크기 20byte를 제외하면 실제 사용자 data는 최대 1460까지 하나의 패킷으로 전송될 수 있습니다. Windows 계열에서는 PC의 기본 MTU가 1500으로 설정되어 있습니다. 레지스터리에 특정 값을 적어주지 않으면 자신의 MTU값을 1500으로 설정됩니다. 그러나 Win2000부터 Media의 특성을 인식하여 dynamic하게 MTU를 설정됩니다.
MTU값 조정
Unix, Linux 계열에서는 ifconfig 명령어로 쉽게 변경할 수 있습니다.
ifconfig hme0 mtu 1400
ifconfig eth0 mtu 1300
Windows 계열은 레지스터리를 수정하면 되며 OS 버전에 따라 설정값이 달라집
최대 UDP datagram 크기
이 론적인 IP datagram의 최대 크기는 65535byte이다. 여기서 IP header 20byte, UDP header 8byte를 제외하면, UDP datagram의 최대 크기는 65507byte가 된다. 하지만 Socket API의 버퍼 크기 제한을 통해서 변화될 수 있다. 일반적으로 UDP socket은 8192 byte 이상이다. 또한 Kernel의 구현에 의해 크기가 변화될 수 있다. 일반적으로 UDP 프로그램들은 512 byte이다.
'Network > Netowrk_link' 카테고리의 다른 글
voip - jitter 정의 (0) | 2009.01.18 |
---|---|
MTU란? (1) | 2009.01.18 |
802.11e MAC 프로토콜 동작 메커니즘 (0) | 2009.01.18 |
Back-Off Algorithm in Slotted CSMA/CA (0) | 2009.01.18 |
QoS -1- (0) | 2009.01.18 |
[출처] 802.11e MAC 프로토콜 동작 메커니즘|작성자 미토
IEEE 802.11e는 802.11 MAC의 DCF 전송방식을 근간으로 무선 LAN의 MAC 계층에서 QoS를 지원할 수 있는 EDCA와 HCCA를 정의함으로써 베스트 에포트 서비스 외에도 전송지연에 민감한 트래픽을 전송할 수 있는 새로운 무선 LAN MAC 프로토콜을 제공한다. 이번 호에서는 802.11e MAC 프로토콜의 등장배경이기도 한 기존 무선 LAN MAC 프로토콜의 QoS 지원을 살펴보고, 802.11e MAC의 경쟁 기반 EDCA 프로토콜의 동작 메커니즘을 알아본다. 정승화_한국루슨트테크놀로지스/LWS/책임연구원 기존 802.11 MAC(Medium Access Control)는 무선 LAN QoS(Quality of Service) 지원에 있어 많은 문제점을 안고 있다. 802.11 MAC의 필수 기능인 DCF(Distributed Coordination Function)는 QoS 지원을 위한 어떤 기능도 제공하지 않는다. 따라서 DCF 방식이 사용되는 경우 모든 데이터 트래픽은 전송 큐에 도착하는 순서대로 서비스가 제공되며 베스트 에포트(Best Effort) 방식으로 처리된다. 802.11 PCF의 QoS 제약점 마지막으로, 무선 매체의 점유 시간 또는 폴링된 스테이션의 전송 시간 등이 기존 MAC에서는 예측할 수 없다는 제약점이 있다. PC에 의해 선택된 스테이션은 최대 2304바이트 이내로 임의 크기의 단일 프레임 전송이 허용된다. 그러나 물리 계층의 전송 속도에 따라서 프레임 전송 시간은 상당히 증가할 수 있는데, 예를 들면 802.11b 물리 계층에서는 극한 상황의 경우, 전송 시간이 20ms를 초과할 수도 있다. 이런 현상은 비경쟁 주기의 잔여 시간동안 폴링된 스테이션에게 QoS를 제공하는 것을 어렵게 만든다. QoS를 위한 802.11e MAC ![]() ![]() ·EDCA와 HCCA 802.11e에서는 QoS 단계를 각각 두개의 채널 접근 메커니즘과 스케줄링 정책에 따라 구분한다(표 1). 향후 표준화가 완료되면 802.11e를 지원하는 제품들은 1, 2, 3단계 작업을 진행해야 한다. 1단계와 2 단계는 전체 8가지의 우선 순위를 구현하고 있으며, 이 8가지 우선 순위는 모든 스테이션과 액세스 포인트에 동일하게 적용된다. 가장 높은 우선 순위의 3단계는 전송 트래픽 특성(TSPEC : Traffic Specification)에 따라 스테이션과 액세스 포인트간 설정된 연결에 QoS 패러미터를 제공한다. 여기에서 트래픽 특성은 데이터 프레임 전송을 위해 802.11e MAC이 어떤 방법으로 전송 스케줄링을 최적화할 것인지 알려준다. ·EDCA TXOP와 폴드(polled) TXOP
경쟁 기반 채널 접근 방식(EDCA) ![]() ![]() ·AC를 이용한 트래픽 우선 순위 구현 802.11e MAC에 정의된 4개의 AC별 전송 큐는 하나의 스테이션 내에서 무선 매체 접근을 위해 각각 개별적인 EDCA 경쟁 개체로서 역할을 수행한다(그림 4). 하나의 AC는 자신의 AIFS 값을 가지고 독립된 백오프 카운터를 유지한다. 만약 동시에 백오프를 마친 AC가 하나 이상 존재할 경우에는 AC 간의 충돌은 가상 충돌 처리기(Virtual Collision Handler)에 의해서 조정된다. 가장 높은 우선 순위의 프레임이 먼저 선택돼 스테이션간 경쟁을 위해 전송되며, 다른 AC들은 CW 값을 증가시켜 다시 백오프 카운터를 갱신한다. |
'Network > Netowrk_link' 카테고리의 다른 글
MTU란? (1) | 2009.01.18 |
---|---|
MTU (0) | 2009.01.18 |
Back-Off Algorithm in Slotted CSMA/CA (0) | 2009.01.18 |
QoS -1- (0) | 2009.01.18 |
QoS (6) _ Congestion Avoidance (혼잡 회피) (0) | 2009.01.18 |
Written by windwiser
[본 포스팅의 그림은 본인의 논문중에 하나에 있던 것들임. - 역시나 불펌금지 ㅋㅋ]
무선 통신 기술에서의 기본적인 매체 접근 기법으로 알려진 CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)에서 주요한 부분이라 할 수 있는 것은 소히 백오프 과정이다. 무선 통신 기술에서는 매체가 공기이기 때문에, 패킷의 충돌 즉, collision 현상을 감지(sense)하는 것이 무척이나 어렵다. 이에, 발상을 바꾸어, 충돌을 감지하는 것이 아니라, 확률적으로 충돌을 회피해 보자는 것에서 시작된 것이 백오프 기법이다. 횡단보도를 걷는 상황을 상상해보자. 두 개의 횡단보도가 있고 한쪽에서는 많은 사람들이 정해진 시간(Arrival Rate?, Period)마다 곧잘 건너고 있지만, 한쪽에서는 많은 사람들이 뒤로 물러나기 바쁜 상황이다. 후자를 소히 High Traffic Load Network라 불러도 좋을 것이다. 전자의 경우 후자에 비해, 사람들이 뒤로 물러심!!이 상대적으로 적어도 좋다. 하지만 후자의 경우 이러한 횟수는 많고 빠르게 증가될 것이다. 하지만 여기서 문제가 끝나는 것이 아니라 얼마나 물러서야 하는가? 얼만큼씩 물러서야 하는가?등의 고민이 있게 된다. 아무리 High Traffic이라 하여도, 최소한의 지연을 가지고자 하는 노력은 필요하기 때문이다. 많은 문서들의 설명을 가만히 보고 있으면 IEEE 802.11 무선랜에서의 CSMA/CA에 대해서 주로 설명하고 있는데, 나는 ZIGBEE에서의 CSMA/CA에 기초해 설명해 볼까 한다. 의도한 바에 따라서.
백오프 과정을 이해하는 것에 핵심적인 key는 BP(BackOff Period)와 CW(Contention Window)의 정확한 관계를 이해하는 것에 있다고 자신한다. 무선랜과 zigbee에 관계없이 반드시 프레임을 전송코자 하는 모든 전송 디바이스들은 반드시 랜덤 지연시간을 결정하고 그만큼 wait를 해주게 된다. 이는 다음 식에 따라 결정된다.
Slotted CSMA/CA Algorithm 수행 시에 중요하게 가만하고 있어야 하는 3개의 variable이 존재한다. 그것은 NB, CW, BE이다.
NB : Number of times CSMA/CA Algorithm was required to backoff while attempting to access the channel.
즉, channel을 접근하는 단계에서, backoff에 대해 요구된 CSMA/CA Algorithm의 수행 횟수가 됨.
CW : channel을 access하기 전에, channel이 idle하다고 판단될 때에, number of BPs 즉, Backoff Period의 수를 의미합니다.(Contention Window을 구성하는 단위)
BE : Backoff Exponent는 CCA(Channel Clear Access)를 수행하기 전에, 기다려야 하는 Random delay value를 결정하는 것에 쓰이는 parameter이다. Random delay value는 다음의 range안에서 결정된다.
1. Initialization Step
- NB = 0, CW = 2
- Batterylife Extension이 지원된다면, 2 or macMinBE 값 중에 작은 값으로 지원되지 않는다면, Default로, macMinBE가 선택된다. ( macMinBE의 Default값은 3이다. )
- 마지막으로, 처음 CSMA/CA Algorithm을 수행 시에는 macMinBE를 0으로 두어, Random Delay를 NULL로 만들어 버려, 바로 CCA동작으로 진행하게 된다.
2. 다음으로, 앞서 정해진 BE에 의해 정해진 Random Delay만큼 기다린다.(Timer)
3. 다음으로, channel의 activity를 검사하기 위해서, BP(Backup Period) boundary에서, 한번의 CCA동작을 수행한다. 이때, channel이 IDLE한가 아닌가에 따라 두 가지 방향으로 수행이 진행된다.
4. IDLE하지 않다면, CW를 2로 reset하고, NB++을 수행하고, BE를 BE+1과 aMaxBE값중에 작은 값으로 SET한다. AMaxBE는 default값이 5이다. BE가 증가한다는 것은 IEEE 802.11에서의 DCF Algorithm 에서 처럼, 이것은 훨씬 큰 backoff delay를 가지게 될 확률이 높아짐을 의미한다. 마지막으로 NB 즉, CSMA/CA의 수행횟수가 backoffs의 최대 값으로 define되어 있는 macMaxCSMABackoff=5보다 작은지 보고 작다면, Random delay 동작으로 돌아간다.
5. CCA후에 IDLE하다면, CW=CW-1;을 수행하고, 다시 CCA를 수행하는데, 다시 한번 CCA를 수행한 후, CW가 마침내 0이 되었다면, Frame을 전송한다.
BP가 결정되면 CW가 결정된다. 만약 상대적으로 어떠한 전송 디바이스에 채널 전송의 우선순위를 주고 싶다고 한다면, 초기 BP의 값을 작게 결정해 줌으로써 우선권을 보장해 줄 수 있을 것이다. 하지만 현실적으로 네트워크의 트래픽은 변화무쌍하고 계속적으로 가중될 수 있다. 따라서, 가중되는 트래픽 상황에 따라 BP의 값을 상대적으로 잇점을 줄 수 있다면 어떨까?
앞서 CSMA/CA수행과정을 읽어보면, BP를 결정하는 BE값에 주목하게 된다. 해당 BE값이 동적으로 설정될 수 있다면 주어진 네트워크 트래픽하에서 또한 변화하고 가중되는 트래픽 상황에서도 특정 노드의 전송을 보장할 수 있는 기법이 나오게 된다. 이러한 동적으로 변화는 트래픽에 따른 SLOTTED CSMA/CA의 백오프 파라미터들을 동적으로 설정하게 함으로써, 간단히 특정 노드의 전송을 보장하는 것이 내가 발표한 논문의 핵심 알고리즘이었다. 마지막 그림은 의도적으로 특정 전송 디바이스의 우선순위를 백오프 과정상의 잇점을 통해 어떻게 보장할 수 있는가를 예를 들어 보여주고 있다.
경우 1과 2의 비교를 통해, 실시간 긴급 노드가 백오프 과정상의 매체 접근의 우선권을 가짐을 알 수 있다. 초기 BE가 상대적으로 작기 때문에, 확률적으로 백오프 지연과정에서 작은 BP(경우 1에서는 3)를 얻게 된다. 이는 짧은 백오프 과정을 만들게 되어, 메시지 노드는 CCA 수행 중에 긴급 노드가 매체를 선점함에 따라 다시 백오프 과정을 수행하게 된다. 경우 3은 OffSet의 역할을 보여주고 있다. OffSet이 3으로 설정된 경우에, 3번째 슬롯까지 메시지 노드는 백오프 과정에 돌입하지 못하고 단순히 기다리게 된다. 이때 긴급 데이터 노드는 백오프 과정을 수행하여 매체를 선점할 수 있게 된다.
다음 그림은 본인 논문의 결과중에 하나로 동적으로 변화하는 네트워크 트래픽에 따라 동적으로 변화하는 백오프 과정으로 인해 향상된 긴급 노드의 성능 평가에 해당한다.
경우 A는 최대 의 네트워크 부하에서의 평균 지연시간과 처리율에 해당한다. 이때 비실시간 메시지 데이터 노드의 수를 증가(20->30)시키면, 네트워크의 부하가 가중되게 된다. 경우 B는 증가된 네트워크 부하로 인해, 실시간 긴급 데이터 노드의 높아진 평균 지연시간과 낮아진 처리율을 나타낸다. 이를 보완하기 위해, 하나씩 감소된 BE와 CW를 새로이 백오프 과정에 적용하게 된다. 이를 통해 향상된 결과가 경우 C에 해당한다. 마지막으로 경우 D는 OffSet을 적용하여 경우 C에 비해 더욱 향상된 결과를 나타낸다. 이처럼 네트워크의 가중되는 트래픽에 따라 동적으로 BE, CW, OffSet을 적용케 되면, 증가된 트래픽 상황에서도 실시간 긴급 데이터의 실시간성을 보존할 수 있음을 실험적으로 증명하고 있다.
'Network > Netowrk_link' 카테고리의 다른 글
MTU (0) | 2009.01.18 |
---|---|
802.11e MAC 프로토콜 동작 메커니즘 (0) | 2009.01.18 |
QoS -1- (0) | 2009.01.18 |
QoS (6) _ Congestion Avoidance (혼잡 회피) (0) | 2009.01.18 |
QoS에서의 혼잡 회피 적용과 이해 (1) (0) | 2009.01.18 |
내용을 보시려면 비밀번호를 입력하세요.
내용을 보시려면 비밀번호를 입력하세요.
내용을 보시려면 비밀번호를 입력하세요.
내용을 보시려면 비밀번호를 입력하세요.
내용을 보시려면 비밀번호를 입력하세요.