[e2e] What's wrong with this picture?

[Detlef Bosau]

zartash wrote:
> [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 
here ;-)

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 
line/channel-coding.

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.
>
>   

Basically yes.

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 ;-)


Regards

Detlef

-- 
Detlef Bosau		Galileistraße 30	70565 Stuttgart
phone: +49 711 5208031	mobile: +49 172 6819937	skype: detlef.bosau	
ICQ: 566129673		http://detlef.bosau@web.de