[e2e] What's wrong with this picture?
detlef.bosau at web.de
Fri Sep 11 08:20:19 PDT 2009
> [ZAU] You mean the modulation, and not line coding? In any case, I am
To my knowledge, "modulation" and "line coding" are used synonymously.
> surprised that a change in modulation would change the delay (or service
> time, for that matter), by so much.
Perhaps not that much, but in Germany we say: "Kleinvieh macht auch Mist".
The translation "many a mickle makes a muckle" seems to be quite useful
In addition, it's not only the line coding but typically you adapt the
channel coding and puncturing as well.
> By a variation in modulation, I would
> expect a change in data rate but not in the delay.
No. I refer to common sense ;-)
What is "data rate" at all?
In wireless networks, you do not have a "serialization delay" which
spreads, say, 1000 bit into a block of 1 ms temporal duration. Instead,
this 1000 bits are often separated into quite a number of "transport
blocks" of, say, 200 bit or less (depending on the channel's condition
of course) and each of these blocks is serviced then. Some may be sent
once, others twice, some even three times until they are successfully
read at the receiver - if this happens at all.
You cannot tell the necessary number of transmissions in advance. So,
you cannot predict the time needed to convey this amount of data along a
given line. This holds particularly true in systems with variable
For this reason, you may well talk about the time needed to convey a
transport block. Or, eventualy, the time needed to convey a packet. But
it does not really make sense to talk about a "rate" here, because this
"rate" may change every few bits in a packet.
>> For quite a few days now, I'm thinking on whether this delay variation
>> may even affect the algorithms for TCP RTO calculation (refer to Edge's
>> paper and its assumptions).
>> I'm not surprised about a multimodal behaviour here. If, I would be
>> surprised to see _only_ two modes here.
> [ZAU] If I assume that the change in modulation does, in fact, impact the
> delay (for whatever reason!),
It affects the time needed to convey a certain amount of data from the
sender to the receiver. Hence, it directly affects the RTT in TCP.
> then I will NOT be surprised to see only two
> modes here. There are only three possible modulations in HSDPA and it is not
Three modulations, actually one channel coding (to my knowlege: Turbo
Code 1/3), quite a few transport lengths and appropriate puncturing
schemes and code occupations. Please keep in mind that HSDPA transport
blocks are "wrapped around" a number of channelization codes.
In addition, the number of transmission attempts for a block may vary.
> [ZAU] At one time, WLAN uses one of the two modulation schemes (well, 11g to
> be precise!) which are DSSS
DSSS is a spreading scheme, not coding. Coding / Modulation would be
QPSK here or 16 QAM respectively.
> and OFDM but a number of connection speeds on
> each of these modulations. And yes, HSDPA uses one of the three modulation
neither DSSS nor OFDM ;-) (I'm not quite sure here, but I think, the
channelization is achieved using Walsh-Hadamard Codes here.)
> schemes. In both cases, the modulation scheme and data rates at a given
> point in time are selected based on the channel conditions.
However, this is the rate data is _sent_ with.
The rate, data is _successfully_ read with, may be different as we have
to take into account retransmissions here.
> [ZAU] I am a bit confused here, are we mixing up throughput and delay here?
Hm. Don't worry, I don't ;-)
Detlef Bosau Galileistraße 30 70565 Stuttgart
phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau
ICQ: 566129673 http://firstname.lastname@example.org
More information about the end2end-interest