'Network/Netowrk_transport'에 해당되는 글 23건
- 2009.01.18 ACK
- 2009.01.18 critical unfairness characterized
- 2009.01.18 TCP [출처] TCP|작성자 실짱
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 |