Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet Format?

From: Walt Steverson <[email-masked]>
Date: Sun, 1 Mar 2009 15:51:18 -0600

I do not think that the uneven boundaries on Reflected Padding will be a
problem.  That being said the proposed alternative test packet format makes
it easier in the Test-Reflector to reuse the received test packet buffer in
order to generate the response packet.  In other words, just allowing the
Test-Reflector to overwrite the Discard Fill padding can save a good bit of
work when building up responses to TWAMP-Test packets.  However, I think
that there should be only one TWAMP-Test packet format and maintaining two
ways of building up response test packets in the Test-Reflector based on the
negotiated Reflect Padding option is undesirable in my opinion.

This draft seems useful to me as a way to attach an opaque blob of data to
each TWAMP-Test packet and guarantee that it will be sent back unchanged by
the Test-Reflector to the Test-Sender.  The Test-Sender can store whatever
it wants in this payload (TLv, XML, etc.) and it should not be necessary to
formally specify its format in a TWAMP extension because the Test-Reflector
does not know or care about what the reflected padding octets represent.

On Fri, Feb 20, 2009 at 4:26 PM, Krzanowski, Roman <
[email-masked]> wrote:

> Al
> I am for the TLV structure as it would open TWAMP for future
> enhancements as well as
> For some propratary  extensions , if needed vendor specific TLV code,
> optional TLVs and so on...
> In most of the control algorithms ( and other) I see TLv as an elegant
> solution to the data structures
>
>
> We would need to preserve the compatibility with the current format but
> .. I guess this canbe done
> My 3cs..
> rmk
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Al Morton
> Sent: Friday, February 20, 2009 4:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ippm] Reflect-Octets: New TWAMP Test Packet Format?
>
> IPPM,
>
> Len Ciavattone and I introduced the possibility
> for a significant test packet format overhaul last
> November at IETF-73:
> http://www.ietf.org/proceedings/08nov/slides/ippm-4/ippm-4.htm
>
> and in the draft
> http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#secti
> on-5<http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#secti%0Aon-5>
>
> We were proposing to make some changes as part of the Reflect-Octets
> draft/work item, because it makes sense to deal with several format
> aspects at once.
>
> There were some suggestions made at the mike and captured in the
> minutes:
>
> >Open question: consider change the structure of the TWAMP structure
> >to TLV type structure to make it more extensible.
> >
> >Questions from the floor: Roman Kraznowski said he had some things he'd
> >like to add.  He'd post to the list.
>
> Please take a look at the slides and the draft
> and make further comments, so we can determine a path forward.
>
> thanks and regards,
> Al and Len
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Fri, 6 Mar 2009 08:54:08 -0800

>From an implementation perspective and in the spirit of allowing quick
turnarounds, the original timestamp location should not be juggled
around.  That would allow implementations to add the two new stamps into
the original incoming packet and send it out quickly and save having to
create a new packet or do mem-copies to temporary locations. The feature
to have the same size test packets in both directions is definitely a
plus.

On the TLV issue, if they are to be opaque then its ok to have them. Is
the spec looking to coordinate the interpretation of the TLV on the
sender?

-murtaza

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Walt Steverson
Sent: Sunday, March 01, 2009 1:51 PM
To: Krzanowski, Roman
Cc: [email-masked]; Al Morton; [email-masked]
Subject: Re: [ippm] Reflect-Octets: New TWAMP Test Packet Format?

I do not think that the uneven boundaries on Reflected Padding will be a
problem.  That being said the proposed alternative test packet format
makes it easier in the Test-Reflector to reuse the received test packet
buffer in order to generate the response packet.  In other words, just
allowing the Test-Reflector to overwrite the Discard Fill padding can
save a good bit of work when building up responses to TWAMP-Test
packets.  However, I think that there should be only one TWAMP-Test
packet format and maintaining two ways of building up response test
packets in the Test-Reflector based on the negotiated Reflect Padding
option is undesirable in my opinion.  

This draft seems useful to me as a way to attach an opaque blob of data
to each TWAMP-Test packet and guarantee that it will be sent back
unchanged by the Test-Reflector to the Test-Sender.  The Test-Sender can
store whatever it wants in this payload (TLv, XML, etc.) and it should
not be necessary to formally specify its format in a TWAMP extension
because the Test-Reflector does not know or care about what the
reflected padding octets represent.

On Fri, Feb 20, 2009 at 4:26 PM, Krzanowski, Roman
<[email-masked]> wrote:

Al

-----Original Message-----

IPPM,

and in the draft
http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#secti
on-5
<http://tools.ietf.org/html/draft-ietf-ippm-twamp-reflect-octets-00#sect
i%0Aon-5> 

thanks and regards,
Al and Len