1 / 24

TCP/IP Header Compression for Satellite Environment

TCP/IP Header Compression for Satellite Environment. Dmitry Batenkov Vladislav Zolotarov. Ittay Eyal Itai Ravid Doris Fischer. Part I Satellite Environment. Dmitry Batenkov Vladislav Zolotarov. Server. Client. Topology (5 stations case). Compressor. Satellite Channel Simulator.

rocio
Download Presentation

TCP/IP Header Compression for Satellite Environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP/IP Header Compression for Satellite Environment Dmitry Batenkov Vladislav Zolotarov Ittay Eyal Itai Ravid Doris Fischer

  2. Part ISatellite Environment Dmitry Batenkov Vladislav Zolotarov

  3. Server Client Topology (5 stations case) Compressor SatelliteChannelSimulator Decompressor

  4. Topology (3 stations case) Compressor SATSIM Decompressor Client Server

  5. Compression station Compressionthread Receivingmodule Sendingmodule From Server To SatSim Compressionmodule

  6. Decompression station Decompressionmodule Receivingmodule Decompressionthread SatSim Client Forwarding thread Sendingmodule Sendingmodule Receivingmodule

  7. SATSIM Module Receivingmodule Sendingmodule Compressor Decompressor Forwarding thread Sendingmodule Receivingmodule Server Satellite channel simulator (5 stations case)

  8. SATSIM Module Decompressionmodule Compressionmodule Receivingmodule Sendingmodule Server Client Forwarding thread Sendingmodule Receivingmodule Satellite channel simulator (3 stations case)

  9. Access synchronization Sending thread APC callbackRecycling WinDis NDIS Adapter Sending module SendPacket()

  10. Access synchronization Receiving thread Postinginitial reads Postingadditionalreads WinDis NDIS Adapter APC callback Receiving module GetNextPacket()

  11. Sendingmodule Decompressionmodule Due timearrived? TS Second thread TS Delay = 0 TS Synchronizaton TS TS Receivingmodule Compressionmodule TS BER SATSIM Main thread

  12. Part IITCP/IP Header Compression Ittay Eyal Doris Fischer Itai Ravid

  13. TCP/IP Header Compression • Protocol for compressing the TCP/IP header part of the packet • Based on RFC1144 created by Van Jacobson in 1990, during his research work at Cisco Ltd. • Compression can get up to 1/8 the size of the original header (from 40 bytes into 5 bytes) • Originally meant to speed up Low-Speed Serial Links

  14. TCP/IP Header Compression – Cont. • In TCP/IP packet the header size is 40 bytes • Though in low speed connections the overhead of an error in the header part of the packet takes a high percentage of the communication • In some modern technology (like satellite communication) we find this overhead, crucial because of the long delay time while crossing the atmosphere

  15. Protocol Main Ideas • High percentage of the packet header stay constant during a connection • Therefore if we knew what were the fields in the previous packet header, we can omit fields that stay constant in the current packet header • We can decrease size of fields that change in a small amount by passing only the difference in the fields content (difference relative to the previous packet header)

  16. Protocol Details • V. Jacobson suggests we keep an uncompressed copy of the previous packet header, on each side of the connection • That way we will update its changed fields each time we get a packet • A full packet header will be passed only in the first packet of a connection (passing also constant fields of the header) or after an error • Afterwards we will pass only the changed fields in the packet header

  17. Protocol Details – Cont. • Since not all the fields change in the same time, we will pass a bit mask field in each beginning of a compressed packet • The bit mask field will indicate which fields have changed from the previous packet header • The bit mask will have a constant order, though only the 1’s bits will indicate a changed field

  18. Protocol Details – Cont. • In V. Jacobson suggestion he indicates the packet compression kind: • TYPE_IP - header content wasn’t touched • UNCOMPRESSED_TCP – if the connection number is stamped into the header (in the IPPROTO_TCP field), but the content of the other fields didn’t change • COMPRESSED_TCP – the packet header is fully compressed

  19. Protocol Details – Cont. • According to the packet type the decompressing computer can determine how it should handle the packet • Decompression is done easily because we know what was the previous packet header content • The reversed process is done in order to decompress the packet headers

  20. Protocol Details – Cont. • The changed fields (in which we send the difference values) are added to the previous packet header stored in the decompression computer • Checksum is recalculated according to the updated fields content

  21. Assurance of the protocol • Fields content is always recoverable, because in all times we know what content was in the previous packet • We can calculate the current full packet header, in each new packet that arrives • Lost packets (during the communication process) are recovered using the regular TCP/IP protocol. Regardless to the compression process

  22. Benefit of Header Compression

  23. Benefit of Header Compression

  24. THE END

More Related