congestion control의 원리

flow control

• 상대방이 데이터를 받을 수 있을 때 허용량 만큼 보내주는거(단-단/client-server/허용된 시간 안에 가는거)

congestion

• 네트워크에 데이터가 많아지면 조절하는거(차막혀서 늦거나, 빨리 출발하는거/가는 속도 조절 가능)
• 패킷 로스가 발생
• 큐잉 딜레이가 늘어나(큐로 인한 딜레이) => 교통 혼잡

시나리오 1

2개의 센더, 리시버, 라우터 하나, 무한한 버퍼, 패킷이 유실되도 재전송x

• 람다 in은 최대 r 이라서 두 센더가 최대한 많이 보내도 양분해서 서 r/2이야
• 딜레이 관점에서는 r/2로 보낼 수록 딜레이가 기하급수적 증가(큐 버퍼가 있으니)

시나리오 2

라우터 하나, 버퍼 유한, 센더는 재전송 전략 있음(타임아웃)

• 100개를 보내면 100개를 받아야함(람다 in=람다 out)
• BUT 데이터 전송량은 달라: 패킷 유실이 있기 때문에 (람다' in>= 람다 in)

이상적 상황

sender가 버퍼의 유효공간을 정확하게 알때(패킷 로스 X일때)

• 패킷 로스에 따른 재전송이 있어서 (람다'in >= 람다out)

현실적 상황(중복 패킷 발생)

• 버퍼 딜레이때문에 느리게 가는데 타임아웃으로 중복 재전송
  
• 매번 중복패킷이 발생한다는 극단적 상황일때 r/4 밖에 못받음ㅜ =>재전송이 많아지면 안좋아

시나리오 3

• 빨강 + 파랑 일때 위에 라우터 타고 B로 간다면, 더 멀리있는 파랑은 빨강에 밀려서 로스가 발생 할 수 밖에 없어
  
• 전송량은 다른 노드에 영향을 줘 =>성능저하

TCP congestion 컨트롤

(네트워크 어시스트 congestion 컨트롤)

• 네트워크 안에 버퍼 상황을 체크 ->혼잡도 커지면 네트워크가 알려줘
• 준비물: 라우터가 측정해서 호스트한테 알려주는 기능
• 정확도 굳 but 설치 힘듬
• ECN Echo를 사용해서 알려줌

End-to-End congestion 컨트롤

• 네트워크 혼잡도를 Host가 계산해서 데이터 유실 많아지면 전송량 조절

congestion 컨트롤 방법

• sender 가 transmission rate를 증가시켜, 로스가 일어나면 감소시키고
• congestion 윈도우를 사용함(cwnd)
• 윈도우를 계속 증가시키다가 로스 나오면 반으로 두동강!
• 리시브 버퍼(rwnd)는 매우크다고 가정했을때 cwnd는 TCP sending rate에 비례

congestion 컨트롤 알고리즘

Slow Start

• 하나 보냈을때 통과면 2배 증가
• 초기 rate가 적지만 증가 빨라!

Congestion 회피

• sthresh(마지막 congestion 발생했을 기점의 절반)
• 2배씩 가는 슬로우 스타트 하다가 sthresh 만나면 1씩 증가
  

Fast 리커버리

• 중복 ACK가 3개 발생되면 시작
• ssthresh +3 부터 1부터 증가하면서 시작 => 네트워크 퍼퍼먼스를 증가시키기 위함

FSM 사이클

TCP 공정함

• TCP는 패킷 스케쥴링이 없는 이상 공정하게 데이터가 보내져야해

TCP 정리

멀티플렉싱, 디멀티플렉싱

• 포트넘버로 어디로 데이터를 보낼지 결정해주는거

reliable 데이터 트랜스퍼

• GBN, selective repeat 방법이 혼용된 방법 사용.

flow 컨트롤

• 상대방의 버퍼사이즈를 보고 데이터 송신량 조절

congestion 컨트롤

• 전체 유저 사용량 보고 조절