[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