congestion이 아닌 loss(wireless환경)? 어떻게?
congestion이 났는지를 확실히 알려주는 게 제일 좋다><
그런데 router에서 그걸 알 수 있다. ECN은 Layer 3에게 되는 것. 그래서 IP의 도움을 받아야 함. IP header에 Time of ser..vice?
여튼 ip헤더에 ECN이 2비트가 들어갔다.
00 | ECN 사용 X-> router에서 손을 안 된다.
01 | ECN capable
10 | ECN capable
11 | Congestion Experienced(congestion 발생)
TCP에서는 3bits가 ECN을 위해 사용 된다. 11이 되면 reciever는 ECE : ECN Echo가 발생. 그러면 sender는 cwnd를 줄이고 그걸 줄였다고 알려줌(CWR).
ECN을 나는 사용하지만 상대는 사용하지 않을 수 있다. 그래서 TCP에서는 3-way handshaking connection establishment를 하는 과정에서 이전에는 syn, syn-ack, ack을 보냈는데 sender가 ecn을 사용하면 ECE=CWR = 1 을 보내주고 그러면 ECE=1을 알려주면 둘 사이 ECN을 사용하고 0을 보내주면 사용 못 함
둘다 ECN을 사용하면 ip쪽에서 헤더에 있는 ECN 2bits를 random하게 01또는 10으로 보내준다. 걔가 router에 도착하면 AQM active queue management라는 게 있다. 여기가 queue이다. packet들이 쭉 쌓이기 시작하면 th max와 th min을 둔다. min 과 max사이는 probabity확률적으로 congestion이 일어났다고 marking을 한다. 안 일어났는데 일어났다고 알려준다. ECN을 사용하지 않으면 고의로 loss발생. max가 넘어가면 11로 세팅. 그런 매커니즘이 있다. 여튼 congestion이 일어났다고 판단되면 ECN쪽에서 01,10으로 보낸 걸 11로 바꾼다. congestion experienced! 여튼 congestion이 났다 그러면 11로 바꾼다 이것만 생각하라는 것.
CE set은 IP쪽에서. 그러면 transport쪽으로 알려준다. sender에게 알려줘야겠다고 생각함. 이때 ACK with ECN = 1을 갖고 알려줌. 그러면 sender가 그걸 받으면 아, congestion상황이구나 하고cwnd를 줄인다. 그리고 나서 본인이 줄였다는 것을 CWR=1로 알려준다. 그리고 나서 receiver는 그걸 받을 때까지 ECE=1를 지속적으로 보내줌. 그리고 sender는 그게 계속 온다고 해서 계속 줄이는 게 아니라 연속된 상황으로 이해하기 때문에 초반에 한번만 줄인다. 그리고 나서 ECE=0을 보낸다.
nonce sum
congestion -> 리시버 알려줌 -> 그런데 리시버가 생각을 함. 이걸 알려주면 센더가 줄이겠지? 해서 계속 받으려는 리시버가 있다는 거. 그걸 막으려고 하는 게 nonce sum이랑 01 10을 하는 거.
처음에 01 10으로 보냄. congestion발생하면 11로 옴. 그러면 리시버는 congestion이 나도 안 알려주고 있음 11이 되면 receiver에서는 보낸얘가 01을 보냈는지 10을 보냈는지 알 수 없음. 그래서 11이 되면 ECE=1이 되는데 그게 아니면 NS은 01 10 정보를 가지고 accumulation해서 이걸 확률적으로 50%는 틀릴 수 밖에 없음. 그게 틀리면 속이고 있다, 판단해서 센더가 조치를 취한다.
4번을 이해하면 가장 좋지만 그 설명이 좀 이상하고 그래서 1,2번만 을 RFC3540에 대해 이해해보삼 이거 숙제
https://www.rfc-editor.org/rfc/rfc3540
fairness congestion contorl은 efficient하면서 fair한 게 목적. 그래서 K개의 커넥션이 가면 R/K로가야 fair함. 그런데 throughput은 RTT의 영향을 받기에 완벽히 공정하지 않다. 그리고 너무 단순화 된 것을 실제와 가깝게 하기 위해 SS모델도 고려하고 TCP는 앞에서 배웠듯 delayed ack을 사용하기에 어찌됏든 RTT에 반비례하는 factor을 갖고 있다.
UDP
UDP는 멀티미디어 스트리밍 서비스를 할 때 주로 사용했다. TCP를 사용하면 센딩레이트가 뾰족뾰족하지만 멀티미디어에서는 constant해야 한다. 이게 나온 배경은 TCP가 멀티미디어에 안되고 UDP가 사용될때 트래픽 양이 높아지니까 UDP에서도 congestion control mechanism이 필요했다. TCP, UDP 트래픽이 서로 섞이면 각각이 가져가는 throughput이 비슷해야겠다. UDP는 될 수 있으면 부드러운 곡선을 그리면 좋겠따. 원래는 TFRC로 출발했는데 최종적으로는 DCCP로 이름이 지어졋다.
APP
DCCP
UDP
이런 모양으로 주로 만들었다.
fairness HTTP1.1에서는 할때마다 계속 커넥션을 새로 만들었다 .웹브라우저와 서버 사이에 뭔가 있는데 거쳐가는 라우터 중에 이미 9개의 커넥션이 있다. 그런데 하나를 추가로 만들면 R/10만큼 가져온다. 그런데 11개를 만들었다? 그러면 전체가 20개가 된다. 그 중 11/20R을 가져온다. 거의 1/2를 가져옴. connection 수를 늘일수록 본인 입장에서는 TCP가 공정하다는 가정 하에 자신의 throughput은 높아진다 . HTTP1.1에서 connection을 많이 하는 건 트루풋이 높아지는 이유도 있다. 그래서 그 당시에 사용했다는 것.
