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

[Xiangsong Cui <[e-mail]>]

Hi Svante,

Thanks for your reply, too.

I would like to discuss these issues one by one, imho if the rationale is
incorrect we needn't to waste time on the details.

Best regards,
Xiangsong


> -----Original Message-----
> From: Svante Ekelin [mailto:[e-mail]]
> Sent: Tuesday, May 03, 2011 10:21 PM
> To: Christofer Flinta; Xiangsong Cui; 'Henk Uijterwaal'; [e-mail]
> Subject: RE: [ippm] draft-baillargeon-ippm-twamp-value-added-octets
> 
> Hi Xiangsong,
> 
> Christofer already answered your first comment, and I will try to answer
the
> questions in the other two comments you made.
> 
> As noted below by Christofer, an aim of this draft is extending TWAMP to
> provide a mechanism which will allow capacity measurement in both the
> forward and reverse path, by transmitting test packets as a train at a
specified
> rate in the forward path, and then reflected as a train with another
specified
> rate in the reverse path.
> 
> So, with regard to your second comment, as the controller (or the
> Session-Sender) may be engaged in multiple concurrent measurement
sessions,
> it needs to be able to identify to which session a reflected test packet
belongs,
> i.e. demultiplexing.
> 
> As for the third comment, the first MUST is due to the fact that the
controller
> needs to be able to specify the rate of the train in the reverse path. As
you
> quote from RFC5357, the send schedule for test packets is not used in the
> baseline TWAMP. The same is true for the new proposed TWAMP mode. The
> MAY statement in RFC5357 regarding the autonomous decision on the send
> schedule at the source is not in conflict with the MUST statement in the
draft.
> For instance, the actual inter-packet interval may be autonomously decided
by
> the Control-Client and Session-Sender, or it may be done by another node
or
> application, but the decision MUST be known at the source since the
> destination (e.g Session-Reflector) is only reflecting the test packets at
the
> specified rate.
> 
> The second MUST is simply a statement of the size relation between the
packet
> interval and the transmission time tt, as is illustrated in the picture on
page 5
> of the draft.
> 
> Hope this helps,
> -- Svante
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Christofer Flinta
> Sent: den 3 maj 2011 12:15
> 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. Our expected output would thus be:
> Forward Capacity and Reverse Capacity.
> 
> TWAMP in its currently form cannot provide capacity estimates separatly 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. Capacity
> estimates can therefore only be provided in the forward direction in a
current
> TWAMP system.
> 
> 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. This way the send rate can be controlled in both directions.
> 
> 
> 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
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm