course Outline
- multimedia traffic service의 특성 및 관련 전송 기법에 대해 이해
- multimedia traffic and QoS 개념
- application level에서의 전송 기법 개념
- transport/session protocol (RTP, SIP) 개념
- Network scheduling 및 policing 개념
All IP
ip를 기반으로 한 internet으로 모든 통신 네트워크 / 서비스가 통합이 되는 개념
- 모든 서비스는 인터넷 위에서, 인터넷은 모든 서비스의 통신 통로
- internet이 궁극적으로 통신 서비스를 천하 통일하는 현상
multimedia service
All IP 추세에 따라 정보전달의 난이도가 높은 서비스가 internet을 기반으로 launching되고 있음
- 고전적인 internet service: HTTP, mail, FTP ...
- multimedia service: streaming, conversation → 실시간 성이며, 정보 전달에 대한 요구조건 존재
Multimedia Traffic: Video
Video: 영상 + 음성 정보
- 기본적으로 연속된 이미지를 저장하는 영상이 보통 용량이 크다
- 영상 품질에 따라 100kbps ~ 3Mpbs (HD급)로 가변
- 사진 / 음악 대비 압도적으로 높은 용량을 필요로 함.
Video는 고용량인만큼 전송 시 압축 기술이 동반된다.
- video compression은 기본적으로 redundancy(중복성)를 줄이는 방향으로 동작한다.
- spatial redundancy: 공간적으로 유사한 pixel은 비슷한 정보를 가진다
- temporal redundancy: 시잔적으로 동일 pixel은 느리게 변함
- 의존성을 없애는 쪽으로 압축이 이루어진다.
- 압축 품질에 따라 같은 영상을 multiple version으로 만들기도 함.
- 무선 인터넷 속도에 따라 적응적으로 서로 다른 용량의 영상 전송 가능
Mutimedia Traffic: Audio
Video에 비해 상대적으로 낮은 용량을 가짐
- 음성 신호를 특정 sampling rate로 sampling → 1s에 몇번 sampling
- sampling된 것을 quantization해서 bit로 표현
bit rate = sampling rate(Hz) * bits per sample(비트가 늘어날 수록 단계가 세밀하다)
- bit rate이 높을수록 sampling rate이 높거나 quantization에 의한 왜곡이 적으므로 음설 품질이 더 우수하다
- quantization(양자화)가 높을수록, sampling rate가 높을 수록 음성 품질은 좋아진다.
MPEG 1 layer 3 (MP3) 혹은 Advanced Audio Coding (AAC)등의 압축 기술을 활용해서 전송률을 최대한 낮춤
- 음성의 경우 G.721, G.729, AMR등 음성에 특화된 압축 기술 사용
사람들의 체감상 Video대비 왜곡에 더 민감하다
Multimedia Traffic: Service
- Streaming stored audio and video (넷플릭스, 유튜브 등)
- on demand로 수신: 수요가 있을 때 실행
- streaming / interactivity / continuous playout (연속재생 같은 경우 유튜브에서 제공)
- 초기 재생을 위한 지연 시간은 보통 허용되며, pre buffering 을 통해 이후 재생은 왠만한 network delay 변화와 관계없이 순조롭게 됨.
- pre buffering으로 최대한 저장해 두었다가 재생 시작
- 인터넷에 문제가 생겨도 버퍼에 저장된 것을 재생한다.
- 성능 관점에서는 average throughput이 관건
client side applicatoin buffering
- 일정 양의 영상정보를 받고 재생
- network delay 변화에도 대처 가능
Conversational Voice and Video
- 실시간으로 서로 음성 / 영상으로 대화하는 형태
- 내용이 미리 만들어진 것이 아닌 현재 실시간으로 생성되어 전달됨
- Delay sensitive (delay, jitter)
- 400ms 이상 걸리면 체감상 답답함을 느낌
- loss tolerant: packet 몇 개가 중간에 빠져도 괜찮다.
Streaming: UDP Streaming
UDP 기반으로 해서 data를 실시간 전송하는 방식
- multimedia의 rate에 따라 송신 측 server에 서 전송률을 조정
- connection이 없으므로 네트워크가 좋아서 속도가 좋으면 많이 보낸다.
- udp는 data가 전송됐는지 확인을 못하므로 RTP와 RTCP와 연계해서 사용한다
Real Time Transport Protocol (RTP) 과 보통 연계
- RTP
- data encapsulation을 하며, sequence number & timestamp 정보를 실음
- timestamp가 보낸 시점과 받는 시점에 찍혀서 400ms안에 들어왔나 확인 가능
- RTCP
- streaming에 대한 server 측 제어 (어디서부터 어디까지 보냈다고 알려주는)
Issue
- congestion control이 없으므로, network 환경에 따라 재생에 문제가 발생할 수 있음.
- 연결이 끊기면 dynamic하게 client측에서 해결하지 못한다.
- RTCP에 의한 재생 제어에 대해 server에서 client별로 trackig을 해야함
- firewall에서 UDP를 막는 경우가 많음 → UDP 받는 쪽에서 port를 열어놔야하므로 방화벽에서 udp 포트를 막는 경우가 있다.
Streaming: HTTP Streaming
HTTP server 형태로 multimedia제공
- TCP 기반으로 해서 data를 전송한다.
- URL에 의해 접근 (TCP connection / HTTP GET)
congestion control등으로 인한 TCP의 flow control 메커니즘이 streaming의 실시간 전송과 대치됨.
- 오늘날은 인터넷이 빨라져서 buffering & prefetching으로 해결 (delay를 두고 전송한다)
- 재생 속도보다 바르게 download해서 미리 client측에 저장
Streaming: Contents Distribution Network
video는 network load의 주 원인이 되어가고 있다. → 비디오가 네트워크를 망가트린다
- 영상 정보 자체가 size가 큼
- 영상 서비스에 대한 사용자가 날이 갈수록 늘어나고 있음 (유튜브, 넷플릭스 등)
- 멀티미디어가 네트워크 설계에 큰 영향을 준다.
single massive data center 기반의 network streaming 방식
- network상에서 client와의 거리가 일반적으로 크다
- client로 가기 위해 여러 ISP를 거쳐야하는 경우가 많으며, 이중 한 ISP의 용량이 적으면 bottlenenck이 된다.
- 자주 보는 영상을 필요 이상으로 전송 빈도수가 높아짐
- 고장나면 전체 service 이용불가로 이어짐 (fail safety 측면에서 최악)
streaming service는 여러대의 server를 분산적으로 두고 제공
- 지역적으로 고르게 분포되며, 각종 video 정보를 복제해서 보유
- private CDN (Google) vs. third party CDN (netflix)
- content를 캐싱해서 client가 요청하면 로컬에서 제공할 수 있다.
CDN구축에서는 두가지 상반된 원칙이 존재
ISP: internet service provider (KT, SKT ..)
- Enter deep: 각 ISP network내에 설치
- Bring home: ISP 주변에 전용 회선으로 연결해서 설치
CDN을 둘러싼 기업의 갈등
- netflix vs. SKB
- netflix cs. LGU+
- 망 이용료 갈등 넷플릭스, sk 브로드밴드에 소송한 기사 등등
Voice over IP
conversational service 에서 가장 기본적인 음성 서비스에 해당
- ip 상에서 voice를 전달하는 일련의 application protocols
- video 만큼 network load가 크진 않음.
- 고전적인 서비스이긴 하지만 delay 관점에선 상당히 민감한 서비스임 → delay 관련 성능 여러가지 중 한가지만 열화가 일어나도 체감상 service quality가 크게 떨어짐
VoIP example (작은 데이터를 자주 보낸다)
- 8kHz sampling, 8bit quantization
- 초당 bit 생성률 : 8 * 8000 = 64kbps
- 20ms마다 bit를 모아서 data 전송 → 이렇게 보내도 160byte 밖에 안된다. (64kbps * 0.02 = 160byte(=1280bps)를 20ms마다 전송)
1kbps = 1000bps
1mbps = 1000kbps
1gbps = 1000mbps
1s = 100ms
- 말을 20ms끊어서 전송한다고 하면 20ms마다 160byte가 수신측에 들어와야한다.
- 수신측 재생 상황 → 20ms마다 160B data 일정하게 들어와야함.
VoIP에 영향을 미치는 성능 요인
packet loss
- 패킷 loss는 일부 허용될 수 있음
- FEC 혹은 interpolation으로 극복가능
End to end delay
- 300~400ms 이하는 ok
- 평균적인 인간이 체감하는 최소 반응시간 길이
- 400ms 이상이면 통신하지 못한다고 생각한다
Packet jitter
- 떨림 정도 → 너무 많이 떨리면 사용자가 듣지 못한다.
- packet inter arrival time의 변화량 (분산으로 계산)
- 일정 수준 이하로 유지가 되어야함.
유무선 통신에서는 jitter는 불가피하므로
- 수신 재생 측에서 de-jittering을위한 buffer를 운영
- 음성 재생 시작 시점에서 수신 직후보다 좀 더 marginal time을 두고 나서 시작 (playout delay)
- sequence / timestamp 정보를 통해 재생 조절
Real Time Protocol (RTP)
어플리케이션 프로토콜
multimedia data 에 대한 부가적인 재생 정보를 담기 위해 data packet을 encapsulation하는 protocoal
- UDP 바로 위에서 동작하며, encapsulated PDU가 곧 UDP의 SDU가 된다.
- RTP header에 부가 정보가 포함됨.
- 애플리케이션에서 multimedia만들어서 헤더가 붙는데 이 헤더를 붙이는게 RTP가 한다.
- 헤더에 multimedia type, SN, timestamp, source ID 가 포함된다.
- 네트워크 환경을 파악 가능하다 → 빨리오면 좋은 것이다.
- SN로 데이터 손실을 알 수 있다.
Real Time Control Protocol (RTCP)
어플리케이션 프로토콜
RTP와 더불어 같이 활용되는 control plane protocol
- RTP에 대한 흐름제어 및 각종 통계정보를 제공
- number, source, time, destination, lenght, info, pritocol(RTCP) 를 제공
Session Initiation Protocol (SIP)
multimedia 전송을 위해 connection management를 해주는 프로토콜
상대편 IP를 알기 위해 application layer에게 물어보는 것
- IP 상에서 동작하면서 호 연결 서비스 제공 → 인터넷 상에서 동작
- 상대방 IP address에 대한 파악/ 관리 기능 포함
HTTP와 유사한 ASCII 기반의 메시지 형태
- 호 연결 명령과 더불어 option parameter를 같이 전송할 수 있음.
SIP address
- ID + 위치 정보 를 담고 있다
- sip: xxxx 형태로 표현됨
- IP address 를 포함하고 있으면 곧바로 IP 전송이 가능하나, 보통 이런 유형이 아님 → DHCP, mobile IP 등을 많이 활용하는 관계로, 요즘은 상대방의 IP가 고정적이지 않음 (상대방 IP를 미리 받아서 저장하지 않음)
- email 형태의 주소를 많이 활용 (SIP proxy를 통한 IP mapping 필요)
SIP를 통한 session initiation 절차
- SIP proxy → registrar → end client
- 1번: 상대편의 ip address를 알고 싶다고 신호를 보낸다
- 서로의 IP address를 알면 이후 media정보는 중간 server를 거치지 않고 직접적으로 주고 받는다. (9번)
SIP Message
디테일하게 보지 않아도 된다
SIP INVITE messge (상대편 위치를 찾기 위한 요청)
- session 시작 시 호 설정 요청을 위해 전달
- 호 요청자 관련 정보 및 parameter
Quality of Service
network 측면에서 service가 요구하는 성능의 품질
- data rate, priority, latency, loss rate, jitter 이런 것들로 표현된다.
Network level Multimedia Delivery
여기서 service한다는 forwarding해준다와 같은 개념이다.
L4 이하에서 multimedia data에 대한 전송 철학 / 개념
best effort service임 (최선을다하겠음)
- 제일 안 좋은 서비스로 "최선을 다하지만 안될 수도 있다"
- 기본적인 철학이다
- 모든 traffic들이 network에서 동일하게 취급된다.
- 흔히 applicaton level에서 multimedia 전송 기법을 고려
Differentiated service
- 서로 특성의 traffic 이 class로 구분되어 priority가 다르게 취급된다.
- 우선순위가 높은 순으로 서비스한다.
Per connection Quality of Service Guarantees
- 연결 별로 서로 다른 요구사항이 존재하며, 이에 맞게 network에서 전달
- 예) 중요 인물 data는 다른 것들보다 빠르게 전송해야함
Best Effort Network
최선을 다하는게 미덕이며, 그 이상에 대한 보장은 없음
- multimedia application의 strict requirement(엄격한 요구사항)를 꼭 만족시키려 하지 않고, network 성능을 최우선으로 고려
- 모든 multimedia connection들을 만족시키려 하면 network는 부하가 커지고 congestion 발생하므로 모든 네트워크는 일단 best effort network로 설계한다
- 모든 친구들에게 동일한 기회를 제공하도록..
network용량이 수요보다 충분히 크도록 network 설계가 이루어져야함
- 이게 best effrot network 서비스 기반으로 설계하는 것이다
- 경제성 조건 필요
- end point 에서의 traffic 요구 모델 정립, 성능 요구사항 정의 및 단대단(end to end) 성능 예측 등이 필요
아래 두가지를 고려해서 네트워크 설계해야함 (network 용량이 수요보다 크도록...)
1. bahdwidth provisioning(조항)
- 주어진 network topology하에서 특정 link가 요구되는 capacity
2. network dimensioning (망에서 소요되는 요소나 링크 수 계산)
- end to end 성능 요구사항을 만족시키기 위한 network 설계 문제
- router 위치 및 연결, 각 link의 capacity 결정 등 네트워크 설계 문제
Multiple Classes of Service
Differentiated srevice는 이 방법을 사용해서 우선순위가 다른 것끼리 나눠서 저장한다.
다양한 applicaition service에 대해 class 로 분류해서 전달
- class에 따라 전달에 대한 우선순위를 다르게 둔다.
packet marking
- IP header의 type of serrvice (ToS)로 인식 → 우선순위를 알 수 있다.
Traffic isolation
- 한쪽 서비스가 다른 한쪽 서비스에게 품질 측면에서 영향을 일으키지 않도록 제어
- isolation하기위해서 treffic policing을 한다.
- traffic policing: 각 서비스 별로 제한을 둠 → 서비스가 서로 다른 룰을 적용한다
Efficient resource usage
- 주어진 네트워크 resource는 아끼지 말고 최대한 다 쓰는 것이 좋음
Scheduling Mechanism
router에서 어떤 packet을 먼저 내보낼지 정하는 과정
First-In-First-Out (FIFO)
- 들어온 순서대로 packet service한다.
Priority Queuing
- class별로 queue를 별도로 둠
- class 별로 처리하면 낮은 우선순위는 처리 못하는 경우발생 (형평성 문제 발생)
Round Robin
- Queue별로 공평하게
Weighted Fair Queuing
- Queue별로 weight에 맞게 공평하게
- 큐 별로 확률은 둔다
Policing : Leaky Bucket
bucket에 담긴 token 양에 따라 packet 전송을 허용
- bucket은 r의 비율로 token이 쌓이며, b개 이상은 담지 못함
- 1개의 packet을 보내려면 token 1개를 써야 함
- 큐에 token을 줘서 급할땐 token을 많이 서서 전송을 강제하도록..
maximum burst size
- b packets
maximum packet in time interval t
- rt+b
Priority Queuing에서 형평성 문제
weighted fair queuing과 leaky bucket을 동시에 사용해서 해결
Policing + Scheduling
Leaky bucket + Weighted Fair Queuing
- bucket내 token에 따라 queue에 packet 축적
- 축적된 packet을 weight에 따라 순차적으로 전송
- Priority Queuing에서 형평성 문제를 방지
'CS > 컴퓨터네트워크' 카테고리의 다른 글
| 14. Local Area Networks& Wide Area Networks (0) | 2023.06.05 |
|---|---|
| 12 Application Layer 1 (0) | 2023.05.28 |
| 10. Layer4: Transport Layer (0) | 2023.05.22 |
| 9. Layer 3: Routing (0) | 2023.05.16 |
| 7. Layer 3: Internet Protocol (0) | 2023.04.15 |
