Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

From: "Tom Alexander" <[email-masked]>
Date: Wed, 5 Mar 2008 21:07:10 -0800

BMWGers,

I read the improved IPv6 draft and it looks very good. I have some minor
comments in the attached text file, but overall it looks to be in very good
shape.

Thanks,

- Tom A.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Al
Morton
Sent: Sunday, February 03, 2008 12:45 PM
To: [email-masked]
Subject: [bmwg] Status of the IPv6 draft following IESG review

BMWG,

The WG draft on IPv6 was on the IESG telechat agenda
at the Jan 10th meeting.  Several ADs entered DISCUSS and other
comments. The IESG comments were resolved by the authors (led by Chip),
as described here:
http://home.comcast.net/%7Eacmacm/BMWG/IESG-Comments-IPv6-Meth4.pdf

I think you'll agree that some good points were raised, and the
draft improved again at this stage of development.  The revised text
is here:
http://tools.ietf.org/html/draft-ietf-bmwg-ipv6-meth-05

So, if you played a role in developing this memo, or (now?) have an interest
in IPv6 benchmarking, this is a good time to view of the changes.

Thanks to Chip, Ahmed, Gunter and Diego for applying their
expertise to this important problem, and to all the BMWG
folks who reviewed and commented along the way.

Al
bmwg chair

_______________________________________________
bmwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bmwg
_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

---

From: David Newman <[email-masked]>
Date: Wed, 05 Mar 2008 21:23:55 -0800

> comments in the attached text file, but overall it looks to be in very good

Hi Tom,

Regarding this comment:

> 2. In section 5.1.1: A 47-byte PoS frame with an IPv6 header has zero
> payload bytes and contains no distinguishing information whatever (i.e.,
> it is impossible to tell one IPv6 packet from another). The PPP header
> certainly contains nothing that can be used for this purpose. How then are
> some of the benchmarking tests (such as latency) to be performed, even
> theoretically? (This is NOT the same case as IPv4, because the IPv4 header
> at least contains an Identification field that COULD be used for this
> purpose.)
> 
> It is suggested that the minimum PoS frame size be increased to 49 bytes to
> allow at least some semblance of practical latency measurement by a physically
> realizable tester.

I'm partly to blame for recommending the use of minimum-length frames. 
There are competing goals here: On the one hand, it's very desirable to 
measure throughput using the shortest frame length possible because this 
exercises the fps limits the hardest. On the other hand, you're right to 
note that minimal-length v6 packets have no room left for the signature 
field many testers use to measure latency.

Adding 2 bytes to the frame length would allow 64k unique IDs for 
latency measurement -- better than 0, but still even that number of 
frames would go by pretty quickly in many tests.

This seems like an implementation-of-the-tester question, but aren't 
there ways of distinguishing IPv6 packets without increasing packet 
length? Just a crude example would be incrementing source and 
destination addresses and having the tester track tx and rx times. Or is 
that not feasible?

dn

> ------------------------------------------------------------------------
>

---

From: Al Morton <[email-masked]>
Date: Thu, 06 Mar 2008 09:04:00 -0500

At 12:23 AM 3/6/2008, David Newman wrote:
>...I'm partly to blame for recommending the use of minimum-length frames.

Perhaps we should just note this fact, and that in practice
some testers may need to add some bytes to the minimum...

Al
(participant)

Whatever we agree to add at this point will need to be prepared as
instructions to the RFC Editor, so they can be included
in the Approval announcement.  I will take care of that task,
if necessary.

Al
bmwg chair

---

From: "Tom Alexander" <[email-masked]>
Date: Thu, 6 Mar 2008 06:16:13 -0800

Hi, David,

I'm by no means an IPv6 expert. However, I did spend some time poking
through the IPv6 headers, and I can't see any way whereby one can even
theoretically distinguish between two packets carrying the same
source/destination addresses based on the IPv6 header alone.

Using the IPv6 addresses to hold tracking information is a possibility
(we've got to do SOMETHING with those 128 bits ;-) but the issue I see is
that forwarding engines in L3 switches that perform fast-path/slow-path
determination based on header fields will then be irretrievably confounded.
Real IPv6 flows would not be expected to have continuously changing source
or destination address fields.

I also checked RFC 4291 but no joy there, either.

Perhaps we could consult with an IPv6 expert on this specific topic? It
would be nice to have a a minimum-size packet with a zero payload if it's
even theoretically feasible to track them. (Or else one could assert in the
methodology that zero-payload packets are applicable to rate tests such as
throughput / forwarding rate, and latency tests would have to have a
non-zero payload.)

Best regards,

- Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Newman
Sent: Wednesday, March 05, 2008 9:24 PM
Cc: [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Hi Tom,

dn

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Thu, 6 Mar 2008 10:28:04 -0500

Tom,

I agree with the observations you are making and we raised similar
arguments when this topic was discussed in the WG. 

In a nut shell, two perspectives were discussed:
- practical perspective which focused on a practically useful minimum
frame size, something that makes sense in real environments
- theoretical perspective which focused on how much one could stress the
device which leads to using packets that have only the main header

In an earlier version we had a note (similar to what Al was proposing in
an earlier e-mail today) indicating that the minimum fame size listed
has no relevancy in real networks. That note however was rejected and we
kept only a note that highlights the testing challenges faced by the use
of such packets without a payload.

   Note: Test tools are commonly using signatures to identify test
   traffic packets to verify that there are no packet drops, out of
   order packets or to calculate various statistics such as delay and
   jitter.  This could be the reason why the minimum frame size
   selectable through the test tool might not be as low as the
   theoretical one presented in this document.

I think it would be great if we add to the above note the fact that the
minimum frame size listed does not have practical applicability but it
can be used for testing a limit case.

Thank you Tom for your comments!
Chip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Alexander
Sent: Thursday, March 06, 2008 9:16 AM
To: 'David Newman'
Cc: [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Hi, David,

Using the IPv6 addresses to hold tracking information is a possibility
(we've got to do SOMETHING with those 128 bits ;-) but the issue I see
is that forwarding engines in L3 switches that perform
fast-path/slow-path determination based on header fields will then be
irretrievably confounded.
Real IPv6 flows would not be expected to have continuously changing
source or destination address fields.

Perhaps we could consult with an IPv6 expert on this specific topic? It
would be nice to have a a minimum-size packet with a zero payload if
it's even theoretically feasible to track them. (Or else one could
assert in the methodology that zero-payload packets are applicable to
rate tests such as throughput / forwarding rate, and latency tests would
have to have a non-zero payload.)

Best regards,

- Tom

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

Tom Alexander wrote:
> BMWGers,
> 
> I read the improved IPv6 draft and it looks very good. I have some 
> minor comments in the attached text file, but overall it looks to be 
> in very
good

Hi Tom,

Regarding this comment:

> payload bytes and contains no distinguishing information whatever 
> (i.e., it is impossible to tell one IPv6 packet from another). The PPP

> header certainly contains nothing that can be used for this purpose. 
> How then are some of the benchmarking tests (such as latency) to be 
> performed, even theoretically? (This is NOT the same case as IPv4, 
> because the IPv4 header at least contains an Identification field that

> COULD be used for this
> purpose.)
> 
> It is suggested that the minimum PoS frame size be increased to 49 
> bytes
to

dn

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Al Morton
> The WG draft on IPv6 was on the IESG telechat agenda at the Jan 10th 
> meeting.  Several ADs entered DISCUSS and other comments. The IESG 
> comments were resolved by the authors (led by Chip), as described 
> here:
> I think you'll agree that some good points were raised, and the draft 
> improved again at this stage of development.  The revised text is 
> here:
> Thanks to Chip, Ahmed, Gunter and Diego for applying their expertise 
> to this important problem, and to all the BMWG folks who reviewed and 
> commented along the way.
> 
> Al
> bmwg chair
>

---

From: "Tom Alexander" <[email-masked]>
Date: Thu, 6 Mar 2008 08:46:58 -0800

Well, the problem is not really about tester implementations. I see the
issue as follows: the standard specifies latency measurements to be
performed at a particular frame size, but nobody can figure out how a
latency measurement could even theoretically be done at that frame size, so
does it even make sense? I'm quite willing to accept an "ideal" tester, but
a "supernatural" tester seems a bit hard to swallow ...

Besides, the latency measurement methodology in RFC 2544 (section 26.2),
which the draft requires, says: "An identifying tag SHOULD be included in
one frame after 60 seconds ... The receiver logic in the test equipment MUST
recognize the tag information in the frame stream and record the time at
which the tagged frame was received (timestamp B)." In a 47-byte frame,
neither the IPv6 payload nor the IPv6 header allow an identifying tag to be
inserted - at least, not as far as I can tell.

Rather than permitting testers to add arbitrary amounts of bytes to the
specified frame sizes (which raises the potential for benchmarks that can't
be compared), perhaps one could add a sentence that the 47-byte frame size
does not apply to latency measurements? This seems simple enough in terms of
instructions to the editor.

The throughput and forwarding rate measurements are fine with 47-byte
frames, provided the DUT is well-behaved and does not duplicate frames.

Cheers,

- Tom
(confused vendor of test equipment)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Al
Morton
Sent: Thursday, March 06, 2008 6:04 AM
To: David Newman
Cc: [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Al
(participant)

Al
bmwg chair

---

From: "Tom Alexander" <[email-masked]>
Date: Thu, 6 Mar 2008 09:06:49 -0800

Hi, Chip,

Thanks for the insight into the WG discussions. That was useful.

I actually agree with the concept of stressing the device with the absolute
minimum size packets that one can create. In my experience this brings out
many bugs, issues and hidden peculiarities; this sort of traffic may occur
rarely if at all in real networks, but unless the benchmark is carried out
one never knows whether the device will survive the occasional burst of
minimum-sized packets.

Thus it makes complete sense for me to use the listed minimum frame size for
throughput, forwarding rate, etc. An "ideal" tester could inject N such
frames, count the M frames that come out, and determine the appropriate
metric. A "real" tester would, of course, have to add a signature to
distinguish duplicate and misordered frames - but that's
implementation-specific.

The only issue I have is with the latency metric. Injecting a stream of
minimum sized frames with no identifying marks into a DUT results in a
stream of minimum sized frames with no identifying marks coming out. You
can't distinguish one frame from another, so you can't calculate the delta
between input and output. What exactly are we to do about measuring latency,
particularly when the methodology says to wait 60 seconds before measuring
timestamp differences? You can see that this is quite independent of actual
testers and signatures and whatnot. This is an issue in the methodology.

It is a relatively minor point, but I think it is likewise easily fixed.

Thanks,

- Tom

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 7:28 AM
To: Tom Alexander; David Newman
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Tom,

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

Hi, David,

Best regards,

- Tom

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

good

Hi Tom,

to

dn

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Thu, 6 Mar 2008 12:44:31 -0500

Tom,

The minimum frame size currently listed is the result of David making
the same case. The note was intended to put a bit of context around that
but, if I understand your comment correctly, you would like for the note
to indicate the principle (need for some payload in order to perform
latency tests) rather than refer to the test tools.

Could you help us adjust the note so that it carries the right
perspective? Here is a proposal:

   Note: Certain benchmarking tests require the traffic to carry
signatures 
   that help distinguish packet and detect out of order packets or to
calculate
   various statistics such as delay and jitter. These signatures are
carried in
   the packet payload. The minimum frame size suggested in this section
does not
   leave room for any packet payload so no room for a signature. For
this reason
   while throughput benchmarking can be performed at the minimum
recommended 
   frame size, latency benchmarking will require frame sizes larger than
the 
   minimum recommended in order to accommodate a signature. 

What do you think?

Best Regards,
Chip

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 12:07 PM
To: Chip Popoviciu (cpopovic); 'David Newman'
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Hi, Chip,

I actually agree with the concept of stressing the device with the
absolute minimum size packets that one can create. In my experience this
brings out many bugs, issues and hidden peculiarities; this sort of
traffic may occur rarely if at all in real networks, but unless the
benchmark is carried out one never knows whether the device will survive
the occasional burst of minimum-sized packets.

Thus it makes complete sense for me to use the listed minimum frame size
for throughput, forwarding rate, etc. An "ideal" tester could inject N
such frames, count the M frames that come out, and determine the
appropriate metric. A "real" tester would, of course, have to add a
signature to distinguish duplicate and misordered frames - but that's
implementation-specific.

The only issue I have is with the latency metric. Injecting a stream of
minimum sized frames with no identifying marks into a DUT results in a
stream of minimum sized frames with no identifying marks coming out. You
can't distinguish one frame from another, so you can't calculate the
delta between input and output. What exactly are we to do about
measuring latency, particularly when the methodology says to wait 60
seconds before measuring timestamp differences? You can see that this is
quite independent of actual testers and signatures and whatnot. This is
an issue in the methodology.

Thanks,

- Tom

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]]
Sent: Thursday, March 06, 2008 7:28 AM
To: Tom Alexander; David Newman
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Tom,

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

Hi, David,

Best regards,

- Tom

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

good

Hi Tom,

to

dn

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Thu, 6 Mar 2008 13:23:29 -0500

Tom,

I also have a solution proposal to the problem you mention, something
specific only to IPv6: 

We can use the Flow Label (20 bits long) which is part of the 40 bytes
long main header to carry a stamp (ID + time stamp) that would enable us
to run even latency tests at minim frame size. I think this is more of
an implementation point though.

Best Regards,
Chip 

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 12:07 PM
To: Chip Popoviciu (cpopovic); 'David Newman'
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Hi, Chip,

Thanks,

- Tom

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]]
Sent: Thursday, March 06, 2008 7:28 AM
To: Tom Alexander; David Newman
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Tom,

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

Hi, David,

Best regards,

- Tom

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

good

Hi Tom,

to

dn

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Fri, 7 Mar 2008 08:41:16 -0500

Dumb question, but could not the flow-label be used for embedding the instrumented signature? Or have people started using this field?

-- 
Aamer Akhter / [email-masked]
Ent & Commercial Systems, cisco Systems

> Chip Popoviciu (cpopovic)
> Sent: Thursday, March 06, 2008 10:28 AM
> > ---------------------------------------------------------------------
> -
> > --
> >

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Fri, 7 Mar 2008 08:50:32 -0500

Aamer,

I am not sure you saw my follow up e-mail yesterday but there I made
this proposal of using the Flow Label in this particular case.

Chip 

-----Original Message-----
From: Aamer Akhter (aakhter) 
Sent: Friday, March 07, 2008 8:41 AM
To: Chip Popoviciu (cpopovic); Tom Alexander; David Newman
Cc: [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Dumb question, but could not the flow-label be used for embedding the
instrumented signature? Or have people started using this field?

> Of Chip Popoviciu (cpopovic)
> - theoretical perspective which focused on how much one could stress 
> the device which leads to using packets that have only the main header
> 
> In an earlier version we had a note (similar to what Al was proposing 
> in an earlier e-mail today) indicating that the minimum fame size 
> listed has no relevancy in real networks. That note however was 
> rejected and we kept only a note that highlights the testing 
> challenges faced by the use of such packets without a payload.
> 
> I think it would be great if we add to the above note the fact that 
> the minimum frame size listed does not have practical applicability 
> but it can be used for testing a limit case.
> 
> Of Tom Alexander

> Perhaps we could consult with an IPv6 expert on this specific topic? 
> It would be nice to have a a minimum-size packet with a zero payload 
> if it's even theoretically feasible to track them. (Or else one could 
> rate tests such as throughput / forwarding rate, and latency tests 
> would have to have a non-zero payload.)
> 
> Best regards,
> 
> - Tom
> 
> Of David Newman

> > in very
> good
> > shape.
> 
> Hi Tom,
> 
> Regarding this comment:
> 
> > 2. In section 5.1.1: A 47-byte PoS frame with an IPv6 header has 
> > zero payload bytes and contains no distinguishing information 
> > whatever (i.e., it is impossible to tell one IPv6 packet from 
> > another). The
> PPP
> 
> There are competing goals here: On the one hand, it's very desirable 
> to measure throughput using the shortest frame length possible because

> this exercises the fps limits the hardest. On the other hand, you're 
> right to note that minimal-length v6 packets have no room left for the

> signature field many testers use to measure latency.
> 
> destination addresses and having the tester track tx and rx times. Or 
> is that not feasible?
> 
> dn
> 
> 
> 
> 
> >
> > Thanks,
> >
> > - Tom A.
> >

> > is

> > to this important problem, and to all the BMWG folks who reviewed 
> > and commented along the way.
> >
> > Al
> > bmwg chair
> >

---

From: Al Morton <[email-masked]>
Date: Fri, 07 Mar 2008 09:10:48 -0500

BMWG,

Two people independently making the same suggestion indicates a possibility
for consensus!  Please comment on Chip's proposal for the
note text ASAP (perhaps modification w.r.t. flow label is on order):

>Note: Certain benchmarking tests require the traffic to carry signatures
>that help distinguish packet and detect out of order packets or to calculate
>various statistics such as delay and jitter. These signatures are carried in
>the packet payload. The minimum frame size suggested in this section does not
>leave room for any packet payload so no room for a signature. For this reason
>while throughput benchmarking can be performed at the minimum recommended
>frame size, latency benchmarking will require frame sizes larger than the

Also, two of Tom's comments suggest to change SHOULD to MUST.  Addition
of a new requirement at this stage requires a consensus check.

Please indicate your opinion on these:

>On page 4:
>
>1. In section 5, "Test Traffic", it is recommended that the "SHOULD" be
>changed to a "MUST". Otherwise it is possible for testers to use a variety
>of traffic profiles to test IPv6 DUTs, leading to results that cannot be
>compared. In any case virtually all of the specifications in this section
>are common practice throughout the industry, and thus nothing is gained by
>allowing testers to arbitrarily deviate from them.

...

>On page 12:
>
>3. In section 7, various IPv4/IPv6 traffic mixes are required. The IPv6
>traffic is well specified in this document (in the preceding sections).
>However, nothing is said about the IPv4 traffic (i.e., what frame sizes,
>what addressing, etc.). It is recommended that a statement be inserted to
>the effect that the IPv4 traffic component MUST follow the specifications
>in RFC 2544.

and on his other suggestions, as well.

thanks for your attention to this matter,
Al
bmwg chair

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Fri, 7 Mar 2008 13:46:35 -0500

I'm travelling with very intermittent access, (about a day or two lag). Apologies for the loss of sync.

I would think that at least for interim (until there is a use for the field), the flow-label field should suffice.

> From: Chip Popoviciu (cpopovic)
> Sent: Friday, March 07, 2008 8:51 AM
> To: Aamer Akhter (aakhter); 'Tom Alexander'; 'David Newman'
> Cc: [email-masked]'
> expertise
> > > -------------------------------------------------------------------
> -
> > > -
> > -
> > > --
> > >

---

From: Merike Kaeo <[email-masked]>
Date: Fri, 7 Mar 2008 11:10:05 -0800

I would agree as well.  When I started catching up w/ thread last  
night that was my initial thought and Chip beat me to it.  I  
currently know of noone that is using the flow label although we  
probably should do a sanity check to make sure that hasn't changed.  
(cisco, juniper, microsoft, *nix systems [insert other co you feel  
relevant] a good start and the hallways next week should provide  
pretty good sanity check)

- merike

On Mar 7, 2008, at 10:46 AM, Aamer Akhter (aakhter) wrote:

> I would think that at least for interim (until there is a use for  
> the field), the flow-label field should suffice.
>
> --

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Fri, 7 Mar 2008 14:19:11 -0500

---

From: "Tom Alexander" <[email-masked]>
Date: Fri, 7 Mar 2008 11:44:16 -0800

If using the flow label for holding identifying information won't break
anything (at least, nothing we know of today) then I have no problem
whatever with specifying a 47 byte frame size in conjunction with the
latency test. 20 bits is more than enough.

My view is that as long as it is theoretically feasible, it is up to the
test equipment implementer to figure out how it can be done. If he/she can't
figure it out then that is his/her fault, not that of the standard.

Thus I suggest that we ignore my comment about the minimum frame size for
latency tests, leave the SHOULDs around the existing frame size definitions
alone, and move the draft along.

Best regards,

- Tom

-----Original Message-----
From: Merike Kaeo [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 11:10 AM
To: Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); Tom Alexander; David Newman; [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

- merike

---

From: "Tom Alexander" <[email-masked]>
Date: Fri, 7 Mar 2008 12:43:38 -0800

Hi, Chip,

That is interesting ... they filter based on the flow label? Does that mean
that setting the flow label to random values will cause routers to do
different things?

Thanks,

- Tom

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 12:05 PM
To: Tom Alexander; Merike Kaeo; Aamer Akhter (aakhter)
Cc: David Newman; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Tom,

Actually I think this is indeed the best approach, leave the draft as it
is and let implementers make the test work with this option. I also
think that between your comments and David's determination to keep the
lowest frame size possible ;) we ended up with an interesting discussion
and uncovering something that can be done only with IPv6 and not with
IPv4 :) Thank you for your feedback.

Merike, I also think that most vendors still stick to the rule of not
touching the Flow Label (even though they implement filtering
capabilities based on it). Moreover, this is a controlled environment so
I think such an implementation of the test will not encounter problems.
Unfortunately I will not be able to attend IETF next week but if you
happen to learn more from other vendors, please let me know.

Many thanks!
Chip    

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 2:44 PM
To: 'Merike Kaeo'; Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); 'David Newman'; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

My view is that as long as it is theoretically feasible, it is up to the
test equipment implementer to figure out how it can be done. If he/she
can't figure it out then that is his/her fault, not that of the
standard.

Thus I suggest that we ignore my comment about the minimum frame size
for latency tests, leave the SHOULDs around the existing frame size
definitions alone, and move the draft along.

Best regards,

- Tom

-----Original Message-----
From: Merike Kaeo [mailto:[email-masked]]
Sent: Friday, March 07, 2008 11:10 AM
To: Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); Tom Alexander; David Newman;
[email-masked]

I would agree as well.  When I started catching up w/ thread last night
that was my initial thought and Chip beat me to it.  I currently know of
noone that is using the flow label although we probably should do a
sanity check to make sure that hasn't changed.  
(cisco, juniper, microsoft, *nix systems [insert other co you feel
relevant] a good start and the hallways next week should provide pretty
good sanity check)

- merike

On Mar 7, 2008, at 10:46 AM, Aamer Akhter (aakhter) wrote:

> I would think that at least for interim (until there is a use for the 
> field), the flow-label field should suffice.
>
> --

>>> - practical perspective which focused on a practically useful 
>>> minimum frame size, something that makes sense in real environments

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Fri, 7 Mar 2008 16:00:32 -0500

You can use the Flow Label as another classification field. Routers can
match on Flow Label bit patterns and have policies related to the
various bit patterns but they will not change the flow label. Using such
capabilities would depend on the environment. In a fully controlled
environment where the end points are controlled and can be instructed to
use certain bit patterns in the low label, these capabilities can be
used to deploy certain services. If however the endpoints are not under
the control of the admin who controls the routers, then the routers can
expect to see flow labels of random bit patterns making it difficult to
define for them policies that map to certain Flow-label values.

A long winded reply to your question but I hope it answers it.

Best Regards,
Chip 

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 3:44 PM
To: Chip Popoviciu (cpopovic); 'Merike Kaeo'; Aamer Akhter (aakhter)
Cc: 'David Newman'; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Hi, Chip,

That is interesting ... they filter based on the flow label? Does that
mean that setting the flow label to random values will cause routers to
do different things?

Thanks,

- Tom

-----Original Message-----
From: Chip Popoviciu (cpopovic) [mailto:[email-masked]]
Sent: Friday, March 07, 2008 12:05 PM
To: Tom Alexander; Merike Kaeo; Aamer Akhter (aakhter)
Cc: David Newman; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Tom,

Many thanks!
Chip    

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 2:44 PM
To: 'Merike Kaeo'; Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); 'David Newman'; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Best regards,

- Tom

-----Original Message-----
From: Merike Kaeo [mailto:[email-masked]]
Sent: Friday, March 07, 2008 11:10 AM
To: Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); Tom Alexander; David Newman;
[email-masked]

- merike

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Fri, 7 Mar 2008 15:04:57 -0500

Tom,

Many thanks!
Chip    

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Friday, March 07, 2008 2:44 PM
To: 'Merike Kaeo'; Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); 'David Newman'; [email-masked]
Subject: RE: [bmwg] Status of the IPv6 draft following IESG review

Best regards,

- Tom

-----Original Message-----
From: Merike Kaeo [mailto:[email-masked]]
Sent: Friday, March 07, 2008 11:10 AM
To: Aamer Akhter (aakhter)
Cc: Chip Popoviciu (cpopovic); Tom Alexander; David Newman;
[email-masked]

- merike

---

From: "Timmons C. Player" <[email-masked]>
Date: Sun, 09 Mar 2008 14:58:40 -0400

Tom Alexander wrote:
| If using the flow label for holding identifying information won't break
| anything (at least, nothing we know of today) then I have no problem
| whatever with specifying a 47 byte frame size in conjunction with the
| latency test. 20 bits is more than enough.
|
Eek.  As a person who works for an implementer, I would say 20 bits is
no where near enough...  2^20 is ~ 1,000,000 possible values.  Suppose
you use all 20 bits for your tx clock.  If your test box has microsecond
accuracy, then your tx clock is going to roll every second?  And of
course, the better the clock on your tester, the quicker it will roll...
( A nanosecond accurate box would roll every 0.001 seconds?  awesome!)

That, and you still don't have any bits to identify flows... :(

I know this is an implementation detail, but with high speed media, e.g.
10G, you've got to have more than 20 bits if you want to report a
precise AND accurate latency value, otherwise you'll see test reports like:

Store and Forward Latency (us): 212.235 + (1000 * x) (where x is some
positive integer)

Timmons

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Sun, 9 Mar 2008 15:40:09 -0400

Timmons,

Good point! It would be great to have more bits to play with but ... :)
I am also wondering if even with this limitation, the test would not be
sufficient. Latencies greater than 1 sec on 10Gig through a single box
might be a good enough (or better than nothing) indication of how the
box is doing beyond just measuring basic throughput. After all, this
test with minimum frame sizes (of this value) really is a limit case.

Chip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Timmons C. Player
Sent: Sunday, March 09, 2008 2:59 PM
To: Tom Alexander
Cc: 'David Newman'; 'Merike Kaeo'; [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Tom Alexander wrote:
| If using the flow label for holding identifying information won't 
| break anything (at least, nothing we know of today) then I have no 
| problem whatever with specifying a 47 byte frame size in conjunction 
| with the latency test. 20 bits is more than enough.
|
Eek.  As a person who works for an implementer, I would say 20 bits is
no where near enough...  2^20 is ~ 1,000,000 possible values.  Suppose
you use all 20 bits for your tx clock.  If your test box has microsecond
accuracy, then your tx clock is going to roll every second?  And of
course, the better the clock on your tester, the quicker it will roll...
( A nanosecond accurate box would roll every 0.001 seconds?  awesome!)

I know this is an implementation detail, but with high speed media, e.g.
10G, you've got to have more than 20 bits if you want to report a
precise AND accurate latency value, otherwise you'll see test reports
like:

Timmons

---

From: David Newman <[email-masked]>
Date: Sun, 09 Mar 2008 14:45:38 -0700

Chip Popoviciu (cpopovic) wrote:
>  Latencies greater than 1 sec on 10Gig through a single box
> box is doing

Not unless the tester was looking for immediate grounds for device 
disqualification!

To put this in context, the insertion time for a 64-byte frame at 10G 
line rate is 67.2 *nanoseconds.* A measurement up in the seconds would 
be way off the charts.

dn

---

From: "Chip Popoviciu (cpopovic)" <[email-masked]>
Date: Sun, 9 Mar 2008 18:02:27 -0400

David,

You are right, my thoughts were more down the first option you mention,
a treshold based conclusion. In other words, if the latency results go
beyond a certain value on a 10Gig interface through a single device than
at least I can draw a conclusion which is more than just doing
throughput at minimum frame size. It is a limit perspective but then
again, the test itself is a limit case.

Chip 

-----Original Message-----
From: David Newman [mailto:[email-masked]] 
Sent: Sunday, March 09, 2008 5:46 PM
To: Chip Popoviciu (cpopovic)
Cc: [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Chip Popoviciu (cpopovic) wrote:
>  Latencies greater than 1 sec on 10Gig through a single box might be a

> good enough (or better than nothing) indication of how the box is 
> doing

dn

---

From: "Tom Alexander" <[email-masked]>
Date: Mon, 10 Mar 2008 06:59:32 -0700

Hi, Timmons,

Sorry, I didn't explain that too well. The 63-bit value I talked about was
supposed to be the transmission time of the first packet in a 383-packet
block. The time is computed by the transmitter at the instant the latter
packet is transmitted, converted to a 255-bit BCH-encoded value, and the
first bit is inserted into the flow label. The fact that you need to grab
383 consecutive packets in order to recover the full 63-bit value at the far
end doesn't make a difference to the process - if you get the first packet
in a 383-packet block OK, then you can figure out the transmit time of that
packet. If you don't get the first packet OK, then try another 383-packet
block, etc.

How about this as a simpler alternative? Fill the flow label with 20 bits of
all-zeros in all packets that are transmitted, except for a special packet
where the 20 bits are set to all-ones. This forms the "identifying tag" that
is required by RFC 2544 section 26.2. The transmitter records (locally) the
64-bit time when the identifying tag was sent. The receiver records
(locally) the 64-bit time when the packet with the identifying tag was
received. At the end of the test, the transmitter and receiver get together
and compare these times; the latency is simply the difference.

Of course, in practice this approach works only if the SUT doesn't drop the
packet with the identifying tag. However, it fits the requirements of the
methodology.

Best regards,

- Tom

-----Original Message-----
From: Timmons C. Player [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 6:33 AM
To: Tom Alexander
Cc: 'Merike Kaeo'; 'Aamer Akhter (aakhter)'; 'David Newman'; [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Tom Alexander wrote:

| Consider an admittedly convoluted implementation of a latency
signature, as
| follows:
| - generate a 63-bit nanosecond timestamp - the range here is from 1
nsec to
| 292 years, which should be adequate
| - add 192 parity bits to the timestamp to form a [255,63] BCH code,
capable
| of correcting up to 30 errors (e.g., due to lost or misordered packets)
| - take a group of 30 consecutive timestamps and interleave their encoded
| bits in the standard fashion, to create a block of 7,650 bits
| - now divide up this 7650-bit block into 382.5 groups of 20 bits and write
| them into the flow labels, 20 bits at a time, spanning 383 IPv6 packets
|
| The above provides a robust way of encoding, into 20 bits, a 63-bit
latency
| timestamp while still supporting the recovery of good timestamps in
the face
| of high packet loss ratios and unknown loss patterns. (You could lose
~8% of
| your packets and still recover every signature intact.) Of course, you
won't
| have a unique latency timestamp associated with EVERY packet - but RFC
2544
| doesn't require that.
|
True, but it requires a latency value for one special packet.  In order
for a test box to calculate the latency of that single packet, it needs
the tx time of that packet encoded in the packet somewhere.  If that
packet doesn't have the tx time in it, then there's no way for the test
box to know how long the packet was in the test network/device.  I don't
see how putting a single clock stamp into 383 packets is very helpful...

| In fact the above is a mite elaborate considering that RFC 2544 only asks
| that you have ONE marked packet in the middle of the trial. But if you
want
| to get continuous latency measurements over the whole trial, something
like
| this should do it. It should also be clear that one could conceive of
| transporting a large timestamp using just 1 bit in the IPv6 header; 20
bits
| increases the number of timestamps transported per unit time, but doesn't
| make much difference to the latency measurement per se.
|
I'm confused.

Timmons

---

From: "Timmons C. Player" <[email-masked]>
Date: Mon, 10 Mar 2008 09:41:26 -0400

David Newman wrote:
| Chip Popoviciu (cpopovic) wrote:
|>  Latencies greater than 1 sec on 10Gig through a single box
|> might be a good enough (or better than nothing) indication of how the
|> box is doing
|
| Not unless the tester was looking for immediate grounds for device
| disqualification!
|
| To put this in context, the insertion time for a 64-byte frame at 10G
| line rate is 67.2 *nanoseconds.* A measurement up in the seconds would
| be way off the charts.
|

You only hope it's way off the charts.  But if the device is buffering
or your testing a system that goes between media, say 10Gig to a DSL
line, 1 second might not be enough...

The problem with an unreasonably small max latency value limit is that
you, as a tester, are in a position where you can't know with certainty
what the real max latency is.

Timmons

---

From: "Tom Alexander" <[email-masked]>
Date: Sun, 9 Mar 2008 23:44:59 -0700

Aha, there are certain obscure benefits for working for a WIRELESS test
implementer. :-) The issue of robustly encoding a large number of message
bits into a small number of physical symbols in such a way that they can be
recovered from a lossy medium is a standard problem in wireless.

Consider an admittedly convoluted implementation of a latency signature, as
follows:
- generate a 63-bit nanosecond timestamp - the range here is from 1 nsec to
292 years, which should be adequate
- add 192 parity bits to the timestamp to form a [255,63] BCH code, capable
of correcting up to 30 errors (e.g., due to lost or misordered packets)
- take a group of 30 consecutive timestamps and interleave their encoded
bits in the standard fashion, to create a block of 7,650 bits
- now divide up this 7650-bit block into 382.5 groups of 20 bits and write
them into the flow labels, 20 bits at a time, spanning 383 IPv6 packets

The above provides a robust way of encoding, into 20 bits, a 63-bit latency
timestamp while still supporting the recovery of good timestamps in the face
of high packet loss ratios and unknown loss patterns. (You could lose ~8% of
your packets and still recover every signature intact.) Of course, you won't
have a unique latency timestamp associated with EVERY packet - but RFC 2544
doesn't require that.

In fact the above is a mite elaborate considering that RFC 2544 only asks
that you have ONE marked packet in the middle of the trial. But if you want
to get continuous latency measurements over the whole trial, something like
this should do it. It should also be clear that one could conceive of
transporting a large timestamp using just 1 bit in the IPv6 header; 20 bits
increases the number of timestamps transported per unit time, but doesn't
make much difference to the latency measurement per se.

There are many different ways of approaching the problem, and I'm sure that
there are far simpler ways of accomplishing all this. But the point I wanted
to convey in my previous e-mail was that if there is any theoretically
feasible way of implementing the latency measurement under the specified
conditions, then the draft is fine and it's up to the implementer to figure
something out; however, if it is theoretically infeasible to implement a
latency measurement, then the draft is broken and needs to be fixed.

Best regards,

- Tom

-----Original Message-----
From: Timmons C. Player [mailto:[email-masked]] 
Sent: Sunday, March 09, 2008 11:59 AM
To: Tom Alexander
Cc: 'Merike Kaeo'; 'Aamer Akhter (aakhter)'; 'David Newman'; [email-masked]
Subject: Re: [bmwg] Status of the IPv6 draft following IESG review

Tom Alexander wrote:

Timmons

---

From: "Timmons C. Player" <[email-masked]>
Date: Mon, 10 Mar 2008 09:33:03 -0400

Tom Alexander wrote:

Timmons

---

From: "Timmons C. Player" <[email-masked]>
Date: Mon, 10 Mar 2008 10:29:19 -0400

Tom Alexander wrote:

| How about this as a simpler alternative? Fill the flow label with 20
bits of
| all-zeros in all packets that are transmitted, except for a special packet
| where the 20 bits are set to all-ones. This forms the "identifying
tag" that
| is required by RFC 2544 section 26.2. The transmitter records
(locally) the
| 64-bit time when the identifying tag was sent. The receiver records
| (locally) the 64-bit time when the packet with the identifying tag was
| received. At the end of the test, the transmitter and receiver get
together
| and compare these times; the latency is simply the difference.
|
Well, that definitely could work. however, the standard modus operandi
of the test vendor's I know about is to encode the tx time in every
packet sent and record latency/jitter/delay/whatever as max/min/avg for
some set of packets.  Some boxes will also generate a histogram of
latency/jitter/delay/whatever for you based on all the received packets.

Anyway, the point of this is that getting a single latency value from a
test is a big step backward from what the test boxes give you now.  If
that's what's required to meet the spec then so be it, but the testing
world is quite a bit more advanced when it comes to measuring
latency/delay/jitter/whatever now than it was when 2544 was written.

Plus, running a special, edge-case test to get a single, context-free
latency number just seems kind of silly to me...

| Of course, in practice this approach works only if the SUT doesn't
drop the
| packet with the identifying tag. However, it fits the requirements of the
| methodology.
|
I guess that's why latency is supposed to be measured at the throughput
level.  The DUT shouldn't be dropping packets at that load. ;-)

Timmons