Subject: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

From: Christofer Flinta <[email-masked]>
Date: Thu, 12 Jun 2014 14:00:19 +0000

Hi IPPM group,

I have a comment on the rate-problem draft.

I fully agree that asymmetrical packet size can be an important feature for rate measurements. However, I don't find it necessary to have it mandatory for all types of measurements, as specified in section 5:

"The ability to control packet size on the tested path and enable
   asymmetrical packet size testing in a two-way architecture are
   REQUIRED.  This allows both the conventional symmetric packet size
   testing and asymmetrical packet size testing to employed to solve
   various aspects of rate measurement: real-time communications often
   have symmetrical streams, while file transfers have highly
   asymmetrical streams in the data and acknowledgement traffic
   directions."

In this paragraph the requirement on asymmetrical packet size is supported by two examples: real-time communications and file transfer. However, the text states that real-time communications are often symmetrical, while file transfer is asymmetrical (because of TCP ACKs). This means that the need for the asymmetrical size is actually mainly for TCP test streams, while most UDP test streams will use symmetrical size.

Therefore, I think asymmetrical size should be mandatory only for TCP test streams and optional for UDP test streams. I suggest changing the first part of the paragraph to:

"The ability to control packet size on the tested path is REQUIRED. Asymmetrical packet size testing in a two-way architecture is REQUIRED for TCP test streams and OPTIONAL for UDP test streams."

BR,
Christofer

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 12 Jun 2014 10:13:08 -0400

Hi Christofer,

This paragraph and requirement is the result of much discussion and
compromise (already).

We do not mandate measurements, but for rate measurement we mandate
the capability to control packet sizes including asymmetrical sizes.
There are circumstances where it is valid to test with UDP using
asymmetrical sizes, so we don't want to mix transport layers with
this requirement.

regards,
Al

From: ippm [mailto:[email-masked]] On Behalf Of Christofer Flinta
Sent: Thursday, June 12, 2014 10:00 AM
To: [email-masked]
Subject: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

Hi IPPM group,

BR,
Christofer

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 12 Jun 2014 14:33:36 +0000

Hi
+1 for Christopher.

There are circumstances where it is valid to test UDP bitrate using symmetrical packet sizes.
Many UDP based protocols like UDP echo plus and TWAMP can measure/estimate bitrates using symmetrical packet sizes. Another concrete example is the TWAMP extension described in RFC 6802. The standard TWAMP specs clearly recommends using symmetrical packet sizes. Why exclude existing protocols?

There were much discussion on this topic in the past but nothing has been done to address it in the draft.
I have not seen any compromise other than the text proposed by Christofer.

Regards
Steve

From: ippm [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: June-12-14 10:13 AM
To: Christofer Flinta; [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

Hi Christofer,

regards,
Al

From: ippm [mailto:[email-masked]] On Behalf Of Christofer Flinta
Sent: Thursday, June 12, 2014 10:00 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

Hi IPPM group,

BR,
Christofer

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 12 Jun 2014 17:11:19 +0200

Hi Christofer,
I'd rather stay with the current wording and requirement. Main app-layer protocols (sip, H.323, etc) are prepared to handle asymmetric streams (i.e. distinct codecs for forward and backward path) on top of UDP. We have asymmetric networks in the access and I can envision many scenarios which require asymmetry for UDP, too (unidirectional video streaming with some RTCP feedback, video-on-demand with feedback channel, asymmetric video with high res in downlink and low res in uplink, even CBR voice with distinct codecs in uplink and downlink might become reality sooner than expected with upcoming VoLTE). 
So I'd favour to extend and be more specific with respect to the text which discusses use cases, but leave the requirement as-is. 
regards Joachim

> Am 12.06.2014 um 16:00 schrieb Christofer Flinta <[email-masked]>:
> 
> Hi IPPM group,
>  
> I fully agree that asymmetrical packet size can be an important feature for rate measurements. However, I don’t find it necessary to have it mandatory for all types of measurements, as specified in section 5:
>  
> “The ability to control packet size on the tested path and enable
>    directions.”
> “The ability to control packet size on the tested path is REQUIRED. Asymmetrical packet size testing in a two-way architecture is REQUIRED for TCP test streams and OPTIONAL for UDP test streams.”
>  
> BR,
> Christofer
>  
>  
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 12 Jun 2014 16:08:37 +0000

Hi Joachim
Christofer did not say asymmetry is not needed. He is saying that both asymmetry and symmetry are valid use cases for active and passive bitrate measurements in two-way architecture. I prefer we use the new proposed text since it satisfies all.

-Steve

From: ippm [mailto:[email-masked]] On Behalf Of Joachim Fabini
Sent: June-12-14 11:11 AM
To: Christofer Flinta
Cc: [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

Hi Christofer,

Am 12.06.2014 um 16:00 schrieb Christofer Flinta <[email-masked]<mailto:[email-masked]>>:
Hi IPPM group,

BR,
Christofer

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 12 Jun 2014 09:26:15 -0700

Dear Al, et. al,
I support text change proposed by Christofer. I believe it does not limit
anything but allows more flexibility to measurement control protocol.
And I'd remind the WG that we had discussion of this particular requirement
before:

   - http://www.ietf.org/mail-archive/web/ippm/current/msg03130.html;
   <http://www.ietf.org/mail-archive/web/ippm/current/msg03130.html>

   - http://www.ietf.org/mail-archive/web/ippm/current/msg03065.html;

Regards,
Greg

On Thu, Jun 12, 2014 at 7:13 AM, MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Christofer
> Flinta
> *Sent:* Thursday, June 12, 2014 10:00 AM
> *To:* [email-masked]
> *Subject:* [ippm] WGLC for draft-ietf-ippm-rate-problem-05
>
>
>
> Hi IPPM group,
>
>
>
> I fully agree that asymmetrical packet size can be an important feature
> for rate measurements. However, I don’t find it necessary to have it
> mandatory for all types of measurements, as specified in section 5:
>
>
>
> In this paragraph the requirement on asymmetrical packet size is supported
> by two examples: real-time communications and file transfer. However, the
> text states that real-time communications are often symmetrical, while file
> transfer is asymmetrical (because of TCP ACKs). This means that the need
> for the asymmetrical size is actually mainly for TCP test streams, while
> most UDP test streams will use symmetrical size.
>
>
>
> Therefore, I think asymmetrical size should be mandatory only for TCP test
> streams and optional for UDP test streams. I suggest changing the first
> part of the paragraph to:
>
>
>
> “The ability to control packet size on the tested path is REQUIRED.
> Asymmetrical packet size testing in a two-way architecture is REQUIRED for
> TCP test streams and OPTIONAL for UDP test streams.”
>
>
>
> BR,
>
> Christofer
>
>
>
>
>

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 12 Jun 2014 21:46:48 +0200

Hi Steve,

my "asymmetric streams" should read as "streams with asymmetric packet
sizes in a two-way architecture". Please correct me if I'm wrong: my
understanding of Christopher's proposal is that streams in the forward
path which trigger streams of distinct packet size in the reverse path
should be optional.
The targeted measurement methodology/process appears to share some main
traits with some earlier, rather theoretical work I've done in another
context [1]. Therein, as part of a feasibility study, we also change
characteristics of forward link measurement streams in the reflecting
node to infer on accurate forward and reverse link one-way delay.
Seconded by findings in the 2330-update draft (in particular when
thinking of  distinct reactive/on-demand capacity allocation policies of
forward/reverse measurement path) the ability to trigger distinct packet
sizes in a two-way architecture's reverse link (for UDP) seems to me to
make sufficient sense to justify more than an "Optional".

[1]: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6553584

br
Joachim

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 12 Jun 2014 22:12:10 +0000

Hi Joachim
RECOMMENDED is probably a better way to go. 
With various Internet traffic mix, we have test results that show forward and reverse available (raw) capacities (with different loading and/or link speed and/or shaping conditions) can be estimated with a single two-way test stream  using the same test packet size (assuming the packet size does not cause fragmentation). 

I am OK with the following statement (as suggested by Christofer): The ability to control packet size on the tested path is REQUIRED. 

I still think the following statement is incomplete or misleading: Asymmetrical packet size testing in a two-way architecture is REQUIRED.

As a minimum, should it better explain when and why asymmetrical packet size testing is REQUIRED?

-Steve

-----Original Message-----
From: Joachim Fabini [mailto:[email-masked]] 
Sent: June-12-14 3:47 PM
To: Steve Baillargeon; Christofer Flinta
Cc: [email-masked]
Subject: Re: [ippm] WGLC for draft-ietf-ippm-rate-problem-05

Hi Steve,

my "asymmetric streams" should read as "streams with asymmetric packet sizes in a two-way architecture". Please correct me if I'm wrong: my understanding of Christopher's proposal is that streams in the forward path which trigger streams of distinct packet size in the reverse path should be optional.
The targeted measurement methodology/process appears to share some main traits with some earlier, rather theoretical work I've done in another context [1]. Therein, as part of a feasibility study, we also change characteristics of forward link measurement streams in the reflecting node to infer on accurate forward and reverse link one-way delay.
Seconded by findings in the 2330-update draft (in particular when thinking of  distinct reactive/on-demand capacity allocation policies of forward/reverse measurement path) the ability to trigger distinct packet sizes in a two-way architecture's reverse link (for UDP) seems to me to make sufficient sense to justify more than an "Optional".

br
Joachim

---

From: Joachim Fabini <[email-masked]>
Date: Fri, 13 Jun 2014 22:54:43 +0200

Hi Steve,

RECOMMENDED for UDP might be one way to go. However, if the rate-problem
draft becomes a RFC, it will be a feature that two-way measurement tools
may implement - as an _option_. In my opinion, asymmetric packet size
for two-way measurements is one of the main contributions of the
rate-problem draft and that justifies a REQUIRED.

Treating UDP and TCP differently with respect to forward and reverse
link packet size would make sense for me - if we know that there is no
use case for UDP. But imho there must be objective arguments why we
_discriminate_ (or privilege) one transport protocol over the other and
_not_ why we treat it in a generic way.
My personal preference for standardization would be to develop generic
solutions, advocate equal protocol treatment - unless there are good
reasons to discriminate one. I don't see such a reason for this specific
case.

I mentioned in my earlier postings some use cases for UDP, which I
believe to be realistic or become real in the next years. And,
continuing rather theoretical about transport protocol evolution:
Half-connections in DCCP target exactly the same communication pattern
which we experience for TCP. Data flow plus control flow is going in one
direction, control flow in the reverse link. This ends up in distinct
packet sizes for forward and reverse link. One can dispute about the
success of DCCP, but I like the design of the protocol as such, it has a
strong theoretical background, including requirements engineering.

To summarize my arguments: imho we should try to go the generic way
unless we have very good reasons _not_ to do so. And reactive link
behavior, combined with asymmetrical uplink/downlink like we find, e.g.,
in today's mobile cellular networks, is imho a _strong_ reason to have
REQUIRED for distinct forward/reverse link packet sizes for all
transport protocols - including UDP (*).

br
Joachim
(*) My experience is that we can trigger state changes and specific
reactive link conditions/transitions (in the context of explorative
measurements) with UDP (or ICMP) much more deterministic than we can do
with TCP.