Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 6 May 2013 17:16:34 +0000

Thanks. That was my point too.

-Samita

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guangqing Deng
Sent: Monday, April 29, 2013 10:11 AM
To: ippm
Subject: Re: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt

It is revealed that the proportion of Internet traffic caused by peer-to-peer file and video sharing is still not low, see http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html. Also, it is predicted that the mobile data traffic will increase quickly in the next years. With the development of wireless access technology, people are increasingly inclined to upload the pictures, audios and videos gathered by their mobile phones to social websites and so on for sharing. In a word, Internet users are not only downloading content from but also creating and uploading content to Internet (and other Internet users).So it may be necessary to let this document allow both symmetric and asymmetric packet sizes and rates in forward and reverse direction.

________________________________
Guangqing Deng
cnnic

From: Samita Chakrabarti<mailto:[email-masked]>
Date: 2013-04-03 09:21
To: [email-masked]<mailto:[email-masked]>; Brian Trammell<mailto:[email-masked]>
Subject: [ippm] ietf86 follow-up: draft-ietf-ippm-rate-problem-02.txt

Hello :

This is regarding my comment at the IETF86 ippm meeting for the section 5 (Test Protocol Control & Generation Requirements) section.
Toward the end of the section, the document states:
"The ability to control packet size on the tested path and enable
asymmetrical packet size testing in a two-way architecture are
REQUIRED."

Request: Relax the requirement for "assymetrical" packet size so that the requirement document allows both symmetric and assymetric packet sizes in forward and reverse direction.

I was asked to provide a usecase for the request and here it is:
Normally in fixed Broadband network, so far we are mostly interested with data traffic download and thus we can see 80/20 (apprx) traffic distribution in forward and reverse direction. Most often in the forward path we have actual traffic packets and in upward direction it is most likely short packet sizes due to acknowledgements etc.
However, looking forward in current and future deployment and in Mobile Broadband networks when we consider applications like VoLTE, peer-to-peer communication, video-chat etc. we can easily expect that forward and reverse direction traffic rate and sizes are equivalent.  Since the converged network carries both mobile and fixed broadband traffic, it is important for many carriers to measure the IP-network performance by using active measurement protocol with same packet size of the traffic and in some cases with same rate in both directions ( i,e both symmetric and assymetric).
Thus, we will need to allow both symmetric and assymetric measurement packet sizes and rates in forward and reverse direction.
Hope this helps in understanding the requirement.

Best regards,
-Samita

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 May 2013 10:35:41 -0700

On Apr 2, 2013 9:21 PM, "Samita Chakrabarti" <
[email-masked]> wrote:
>
>
> Hello :
>
> This is regarding my comment at the IETF86 ippm meeting for the section 5
(Test Protocol Control & Generation Requirements) section.
> Request: Relax the requirement for "assymetrical" packet size so that the
requirement document allows both symmetric and assymetric packet sizes in
forward and reverse direction.
> Normally in fixed Broadband network, so far we are mostly interested with
data traffic download and thus we can see 80/20 (apprx) traffic
distribution in forward and reverse direction.

Incidentally I have been collecting data from a business cable user
configured for 20mbit down and 7 Mbit up.

Packets in each direction is nearly symmetrical 89% ratio.

Bytes was 48%. An astounding percentage (over half) were marked CS1.

Furthermore fq-codel is enabled on the uplink and it dropped 3.3% of the
packets marked background over a 10 day period.

So I think in the age of tcp window scaling… gdrive and the like some of
our assumptions regarding edge network asymmetry already need to be
revisited and analysis of stuff like my small scale testbed ramped up.

Most often in the forward path we have actual traffic packets and in upward
direction it is most likely short packet sizes due to acknowledgements etc.
> However, looking forward in current and future deployment and in Mobile
Broadband networks when we consider applications like VoLTE, peer-to-peer
communication, video-chat etc. we can easily expect that forward and
reverse direction traffic rate and sizes are equivalent.  Since the
converged network carries both mobile and fixed broadband traffic, it is
important for many carriers to measure the IP-network performance by using
active measurement protocol with same packet size of the traffic and in
some cases with same rate in both directions ( i,e both symmetric and
assymetric).
> Thus, we will need to allow both symmetric and assymetric measurement
packet sizes and rates in forward and reverse direction.
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>