mihai, problema pusa de tine nu este deloc simpla ;) si multe minti
'luminate' din tari civilizate cu banda super larga isi ard neuronii cu ea :)
so, subectu are treaba in special cu TCP pentru _retele broadband afectate de
delay mare_ (de ordinul sutelor de ms, satelitu' e departe!), cum este cazul
aici.
Trei chestiuni apar in principal, scuze ca e english, nu e timp pentru
traduceri din pacate si de altfel nici nu e nevoie ;-)...
1. window scaling
2. time stamping
3. ACK-uri selective
(toate trei vor fi incorporate in TCP suite v6)
1.:
de ce apar probleme:
"In a broadband satellite communication system, the high data rate and the
large propagation delay cause a large
amount of data to be �in flight� between the endpoints of the communication
at any given time.
Consider as an example a T1-rate (1.544 Mbps) channel through a geostationary
satellite, at
22,300 miles altitude. In such a system, the propagation delay from the
earth's surface to the
satellite exceeds 120 ms. Accordingly, more than 120 x 4=480 ms elapses
between the time a byte
is sent in this system and the acknowledgment returns via the satellite.
Multiplying this �round-trip-
time� by the data transmission rate yields a so-called bandwidth-delay
product of more than
1544000 x 0.480=741120 bits, or 90.5 kilobytes (kB). The bandwidth-delay
product represents
the maximum amount of information which can simultaneously be in transit
between the endpoints
of the communication. However, TCP has a maximum window size of 64 kB (65536
bytes),
which limits the throughput achievable in the system to 65536/0.480=136.5333
kB/s, or 1.092
Mb/s, less than three-quarters of the T1 channel rate. This problem of
unsuitably small window
size is not unique to satellite communication, for it is found in other
modern high-speed networks
as well; it is simply exacerbated over satellites because of the large
propagation delay."
pentru partea cu window scaling sint propuse solutii care sa mearga cu
fereastra de pina la 1GB (65536x2^14)!
(RFC 1072)
2.:
TCP provides 32 bits for specifying a sequence number for the frame (in TCP
parlance, the segment). In a broadband
network, the corresponding space of 2 31 sequence numbers can be exhausted
quickly and then
reused. This �rollover� or �wrap-around� of the sequence number can lead to
ambiguities in
acknowledging frames and in providing them in proper order to higher-level
applications. A
solution to this problem has been proposed that each TCP segment should
bear a time stamp. With such time-stamping, the ambiguity caused by
wrap-around can be
eliminated.
(RFC 1323)
3.:
TCP�s error control strategy is based upon an assumption of segment losses
being due to
congestion. While congestion can indeed cause frame losses, the imperfections
of the satellite
channel cause errors as well. The go-back-N sort of retransmission scheme
used by TCP may be
appropriate for congestion-induced losses, but this scheme results in many
retransmissions which
are unnecessary and which correspondingly reduce the throughput in the case
of random losses
[62]. Now while TCP�s fast retransmit/fast recovery algorithm indeed
retransmits a single frame
lost randomly, TCP does not provide for the receiving entity to specify
multiple randomly lost
individual frames. Correspondingly, there is no provision for retransmitting
multiple non-contiguous
individual frames. A solution to such shortcomings is proposed in RFC 2018,
which suggests using selective acknowledgments. With this method, TCP segment
numbers are
used to specify upper and lower edges of blocks of received bytes. A TCP
implementation
supporting this option can infer from such information which segments need to
be retransmitted.
cam asta...
daca e de optimizat, din punctul de vedere al NOC-ului mai apar si alte
nebunii (din cauza return channelului asimetric, in general pe xDSL),
'goodies' care sint valabile numai pe retele hibride ;)
subiectul este amplu dezbatut si studiat in multe 'technical reports' la:
http://www.isr.umd.edu/CSHCN/
so...tu te-ai gindit foarte bine, cresterea window size-ului pentru transfer
pe DVB e una din solutii, generall speaking.
numai bine,
radu.
--
Radu Stoian
CA Systems Manager
Deuroconsult SRL Brasov
Romania
Mihai RUSU wrote:
> hi all
>
> ma gandeam la optimizarea transferului pe DVB cand mi-a venit urmatoarea
> idee: daca pot face linux-ul (forta chiar) sa isi modifice putin politica
> prin care seteaza window-ul la conexiunile tcp in principiu ar trebui sa
> obtin o viteza sporita pe dvb (upload mai putin si proxy-ul de la DVB nu
> mai trebuie sa astepte dupa ACK-urile mele).
> dupa ce am sapat ceva vreme prin kernel am obsevat ca lucrurile nu sunt
> chiar simple (linuxul are o politica buna de schimbare a window-ului, in
> functie de calitatea conexiunii).
> in acelasi timp nefiind expert in tcp/ip programming e foarte posibil sa
> ma aberez in ce am precizat mai sus (sau cel putin sa starnesc zambete
> ironice).
> de asta dau pe lista si intreb pe altii mai "luminati" daca cresterea
> window-ului (presupunand ca se poate) ar creste viteza de download pe DVB
>
> thanks
>
> ----------------------------
> Mihai RUSU
> RoEduNet Network Engineer
> "... and what if this is as good as it gets ?"
>
> ---
> Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
> unsubscribe from this list.
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
