[e2e] local recovery or not local recovery, was: Re: Satellite networks latency and data corruption

alok alokdube at hotpop.com
Tue Jul 5 06:27:01 PDT 2005


Hi,

Thank you for the response..

>
> This is perhaps a possible problem for CETEN, where a correct 
> implementation requests floating point calculation for each IP 
> datagram.  (Perhaps, one can improve the algorithm in this respect.)
>
> To illustrate the importance of this matter, please consider the IPv6 
> header: Because there was no compelling reason for spending this 
> processing effort, one has _left_ _out_ the header checksum!
>
I prefer being silent on the matter :-)

> For 3G networks, my position is that the gateways between Internet and 
> mobile network are typically quite large computer systems, each one 
> serving some few hundreds of flows. In this case, the effort is 
> acceptable.
>
> In satellite networks: I don´t know. Particularly the state variables 
> for ARQ in high bandwidth systems may turn out inacceptable high.
>
> 2.: Fairness:
>
> If ARQ is placed on the end system, the whole network path "enjoys" 
> necessary retransmissions. Particularly, when a packet must be sent 
> 100 times or more to be successfuly received ad least once, it may 
> increase the network performance to plate ARQ on intermediate sywtems.
>
if it is wire line/fibre, i think we do not have to worry about losses.

> Once again on 3G networks: Typically, 3G networks are only used as 
> access line. So the major part of the path typically resides in the 
> wirebound internet. Therefore, it makes sense not to bother ther 
> internet with retransmissions. Even more, ARQ in 3G networks is done 
> on radio block level, which is more efficient than ARQ on pakcet level.
>
well I did see your website, but ....what is "3G"?
it does not use anything but the same fiber and copper or media than was 
already there, right?

> However, in satellite networks, I can imagine that the bottleneck is 
> really the satellite link itself. In that case, it would make only a 
> minor difference, if ARQ is placed on IS or ES.
>
>
Yes I wanted to know if there are numbers when done on ES and how it 
impacts the channel utilization on intermediate hops?

> 3.: User perspective:
>
> How long does it take for a packet to be delivered?
>
> Again: On a 3G network, the major transission time is spent on the 
> Intentet, in case a _RAW_ channel _WITHOUT_ ARQ/RLP is used.
> Let´s consider a latency 50 ms and 100 transmissions, than a user will 
> see 5 s STT latency for a packet.
>
> When the same packet could be sucessfully delivered via RLP and STT 
> would be increased by 100 ms for that reason, STT would be 150 ms. 
> This is less than 5 s, and this is preferable to the user.
>
> Satellite networks: Here the major time is spent on the satellite link.
>
> In summary, I´m not quite sure but I can imagine that in satellite 
> networks error recovery is left to the end systems. 


I think not, perhaps someone can confirm.

> I think the error recovery effort for IS can turn out unduly high with 
> not that much benefit for fairness and user.
>
> Basically, high costs (1.) are an argument for (a), utilization and 
> good user performance (2., 3.) are an argument for (b).
>
> It is a tradeoff.
>
>>
>> How is (a) different from (b) in terms of effective utilization? 
>> Obviously it is true if an end point A is talking to B and C :
>
>
> This is mainly covered by 2. Fairness.
>
> Of couse, the utilization of a link decreases if it is fed up with 
> retransmissions only.
>
> I think, the consideration can turn out quite different, depending on 
> the actual scenario: E.g. a satellite mobile phone could be attached 
> to the Internnet. Or a satellite link could be used for Internet 
> backbone connections, perhaps wheather dependent in combination with a 
> fibre link.
>
By fairness, do you mean that "i use up someone else's 
space/time/bandwidth"? no that is not what I was asking. What on the 
internet is "fairness"?

I just wanted to know what the results are, if any, when ARQ is done 
ES<==>ES.

-thanks
Alok


More information about the end2end-interest mailing list