Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets

[Xiangsong Cui <[e-mail]>]

Hi Christofer,

Thanks for your reply, please see my comments inline.

> -----Original Message-----
> From: Christofer Flinta [mailto:[e-mail]]
> Sent: Tuesday, May 03, 2011 6:15 PM
> To: Xiangsong Cui; 'Henk Uijterwaal'; [e-mail]
> Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> Hi Xiangsong,
> 
> Thanks for your input. I will try to answer the questions in your first
comment.
> 
> This draft is trying to provide a means for measuring the capacity in both
the
> forward and reverse directions as two separate measurements. This is
similar
> to the current capabilities of TWAMP, where e.g. delay and packet loss can
be
> measured separately in both directions. 

No, I don't think they are similar, because, round-trip delay, which is a
metric defined in RFC2681, is a "metric", however, we have no any definition
on "round-trip path capacity" metric, right?
What is more important, the round-trip delay metric is meaningful, for
example, in TCP, the TCP sender depends on the ACK clock to increase its
window, which is very relevant to the RTT metric. But what is the meaning of
round-trip path capacity metric?

Our expected output would thus be:
> Forward Capacity and Reverse Capacity.

Yes, I do know your expectation, you are expecting Forward Capacity /and/
Reverse Capacity, you are not needing the capacity of "Forward Capacity
/plus/ Reverse Capacity". Why you not utilize the one-way test on forward
path and reverse path? Why you have to couple the two independent metrics
together, and use the two-way test to cover the two one-way metrics?

> 
> TWAMP in its currently form cannot provide capacity estimates separatly in
> both directions. 

Yes, I think you are right on this sentence. But I think you are using the
wrong tool here, the same question, why you like to use TWAMP for metrics
"separately in both directions", why not OWAMP "separately in both
directions"?

Today we may send trains of packets in the forward direction
> and have those packets reflected back to the sender by the reflector. The
send
> rate of each train in the forward direction can be controlled by the
sender,
> which is needed for all capacity measuring methods. However, the send rate
of
> the reflected trains in the reverse direction cannot be controlled, since
each
> packet is reflected back as soon as it arrives at the reflector. 

Yes, and I guess this is the intention of RFC5357's co-authors (or IPPM WG),
there is no MUST or SHOULD, and RFC5357 reads "In the case of TWAMP Light,
the Session-Reflector does not necessarily have knowledge of the session
state" (Note this statement is from informative appendix).

Capacity
> estimates can therefore only be provided in the forward direction in a
current
> TWAMP system.

I think this is just because we only have one-way capacity (if you are
talking about capacity metric defined in RFC5136).

> 
> The aim of this draft is to extend TWAMP with a mechanism that lets the
> reflector store the packets of a train and then send each train back at a
specific
> rate.

It seems you are changing the session-reflector to "session-receiver plus
session-sender", right?


 This way the send rate can be controlled in both directions.

But the paths in the two directions are different and independent. And TWAMP
is not equal to "local OWAMP plus remote OWAMP", I think.

Best regards,
Xiangsong

> 
> 
> I hope this gave some clarification.
> Christofer
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Xiangsong Cui
> Sent: den 3 maj 2011 05:43
> To: 'Henk Uijterwaal'; [e-mail]
> Subject: Re: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> Hi Henk,
> 
> Sorry for the late comments.
> 
> I take a quick look on this draft and have some comments.
> 
> First, this draft seems like about capacity, e.g. path capacity,
>    This memo describes the optional extensions to the standard TWAMP
>    test protocol for identifying test sessions and packet trains, and
>    for measuring capacity metrics like the available path capacity,
>    tight section capacity and UDP throughput in the forward and reverse
>    path directions. (copied from abstract)
> 
> But, we all know that path is a unidirectional concept, so I don't
understand,
> why we need the two-way test to measure the "path capacity"? Why not the
> one-way test? For example, in the ADSL/3G/4G/etc. network, the upstream
> path and downstream path provide different "capacity", how can the two-way
> test be applied? And what is the expected "path capacity" metric result in
this
> approach?
> 
> 
> Second, the motivation of this draft, the first challenge is "The
different trains
> within a session cannot be differentiated" (copied from minutes), and the
draft
> reads
>    "The controller (or the Session-Sender) requires a method for
>    demultiplexing the received test packets to the correct test session
>    especially when it manages multiple active test sessions. "
> 
> where is the requirement from? Why the controller cannot set up multiple
> control sessions to manage the multiple test sessions separately?
> 
> 
> Third, section 3 reads,
> 
>    The packet interval between consecutive packets for each train sent
>    by the Session-Sender and reflected by the Session-Reflector MUST be
>    calculated and determined by the controller or an application or
>    entity communicating with the controller. [...]
> 
>    The transmission time tt to send one packet (i.e. determined by the
>    interface speed and the IP packet size) is also shown in the picture.
>    Observe that the packet interval MUST be larger than or equal to tt.
> 
> Why we need the two "MUST"? Section 3.6 of RFC5357 tells us:
> 
>    The send schedule for test packets defined in Section 3.6 of OWAMP
>    [RFC4656] is not used in TWAMP.  The Control-Client and Session-
>    Sender MAY autonomously decide the send schedule.  The Session-
>    Reflector SHOULD return each test packet to the Session-Sender as
>    quickly as possible.
> 
> 
> As a conclusion, I DISAGREE with it BEFORE I was told the answers.
> 
> Best regards,
> Xiangsong
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Henk Uijterwaal
> > Sent: Thursday, April 07, 2011 4:13 PM
> > To: [e-mail]
> > Subject: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> >
> > IPPM group,
> >
> > In Prague, Steve and colleagues presented
> > draft-baillargeon-ippm-twamp-value-added-octets and asked if this can
> become
> > a
> > WG document.  If you support
> > this idea or disagree with it, please speak up on the list before
> > April
> 21.
> >
> > Henk (as WG chair)
> >
> > --
> >
>
----------------------------------------------------------------------------
> --
> > Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
> > RIPE NCC
> > http://www.xs4all.nl/~henku
> >                                           Phone: [phone]
> >
>
----------------------------------------------------------------------------
> --
> >
> > There appears to have been a collective retreat from reality that day.
> >                                  (John Glanfield, on an engineering
> > project)
> > _______________________________________________
> > ippm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ippm
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm