[e2e] Satellite Date Rates

[David P. Reed]

This just triggered a thought on my part that might be worth following 
up.   Why not use erasure-coding (tornado code or digital fountain) as 
the basis of recovery for lost packets on such long-delay links?

This wouldn't reduce the latency for any individual lost packet, of 
course, but would allow "optimistic retransmission" (i.e. graceful 
blending with an FEC strategy, if the "retransmission" is done before 
the packet loss is known).

If no one has invented this yet, please note that this email is prior 
art, and blocks any attempt to patent the idea.

Arjuna Sathiaseelan wrote:

>Dear Lloyd,
>  Thanks for your explainations. I am writing down the details provided by
>Sally Floyd's RR-TCP:Reordering Robust TCP paper:
>
>Satellite links have very long RTTs, typically on the order of several
>hundred milliseconds. To keep the pipe full,link-layer retransmission
>protocols for such links must continue sending subsequent packets while
>awaiting for an ACK or NAK for a previously sent packet. Here, a
>link-layer retransmission is reordered by however many packets were sent
>between the original transmission of that packet and the return of the ACK
>or NAK.
>[C.Ward, H.Choi and T.Hain. A datalink control protocol for LEO satellite
>networks providing a reliable datagram service. IEEE/ACM Transactions on
>Networking, 3(1):91-103,Feb 1995.]
>
>I was wondering whether this causes any reordering in GEO satellites?
>
>Regards,
>Arjuna
>
>
>
>  
>
>>>Reordering in satellites occurs mainly due to link level retransmissions
>>>      
>>>
>>It does? Can you give us evidence supporting that claim?
>>
>>(People tend to presume a satellite channel is more errored than it
>>is. You need a BER better than 10e-5 to carry IP traffic well, so you
>>dimension coding for the channel appropriately. A 45MHz transponder
>>with an HDLC serial stream going through it may have no link layer to
>>speak of.)
>>
>>If the link layer is causing massive reordering, it may not be
>>designed well for IP traffic - see RFC3366 section 3.1.
>>    
>>
>
>
>
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dpreed.vcf
Type: text/x-vcard
Size: 113 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20041126/3c40d67e/dpreed.vcf