[e2e] What's wrong with this picture?

Thu Sep 10 20:43:09 PDT 2009

> -----Original Message-----
> From: end2end-interest-bounces at postel.org [mailto:end2end-interest-
> bounces at postel.org] On Behalf Of Detlef Bosau
> Sent: Thursday, September 10, 2009 10:24 PM
> To: end2end-interest at postel.org
> Cc: David P. Reed
> Subject: Re: [e2e] What's wrong with this picture?
> 
> Dominik Kaspar wrote:
> >
> > A CDF illustration of the results is available here:
> > http://home.simula.no/~kaspar/static/cdf-hsdpa-rtt-00.png
> >
> > What is the reason of these two modes? Is it caused by adaptive
> > modulation and coding on the physical layer? If so, why does it affect
> > the delay so much? I would only expect a reduced bandwidth, but not
> > much change in delay...
> >
> >
> 
> I'm a bit curious about this discussion. I really thought, these things
> were understood, and it's only me, who doen't know the literature.
> 
> A remarkable property of HSDPA is that service times may vary on an
> _extremely_ large range.
> 
> This is due to variations in
> - line coding,

[ZAU] You mean the modulation, and not line coding? In any case, I am
surprised that a change in modulation would change the delay (or service
time, for that matter), by so much. By a variation in modulation, I would
expect a change in data rate but not in the delay. Is there a study that you
are referring to?

> - channel coding,
> - transport block length, i.e. code usage and  puncturing and
> - MAC delay.
> 
> 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!), then I will NOT be surprised to see only two
modes here. There are only three possible modulations in HSDPA and it is not
unusual that only two of them are used. This is because HSDPA uses a
particular modulation based on channel conditions, and it is okay to not
observe extreme variations in the channel conditions.

It would be nice if the experiment is repeated when the laptop with HSDPA
card moved around -- but still no guarantee that all the three modulations
will get a chance to be utlized. This all assumes that modulation affects
the delay significantly, something I am still unable to make peace with.

> To my knowledge, WLAN uses only two line codings (HSDPA and the like may
> use three, is this correct? QPSK, 16 QAM and sometimes even 64 QAM?),
> however, there is less variation in channel coding and puncturing etc.
> like in
> HSDPA.

[ZAU] At one time, WLAN uses one of the two modulation schemes (well, 11g to
be precise!) which are DSSS and OFDM but a number of connection speeds on
each of these modulations. And yes, HSDPA uses one of the three modulation
schemes. In both cases, the modulation scheme and data rates at a given
point in time are selected based on the channel conditions.

> I gathered some results from the EURANE project and related research
> projects on http://www.detlef-bosau.de/index.php?select=symbols
> in order to have an overview, at least for myself, about the delay
> variation in HSDPA.
> 
> Please note, that even a transport block's "Payload" may vary from 176
> to 21576 bits. And HSDPA may repeat a transport block up to three times.
> So, without MAC and propagation latency, the HSDPA throughput (for
> _code_ bits, not even for _information_ bits) may vary from 21576 bits /
> 2 ms = 10798000 bits/second downto 176 bits / 6 ms (eq. three sending
> attemps) = 29333 bits/s. This is a factor of nearly 369.
> 
> And I neglected
> - any propagation delay,
> - the times used for ACKs/NAKs on L2,
> - MAC delays.
> 
> If you think about up to 8 terminals in a cell, you may well see a
> certain throughput (gross) (? I always mix up gross and net bit rate
> here, I'm German, our chancelor always gets confused with gross and
> net....) at one time, and a 2500 times larger one at another time.
> 
> And of course, you're likely to see anything in between. So, it's
> basically somewhat astonishing to see _only_ two modes here....

[ZAU] I am a bit confused here, are we mixing up throughput and delay here? 

Best regards,
Zartash

> Do we have more precise information about the scenario?
> 
> Detlef
> 
> 
> > Greetings,
> > Dominik
> >
> >
> > On Tue, Sep 8, 2009 at 7:56 PM, David P. Reed<dpreed at reed.com> wrote:
> >
> >> I should not have been so cute - I didn't really want to pick on the
> >> operator involved, because I suspect that other 3G operators around the
> >> world probably use the same equipment and same rough configuration.
> >>
> >> The ping and traceroute were from Chicago, using an ATT Mercury data
> modem,
> >> the same channel as the Apple iPhones use, but it's much easier to run
> test
> >> suites from my netbook.
> >>
> >> Here's the same test from another time of day, early Sunday morning,
> when
> >> things were working well.
> >>
> >> Note that I ran the test over the entire labor day weekend at
> intervals.
> >> The end-to-end ping time was bimodal.  Either it pegged at over 5000
> >> milliseconds, or happily sat at under 200 milliseconds.   Exactly what
> one
> >> would expect if TCP congestion control were disabled by overbuffering
> in a
> >> router preceding the bottleneck link shared by many users.
> >>
> >> ------------------------------
> >>
> >> $ ping lcs.mit.edu
> >> PING lcs.mit.edu (128.30.2.121) 56(84) bytes of data.
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=1 ttl=44
> >> time=209 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=2 ttl=44
> >> time=118 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=3 ttl=44
> >> time=166 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=4 ttl=44
> >> time=165 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=5 ttl=44
> >> time=224 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=6 ttl=44
> >> time=183 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=7 ttl=44
> >> time=224 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=8 ttl=44
> >> time=181 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=9 ttl=44
> >> time=220 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=10 ttl=44
> >> time=179 ms
> >> 64 bytes from zermatt.csail.mit.edu (128.30.2.121): icmp_seq=11 ttl=44
> >> time=219 ms
> >> ^C
> >> --- lcs.mit.edu ping statistics ---
> >> 11 packets transmitted, 11 received, 0% packet loss, time 10780ms
> >> rtt min/avg/max/mdev = 118.008/190.547/224.960/31.772 ms
> >> $ traceroute lcs.mit.edu
> >> traceroute to lcs.mit.edu (128.30.2.121), 30 hops max, 60 byte packets
> >>  1  * * *
> >>  2  172.26.248.2 (172.26.248.2)  178.725 ms  178.568 ms  179.500 ms
> >>  3  * * *
> >>  4  172.16.192.34 (172.16.192.34)  187.794 ms  187.677 ms  207.527 ms
> >>  5  12.88.7.205 (12.88.7.205)  207.416 ms  208.325 ms  69.630 ms
> >>  6  cr84.cgcil.ip.att.net (12.122.152.134)  79.425 ms  89.227 ms
> 90.083 ms
> >>  7  cr2.cgcil.ip.att.net (12.123.7.250)  98.679 ms  90.727 ms  91.576
> ms
> >>  8  ggr2.cgcil.ip.att.net (12.122.132.137)  72.728 ms  89.628 ms
> 88.825 ms
> >>  9  192.205.33.186 (192.205.33.186)  89.787 ms  89.794 ms  80.918 ms
> >> 10  ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158)  79.895 ms  70.927
> ms
> >>  78.817 ms
> >> 11  ae-1-5.bar1.Boston1.Level3.net (4.69.140.93)  107.820 ms  156.892
> ms
> >>  140.711 ms
> >> 12  ae-7-7.car1.Boston1.Level3.net (4.69.132.241)  139.638 ms  139.764
> ms
> >>  129.853 ms
> >> 13  MASSACHUSET.car1.Boston1.Level3.net (4.53.48.98)  149.595 ms
> 154.366 ms
> >>  152.225 ms
> >> 14  B24-RTR-2-BACKBONE.MIT.EDU (18.168.0.23)  146.808 ms  129.801 ms
> 89.659
> >> ms
> >> 15  MITNET.TRANTOR.CSAIL.MIT.EDU (18.4.7.65)  109.463 ms  118.818 ms
> 91.727
> >> ms
> >> 16  trantor.kalgan.csail.mit.edu (128.30.0.246)  91.541 ms  88.768 ms
> >>  85.837 ms
> >> 17  zermatt.csail.mit.edu (128.30.2.121)  117.581 ms  116.564 ms
> 103.569 ms
> >> $
> >>
> >>
> >>
> >>
> >
> >
> 
> 
> --
> 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
> 