rdt 1.0 ->2.0 에러가 생긴다 이를 해결하기 위해 어떤 자료구조를 사용하는가?
rdt1.0과 rdt2.0의 차이
rdt 1.0 패킷 손실이 없다
rdt 2.0
4계층에서 reliability
ACK
negative acknowledgement
ACK 3 해석이 달라진다(positive ack vs negative ack)
SACK
rdt2.0->rdt2.1 넘어가는 이유와 추가적인 자료구조
fatal flaw : 치명적인 오류 뭐가 치명적?
2.0에서 fatal flaw가 있다.
그래서 이제 rdt3.0
ack가 오는데 얼마나 기다려야 할 지 모르면 마냥 기다릴 수 있다.
그러면 프로토콜로서 의미가 없다
rdt3.0에서부터는 time이라는 개념이 들어간다.
rdt2.1은 rdt2.0과 다르게 sender입장에서
data를 보내면 ack가 온다.
receiver입장에서는 ack가 중요하다.
데이터가 가고 안가고 하는 문제
ACK가 무조건 간다고 가정
하지만 안 올 수 있다.
우리는 ACK가 무조건 간다고 가정하고 있다. 하지만 ACK도 날라갈 수 있다.
이를 고려한게 rdt2.1 sequence number를 썼다. TCP NUmber를 0과 1만 두었다.(1비트)
rdt3.0에서는 timer를 둔다. 기다리는 시간에 제한을 두고, timeout이 되면 ACK를 못받은 애들부터 다시 패킷을 보내야 한다.
propagation deleay가 중요해진다
네트워크가 발달하면서 transmission delay는 매우 작아진다.(L/R)
utilization 높이는 방법->pipelining
근데 만약에 에러가 나면 어떡할 것인가?
Go-back-N
parallel하게 보내는 것이 Go-back-N(몇 개 보내느냐)
10개를 보내면 ACK는 1번만 마지막까지 제대로 왔다고 판단을 하면 ACK를 보냄
cumulative ack!!!
1-10까지 보내는데 4에서 에러가 나면
ACK10 -> 앞에 10개는 다 받았다라고 약속을 하려고 했는데,
4가 에러가 나면 복잡해진다
이게 바로 SAC selective acknowledgement
positive ACK
negative ACK
selective를 쓸지 말지와 positive인지 negative인지는 별개의 문제이다.
ACK3은 프로토콜에 따라 의미가 달라질 수 있다.
ack3 일반적인 경우는 3번을 받았든 3개를 받았든 3과관련된 걸 받았다. 이게 positive
negative는 못받았다.
cumulative는 positive에서 얘기를 하면 중간에 못받은게 있으면 받은애 중에서 가장 큰 숫자에 해당하는애
집어서 보내주는게 individual ack 나 이거이거 받았어요
GBN vs Selective Repeat
selective가 더 나아보이지만
하지만 3000개가 된다면 기억할 수 없다.
추가적인 data structure가 필요하다
keep tracking 하기 위한 버퍼가 필요하다
이게 96년도에 TCP에 들어갔다.
그거 없이 해보자 =>GBN
노란색: 보냈는데 ACK가 아직 안왔어
cumulative!
문제가 없을 때 좋다!!
problem
3가지 경우가 있다.
1)보냈는데 가다가 죽는거
receiver는 오는지도 모름!!!!!
RTO Retransmission Time out 재전송하기 위한 타임아웃
RTT를 가지고 RTO를 설정하고 이거를 가지고 congestion control에 활용한다
RTT는 시간에 따라 아주 들쑥날쑥하다! RTT는 가변적
2)ACK가 오다가 죽는 경우
sender는 내가 보냈는데 ACK가 안오니까
sender쪽에서는 timeout이 된다.
내가 보냈는데 보낸게 안갔거나 ACK가 안왔거나
모르니까 똑같은걸 또 보낸다
앞그림과 여기서 달라진다.
앞 그림에서는 pkt1을 결국 receiver가 한번만 받는다. 하지만 이번에는 pkt1을 두번 받는다.
receiver는 discard시킨다. 하지만 ACK는 보낸다.
중복패킷이 detec되면 ack만 하면 되고 위쪽 계층에 보내지 않는다.
sequence number가 같으니까! 중복패킷 알 수 있다.
ack1은 이제서야 받는다.
3) timer고려해서 죽는경우 premature timeout/delayed ACK
ACK가 죽은건 아니고 오고있는데 늦게 오고 있어서 timeout에 걸린다. sender입장에서는 ACK loss와 같은 상홯
하지만 ack가 오기는 한다. ack1이 늦게 왔어. 난 두번보냈는데 앞에거가 늦게 온건지 뒤에 보낸게 온건지 알 수가 없다. sender는 그냥 오면 그냥 다음거 보내면 된다.
premature timeout:
delayed ACK: 오다가 큐잉 딜레이가 걸려 있거나...
32비트 sequence number를 사용하고 있고, 이게 부족해서 이제는 timestamp이용해서 64비트로 버티고 있다.
positive ack를 쓰고 있으니까
resend ack1
time out이 될때까지 sender는 모름
2가 아직 해결이 안됐으니까 2,3,4,5 -->
selective repeat
-----------
MSS: maximum segment size
TCP의 최대 사이즈
3계층에 MTU: Maximum transmission unit: 3계층과 관련된 거지만 L2에서 어떤걸 쓰느냐에 따라 달라진다
MSS는 4계층과 관련
flow control: receiver가 initiate하는 거
Advertised Window
flow control할 떄 사용됨
receiver가 적어둠
그러면 sender로부터 이것 이하인것만 받아들임
TCP는 바이트 단위
Seq는 랜덤하게 ㅎ작은 숫자에 몰려있지 않게 하기 위해서
TCP는 Seq를 42보내면 ACK는 43보낸다. 그냥 약속 42까지 받았다
+1을 해준다
알고리즘 상으로는 앞에것과 다르지 않다.
ARQ