파이프라이닝된 신뢰적인 데이터 전송 프로토콜

프로토콜 rdt3.0 : 비트 오류와 손실이 있는 채널 상에서 신뢰적인 데이터 전송 가능

기능적으로는 정확한 프로토콜이지만 전송 후 대기(stop-and-wait) 프로토콜이기 때문에 성능 좋지 않음.

 

전송 후 대기 방식 예시

호스트1(미국 서부), 호스트2(미국 동부)에 있는 두 종단 호스트의 경우 가정

두 종단 시스템 사이의 광속 왕복 전파 지연(RTT) = 약 30ms

두 호스트는 1Gbps 전송률(R)을 가진 채널로 연결되어 있음

헤더필드와 데이터를 모두 포함하여, 패킷당 1000바이트(8000비트)의 패킷 크기(L)을 가지고 1Gbps 링크로 패킷을 전송하는 데 필요한 시간은 L/R = 8000bit / 10^9bit/sec = 8×10^-6 sec=8 μs (마이크로초)이다.

 

송신자가 t=0에서 데이터를 전송하기 시작한다면 t = L/R = 8μs에서 마지막 비트가 송신측의 채널로 들어간다.

그다음 패킷은 15ms 동안 대륙을 횡단하고, t = RTT/2 + L/R = 15.008에 수신 측으로 마지막 비트가 도착한다.

(ACK 패킷은 매우 작은 크기이므로 전송 시간 무시)

수신자는 데이터 패킷의 마지막 비트가 수신되자마자 ACK 패킷을 송신하기 시작할 수 있다고 가정하자.

송신자 측에서 ACK 패킷은 t = RTT + L/R = 30.008ms 후에 다시 받을 수 있다. 

결국 송신자는 30.008ms 중 0.008ms 동안만 데이터를 전송한 것이다.

송신자의 이용률 utilization = 송신자가 채널을 통해 실제로 분주하게 비트를 전송하는 데만 걸린 시간

U(sender) = (L/R) / (RTT + L/R) = 0.008 / 30.008 = 0.00027

즉, 송신자는 단지 시간의 0.027% 만큼만 바빴다고 볼 수 있다.

송신자는 30.008ms 동안 1000바이트를 송신할 수 있지만, 초당 1Gbps 링크를 가용한다 해도 267kbps의 유효 처리량(effective throughput)을 갖는다.

단지 267kbps 처리량을 갖는 1Gbps 링크는 매우 큰 비용 낭비이다.

이에 송신자와 수신자 사이의 중간 라우터에서 발생하는 처리 지연, 큐잉 지연과 송신자와 수신자에서의 하위 계층 프로토콜 처리 시간까지 고려한다면, 이보다도 더 나쁜 성능이라 볼 수 있다.

 

이에 대한 간단한 해결책은 송신자에게 확인응답을 기다리지 않고 여러 패킷을 전송하도록 허용하는 것이다.

만약 송신자가 확인응답을 기다라지 않고 3개의 패킷을 전송한다면, 송신자의 이용률은 3배가 될 것이다.

많은 전송 중인 송신자-수신자 패킷을 파이프라인에 채워 넣음으로써 나타낼 수 있다. 이러한 기술을 파이프라이닝이라 한다. 파이프라이닝 방식은 신뢰적이 데이터 전송 프로토콜에서 다음과 같은 중요성이 있다.

- 순서 번호의 범위가 커져야 한다. 왜냐하면 각각의 전송 중인 패킷은 유일한 순서 번호를 가져야 하고 전송 중인 확인응답(ACK)이 안 된 여러 패킷들이 있을 수 있기 때문이다.

- 프로토콜의 송신 측과 수신 측은 하나 이상의 패킷을 버퍼링해야 한다. 최소한 송신자는 전송되었으나 확인응답되지 않은 패킷을 버퍼링해야한다. 정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요하다.

- 필요한 순서 번호와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손상 패킷 그리고 상당히 지연된 패킷들에 대해 응답하는 방식에 따라 결정된다. 

 

파이프라인 오류 회복의 기본적인 방법 두가지 => GBN(Go-Back-N, N부터 반복), SR(Selective Repeat, 선택적 반복)

 

1. GBN(Go-Back-N, N부터 반복)

송신자 : 확인응답을 기다리지 않고 여러 패킷을 전송할 수 있다. 단, 확인응답이 안 된 패킷의 최대 허용 수 N보다는 크지 않아야 한다.

 

아래의 그림을 보자. (sender 측 원도우 사이즈 5 가정)

송신자는 윈도우 구간 내에서 패킷을 송신할 수 있다. Go-Back-N에서 N은 이 윈도우 사이즈를 의미한다.

이 window가 순서번호 공간에서 오른쪽으로 slide(이동)하며 동작한다.

 

파란색은 확인 응답을 받은 부분을 의미한다. 

하늘색은 전송은 하였으나 아직 확인 응답이 오지 않은 패킷을 의미한다.

6번(하늘색 패킷)은 확인응답이 안 된 가장 오래된 패킷의 순서 번호이고 이를 base로 정의한다.

 

그리고 전송될  다음 패킷 순서번호는 nextseqnum으로 정의하고 아래의 상황에서는 8번까지 전송한 상황이므로 nextseqnum은 9가 된다.

 

다시 정리해보면 

구간 [0, base -1] 에서 순서번호는 이미 전송되고 확인 응답까지 된 패킷

구간 [base, nextseqnum - 1] 은 송신은 되었지만 아직 확인 응답이 되지 않은 패킷

구간 [nextseqnum , base + N - 1] 은 상위 계층으로부터 데이터가 도착하면 바로 전송될 수 있는 패킷을 의미한다.

 

다시 window 사이즈였던 N의 의미를 생각해보면 전송되었지만 아직 확인 응답이 안된 패킷을 허용할 수 있는 순서 번호의 범위라 할 수 있다.

왜 확인 응답이 안되 패킷의 수를 N으로 제한하였을까? N으로 제한하지 않는 상황이라면 즉, 확인 응답 없이 무한한 패킷을 전송할 수 있다는 의미가 된다. =>즉 흐름 제어와 혼잡제어를 위해 윈도우 사이즈는 N으로 제한된다.

 

흐름 제어
빠른 송신자가 느린 수신자를 데이터로 압도하는 것을 방지
수신자의 처리 속도를 고려하여 작은 윈도우 크기를 적용 가능

혼잡 제어
네트워크에 너무 많은 패킷이 존재하면 패킷 지연과 손실이 발생하여 성능이 저하
송신자는 전체 네트워크 성능을 위해 각 네트워크 요소를 고려해야 함

 

패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함. k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [0, 2^k - 1]임

순서 번호를 포함하는 계산은 modulo 2^k 연산을 이용한다. (크기 2^k의 링처럼 생각해보면, 순서 번호 2^k - 1 다음 번호는 0이 된다)

rdt3.0에서는 1비트의 순서 번호 필드를 가지므로 [0,1]의 순서 번호 범위를 가진 것이다.

 

 

GBN 송신자는 다음과 같은 3가지 타입의 이벤트에 반응해야 한다.

1. 상위로 부터 호출 

rdt_send()가 위로부터 호출되면, 송신자는 우선 window가 가득 찼는지, 즉 N개의 아직 확인 응답이 되지 않은 패킷이 있는지 확인한다. 만약 window가 가득 차 있지 않다면 패킷이 생성되고 송신된다. 그리고 변수들이 적절하게 갱신된다.

window가 가득 차 있다면 (nextseqnum == base + N이라면) 송신자는 데이터를 상위 계층으로 반환한다. (refuse_data(data))

상위 계층은 나중에 다시 rdt_send()를 호출할 것이다. 실제 구현에서는 송신자가 이 데이터를 버퍼링하거나, 오직 window에 여유가 있을 때만 rdt_send()를 호출할 수 있게 동기화메커니즘(ex : 세마포어, 플레그)를 사용할 것이다.

 

if(nextseqnum < base + N) {

        sndpkt[nextseqnum] = make_pkt(nextseqnum, data, checksum)

        udt_send(sndpkt[nextseqnum])

        if(base == nextseqnum)

                start_timer

        nextseqnum++

        }

else

        refuse_data(data)

 

2. ACK의 수신

GBN 프로토콜에서 순서 번호 n을 가진 패킷에 대한 확인응답은 누적 확인응답으로(cumulative acknowledgement)로 인식됨.

누적 확인응답은 수신 측에서 올바르게 수신된 n을 포함하여, n까지의 모든 순서번호를 가진 모든 패킷에 대한 확인 응답이다. 이는 GBN 수신자 측에서 고려 대상이 된다.

 

3. timeout 이벤트

Go-Back-N이라는 프로토콜의 이름은 손실이 있거나 아주 긴 지연된 패킷이 있을 때 송실자 동작을 내포한다.

전송 후 대기(stop-and-wait) 프로토콜에서와 같이, 타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다.

타임아웃 발생 시, 송신자는 이전에 전송되었지만 아직 확인응답이 되지 않은 모든 패킷을 재전송한다.

timeout 

-----------------

start_timer   //단일 타이머

udt_send(sndpkt[base])

udt_send(sndpkt[base+1])

...

udt_send(sndpkt[nextseqnum-1])

 

송신자는 가장 오래된 '전송했지만, 아직 확인 응답이 안 된 패킷' 구간 [base, nextseqnum-1]에 대한 타이머로 생각할 수 있다.

만약 한 ACK가 수신되었지만, '전송했지만, 아직 확인 응답이 되지 않은 패킷'이 존재한다면 타이머는 다시 시작된다. window 구간내 송신된 패킷들이 모두 확인 응답을 받았을 때(base == nextseqnum) 타이머는 멈춘다.

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)

----------------------------------------

base = getacknum(rcvpkt)+1

if(base == nextseqnum)

        stop_timer

else

        start_timer

 

 

이제 GBN 수신자의 행동을 살펴보자.

만약 순서 번호 n을 가진 패킷이 오류없이, 순서대로 수신된다면(즉, 상위 계층에 마지막으로 전달된 데이터가 순서번호 n-1을 가진 패킷에서 온 것이라면), 수신자는 패킷 n에 대한 ACK를 송신하고 상위 계층에 패킷의 데이터 부분을 전달한다.

rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && hasseqnum(rcvpkt, expectedseqnum)

----------------------------------------------------------------------------------

extract(rcvpkt, data)

deliver_data(data)

sndpkt = make_pkt(expectedseqnum, ACK, checksum)

udt_send(sndpkt)

expectedseqnum++

 

패킷이 상위 계층에 한번에 하나씩 전송(즉, 수신자 측 window 사이즈 1)되므로, 만약 패킷 k가 수신되고 상위 계층에 전달되었다면, 이때는 이미 k보다 작은 순서 번호를 가진 모든 패킷 또한 전달되어 있다는 것을 의미한다. 즉, 누적 확인응답을 사용하는 것이라 볼 수 있다.

 

 

그 외의 경우에 수신자는 그 패킷을 버리고 가장 최근에 제대로 수신된 순서의 패킷에 대한 ACK를 재전송한다.

default

----------

udt_send(sndpkt)

 

GBN 프로토콜에서 수신자는 순서가 잘못된 패킷들을 버린다.

수신자는 상위 계층에 데이터를 전달해야한다.

지금 패킷 n 이 수신되어야 하지만, 다음 패킷 n+1 이 먼저 도착했다고 가정하자. 데이터가 순서대로 전달되어야 하므로, 수신자는 패킷 n+1을 저장하고 나중에 패킷 n이 수신되고 전달된 후에 상위 계층에 n+1 패킷을 전달한다. 그러나 만약 패킷 n이 손실되었다면 송신자 GBN 재전송 규칙에 따라 패킷 n과 n+1이 모두 재전송될 것이다. 

수신자는 어떤 순서가 잘못된 패킷에 대해 버퍼링을 할 필요가 없다. 따라서 송신자는 window 상위,하위 경계와 window 안에 있는 nextseqnum 위치를 유지해야 하지만, 수신자가 유지해야하는 것은 단지 다음 순서 패킷의 순서 번호(expectedseqnum)이다. (올바르게 수신된 패킷을 버리는 것의 단점은 그 패킷의 재전송이 손실되거나 왜곡될 수 있으므로 많은 재전송이 필요할 수도 있다는 것이다.)

 

아래의 그림은 window 크기가 4인 패킷인 경우에 대한 GBN 프로토콜의 동작을 보여준다.

 

window 크기 제한 때문에 송신자는 패킷 0부터 3까지를 송신한다.

이후 송신을 계속하기 위해 하나 이상의 패킷이 긍정 확인 응답되는 것을 기다려야한다.

각각의 성공적인 ACK(ACK0, ACK1)가 수신되었을 때, window는 앞으로 이동하고 송신자는 새로운 패킷4, 패킷5를 순차적으로 전송한다.

수신 측에서는 패킷 2가 손실(loss)되었으므로, 패킷 3, 4, 5는 순서가 잘못된 패킷으로 판단하여 제거한다.

 

 

 

GBN 프로토콜을 구현했던 확장된 FSM 구조는 다양한 이벤트에 대한 대응으로 취할 수 있는 동작을 구현하는 절차들과 유사하다.

이러한 이벤트 기반 프로그래밍(event-based programming)에서의 다양한 프로시저들은 프로토콜 스택에서 다른 프로시저에 의해 야기되거나 인터럽트의 결과로 요청될 것이다.

송신자에서의 이벤트는

1) rdt_send()를 호출하기 위한 상위 계층 개체로부터의 호출

2) 타이머 인터럽트

3) 패킷이 도착했을 때 rdt_rcv()를 호출하기 위한 하위 계층으로부터의 호출

이다.

 

GBN 프로토콜은 TCP의 신뢰적인 데이터 전송의 기술과 밀접하게 관련되어있고

이 기술에서는 순서 번호, 누적확인 응답, 체크섬, 타임아웃/ 재전송 동작에 대한 사용이 포함된다.

 

 

GBN 프로토콜은 송신자가 패킷으로 파이프라인을 채우는 것을 가능하게 하여, 전송 후 대기 프로토콜에서의 채널 이용률 문제를 피하도록 하고 있다. 그러나 GBN 자체에도 성능 문제를 겪는 시나리오들이 존재하는데, 특히 window 크기와 대역폭 지연(bandwidth-delay) 곱의 결과가 모두 클 때, 많은 패킷을 재전송하므로, 많은 패킷을 불필요하게 재전송하는 경우가 발생한다.

채널 오류의 확률이 증가할수록 파이프라인은 불필요한 재전송 데이터로 채워진다.

예를 들어, 매번 한 단어가 왜곡될 때 마다, 그 단어 주위의 1000단어(window 크기 1000word)가 반복되어야한다. 

 

 

2. SR(Selective Repeat, 선택적 반복)

파이프라인 오류 회복의 다른 방법인 SR(Selective Repeat, 선택적 반복) 프로토콜은 수신자에서 오류(손실되거나 변조된)가 발생한 패킷을 수신했다고 판단하는 패킷만을 송신자가 다시 전송한다. 이로써 불필요한 재전송을 피할 수 있다. 필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.

window 크기 N은 파이프라인에서 아직 확인응답이 안된 패킷 수를 제한하는 데 사용된다. GBN과의 차이점은 window에 있는 몇몇 패킷에 대한 ACK를 송신자가 이미 수신 했을 것이란 거다.

SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확이응답을 한다. 순서가 바뀐 패킷은 빠진 패킷이 수신될 때까지 버퍼에 저장하고, 빠진 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계층에 전달한다.

만약 패킷 2가 손실되고 패킷 3,4,5를 송신했다면 수신자는 패킷 3,4,5를 버퍼에 저장하고, 송신자가 패킷 2 타임아웃에 의해 재전송하여  수신자 측으로 패킷 2가 수신되었을때 수신자는 2,3,4,5를 상위 계층으로 전달한다.

 

SR 송신자 이벤트와 행동

1. 상위로부터 데이터 수신 : 상위에서 데이터가 수신될 때, SR 송신자는 패킷의 다음 순서 번호를 검사한다. 순서 번호가 송신자 window 내에 있으면 데이터는 패킷으로 송신된다. 그렇지 않으면 GBN처럼 버퍼에 나중에 전송하기 위해 되돌려진다. 

if next abilable seq# in window => send pkt

2. 타임아웃 : 타이머는 손실된 패킷을 보호하기 위해 재사용된다. 그러나 타임아웃시 오직 한 패킷만이 전송되기 때문에, 각 패킷은 자신만의 논리 타이머가 있어야 한다. 하나의 타이머가 여러 개의 논리 타이머를 흉내 내는 데 사용된다.

timeout(n) => resend pkt n, restart timer 

3. ACK 수신 : ACK가 수신되었을 때, SR 송신자는 그 ACK가  window내에 있다면 그 패킷을 수신된 것으로 표기한다. 만약 패킷 순서 번호가 send_base와 같다면, window base는 가장 작은 순서 번호를 가진 아직 확인 응답되지 않은 패킷으로 옮겨진다. 만약 window가 이동하고 window 내의 순서 번호를 가진 미전송 패킷이 있다면, 이 패킷들은 전송된다.

 

SR 수신자 이벤트와 행동

1. [rcv_base, rcv_base+N-1] 내의 순서 번호를 가진 패킷이 손상없이 수신 :

이 경우 수신된 패킷이 수신자의 window에 속하는 것이며, 선택적인 ACK 패킷이 송신자에게 회신된다.

만약 이 패킷이 이전에 수신되지 않았던 것이라면 버퍼에 저장된다. 

만약 이 패킷이 수신 window(rcv_base)의 base와 같은 순서 번호라면, 이 패킷과 이전에 버퍼에 저장되어 연속적으로 번호를 가진(rcv_base로 시작하는) 패킷들은 상위 계층으로 전달된다.

즉, window의 base와 도착 패킷의 순서 번호가 동일하면 해당 패킷부터 버퍼된 연속 패킷들을 모두 전달

2. [rcv_base - N, rcv_base -1] 내의 순서 번호를 가진 패킷이 수신:

이 경우에는 이 패킷이 수신자가 이전에 확인응답한 것이라도 ACK가 생성되어야 한다.

즉, 수신자가 현재의 window base보다 작은 특정 순서 번호를 가진 이미 수신된 패킷을 무시하지 않고 재확인 응답을 한다는 것이다.

예를들어 아래의 그림처럼 송신자와 수신자의 순서 번호 공간을 주었을 때, 수신자가 송신자에게 보내는 send_base 패킷에 대한 ACK가 없다면, 수신자는 그 패킷을 이미 수신했음이 분명하더라도 결국 송신자는 send_base 패킷을 재전송할 것이다.

 만약 수신자가 이 패킷에 대한 확인응답을 하지 않는다면, 송신자의 window는 앞으로 이동할 수 없을 것이다.

송신자와 수신자는 올바른 수신과 그렇지 않는 수신에 대해 같은 관점을 갖지 않는다. 즉, 송신자와 수신자의 window는 항상 같지는 않다는 뜻이다. 

 

3. 그외의 경우, 패킷을 무시한다.

 

 

2.의 송수신자 간 window 동일하지 않음에 대한 이슈

송신자와 수신자 window 사이의 동기화 부족은 순서 번호의 한정된 범위에 직면했을 때 문제가 발생할 수 있는데,

예를 들어, 한정된 범위의 네 패킷 순서 번호 0, 1, 2, 3과 window 크기 3에서 어떤 일이 일어 날 수 있는지 생각해보자.

0부터 2까지 패킷이 전송되어 올바로 수신되고, 수신자에게서 확인이 되었고 그 순간에 수신자의 window는 각각의 순서 번호가 3, 0, 1인 4, 5, 6 번째 패킷에 있다고 가정하자.

여기서 두 가지 시나리오(a),(b)를 고려해보자. (아래 그림 참고)

 

(a) 처음 패킷에 대한 ACK가 손실되고 송신자는 이 패킷을 재전송한다. 그 다음 수신자는 순서 번호가 0인 패킷(처음 보낸 패킷의 복사본)을 수신한다.

 

(b) 처음 3개의 패킷에 대한 ACK가 모두 올바르게 전달되었다. 송신자는 자신의 window를 앞으로 이동시켜 각각의 순서 번호가 3, 0, 1인 4, 5, 6 번째 패킷을 보낸다. 순서 번호 3을 가진 패킷이 손실되고, 순서 번호 0을 가진 패킷(새로운 데이터를 포함한 패킷)은 도착한다.

 

 

수신자는 송신자의 행동을 볼 수 없으므로, 송신자와 수신자 사이에 커튼이 있다고 생각해볼 수 있다. 모든 수신자는 채널을 통해 받고, 채널을 통해 보내는 메시지의 순서를 관찰한다.

다섯 번째 패킷의 원래 전송과 첫 번째 패킷의 재전송을 구별할 방법은 없다.

너무 큰 window를 가지게 되면 SR 수신자는 새 패킷인지 재전송 된 패킷인지 딜레마에 빠지게 될것이다.

=> 해결 순서번호 공간의 크기를 늘린다. 정확히 말하면 순서 번호 공간의 크기를 윈도우 크기의 2배이상으로 느려야한다.

반대로 말하면 윈도우 사이즈는 순서번호 공간의 크기의 절반 이하여야 한다.

 

윈도우 사이즈 <= 순서 번호 공간의 크기의 절반임을 증명하기
가정:
순서 번호 공간의 크기를 M, 윈도우 크기를 W라고 하자.

목표: W ≤ M/2 임을 보이기

귀류법을 사용하여
W > M/2라고 가정하고, 이로 인해 발생할 수 있는 문제를 보여 이 가정이 잘못되었음을 증명하자.
시나리오:
송신자가 순서 번호 0부터 W-1까지의 패킷을 전송했다고 가정한다.
수신자가 이 모든 패킷을 올바르게 수신하고 ACK를 보냈지만, 모든 ACK가 손실되었다고 가정한다.
문제 발생:
송신자는 ACK를 받지 못했으므로 타임아웃 후 패킷 0부터 다시 전송을 시작한다.
수신자의 윈도우는 이미 W만큼 이동했으므로, W에서 2W-1 범위의 순서 번호를 기대하고 있다.
W > M/2이므로, 수신자가 기대하는 순서 번호 중 일부는 M을 초과하여 순환된다.
모호성 발생:
송신자가 재전송한 패킷 0은 수신자 입장에서 새로운 패킷 M으로 해석될 수 있다.
이는 패킷의 순서와 신규성을 구분할 수 없게 한다.
결론:
이러한 모호성을 피하기 위해서는 W ≤ M/2 조건이 반드시 만족되어야 한다.
따라서 윈도우 크기는 순서 번호 공간의 절반보다 작거나 같아야 한다.

 

신뢰적인 데이터 전송 메커니즘 요약

메커니즘	사용설명
체크섬	전송된 패킷안의 비트오류를 발견하는 데 사용
타이머	채널 안에서 패킷이 손실되었기 때문에 발생되는 패킷(또는 이것의 ACK)의 타임아웃/재전송에 사용됨. 타임아웃은 패킷이 지연되었지만 손실되지는 않았을 때(조기 타임아웃),  또는 패킷이 수신자에 의해 수신되었으나 수시자에서 송신자로의 ACK가 손실되었을 때 발생하기 때문에, 수신자에 의해 수신되는 패킷은 중복으로 복사(수신)된 패킷일 수 있음.
순서 번호	송신자에서 수신자로 가능 데이터 패킷의 순서 번호를 붙이기 위해 사용. 수신자 패킷의 순서번호와 간격은 수신자가 손실된 패킷을 검사하게 함. 중복된 순서 번호를 갖는 패킷은 수신자가 패킷의 중복 검사를 하게 함
확인 응답	수신자가 패킷이 정확히 수신되었다는 응답을 송신자에게 하기 위해 사용.  확인응답은 일반적으로 패킷 또는 이미 확인 응답된 패킷들의 순서번호를 전달. 확인응답은 프로토콜에 따라, 개별적이거나 누적된 것일 수 있음
부정 확인 응답	수신자가 패킷이 정확히 수신되지 않았다는 응답을 송신자에게 하기 위해 사용. 부정 확인응답은 일반적으로 정확히 수신되지 않은 패킷의 순서 번호를 전달함.
window, pipelining	송신자는 주어진 범위에 있는 순서 번호를 가진 패킷만 전송하도록 제한될 수 있음. 확인 응답은 아직 없지만 허가된 패킷이 전송될 수 있으므로, 송신자의 이용률은 전송 후 대기 모드의 동작보다 증가할 수 있다. window 크기는 수신자의 메시지를 수신하고 버퍼링하는 능력, 네트워크 혼잡 정도 에 근거하여 설정됨.

 

 

 

 

 

 

참고 자료 :

https://media.pearsoncmg.com/ph/esm/ecs_kurose_compnetwork_8/cw/content/interactiveanimations/go-back-n-protocol/index.html

Go-Back Protocol

https://media.pearsoncmg.com/ph/esm/ecs_kurose_compnetwork_8/cw/content/interactiveanimations/selective-repeat-protocol/index.html

Selective Repeat Protocol