1. 네트워크 레벨에서 인식(recognition)을 할 수 없는 프로토콜 개발
네트워크 레벨에서 어떠한 Application에 의해 발생하는 트래픽인지 원천적으로 인식할 수 없도록 하는 프로토콜 개발. Protocol Header Encryption도 당연히 구현해야 함. 이러한 Protocol의 개발은 (예를 들면) 보이스톡의 음질 저하 논란을 잠재울 수 있음. 현재 Skype라는 어플리케이션이 이러한 기능을 충분히 지원하고 있기는 하나 (어렵지만) 트래픽 인식을 할 수 있는 취약점이 존재하는 상황임.


2. UDP 기반의 전송 보장 프로토콜 개발
기존의 TCP 프로토콜의 문제점은 앞부분의  내용의 전송이 완료되지 않고서는 뒷 부분의 전송을 처리하지 않는 메카니즘임. 이는 File Sharing(파일의 뒷부분부터 전송이 완료되어도 됨)에서는 적합한 방식이 아님. 또한 SEQ/ACK 정보만으로 데이터 전송을 보장하는 것에는 한계가 있음(Selective ACK방식은 좀 복잡). 게다가 TCP 프로토콜은 남에게 피해를 주지 않으려는 속성이 있어서 네트워크 레벨에서 TCP starvation과 같은 현상이 나타나기도 하기 때문에 좀 더 Aggresive한 방식의 도입이 필요함. 그리고 Signaling과 Streaming을 혼용하는 VoIP / Video Conference에서도 그리 적합하지 않음. TCP와 UDP의 특징을 혼용한 Hybrid Transport Layer의 설계 필요성이 대두. 참조 - http://en.wikipedia.org/wiki/QUIC, http://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol


3. Object Cache Proxy 개발
Zip파일이나 Youtube 동영상과 같은 Object 단위 컨텐츠를 네트워크 레벨에서 caching을 하여 네트워크 부하를 줄여 줄 수 있는 장비 개발(jaguar).


4. Packet Cache Proxy 개발
Object Cache Proxy와 비슷하나 Packet 레벨로 접근한다는 것이 차이. 똑같은 TCP(혹은 UDP) Data들의 내용을 caching하여 네트워크 부하를 줄여 줄 수 있는 장비 개발(steel head).


5. SW기반의 라우팅 장비 개발
네트워크 트러블을 고의적으로 야기시키기 위한 SW 기반의 장비 구현(이는 현재 SnoopSpy에 구현 단계임).


6. 서적 집필
그간 터득해 온 지식들을 정리할 수 있는 IT 서적 발간.


[ps]
1, 2번은 잘 만들어 놨다 해도 일반 Application에 금방 도입하지는 못하니 Proxy 형태로 제공을 해서 테스트할 수 있음.
3, 4번은 그냥 만들어 네트워크단에 붙여서 테스트하면 됨.
5번은 현재 진행중.
6번은 아직 미정.
You would..