ACK

|
cumulative ACK : 누적 ACK
duplicate ACK : 중복 ACK

'Network > Netowrk_transport' 카테고리의 다른 글

QoS Protocol & Architectures 1  (0) 2009.01.18
IntServ DiffServ  (0) 2009.01.18
diffserv  (0) 2009.01.18
critical unfairness characterized  (0) 2009.01.18
TCP [출처] TCP|작성자 실짱  (0) 2009.01.18
And

critical unfairness characterized

|
We introduce two critical unfairness cases.

In the first case, downstream TCP connections are penalized with respect to upstream ones. This is explained as follows: packets belonging

to multiple downstream TCP connections are buffered inside the Access Point wireless interface. Note that the Access Point does not enjoy a privileged access to WLAN capacity, with

respect to user terminals. Hence, a single station transmitting upstream packets will get the same priority as that of the Access Point which needs to transmit downstream packets

heading towards many stations. Thus, downstream TCP connections suffer because of the arising congestion and corresponding packet losses happening in the download buffer

at the Access Point. These losses in conjunction with TCP congestion control mechanism cause the starvation of downstream connections. This is defined as "critically" unfair.

The second case arises from the interaction of multiple TCP connections in the upstream direction. In this case, the Access Point wireless interface has to transmit TCP ACK packets

traveling downstream towards stations in the WLAN. Also, in this case, we have a bottleneck because the Access Point can not access the medium with a priority higher than other

stations. Hence, the Access Point buffer will be congested leading to severe loss of TCP ACK packets. Due to the cumulative nature of TCP ACKs, few connections will be able

to "survive" and open their window, while the majority of connections will get starved. Note that this situation is not specific of our scenario; it can happen in whatever

environment characterized by heavy losses of ACK packets. This case is also another example of "critical unfairness".

'Network > Netowrk_transport' 카테고리의 다른 글

QoS Protocol & Architectures 1  (0) 2009.01.18
IntServ DiffServ  (0) 2009.01.18
diffserv  (0) 2009.01.18
ACK  (0) 2009.01.18
TCP [출처] TCP|작성자 실짱  (0) 2009.01.18
And

TCP [출처] TCP|작성자 실짱

|

outing : 가는 길을 알려는 것.

forwarding : 경로가 정해져 있고 그길로 보내주는 것.(전화)

* 인터넷은 routing + forwarding


전화는 전송률이 일정하다..

인터넷은 전송률이 일정하지 않고 보장하지 못한다.

* 인터넷 라우터는 패킷 하나하나를 보았을때는 비효율적이지만 전체를 봤을때는 가격비에 효율적이다.


라우터는 자신이 처리할 수 있는 패킷량보다 더 많이 들어오면 버려버린다.


Congestion : 네트웍에 트래픽이 너무 혼잡한 상태..

= Gueueing error


-> Packet loss가 일어나는 경우

1. 라우터의 큐가 넘치는 경우.

2. Checksum 검사를 했을때 데이터 손실이 있다고 판단된 경우 -> Transmission error

3. TTL(time to live)값이 0이 되었을 때(ex, routing loop)

* 위 3가지 문제를 TCP가 해결한다.


TCP가 해야할일 Retransmission(재전송), Reordering(순서정렬), Flow Control(흐름제어)  => Reliable(신뢰성)


IP계층(Network)에서는 패킷이 사라졌는지 확인이 불가능..(IP는 패킷 전송에 최선은 다하지만 보장은 못한다.)

TCP헤더에 Sequence number을 붙여서 패킷이 손실이 되었는지 / 순서되로 받았는지 확인함.

+ Flow control을 함


UDP

TCP가 하는 재전송, 순서정렬, 흐름제어를 해주지 않는다.

- 영상이나 음성 전달시 약간의 Loss는 무시할 수 있다.

- 경로가 하나뿐인경우 패킷순서정렬이 필요없다(LAN)

- 하나의 패킷으로 전송되는 경우에 순서정렬이 필요없다.

TCP는 기본적으로 위에 3가지 기능을 기본적으로 지원하기 때문에 필요가 없다 생각하는 경우 이를 해제 할 수 없다.

그렇기 때문에 UDP를 사용한다.


패킷이 1,2,4,5 순서로 들어왔을때 3번이 손실되었을 확률과 후에 늦게 들어올 확률??

- 뒤에 3개의 패킷이 전송되도록 전송이 안되면 3번 패킷이 에러난걸로 판정하고 재전송 요청..


ACK : 패킷을 정상적으로 받았을 때

NACK : 패킷이 에러가 났을 때..


수신한 패킷마다 ACK를 보낸다면 전송속도가 떨어진다.

* RTT : 패킷을 보냈을때 수신자의 대답이 돌아올때까지 걸리는 총 시간.

* PPS : 초당 처리하는 패킷수.

패킷길이가 길어지면 딜레이가 발생.. -> 패킷을 채울때까지 기달려야 하니깐.

* 음성은 약 10ms단위로 해서 패킷을 만들어 전송한다.

* Window : Ack를 안받고도 한번에 보낼 수 있는 패킷 수 조절..

Flow control 은 네트워크의 상태에 따라 패킷을 많이 보낼지 적게 보낼지 결정..

* dupACK : 1,2까지 전달되고 4,5,6이 전달되면서 3이 손실되었을때 수신자는 3번을 재전송해달라고 요청하는 경우.

* Fast Retransmit


재전송하는 경우

1. Time out : 수신이 완료된 패킷이 적어서 dupAck 조건이 성립안하면...

2 dupAck가 3개이상 뜨는 경우


패킷을 전송할때 첨에는 1부터 시작하여 2제곱승으로 증가한다 (최대 증가값(ssthresh)는 64) : Slow Start

최대값까지 증가후는 1씩 증가하며, 수신측에서 NAck가 왔을때 1/2로 감소한뒤 1씩 증가..


TCP의 속도는 RTT에 반비례한다.

* RTT는 패킷을 전송하고 ACK가 돌아오는데까지 걸리는 시간.


Congestion이 발생했으면 네트워크 상태가 혼잡한 상태..

Congestion이 발생하면 자기 책임이라 생각하고 전송량을 1/2로 줄인다.

-> 따라서 데이터를 전송하는 모든 송신자가 전송량을 1/2로 줄이기 때문에 라우터는 처리할 양이 반으로 줄어들기 때문에 그 사이에

    Congestion 문제를 해결시도하며, 금방 풀 수 있다.


Slow Start parse : 1부터 시작하여 2의 제곱승으로 증가하는 방식

Congestion avoid phase : 전송을 하다가 전송에러 1/2로 감소된 후 다시 1씩 증가하는 방식


TCP의 flow control 방식을 한단어로 AIMD (Additive increase, Muliiplicative Decrease)

- Slow Start 비율이 작기 때문에 보통 AIMD라 부름..


비디오/오디오는 일정한 전송속도 보장이 있는 것이 좋다.

하지만 Tcp에서는 네트워크 상태에 따라서 흐름제어를 하기 때문에 비효율 -> 따라서 버퍼링을 함


TCP에서는 Packet loss가 일어나면 무조건 congestion으로 판단..

-> 그렇다면 패킷 로스가 일어나는 경우는 3가지 경우인데 이를 다 congestion으로 처리를 한다면 TCP의 오동작으로 볼 수 있다.

하지만 통계로 보았을 때 유선에서 실제 Congestion이 일어날 확률이 99%이고 나머지가 1%미만이기 때문에 ...

하지만 무선환경에서는 다르다..오동작률이 20%....


무선에서 패킷전송 속도는 √p 에 반비례한다. (p : average packet loss rate)

유선에 비하여 약 30%정도 떨어진다.

[출처] TCP|작성자 실짱



'Network > Netowrk_transport' 카테고리의 다른 글

QoS Protocol & Architectures 1  (0) 2009.01.18
IntServ DiffServ  (0) 2009.01.18
diffserv  (0) 2009.01.18
ACK  (0) 2009.01.18
critical unfairness characterized  (0) 2009.01.18
And

IP Header 와 IP 서비스의 특징

|
사용자 삽입 이미지

IP 서비스의 특징
Unreliable datagram service
Out of order Datagrams
Duplicates may be received

 
Fragmentation and Reassembly

Fragmentation :

IP datagram이 순서가 지켜지지 않는 원인 중의 하나인데, IP datagram을 라우터 상에서 잘라서 전송하는 경우가 발생한다. 즉 링크 레이어의 페이로드보다 크기가 큰 경우에는 더 작은 TCP segment들로 쪼개서 전송하게 된다. 만일에 하나의 프래그먼트가 유실되면 전체 IP datagram 은 버려진다. 결구 TCP time-out 이 발생하고 전체 TCP segment는 재전송될 것이다.

Reassembly :

이러한 Fragmented 된 segment를 받은 경우 해당 IP header의 flag 정보를 통해서 fragment 되었다는 사실을 알게되고 다시 수신 측에서 reassemble 하게 된다.

fragmentation & reassembly는 g/w 또는 router 가 이러한 작업을 할 수도 있지만 병목현상이 발생할 수 있으므로 미리 해두는 것이 좋다.

'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP (Internet Protocol)  (0) 2009.01.18
And

IP (Internet Protocol)

|

윤 상배

dreamyun@yahoo.co.kr

교정 과정
교정 0.8 2003년 3월 19일 23시
이미지추가

차례
1절. 소개
2절. IP (Internet Protocol)
2.1절. IP 란
2.2절. IP 헤더
2.3절. 경로배정(routing)
2.4절. 데이타 단편화 (fragmentation)
2.4.1절. MTU(Maximum Transmission Unit)
2.4.2절. 단편화및 재조립
2.5절. IP 헤더의 예
3절. 결론

1절. 소개

우리는 그동안 몇번의 기사를 통해서 IP에 대해서 이미 알아보았다. 이번에는 IP에 대한 좀더 자세한 내용을 알아보도록 하겠다.

이문서는 여러분이 TCP/IP 에 대한 기본적인 이해를 하고 있다고 가정할것이다. 이 문서를 읽기전에 TCP/IP 개요, TCP/IP 개요(2), TCP/IP 개요(3) 에 대한 문서를 먼저 읽어서 TCP/IP 에 대한 어느 정도의 이해를 해놓길 바란다.


2절. IP (Internet Protocol)

2.1절. IP 란

IP 는 인터넷으로 연결된 호스트 사이에 bit 데이터 (인터넷 데이타 그램)의 교환을 가능하도록 하기 위해 만들어진 프로토콜이다. IP는 인터넷 환경에서 host 간 데이타 그램의 교환을 목적으로 하므로 host-to-host 프로토콜이라고 불리우기도 한다.

IP는 addressing(주소지정) 과 데이타 그램의 단편화를 통해서 데이타 그램을 교환한다. 일단 보내고자 하는 크기의 데이타가 있다면, IP는 이 데이타를 한꺼번에 보내지 않고, 여러개의 조그만 데이타 그램으로 단편화 (fragmentation) 작업을 수행하게 된다. 그리고 이러한 단편화된 데이타 앞에 목적지로 찾아갈수 있도록 하기 위한 여러가지 정보 들을 채워 넣게 된다 (이것을 IP Header 이라고 한다).

그림 1. 단편화된 데이타들

위의 그림을 보면 하나의 Internet Data 를 보내기 위해서 3개의 조그만 데이타로 쪼개고 이앞에 IP Header 을 붙였음을 알수 있다.

IP 프로토콜은 다음과 같은 몇가지 특징을 가지고 있다.

비신뢰성(unreliable)

IP 는 데이타 그램이 목적지로 전달될 것이라는 것을 보증하지 않는다. IP 데이타 그램은 목적지로 가는 도중 여러가지 원인에 의해서 손실될수도 있는데, IP 헤더에는 이러한 손실을 복구하기 위한 어떠한 장치도 마련되어 있지 않다. 대신에 TCP 에 이러한 데이타 손실을 복구하기 위한 장치를 마련한다.

비연결지향성(connectionless)

호스트와 호스트간에 데이타 그램을 전달하기 위하여서 세션을 개설하지 않는다. 모든 데이타 그램은 각각 독립적으로 전달되게 된다. 받는 호스트에서는 해당 데이타 그램간의 연관성에 대해서 전혀 알지 못한다. 만약 A와 B 데이타가 호스트로 전달되고, A가 첫번째 데이타 B가 두번째 데이타라고 한다면, 받은측에서는 어느 데이타가 첫번째 데이타인지 알지 못한다. 또한 B데이타가 A데이타 보다 먼저 전달될수도 있는데, IP는 이를 교정할수 있는 장치를 가지지 않는다.


2.2절. IP 헤더

이번장에서는 IP 프로토콜의 헤더 포맷에 대해서 알아보도록하겠다.

그림 2. IP 헤더

Version: 4bits

IP 포맷의 버젼을 나타낸다. 현재는 주로 IPv4 가 가장 널리 쓰이며, 차세대 포맷으로 IPv6 가 제안되어서 조금씩 사용범위가 늘어나고 있는 추세이다.

IHL(Internet Header Length): 4bits

IP 헤더의 길이다. 보통은 32bit 크기를 가지는 5개의 열로 이루어진다. 나마지 하나의 열은(Options, Padding)는 옵션사항이다.

Type of Service: 8 bits

인터넷에는 다양한 종류의 데이타 그램이 돌아다닌다. 이중 어떤것은 상대적으로 중요한 데이터 그램이라서 데이타 전송에 있어서 다른 데이타 그램보다 전송에 있어서 우선순위를 두어야 하는 그런경우가 있을것이다. 이럴때 Type of Service 를 이용함으로써, 데이타 그램의 전송에 대한 우선순위 등을 제어할수 있다. 간단한 형태의 QOS(Quality of service) 라고 볼수 있다.

Total Length: 16 bits

IP 헤더와 실제 데이타의 크기를 모두 합친 크기이다.

Identification: 16 bits

보내고자 하는 데이타 그램에 단편화(fragmentation)가 일어났을경우 단편화된 각 데이타 그램을 구분할수 있는 일련의 번호이다. 이 값을 이용해서 이 데이타 그램이 어떤 데이타 그램에서 단편화 된것인지를 알수 있다.

Flags: 3bits

데이타 그램의 단편화에 대한 정보를 알려주기 위해서 사용된다. 첫번째 비트는 예비로 사용되며, 0으로 세팅된다. 두번째 비트와 세번째 비트는 단편화된 데이타그램의 정보를 세팅하기 위해서 사용된다. 두번째 비트가 0으로 세팅되었을경우 단편화된 데이타임을 의미하며, 1일경우 단편화 되지 않은 데이타를 의미한다. 3번째 비트가 0일경우 마지막 단편화 데이타 임을 나타내며, 1일경우에는 단편화된 데이타가 더 있다는것 나타낸다.

표 1. Flags 세팅

0 예비 : 반드시 0
1 (DF) 0 = 단편화되었음, 1 = 단편화되지 않았음
2 (MF) 0 = 마지막 단편화 데이타, 1 = 단편화 데이타 더 있음

     0   1   2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
Fragment Offset: 13bits

데이타그램에 대한 단편화가 일어났을경우 현재 데이타 그램이 원래 데이타 그램의 몇번째 위치부터 단편화가 이루어 졌는지를 나타낸다.

Time To Live: 8bits

TTL 이라고 불리우는 값으로 데이타 그램이 살아있을 시간을 지정한다. 시간 이라고 해서 1시간 2시간 하는 시간이 아닌, 몇개의 라우터를 이동할수 있는지를 명시함으로써 데이타 그램의 생존기간을 명시한다. IP 데이타 그램이 라우터를 경유하게 되면 라우터는 TTL 필드를 조사해서 TTL의 값에 1을 빼준다. 만약 TTL 에 16의 값이 세팅되어 있다면 16번째 라우터를 지날때 TTL 값은 0이 될것이며, 라우터는 이 데이타 그램을 전달하지 않고 drop 시켜버린다. TTL 값을 명시하는 이유는 데이타 그램이 라우터 상에서 무한 순환 하는 사태가 발생할수 있기 때문이다.

Header Checksum: 16bits

Header 정보는 고정된게 아니고 필요에 따라 바뀌게 된다(TTL 과 같은정보). 그러므로 헤더를 체크할수 있는 장치를 필요로 한다.

Source Address: 32bits

데이타그램을 보내는 측의 IP 주소이다.

Destination Address: 32bits

데이타그램을 받는측의 IP 주소이다.

Options: 크기변화

프로그램의 특성에 의해서 특정한 기능을 추가하기 위해서 사용된다. 이 필드는 필수적인 것이 아니다. 데이타 그램에 보안기능을 추가하거나, QOS 와 같은 기능, 혹은 라우팅관련된 부가적인 여러 기능을 추가하기 위해서 사용된다.

Padding: 크기변화

특별한 사용용도는 없다. 단지 32bit 크기를 맞추기 위해서 사용되며, 0으로 세팅된다.


2.3절. 경로배정(routing)

IP 데이타 그램의 목적지까지의 경로 배정은 Destination Address 필드에 세팅되어 있는 IP 주소를 통하여서 이루어진다. 일단 데이타 그램이 보내질 목적지가 LAN 상에 존재하면, 데이타 그램은 곧바로 해당 목적지 호스트로 보내어진다. 그렇지 않을경우 데이타 그램은 설정되어 있는 default gateway(router) 로 보내어진다. 이것은 router 의 ip routing table 에 의해서 목적지까지 경우되어서 최종 호스트로 도착하게 된다. 여기에 대한 내용들은 이미 다른 기사에서 자세히 언급되어 있음으로 이정도에서 끝내도록 하겠다.



2.4절. 데이타 단편화 (fragmentation)

위에서 IP 헤더 필드를 설명하면서 "데이타 단편화" 에 대한 언급을 했었다. 이번장에서는 이러한 데이타 단편화가 일어나는 원인과 어떻게 단편화된 데이타를 재조합 할수 있는지에 대해서 알아보도록 하겠다.


2.4.1절. MTU(Maximum Transmission Unit)

MTU 란 다음 호스트에 한번에 보낼수 있는 데이타 그램의 크기이다. 어쨋든 데이타를 한번에 몽땅 보낼수는 없으므로 호스트에서는 이것을 적당한 크기로 잘라내야 할것이다. 그런데 이 적당한 크기라는게 말그대로 적당한 크기로 망에 따라서 약간씩 그 크기가 다르며, 각 망에서 통신하기에 가장 최적화된 크기의 MTU를 가지고 있다. MTU 사이즈는 헤더를 제외한 data 만의 크기이다.

이러한 MTU 사이즈는 여러번의 테스트를 걸쳐서 각망에 최적화된다라고 생각되는 실험적인 크기로 정해진다. 우리가 보통 사용하는 이더넷 망의 경우 1500, ATM 망의 경우 9600 의 사이즈를 가지며, SLIP 의 경우 576 의 크기를 가진다. 또한 이 값은 망 상태에 따라서 네트웍 관리자에 의해서 임의로 조정될수 있다.

[root@localhost root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:BF:2C:7B:B2
inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:355481 errors:1 dropped:0 overruns:0 frame:0
TX packets:360573 errors:0 dropped:0 overruns:0 carrier:0
collisions:5023
RX bytes:369176288 (352.0 Mb) TX bytes:33374363 (31.8 Mb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:68 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
RX bytes:3400 (3.3 Kb) TX bytes:3400 (3.3 Kb)
이러한 MTU 의 크기는 ifconfig 를 통해서 확인 가능하며, 변경도 가능하다. 위의 ifconfig 정보는 필자의 리눅스박스에서 측정한 크기이다. 필자의 리눅스 박스는 보통의 이더넷카드를 이용하므로 MTU 1500 으로 세팅되어 있다.

2.4.2절. 단편화및 재조립

인터넷은 다양한 환경을 가지는 망으로 서로 연결되어 있음으로, 데이타 그램이 목적지로 이동하는 동안 다양한 MTU 크기를 가지는 망을 통과하게 된다. 만약 1500 의 MTU 크기를 가지는 호스트에서 만들어진 데이타 그램이 576 MTU 크기를 가지는 SLIP 를 통과하게 되면 어떻게 될까 ? 1500 의 크기로는 576 크기를 통과할수 없음으로, 576 크기에 맞도록 데이타가 단편화 되게 된다.

   IPH : IP Header
+-----+------------------------+
| IPH | 1500 |
+-----+------------------------+

+-----+-----+ +-----+-----+ +-----+-----+
| IPH | 576 | | IPH | 576 | | IPH | 348 |
+-----+-----+ +-----+-----+ +-----+-----+
위의 그림처럼 1500 데이타는 2개의 576크기를 가지는 데이타 그램과 348 크기를 가지는 데이타 그램으로 단편화 되게 될것이다. 또한 이 데이타 그램은 단편화 된다고 하더라도, IP 데이타 그램의 특성을 가져야 함으로 각각 IP 헤더를 가지는 완전한 IP 데이타 그램의 형태가 될것이다.

이렇게 단편화 되어서 전송되는 데이타 그램의 경우 목적지에 서로 다른 순서로 도달할수가 있을것이다. 그러므로 단편화 작업을 수행할때, 각각의 단편화된 데이타 그램이 원래의 데이타그램의 어떤 위치에서 단편화 되었는지등의 정보를 넣어둠으로써 최종도착지점에서 단편화된 데이타를 다시 조립할수 있도록 만들어줘야 할것이다. 이러한 작업은 커널의 IP를 담당하는 모듈에서 자동적으로 수행하며, IP 테이블의 Flags 와 Fragment Offset 필드를 수정함으로써 단편화 정보를 유지하게 된다. 여기에는 현재의 데이타 그램의 단편화가 되어있는지 단편화가 되어 있다면, 어떤 데이타그램에서 단편화 된것인지, 몇번째 단편화 데이타 인지, 마지막 단편화 데이타 인지, 원래 데이타 그램에서 offset 은 어느정도가 되는지등의 정보가 들어가게 된다. 최종적으로 목적지에서는 데이타 그램의 Identification 과 Flag, Fragment Offset 을 이용해서 단편화된 데이타를 재조립하게 될것이다.


2.5절. IP 헤더의 예

다음은 IP 헤더의 가장간단한 예로 단편화가 일어나지 않은 데이타 그램의 IP 헤더의 형태이다.

    0                   1                   2                   3  
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
데이타 그램의 총 크기는 168bit 이고, 이중 헤더의 크기가 160bit 데이타의 크기가 8bit 임을 알수 있다. IPv4 버전이며, 단편화가 일어나지 않았(Flg=0)음을 알수 있다.

이번에는 좀더 복잡한 예로, 단편화가 일어난 데이타 그램의 경우이다. MTU 사이즈는 2048 이며, 보내고자 하는데이타의 크기는 2500 이라고 가정하겠다.

이것은 첫번째 데이타 그램이다.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 2208 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 112 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |


| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
데이타 그램의 총크기는 2048 + (32*5) = 2208 이 될것이다. 데이타 그램의 단편화가 이루어졌음으로 Flg = 1 이 세팅된다. 그리고 단편화된 데이타 중 첫번째 데이타 그램이므로 Fragment Offset 는 0이 될것이다.

다음은 두번째 데이타 그램이다.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 612 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 112 |Flg=0| Fragment Offset = 2048 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |


| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identification 이 112 임을 주목하라. 마지막 단편화 데이타 이므로 (더이상 단편화된 데이타가 없음) Flg 가 0으로 세팅되어있다. 이 데이타 그램의 Total Length 는 (32 * 5) + ( 2500 - 2048 ) = 612 가 될것이다. 그리고 이 단편화된 데이타 그램이 원래 데이타 그램에서 단편화된 위치는 2048 이 될것임으로 Fragment Offset 는 2048 이 될것이다.

3절. 결론

이상 IP 프로토콜에 대한 좀더 자세한 내용들을 알아보았습니다. 이러한 내용들에 대한 좀더 자세한 내용을 원한다면 RFC791 와 W. Richard Stevens 의 TCP/IP Illustrated Volume 1 을 참고하기 바랍니다.


'Network > Netowrk_network' 카테고리의 다른 글

실시간 통신 시스템 위한 VoIP 표준 프로토콜 H.323과 ..  (0) 2009.01.18
IPv4 Header  (0) 2009.01.18
VoIP 관련 표준 문서  (0) 2009.01.18
IP헤더  (0) 2009.01.18
IP Header 와 IP 서비스의 특징  (0) 2009.01.18
And

MTU란?

|
Window 2000 / XP
     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
And

MTU

|
MTU(Maximum Transmission Unit)이란?

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
And

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) 방식으로 처리된다.
동일 서비스 지역내 있는 모든 스테이션도 액세스 포인트와 동일한 우선 순위를 가지고 무선 매체에 접근하기 위해 서로 경쟁한다. 네트워크에 참여하는 스테이션의 수가 증가할 때 CSMA/CA 기반의 무선 LAN 환경에서는 스테이션 간의 충돌 확률이 상대적으로 높아지며, 충돌에 의해 빈번히 데이터 프레임의 재전송을 유발시키기도 한다. 이런 상황으로 인해 전체적인 네트워크 성능이 저하될 뿐만 아니라, QoS 지원도 어려워진다.
무엇보다도 DCF는 상이한 사용자의 우선 순위에 따라 전송 프레임을 차별화하지 않으며, 채널 접근 권한을 획득하기 위해 경쟁하는 모든 스테이션에 동등한 확률적 기회만을 부여한다. 그러나 이와 같은 채널 접근 방식은 차별화된 우선 순위의 프레임을 가지고 있는 스테이션에게는 바람직하지 않다.
802.11 MAC의 PCF(Point Coordination Function)는 DCF와는 달리 실시간 트래픽에 대한 서비스를 지원하기 위해 개발됐지만, 현재 QoS를 지원하는데 상당히 많은 문제점을 낳고 있다.


 

802.11 PCF의 QoS 제약점
실제 PCF 기능이 구현돼 상용화된 제품도 거의 전무한 상황이다. 802.11 MAC의 PCF에서 QoS를 지원하는데 있어 제약점으로 지적된 부분을 살펴본다. 
첫 째, PCF 방식에서 액세스 포인트에 위치하는 PC(Point Coordinator)는 폴링을 위해 단순히 라운드 로빈(Round-Robin) 방식에 근간을 둔 스케줄링 알고리즘을 규정하고 있다. 그러나 실제 차별화된 QoS를 요구하는 다양한 트래픽의 종류가 있기 때문에 트래픽에 대한 우선 순위를 부여할 수 없는 라운드 로빈 알고리즘은 이를 지원하는데 충분하지 않다.
둘 째, 만약 수퍼(Super) 프레임의 크기가 작을 경우 경쟁 주기(Contention Period)와 비경쟁 주기(Contention Free Period)의 반복은 상당한 오버헤드를 유발시킬 수 있다. 따라서 PCF가 최소한의 지연을 지원하기 위해서는 수퍼 프레임의 크기가 작을수록 유리하다. 예를 들면, PCF를 이용해 10ms의 지연을 요하는 음성 트래픽을 지원하려면 수퍼 프레임의 크기 역시 10ms 정도가 돼야 할 것이다. 이런 문제점을 해결하기 위해 802.11e MAC는 비경쟁 주기와 경쟁 주기 모두에서 폴링 기반의 채널 접근 방식을 제공한다.
 셋째, 기존의 MAC에서는 비콘(Beacon) 프레임의 전송 또는 수퍼 프레임의 시점이 변경될 수 있다(그림 1). PC는 TBTT(Target Beacon Transmission Time) 다음에 전송해야 하는 비콘 프레임을 준비하며, 매체가 PISF(Point Inter Frame Space) 동안 간격을 뒀다면, 비콘 프레임을 전송한다. 하지만 문제점은 스테이션들이 다가오는 TBTT 안에 프레임 전송을 마칠 수 없음에도 불구하고, 전송을 개시할 수도 있으며, 이로 인해 비콘 프레임 전송이 지연될 수도 있다.
TBTT 이후에 즉시 전송돼야 할 비콘 프레임의 지연은 결국, 비경쟁 주기안에 전송해야 하는 시제한 프레임의 전송을 지연시킨다. 이런 문제점은 비경쟁 주기에서 예측하기 어려운 시간 지연을 초래해 QoS에 심각한 영향을 미친다. 반면에 802.11e MAC 스테이션은 다가오는 TBTT 시간 안에 프레임 전송을 마칠 수 없다면, 비경쟁 주기를 보장하기 위해 새로운 전송을 개시하지 않도록 구현된다.

마지막으로, 무선 매체의 점유 시간 또는 폴링된 스테이션의 전송 시간 등이 기존 MAC에서는 예측할 수 없다는 제약점이 있다. PC에 의해 선택된 스테이션은 최대 2304바이트 이내로 임의 크기의 단일 프레임 전송이 허용된다. 그러나 물리 계층의 전송 속도에 따라서 프레임 전송 시간은 상당히 증가할 수 있는데, 예를 들면 802.11b 물리 계층에서는 극한 상황의 경우, 전송 시간이 20ms를 초과할 수도 있다. 이런 현상은 비경쟁 주기의 잔여 시간동안 폴링된 스테이션에게 QoS를 제공하는 것을 어렵게 만든다.
 이와 같이 802.11 MAC는 높은 수준의 QoS와 실시간 전송이 요구되는 무선 LAN의 다양한 응용 서비스 지원에 많은 제약점을 갖고 있다. 따라서 무선 LAN에서 보다 진보된 QoS를 제공하기 위해서는 기존의 802.11 MAC를 보완한 802.11e MAC의 도입이 필수적이다.

QoS를 위한 802.11e MAC
현재 표준화가 진행되고 있는 802.11e에서는 기존 802.11 MAC 프로토콜 DCF와 PCF를 기반으로 하는 HCF(Hybrid Coordination Function)를 규정하고 있다. HCF는 무선 LAN의 QoS를 향상시키기 위한 새로운 매체 접근 메커니즘을 포함하며, 경쟁 주기와 비경쟁 주기 모두에서 QoS 데이터를 전송할 수 있다. 또한 802.11e에서는 QoS를 지원하는 스테이션과 액세스 포인트를 기존 802.11 스테이션과 액세스 포인트로부터 구분하기 위해 이들을 각각 QoS 스테이션(QSTA : QoS Station)과 QoS 액세스 포인트(QAP : QoS AP)라고 부른다.


·EDCA와 HCCA
HCF는 두개의 동작 모드를 가지는데, 경쟁을 기반으로 하는 EDCA(Enhanced Distributed Channel Access)와 폴링 메커니즘을 이용한 비경쟁 기반의 채널 접근 방식을 사용하는 HCCA(HCF Controlled Channel Access)가 바로 그것이다(그림 2).
EDCA와 HCCA는 액세스 포인트에 위치하는 HC(Hybrid Coordinator)에 의해 제어되며, DCF와 PCF를 사용하는 기존 802.11 MAC와도 호환된다. EDCA는 QoS 지원(Supported QOS) 위해 유선 네트워크의 DiffServ와 유사한 우선 순위 트래픽(Prioritized Traffic)을 제공하는 반면, HCCA는 QoS 보장(Garanteed QoS)을 위해 IntServ와 유사한 패러미터 트래픽(Parameterized Traffic)을 제공하도록 설계됐다.

802.11e에서는 QoS 단계를 각각 두개의 채널 접근 메커니즘과 스케줄링 정책에 따라 구분한다(표 1). 향후 표준화가 완료되면 802.11e를 지원하는 제품들은 1, 2, 3단계 작업을 진행해야 한다. 1단계와 2 단계는 전체 8가지의 우선 순위를 구현하고 있으며, 이 8가지 우선 순위는 모든 스테이션과 액세스 포인트에 동일하게 적용된다. 가장 높은 우선 순위의 3단계는 전송 트래픽 특성(TSPEC : Traffic Specification)에 따라 스테이션과 액세스 포인트간 설정된 연결에 QoS 패러미터를 제공한다. 여기에서 트래픽 특성은 데이터 프레임 전송을 위해 802.11e MAC이 어떤 방법으로 전송 스케줄링을 최적화할 것인지 알려준다.
EDCA 방식은 인프러스트럭처 모드와 애드혹 모드에서 우선 순위 기반의 QoS를 지원하는데 사용된다. 즉, EDCA는 상위 계층으로부터 우선 순위가 상이하게 부여된 프레임에 대해 차별화된 채널 접근 기능을 제공하는 반면 HCCA은 인프러스트럭처 모드에서 패러미터 기반의 QoS를 제공한다.
802.11e MAC는 패러미터 QoS를 제공하기 위해 데이터를 전송하기 이전에 두개의 스테이션간에 트래픽 스트림이라는 가상 연결을 설정한다. 실제 전송될 데이터의 특성과 QoS를 요구하는 패러미터들은 트래픽 스트림을 설정하는 과정에서 상호 절충과 교환 작업을 거친다. 액세스 포인트는 교환된 QoS 패러미터를 근간으로 각각의 스테이션에 무선 대역을 할당하며 폴링 프레임과 다운링크 프레임 전송 등에 대한 프레임 전송 스케쥴링을 한다.


·EDCA TXOP와 폴드(polled) TXOP
802.11e MAC에 새로이 추가된 가장 기본적이고 중요한 개념이 TXOP(Transmission Opportunity)다. TXOP는 특정 스테이션에게 프레임을 전송할 수 있는 일정 시간을 부여하고 이를 보장하기 위해 사용된다. TXOP 획득은 EDCA 경쟁에서 성공하거나 액세스 포인트로부터 QoS CF-Poll 프레임을 받음으로써 가능해지는데, 전자는 EDCA TXOP로 후자는 폴드(polled) TXOP라 불린다.
이와 같이 TXOP라는 새로운 개념을 이용해 임의의 한 스테이션이 프레임을 전송할 수 있도록 일정 시간을 부여하거나 강제적으로 전송 시간을 제한할 수 있다. TXOP의 전송 시작 시간과 최대 전송 시간은 액세스 포인트에 의해 결정되는데, EDCA TXOP의 경우 비콘 프레임에 의해, 폴드 TXOP 경우는 QoS CF-Poll 프레임에 의해 스테이션에 통보된다.
EDCA는 오직 경쟁 주기에서만 사용되는 반면에 HCCA는 이론적으로 경쟁 주기와 비경쟁 주기 모두에서 동작할 수 있다. 그러나 802.11e 표준안은 HCCA의 사용을 경쟁 주기에서만 권고하고 있는데, 이는 CF-Poll와 QoS CF-Poll을 사용하는 폴링 메카니즘의 동시 구현이 복잡하기 때문이다. 멀티캐스트 프레임과 브로드캐스트 프레임은 경쟁 주기 또는 비경쟁 주기 동안 액세스 포인트에 의해 전달되는데, 경쟁 주기에서는 EDCA를, 비경쟁 주기에서는 PCF를 사용한다.

 

경쟁 기반 채널 접근 방식(EDCA)
앞에서 살펴본 바와 같이 경쟁 기반 채널 접근 방식인 EDCA는 기존의 DCF를 강화해 8가지 종류의 사용자 우선 순위를 가지는 프레임에 대해서 차별화된 매체 접근을 허용하고 있다. 상위 계층으로부터 MAC 계층에 도착하는 각 프레임은 특정 사용자 우선 순위 값을 지니게 되며, 각각의 QoS 데이터 프레임 MAC 헤더에는 사용자 우선 순위 값이 실린다.
이들 우선 순위를 포함하는 QoS 데이터 프레임의 전송을 위해 802.11e QoS 스테이션은 4개의 AC(Access Category)를 구현한다. MAC 계층에 도착하는 프레임의 사용자 우선 순위는 서로 대응되는 하나의 AC로 할당된다(표 2). 이 표에 있는 사용자 우선 순위는 IEEE 802.11D 브리지 표준안에 명시돼 있다. 모든 AC는 각각의 전송 큐와 AC 패러미터를 가지는데, AC간 우선 순위의 차이는 서로 다르게 설정된 AC 패러미터 값으로부터 구현된다.
기본적으로 EDCA는 AC에 속한 프레임을 전송하기 위한 경쟁에 있어 DCF가 사용하는 DIFS, CWmin, CWmax 대신에 각각 AIFS[AC], CWmin[AC], CWmax[AC]를 사용한다. AIFS[AC]는 SIFS + AIFS [AC]  슬롯타임에 의해 결정되는데, 여기서 AIFS[AC]는 0보다 큰 정수값이다.
프 레임 전송 도중 스테이션간 충돌이 발생할 경우 새로운 백오프 카운터를 생성하는 EDCA의 백오프 과정은 기존의 DCF와 유사하다. EDCA에 각 AC별로 상이하게 할당되는 'PF(Persistence Factor) ∈ [1,16]' 라는 것을 추가한다. 만약 PF 값이 2인 경우는 DCF와 동일하게 CW(Contention Window) 크기가 지수함수적 증가를 보인다. 최근의 802.11e 드래프트에서는 PF를 기본값인 2로 고정했으며, 백오프 과정에서의 AC별 차별화는 다른 EDCA 패러미터를 사용하도록 했다.


·AC를 이용한 트래픽 우선 순위 구현
EDCA의 채널 접근 방식도 DCF와 유사하다. 단, 각 AC별로 상이한 AIFS(Arbitration Inter Frame Space)와 CW를 유지한다(그림 3). 여기서 AIFS는 PIFS와 DIFS 보다는 큰 값이어야 하는데, 이는 적어도 SIFS 시간보다 크게 설정해 ACK 프레임 등의 전송을 보호하기 위함이다.
EDCA 패러미터 집합으로 일컬어지는 AIFS[AC], CWmin[AC], CWmax[AC] 등의 값은 액세스 포인트에 의해 비콘 프레임에 실려 각 스테이션에 통보될 수 있다. 기본적으로 AIFS[AC]와 CWmin[AC]의 값이 작을수록 높은 우선 순위를 가지며, 이에 따라 채널 접근 지연이 짧아져 주어진 트래픽 환경에서 보다 많은 대역을 사용한다.
이런 EDCA 패러미터들은 다양한 사용자 우선 순위 트래픽에서의 채널 접근을 차별화하기 위해 사용되는 중요한 수단이 되고 있다. 더불어 각 AC별 패러미터를 포함하는 EDCA 패러미터 값의 적절한 설정은 네트워크 성능을 최적화하는 동시에 트래픽의 우선 순위에 의한 전송 효과를 얻게 해준다. 따라서 액세스 포인트는 네트워크에 참여한 모든 스테이션에 공평한 매체 접근 보장을 위해 EDCA 패러미터에 대한 전체적인 관리와 조정 기능 수행이 요구된다.

802.11e MAC에 정의된 4개의 AC별 전송 큐는 하나의 스테이션 내에서 무선 매체 접근을 위해 각각 개별적인 EDCA 경쟁 개체로서 역할을 수행한다(그림 4). 하나의 AC는 자신의 AIFS 값을 가지고 독립된 백오프 카운터를 유지한다. 만약 동시에 백오프를 마친 AC가 하나 이상 존재할 경우에는 AC 간의 충돌은 가상 충돌 처리기(Virtual Collision Handler)에 의해서 조정된다. 가장 높은 우선 순위의 프레임이 먼저 선택돼 스테이션간 경쟁을 위해 전송되며, 다른 AC들은 CW 값을 증가시켜 다시 백오프 카운터를 갱신한다.
 앞에서 언급한 바와 같이 802.11e는 특정 스테이션이 전송을 개시할 때 TXOP에 근거해 전송 시간을 정한다. 802.11e 액세스 포인트는 AIFS[AC], CWmin[AC], CWmax[AC] 등의 EDCA 패러미터와 EDCA TXOP 시간인 TXOP Limit [AC]를 비콘 프레임에 실어서 각 스테이션에 전달한다.
EDCA TXOP Limit 시간 동안에는 ACK와 연속되는 프레임 전송 간에 SIFS 간격으로 여러 개의 프레임을 동시에 전송할 수 있는데, 이와 같이 여러 개의 프레임을 동시에 전송하는 것을 'EDCA TXOP 버스팅(Bursting)'이라 부른다(그림 5).
TXOP Limit 시간 동안 우선 순위를 포함하는 두개의 QoS 데이터 프레임이 전송되는데, 이때 두개의 QoS 데이터 프레임과 ACK 프레임이 액세스 포인트에서 결정된 TXOP Limit 시간 내에 전송됨을 알 수 있다. EDCA TXOP 버스팅은 여러 개의 프레임을 전송할 때 반드시 TXOP Limit를 준수하기 때문에 EDCA TXOP 버스팅에 의해 전체 네트워크의 성능은 영향을 받지 않는다. 따라서 적절한 TXOP Limit 값의 선택은 전체 네트워크 성능을 향상시킬 수 있다.
다음 호에는 비경쟁 기반의 HCCA를 알아보고, 보다 나은 QoS를 제공하기 위해 제안된 802.11e의 각종 선택 기능에 대해 살펴본다.



'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
And

Back-Off Algorithm in Slotted CSMA/CA

|

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를 해주게 된다. 이는 다음 식에 따라 결정된다.

위 식에 의해 결정된 시간은 해당 디바이스가 기다려야만 하는 시간임과 동시에 BP에 해당한다. 후자가 더 중요하다. 말그대로 풀자면 물러서는 주기정도로 해석될 것이지만 이는 그리 간단한 개념은 아니다. 예를 들어, bp가 3으로 결정되었다고 하자. 이것은 기본심볼단위 3개만큼의 시간에 해당하며 이 시간이 반드시 기다려야 하는 랜덤지연시간에 해당한다. 더욱이 이 3이라는 bp값은 cw의 구성 bp수에 해당하게 된다. 즉, 큰 bp는 큰 cw를 만들게 된다. 앞서 식의 랜덤지연시간이 bp이며 이 bp가 3이라 결정되었다면, 하나의 cw를 구성하는 bp가 3이되고  CCA가 2개의 CW를 수행한다고 할 때, 총 6개의 BP가 CCA수행에 필요케 된다. 이러한 일련의 구성의 흐름은 백오프 과정을 이해하는 것에 매우 기초적이고 중요하다.

위 그림은 내가 ICCAS 저널에 실었던 논문의 한 그림이다. 위 그림은 긴급 노드가 백오프 과정상의 차이로 인해 어떻게 일반 노드에 비해 전송의 우선순위를 가질수 있는지를 보여주고 있다. 긴급 노드가 만약, BP가 3이 결정되고 일반 노드가 4가 결정되었다면, 경쟁구간내에서 작은 BP와 작아진 CW에 근거해 긴급 노드의 채널 접근이 먼저 이루어짐에 따라, 일반 노드는 다시 백오프 과정을 수행해야 한다는 것이 그림의 요지이다.

다음 그림은 역시 같은 논문에 사용한 그림으로 무선랜과 지그비의 백오프 기법의 차이를 보다 자세히 보여주고 있다. 여기서의 물리계층은 DSSS라고 가정하고 있다.

위 그림에서 먼저 생각해 보아야 할 것은, 최대 허용가능한 BP의 범위가 작은 센서네트워크 쪽보다 해당 범위가 최대 1023개의 BP값을 가지는 무선랜에서 보다 더 트래픽 적응에 용이하다는 점이다. 언뜻 생각해 보면, 큰 BP는 많은 백오프 지연시간을 만들지 않나 생각할 수 있지만, 네트워크에 가중되는 트래픽이 커질때, 센서네트워크 나아가 지그비에서는 최대 4번의 재전송 시도후에 프레임을 버릴 수 밖에 없다는 것에 문제가 있다. 반면에, 무선랜에서는 큰 CW구성 BP 수에 있어서의 허용 범위를 가지기 때문에 네트워크 트래픽이 계속적으로 가중된다고 할지라도 보다 재전송 여유를 가질 수 있는 것이다.

위 그림은 센서네트워크(IEEE 802.15.4) 나아가 ZIGBEE에서의 SLOTTED CSMACA의 수행 순서도에 해당한다. 아래는 이에 대한 수행절차에 대한 설명이다.

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
And

QoS -1-

| 2009. 1. 18. 17:58
보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.
prev | 1 | ··· | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ··· | 43 | next