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 |
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 |
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%정도 떨어진다.
'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 |

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 |
- 차례
- 1절. 소개
- 2절. IP (Internet Protocol)
- 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. 단편화된 데이타들
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 |
2.4.2절. 단편화및 재조립
인터넷은 다양한 환경을 가지는 망으로 서로 연결되어 있음으로, 데이타 그램이 목적지로 이동하는 동안 다양한 MTU 크기를 가지는 망을 통과하게 된다. 만약 1500 의 MTU 크기를 가지는 호스트에서 만들어진 데이타 그램이 576 MTU 크기를 가지는 SLIP 를 통과하게 되면 어떻게 될까 ? 1500 의 크기로는 576 크기를 통과할수 없음으로, 576 크기에 맞도록 데이타가 단편화 되게 된다.
IPH : IP Header |
이렇게 단편화 되어서 전송되는 데이타 그램의 경우 목적지에 서로 다른 순서로 도달할수가 있을것이다. 그러므로 단편화 작업을 수행할때, 각각의 단편화된 데이타 그램이 원래의 데이타그램의 어떤 위치에서 단편화 되었는지등의 정보를 넣어둠으로써 최종도착지점에서 단편화된 데이타를 다시 조립할수 있도록 만들어줘야 할것이다. 이러한 작업은 커널의 IP를 담당하는 모듈에서 자동적으로 수행하며, IP 테이블의 Flags 와 Fragment Offset 필드를 수정함으로써 단편화 정보를 유지하게 된다. 여기에는 현재의 데이타 그램의 단편화가 되어있는지 단편화가 되어 있다면, 어떤 데이타그램에서 단편화 된것인지, 몇번째 단편화 데이타 인지, 마지막 단편화 데이타 인지, 원래 데이타 그램에서 offset 은 어느정도가 되는지등의 정보가 들어가게 된다. 최종적으로 목적지에서는 데이타 그램의 Identification 과 Flag, Fragment Offset 을 이용해서 단편화된 데이타를 재조립하게 될것이다.
2.5절. IP 헤더의 예
다음은 IP 헤더의 가장간단한 예로 단편화가 일어나지 않은 데이타 그램의 IP 헤더의 형태이다.
0 1 2 3 |
이번에는 좀더 복잡한 예로, 단편화가 일어난 데이타 그램의 경우이다. 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 |
다음은 두번째 데이타 그램이다.
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 |
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 |
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 |
내용을 보시려면 비밀번호를 입력하세요.