Subject: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic

From: "[email-masked]" <[email-masked]>
Date: Mon, 8 Jun 2015 10:27:08 +0800

Dear all，
     
      As mobile phones and other smart devices are proliferating, more and more end users like directly uploading and sharing their photos, videos or other documents by data centers. 
      Besides, mobile devices emerging are fully cloud-dependent that are not equipped with much storage but rely on large storage in data centers. 
      For these reasons, a large number of Online Storage Service Providers(OSSPs),Photos Sharing Service Providers (PSSPs), and Videos Sharing Service Providers (VSSPs) emerge at a historic moment so that make upstream traffics rapidly increasing and expected to continue doing so in the future. 
      A lot of factors, such as long round-trip-time (RTT), low robustness of delivery, and transport bottlenecks, etc., lead to low upload rate, which cause poor user experiences.
      I have proposed an approach to upload acceleration transport network for upstream traffics, and the drafts was submitted. 
      This is the link, http://datatracker.ietf.org/doc/draft-qin-tsvwg-uatnut/ 
     Any comments are welcome.

   Regards,

   Xiaowei Qin

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 8 Jun 2015 10:22:39 +0100

Hi,

in the draft you write that

   According to the report in [1], throughput measurements
   from over 1.5 million mobile devices have shown that compared with an
   average downstream throughput of over 1860 Kbps, the average upstream
   throughput is only about 430 Kbps.  This is because of the adoption
   of cache techniques such as CDNs to acelerate downloading large
   content that moves the "content" closer to end users.

Really? If that is true, then the same problem will also affect non-mobile 
users. But I have access to logs that show considerably higher typical 
speeds.

I think that before this can progress, you have to show that the problem 
really is a lack of things like CDNs for upload.

Arnt

---

From: joel jaeggli <[email-masked]>
Date: Mon, 8 Jun 2015 08:36:44 -0700

On 6/7/15 7:27 PM, [email-masked] wrote:
> Dear all��
>      
>       As mobile phones and other smart devices are proliferating, more
> and more end users like directly uploading and sharing their photos,
> videos or other documents by data centers. 
>       Besides, mobile devices emerging are fully cloud-dependent that
> are not equipped with much storage but rely on large storage in data
> centers. 
>       For these reasons, a large number of Online Storage Service
> Providers(OSSPs),Photos Sharing Service Providers (PSSPs), and Videos
> Sharing Service Providers (VSSPs) emerge at a historic moment so that
> make upstream traffics rapidly increasing and expected to continue doing
> so in the future. 
>       A lot of factors, such as long round-trip-time (RTT), low
> robustness of delivery, and transport bottlenecks, etc., lead to low
> upload rate, which cause poor user experiences.
>       I have proposed an approach to upload acceleration transport
> network for upstream traffics, and the drafts was submitted. 
>       This is the
> link, http://datatracker.ietf.org/doc/draft-qin-tsvwg-uatnut/ 

HSDPA/HSUPA/LTE networks employ asymmetry in data-rates between the
tower and the handset, and the handset and the tower; so your first and
most direct source of asymmetry is right at radio access-side of things.

   just
   installing more data servers will not be enough[RFC6392].  Moving
   data server closer to the end users results in greater network
   efficiency: improved Quality of Service (QoS), increased robustness
   of delivery,and lower latency.

The only parameter that distance changes directly is bandwith
delay-product. if the carrier's network is congested it's congested
irrespective of the destination.

>    Regards,
> 
>    Xiaowei Qin
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 9 Jun 2015 10:52:33 +0800

Hi, Arnt
Thanks for the review

In your letter：

I have do test only for mobile devices, and the the report comes from: http://testmyiphone.com/stats.
If you have statistics for PC or via WiFi, could you share it? Thank you very much.

This is the latest stats:
Download:
Download tests taken 3,140,257 
Average speed 3585.44 kbps
Upload:
Upload tests taken 708,158
Average speed 630.56 kbps
The asymmetric capacity of physical links such as in ADSL may be also an factor, but many Content Service Providers (CSPs) have deployed their own CDNs or have made a business agreement with CDN providers ,such as Akamai, to move the content closer to end users for high download throughput.
In order to validate the analysis described above, I have also take a practical measurement in China Mobile Labs (located in Beijing) which is the department of the China Mobile Limited. A data server deployed in Shenzhen, situated immediately north of Hong Kong (about 2500 kilometers away from Beijing) is used to continuously wait for packets from mobile devices. 
The mobile devices is connected to Internet via TD-LTE, and content generated by mobile devices is directly uploaded to the receiver without any acceleration processing. The average upstream throughput is about 180 kbps. 
I also deploy a data server in Beijing,  the average upstream throughput can be up to 860 Mbps. 
Therefore, "moving content closer to end users results in greater network efficiency, increased robustness of delivery, and lower latency" in [rfc6707],[rfc6770],[rfc6392].
IMO, moving the "data center" closer to end users may also provide numerous benefits for uploading service: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery.

From: Arnt Gulbrandsen
Date: 2015-06-08 17:22
To: apps-discuss
Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic
Hi,

 

Arnt

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 9 Jun 2015 11:01:23 +0800

i am sorry
there is an mistake in "I also deploy a data server in Beijing,  the average upstream throughput can be up to 860 Mbps“.
That is 860 kbps.

From: [email-masked]
Date: 2015-06-09 10:52
To: Arnt Gulbrandsen; apps-discuss
Subject: Re: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic
Hi, Arnt
Thanks for the review

In your letter：

 
From: Arnt Gulbrandsen
Date: 2015-06-08 17:22
To: apps-discuss

 

Arnt

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 9 Jun 2015 11:13:52 +0800

Hi, joel
Thanks for you review.

> The only parameter that distance changes directly is bandwith delay-product. 
> if the carrier's network is congested it's congested irrespective of the destination.

Yes, i agree with you, there exists an asymmetric capacity of physical links. This because traditional Internet data services are frequently that end users download content from data centers or Content Service Providers (CSPs) distribute content to their end users, so traffic volume generated by end users account for very small proportion of all Internet traffics.
IMO，end users can get high data downstream rate than upstream not only because of asymmetric capacity of physical links， as well as of the adoption of cache techniques such as CDN.
In order to validate the analysis described above, I have also take a practical measurement in China Mobile Labs (located in Beijing) which is the department of the China Mobile Limited. A data server deployed in Shenzhen, situated immediately north of Hong Kong (about 2500 kilometers away from Beijing) is used to continuously wait for packets from mobile devices. 
The mobile devices is connected to Internet via TD-LTE, and content generated by mobile devices is directly uploaded to the receiver without any acceleration processing. The average upstream throughput is about 180 kbps. 
I also deploy a data server in Beijing,  the average upstream throughput can be up to 860 kbps. 
This because of long round-trip-time (RTT) causes large delay and inversely proportional TCP throughput，even over a relatively long distance, throughput may go from maximum to nothing.
Therefore, Content Service Providers (CSPs) have deployed their own CDNs or have made a business agreement with CDN providers ,such as Akamai, to move the content closer to end users for high download throughput.

Regards

Xiaowei Qin

From: joel jaeggli
Date: 2015-06-08 23:36
To: [email-masked]; apps-discuss
Subject: Re: [apps-discuss] An Upload Acceleration Transport Network for Upstream Traffic

   just

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 9 Jun 2015 12:04:25 +0100

[email-masked] writes:
> If you have statistics for PC or via WiFi, could you share it?

I'm afraid I cannot. I was a contractor until quite recently and there's an 
NDA. (I have signed too many NDAs.)

I can say that I didn't measure any performance difference based on hop 
count. I did measure differences for small files (speed started slow and 
then increased, and the increase was faster when the client was closer), 
and I did measure large differences based on customer ISP (we had good 
connections to some ISPs and poor to some). But not based on pure distance 
or the number of hops.

> The asymmetric capacity of physical links such as in ADSL may 
> be also an factor, but many Content Service Providers (CSPs) 
> have deployed their own CDNs or have made a business agreement 
> with CDN providers ,such as Akamai, to move the content closer 
> to end users for high download throughput.

Akamai does several things. For instance, it copies popular content to many 
servers, so file system bandwidth increases. (At work we use a CDN mostly 
for this reason.)

> In order to validate the analysis described above, I have also 
> take a practical measurement in China Mobile Labs (located in 
> Beijing) which is the department of the China Mobile Limited. A 
> data server deployed in Shenzhen, situated immediately north of 
> Hong Kong (about 2500 kilometers away from Beijing) is used to 
> continuously wait for packets from mobile devices. 
> The mobile devices is connected to Internet via TD-LTE, 
> and content generated by mobile devices is directly uploaded to 
> the receiver without any acceleration processing. The average 
> upstream throughput is about 180 kbps. 

Yes, but what's the reason for the difference? ISPs playing peering games? 
Policy routing? Some ISPs even try to detect speed tests and reallocate 
bandwidth, using products like http://www.ipoque.com/products/prx-g-series
which can be configured to do things like "permit fast transfers only if 
the other end is also our customer, the URL contains /speedtest/ or the 
packets are routed via a transit provider on this list: ..."

Arnt

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 10 Jun 2015 09:54:39 +0800

Hi,Arnt

>which can be configured to do things like "permit fast transfers only if
t>he other end is also our customer, the URL contains /speedtest/ or the
p>ackets are routed via a transit provider on this list: ..."

There may exist limitation of network bandwidth and hops delay between the two MANs , or two ISPs. And there may also exist data transmission bottlenecks between the two Telecommunication Service Providers. So, we need move the "data receiver" closer to the end user to avoid delivery bottlenecks.

>servers, so file system bandwidth increases. (At work we use a CDN mostly

Yes, I want to give an acceleration network for upstream traffic like CDNs. When end user requests to upload content to data center, the request will be redirected to an appropriate Edge Server(for instance,the ES is an access server and the user is directly attached to it), and the content is actually delivered to data center by the UATN(Upload Acceleration Transport Network).

Xiaowei Qin

From: Arnt Gulbrandsen
Date: 2015-06-09 19:04
To: apps-discuss

 

 
 
Arnt