Subject: [ippm] Questions about the TWAMP reflect padding draft

From: "Walt Steverson" <[email-masked]>
Date: Thu, 2 Oct 2008 16:51:42 -0500

Al & Len,

I've got three questions/comments about
draft-morton-ippm-twamp-reflect-padding-00.

Question #1:
The ability for the Session-Sender to store extra information in the
test packet padding seems like a useful capability.  However, I'm
uncertain about how the "reflect and operate on padding bits" mode
would work.  Wouldn't the Session-Sender and Session-Reflector have to
agree on the format of the data within the reflected padding?  Would
the negotiation of how to treat the reflected padding consume more
mode bits or would the setting of the "reflect and operate on padding
bits" flag imply a format for the reflected padding?

Question #2:
In section 4.1.2 of the draft it states:  "IF the test packet length
is truncated within this field, THEN ALL packet padding MUST be
reflected by Session-Reflectors using this feature."  I take this to
mean that if the padding-to-be-reflected length is greater than the
normal length of the test packet padding then the Session-Reflector
will increase the size of the packet padding to ensure that all of the
padding-to-be-reflected will fit.  Is that the case or will the
padding-to-be-reflected be truncated to fit inside the normal length
of the test packet padding?  If the two packet padding lengths are
incompatible which one wins?  Would it be easier to specify in the
draft that the padding-to-be-reflected length MUST be less than or
equal to the amount of test packet padding that the Session-Reflector
will insert?

Question #3:
What happens when the Control-Client sends a Request-TW-Session
message with a padding-to-be-reflected length of 12 bytes and the
Server responds by accepting but specifies a length of 6 bytes in the
padding-to-be-reflected length field?  It seems to me as though the
padding-to-be-reflected length field in the Accept-Session message is
only useful when the session is not accepted in which case it can
provide feedback to the client about what the acceptable value would
have been.  Otherwise if the test session is accepted the
padding-to-be-reflected length field in the Accept-Session message
MUST match the length specified in the Request-TW-Session message.

Thanks,
Walt
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Fri, 03 Oct 2008 12:26:33 -0400

Walt,

thanks for you interest and questions, replies below,

At 05:51 PM 10/2/2008, Walt Steverson wrote:
>...

Yes and yes. "reflect AND operate" is a complicated feature, and
more development is needed.  I think that a capability to
communicate a manufacturer ID and version code might be needed.
I need to discuss this particular feature with Len some more.
It was also something I mentioned in the IETF-72 slides, which were
more advanced than the draft.

>padding-to-be-reflected will fit.

That's one way to read it, but the sentence needs clarification.
We were thinking of the case where the Session-Reflector would
truncate the padding, such that the IP info fields of test packets
are the same length from Sender->Reflector and Reflector->Sender.
The larger TWAMP-Test Reflector Packet format causes this issue.

>Is that the case or will the

Yes, that's a good way to do it.

>MUST match the length specified in the Request-TW-Session message.

These are valid considerations, given the function that the
current field name implies. We definitely need to add
complete descriptions for ALL new fields, and will do so.

What we really meant here was, for each of the two formats:

Request-TW-Session   Actual Octets to be reflected
Accept Session       Actual Octets being reflected

It's confusing because there was never any padding in these messages,
just some MBZ available for the future (now), which I incorrectly
referred to as "padding".

So, rather than a length field as the name implies,
this is a 2 octet field that the Control-Client can expect
compliant Servers to reflect in the Accept Session message.
That's how we saw it, at least.

We probably should have named this memo: Reflect Octets Feature

We've been working on the 01 version off and on
since July, trying to clean-up some points like these.

stay tuned, and thanks again,
Al