안녕하세요? 김동주님.

정말 좋으신 질문이네요.
TIC 벤더(미국 벤더)에서 얘기하는 내용은 아래와 같습니다.
한마디로 "관련법을 잘 지키고 있으므로 TIC를 적용한 통신사업자는 CP에게 허락을 받을 필요는 없다"는 의견입니다.

1. Copyright compliance:
Storing and delivering content from a cache can raise several questions pertaining to copyright and digital rights management. A transparent cache must follow the strict guidelines outlined within the Digital Millennium Copyright Act (DMCA) and equivalent legislation for content deployments outside of the United States.

2. Are there Concerns for Copyright Infringement?
Content delivery can be fraught with legal complexity; however the Digital Millennium Copyright Act—USA (DMCA) and other similar documents were authored to recognize caching of P2P and HTTP-streaming content for the purpose of network efficiency and without modification as legal and protected by law. Similar documents in the European Union (EU) also provide guidance, acknowledge the requirement, and protect network operators from liability for routing, caching and hosting 3rd party content.

The transparent caching strategy used within Intelligent Content Networking is fully compliant with the procedural “safe harbor” requirements of these legal acts. A transparent caching strategy works by intercepting the network traffic transparently to the browser. It short-circuits the retrieval process of the desired file if it is in the cache. Transparent caches are especially useful to service providers because they require no browser setup modification.

3. DMCA Terms
- The service provider is not the one who originally made the material available -> TIC fully compliant
- Caching is automatic with intermediate and temporary storage of content in local servers -> TIC fully compliant
- Service provider did not modify the content -> TIC fully compliant
- Service Provider complies with industry standards regarding updating of the content -> TIC fully compliant
- Service provider does not interfere with the content’s access manners (ie passwords) -> TIC fully compliant
- Service provider must remove infringing files upon gaining actual knowledge of infringement -> TIC fully compliant


제가 YouTube 동영상 캐싱을 위한 Google의 정책은 잘 모르겠는데요 (혹시 관련 문서가 있으면 공유 부탁드려요~)
실제로 TIC의 적용 목적은 "YouTube 동영상"을 위함! 이거든요. 만약 이게 안되면 통신사업자가 TIC를 도입할 이유가 없을 것으로 보이구요.
제가 알기로 미국에 몇몇 통신사업자는 이미 TIC를 도입하여 YouTube 동영상을 캐싱하고 있습니다.

평소 무척 궁금한 사항이었는데, 이렇게 신속한 답변 해주시어 감사드립니다. Google이 문제삼았다는 내역은 구두로 들은 내용이라 좀 더 확인이 필요합니다.

도움 되셨다니 다행입니다. ^^*

Google 정책 관련하여 좋은 정보 아시게 되면 공유 부탁드릴께요~*

안녕하세요. 저도 위 내용에 관심이 많은데요..^^
몇가지 궁금한점이 있습니다.

1. 미국에서 TIC를 도입해 YouTube 동영상을 캐싱하고 있는 통신사업자가 있다고 하셨는데...
해당 사업자의 이름이나, 구체적인 적용 사례에 관한 정보를 얻을 수 있을까요?

2. 과거 웹 캐시 같은 경우는 사용자 인증을 통한 유료서비스를 사용하지 못하거나 (특정 페이지 접속불가),
캐시미스시 자동으로 오리진 서버로 Redirect 하지 못하는 등 문제가 많았던 것으로 알고 있습니다.
비디오 콘텐츠를 주 타깃으로 하는 현재의 TIC 장비의 경우 위와 같은 서비스 실패 가능성은 없는건가요?
(OTT/CP의 유료서비스나 광고에 영향을 줄 수 있는 소지가 있다면 이또한 문제가 될 것 같아서요..^^)

1. 미국에 Sprint, Verizon, Frontier에서 적용한 것으로 알고 있습니다(관련 업체로 부터 들은 얘기). Level 3(통신사업자이면서 CDN사업자)도 검토 중이라 작년말에 들었는데 결과는 잘 모르겠네요.

2. 말씀하신 문제(유료 컨텐츠)에 대해서는 다음과 같은 원리(절차)로 문제를 해결하였습니다.

[1단계] 유저가 요청한 컨텐츠가 TIC에 있어도 TIC는 항상 Origin Server로 유저의 요청(HTTP)을 보냅니다.

- 그렇게 하는 이유는 3가지 인데요.
1) 유료 컨텐츠에 대한 보호: 유저의 요청을 받은 Origin Server는 유료 컨텐츠에 대해서 User Credential(ID/PW)를 요청하고, 확인된 유저에 대해서만 컨텐츠를 내려 보냅니다. 그렇지 않은 경우 Origin Server는 컨텐츠를 전달해 주지 않겠죠. 따라서 TIC는 Origin Server로 부터 컨텐츠가 오지 않은 이상 유저에게 컨텐츠를 전달해 주지 않습니다.

2) Contents Freshness 확인: TIC에 저장된 컨텐츠가 "최신"인지 TIC는 알 방법이 없으므로 Origin Server가 컨텐츠의 일부(예. 8KB)를 TIC가 수신하면 이를 보고 내가 가지고 있는게 최신 건지 확인을 합니다. (컨텐츠 앞에 일부를 해싱하여 관리함)

3) CP에 User Behavior를 제공: CP 입장에서는 어떤 컨텐츠를 많이 봤는지 알아야 이를 통해 마케팅/광고등의 행위를 할 수 있을 것이구요. TIC는 항상 유저의 요청을 일단 Origin Server로 보내어 CP가 이를 파악할 수 있도록 합니다.

[2단계] 이와 같이 일단 Origin Server로 부터 컨텐츠의 일부(예. 8KB)를 받은 TIC는 Origin Server와의 TCP connection을 끊어 더 이상 컨탠츠를 수신하지 않고, TIC에 있는 컨텐츠를 가입자에게 전달해 줍니다.

질문에 답을 다시 정리해 드리면,
1. TIC는 비록 캐싱되어 있는 컨텐츠라 할지라도 유저의 요청을 Origin Server로 보내고,
2. Origin Server는 유료 컨텐츠에 대해 사용자 credential 확인 후에 컨텐츠를 유저 방향으로 전달 시작
3. TIC는 Origin Server로 부터 컨텐츠가 들어 옴을 확인 후에
4. Origin Server로 TCP RST을 보내어 더 이상 컨텐츠가 전달되지 못하도록 연결을 끊어 버리고
5. TIC는 캐싱된 컨텐츠를 유저에게 전달함

만약 2번에서 사용자 인증에 실패하게 되면, TIC는 캐싱된 컨텐츠를 유저에게 전달하지 않음

그리고 아래 블로그글 보시면 TIC 동작 원리를 이해하시는데 도움이 되실 거에요.
https://www.netmanias.com/bbs/view.php?id=blog&no=243

친절한 설명 감사드립니다. ^__^

네~ ^^*

한가지 더 궁금한 내용이 있습니다.

보통 OTT 사업자들은 각 콘텐츠의 URL을 계속 바꾸는 방식을 사용해 콘텐츠 캐싱을 어렵게 한다고 하던데..
TIC들은 어떤식으로 이 문제에 대응하고 있는지요?

TIC 업체는 다음과 같은 기능을 잇점이라 얘기하고 있습니다.

TIC implements an advanced content payload inspection to complement URL identification, allowing it to recognize multiple URL denominations of same object as object

즉, 서로 다른 Origin Server(따라서 다른 URL)에 있는 동일 비디오파일을 식별하여(동일 비디오파일인지 판단하여) 하나의 비디오파일만 캐싱을 한다고 합니다.

이 기능으로 미루어 짐작하면(정확하지는 않아요~ ^^*)
Origin Server에서 URL을 바꾸어도 컨텐츠 내용이 바뀌지 않는 한, TIC는 컨텐츠 내용의 앞부분을 hashing하여 가지고 있고, 이 내용을 기반으로 캐싱 로직(cache miss, cache hit, cache fill)이 이루어 지므로, TIC는 동일 contents라 인식할 것으로 예상합니다. 따라서 TIC 입장에서 캐싱에 별 문제가 없을 듯 합니다.

그렇군요.. 감사합니다. ^^