ATM은 일정한 Bit rate를 보장한다. 로스없고 순서에 맞춰서. virtual circuit switching 이기에 미리 경로를 만든다. 그래서 순서에 따라 도착함. 일정 시간내에 도착 보장. 그중에서 Available은 적어도 최소한의 bandwidth를 보장. 그러나 로스는 처리 못함. 순서는 virtual circuite이기에 보장하지만 딜레이는 보장 못함. 결국 뭐 실패함
diffserv(differentiated service)
intserv(integrated service)
based on the explicit resource reservation per flow
reservation protocol로 예약을 하고 OK되면 그 서비스를 받는 것. RSVP가 엄청 복잡.
예약을 할 때 얼마 시간에 얼마를 준다든가..요청한 트레픽에 살짝 덜 미치게 넘치지 않게 와야. 그래서 policy가 필요하다.
class 1,2,3 이런 걸 구별하는 값. DSCP
flow들을 class로 나눈다. 클래스 간에 차이점을..end to end Qos는 아니고 단지 각각의 라우터에서 볼 때 클래스별로 차별화된 서비스를 제공할 뿐이다.
PHB : per hop behavior 각각의 라우터에서 어떤 식으로 핸들링 하는가에 대한 기술. 클래스에 따라서 어떤 식으로 각각 라우터에 처리할 것인가에 따라 포워딩을 하는 것이다. 이게 scheduling이다. 누구를 먼저보내고 어떻게 할 것인가. 약간의 차별화 된 서비스를 할 수 있다.
기본적으로 sufficient provisioning of bandwidth(over engineering)과 ..
DASH는 어플리케이션 레벨에서 밴드 위스를 어댑티브로 바꿈. 대쉬에서는 영상의 질이 적고 떨어질 수.. CDN쪽에서는 될 수 있으면 동일한 내용을 여러 서버에 분산시키고 클라이언트에서 가까운 쪽에 있는 서버부터 데이터를 받게 한다.
elastic : 빨리보내면 좋지만 늦게 보내도 괜찮은. congestion이 우려되면 sending rate를 줄이는.
라우터에서 버퍼를 얼마나 크게 해야 하는가?
대략적으로 RFC3439에서는 TCP개수가 적을 때 edge쪽 라우터일 경우에 대략 B = RTT * C(link capacity)
core쪽에서는 굉장히 많은 flow가 흘러감. 이럴 땐 B = RTT * c/root(N)
버퍼가 많으면 좋은가? 많은게 항상 좋은 게 아니다. 많으면 loss가 줄어드니 좋지만 queuing delay가 늘어남.
reduce packet loss, but can increase queueing delay. 만약 버퍼가 버퍼링이 시작되면 컨제션이 일어났다는 징조. 버퍼가 굉장히 많으면 로스는 일어나지 않기에 컨제션 컨트롤 메카니즘이 돌지 않는다. 응답성이 너무 느려진다. 초기의 컨제션에 대한 응답과 반응이 다 느려진다. 그래서 좀 어렵다. 학자들마다 논쟁이 많아많아.
버퍼블로트?
이건 persistently full buffer problem이다. 지속적으로 버퍼가 차 있다면? 버퍼에 항상 10개의 패킷이 발견된다면 앞의 10개가 서비스되고 본인이 서비스 된다. 그래서 항상 딜레이가 있다는 겨. 이걸 없애기 위해 솔루션으로 스케쥴링을 사용했다. 어째서 이런 현상이 ? 보내는 레이트는 10ms 초당 백개 정도? 이런 상황에서 큐잉 딜레이가 25개가 되어 있다. 여기에 한 패킷 보낼 떄 10ms가 걸리니까 10마다 하나씩 감소하겠지 큐에 저장된 얘들이? 200ms가 되면 5개가 남겠지? 그런데 패킷이 갔다가 200ms만에 다시 돌아온다. 그러면 윈도우 사이즈가 늘어나서 보낼 수 있다. 하나의 액에 하나를 보냄. 여기서는 200ms가 지나고 나면 10ms마나 ack이 오니까 여기서 보낼 때는 10ms마다 200ms지나면 하나 보낼때 다시 하나가 옴. 그러면 항상 패킷이 항상 5개가 존재하게 됨. 그러면 항상 50ms의 딜레이를 먹고 들어간다는 것.
대략적으로 RFC3439에서는 TCP개수가 적을 때 edge쪽 라우터일 경우에 대략 B = RTT * C(link capacity)
이 조건 때문에 발생하고 있음. 위의 예를 적용하면 20packet을 가져야 함. 그런데 25를 가지고 있음.
먼저 온 애를 먼저.
우선순위가 높은 애를 먼저
돌아가면서
페어 큐 : 공평하게 weighted는 가중치를 준다는 겨. 10:3의 비율로 보낸다던지. 뭐 그런.
가장 단순한 것. 우선순위 높은 얘를 먼저 서비스, 그리고 나면 낮은거. 우선순위에 따라 서비스를 해주는. 순위가 높은 얘들은 먼저 해줄 수 있음. diffserv같은 거 적용할 수 있음. 우선쉰위가 낮은 얘들은 starvation될 수 있음
우선순위가 높은 얘가 있으면 높은 얘가 없으면 낮은 애를 서비스 하는 식.
라운드 로빈은 패킷을 클래스로 나눠서 분류 그리고 cyclically하게 돌아가면서 서비스를 해주면 공평하게 서비스가 되지 않을까 하는 것. 클래스에 따라 공평하게! 이러면 페어할까? 과연 공평할까? 패킷 길이가 다 똑같으면 좋은데 패킷 길이가 다 다르다. 패킷 길이가 긴 녀석들이 서비스를 많이 가져간다. 또한 패킷 길이가 같더라도 만약 서비스를 해주려고 할 때 패킷이 존재하지 않는다면? 해당 큐를 띄어넘고 다시 반복된다. 13123에 대해 13213을 가야 하는게 아닌가?
만약 weighted된 상태로 round robin을 하겠다면?
컴퓨터 OS도 스케줄링을 한다. 거기의 알고리즘이 있다. 거기에서 PS가 있다. 얘들은 시간 단위를 아주 짧게 해서 넘기는 방식이다. 패킷에서 가장 fair하게 서비스를 하면 패킷 길이가 패킷은 한 비트 안에서 보낼 수가 없다. 이렇게 하는 것처럼 모사를 해서 서비스 하는 게 bit by bit round로 하는 것 처럼 해서 서비스를 하는 게 fair queue방식이다. 한 bit씩 보낸다고 하면 누가 가장 먼저 보낼까? 가장 먼저 다 보내지는 얘를 먼저 보낸다는 것. 패킷은 bit로 못 보내니까 bit로 보낸다고 가정했을 때 가장 먼저 보내지는 얘를..이런 새로운 받는 서비스 양, 이게 가상의 시간이다. 이런 걸 갖고 한다. 이 시간은 어떻게 증가하는가? 실제적으로 bit by bit으로 보낸다고 가정할 때 서비스를 받는 채널의 개수 분의
서비스가 단위시간당 1만큼 보낸다고 하면 요총한 얘가 2명이 요청하면 나눠쓰니까 0.5가 된다. 그런 식으로 하는 것.
R(t)에 따라 개산을 하는데 아래 equation에 의해 결정됨. j는 채널 j에서 i는 i번째 패킷이 서비스를 시작하는 시간이다. 그 시간은 R(t)이다. 다른 관점의 시계이다. 서비스를 시작하는 시간은 자기의 채널에 이전 캐핏이 서비스가 다 끝나는 시간과 자기가 도착했을 때의 시간 중에서 큰 것이다. 자기의 이전 패킷이 서비스가 안 마쳤을 때 끝난 시간이 자신이 서비스 시작하는 시간, 다 끝났으면 자신이 도착하는 시간. 이전에 도착한 패킷이 bitbit round robin에 의해 끝나야 시작.
서비스를 받기 시작해서 자신의 길이 bit만큼의 시간이 지나면 완료되는 시간이다. 여기서 시간은 항상 가상의 시간 R(t)이다. 이 다음에 실제 패킷을 전송한 다음에는 F의 시간이 항상 원리는 간단데스
점선은 bit by bit rr방식으로 했을 때, 보라선은 실제 패킷이 전송될 때
제일 처음에 채널 1에 도착, 길이가 3 현재 자신만 도착, 서비스를 도착하자마자 받음. 시간 0부터 받기 시작, 끝나는 시간은 3. 다른 얘가 없으니 전송을 시작. 그리고 실제 시간 3이 경과 후 전송이 끝남. 그러나 bbrr은 안 끝남. 그 다음 시간에 1시간에 채널2에서 도착했음. 채널2에서는 도착 시간이 1이고 자신의 길이도 1 그래서 끝나는 시간은 2 bbrr은 시간 1부터는 서로 나눠서 서비스를 받음. 그래서 1/2만큼 서비스가 제공되고 있는 것. 그리고 채널 1에서 다시 도착. 도착하자 마자 받는 게 아니라 3부터 서비스를 받고 길이가 1이니 4에서 끝남. 그 다음에 ㅐㅊ널2에서 1.5에 도착했지만 이전에 도착했던 얘가 2에 끝나기에 자신의 서비스는 2에 길이는 4 마치는건 6. 그래서 보면 채널1의 3에서 서비스가 끝났으니까 채널1의 나머지, 채널 2의 나머지 2를 보고 서비스가 가장 빨리 끝난 친구를 찾음. 이때 채널 3에서 2에서 시작. 그리고 3이니까 5에 끝남. 서비스가 끝나고 나면 그 다음은 4,6,5 중에서 4가 제일 작으니 걔를 선택,
ip는 에러 리포트 기능이 없음. 그래서 에러 리포트는 ICMP protocol을 통해서 한다. 진단 같은 걸 할 때. 보통은 위의 레이어..IP위에 ICMP.. ICMP은 ip를 통해서 전달..그런데 기능적으로 ..
ipv4는 ...
밑에 있는 레이어는..IP는 자신이 서비스를 제공하기 위해 자기 밑의 레이어에서 제공하는 뭔가를 이용한다. IP는 자신이 만족시켜주는 게 없다. best effort service. 그래서 밑에 녀석에게 자꾸 요구를 해야함. 그게 미국방성..?경로가 있기만 하다면 전달만 하라. 요구사항이 없다. 최선을 다할 뿐. 임의의 네트웤을..
