Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 1 Jun 2013 14:47:28 +0000

On May 31, 2013, at 5:48 PM, Dan Wing <[email-masked]> wrote:

> 
> On May 31, 2013, at 5:45 AM, [email-masked] wrote:
> 
>> A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment.
> 
> I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the documents talk about how IPID is useful on IPv4 (if the sender is monotonically increasing the IPID, which is a necessity for the existing system to operate) and how routers sometimes send a packet twice (which is normal behavior of Ethernet) and that the monotonically increasing IPID helps distinguish Ethernet re-transmissions from host stack retransmissions.
> 
> I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 published in 1996) had similar needs and solved them at the RTP application layer with sequence numbers and timestamps, and with its RTCP feedback channel.  The two I-Ds that I reviewed did not discuss why this application timing problem cannot be solved at the application layer like RTP solved it.
> 
> I did not see an analysis of forcing an IPv6 fragmentation header (as done by 4rd for transparency, http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could provide a function nearly identical to the existing (ab)use of IPv4 IPID.
> 
> -d

Well, we can discuss what layer RTP is in; I'm not sure it's application. It's usable by a number of applications. 

I would agree that the requirement to place it in a network layer header has not been established; they could, for example, use the octet sequence number in the TCP header, unless everything above the network layer is encrypted. However, I think it *is* fair to say that putting it lower down the stack makes it readily accessible for more applications or transports more quickly. You have experience with Happy Eyeballs, and the fact that the horrendous design of the socket API forces us to change every application individually when we could have changed the invisible underpinnings of an OS API once, and in so doing ported all of the applications to IPv6 as well. She has a similar problem, but in a packet.

---

From: Nalini Elkins <[email-masked]>
Date: Sat, 1 Jun 2013 08:35:43 -0700 (PDT)

Guys,

1.  RTP:  I do not think that it is pertinent.    I do not know what Dan is suggesting - that we change ALL applications to provide seq. no and timestamp?   Large companies use hundreds of applications running under TCP/IP.  This is completely undoable.

2.  Forcing of IPv6 fragmentation header.  We did discuss this in section 3: http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11

It is as follows:

"The current IPv6 specification does not provide a packet sequence number or similar field in the IPv6 main header.  One option might be to force all IPv6 packets to contain a Fragment Header.  In packets which are entire in and of themselves, the fragment ID would be zero - that is, an atomic fragment. Why was a new destination option header defined rather than recommending that Fragment Header be used?

Our reasoning was that the PDM destination option header would provide multiple benefits : the packet sequence number and the timestamp to calculate response time. "

The second reason for not having a fragment header is that unfortunately, a number of firewalls, etc, drop packets which contain IPv6 fragment headers.  I find this to be unsuitable behavior which I hope will change .   But, it is the reality.

3.  TCP Sequence Number:  this was discussed in: http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#section-1.3

It is as follows:

"TCP Sequence number is defined in RFC0793[RFC0793].  Some have  proposed that this field will meet the needs of EDCO networks for a  packet sequence number.  Indeed, the TCP Sequence Number along with the
TCP Acknowledgment number can be used to calculate dropped packets, duplicate packets, out-of-order packets etc. That is, IF the packet flow itself reflects accurately what happened on the wire!
See Scenario 1 (Section 1.5.2) and Scenario 2 (Section 1.5.3) for what happens with packet trace capture in real networks. The TCP Sequence Number is, obviously, available only for TCP and not other transport protocols." 

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
From: Fred Baker (fred) <[email-masked]>
To: Dan Wing (dwing) <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Saturday, June 1, 2013 7:47 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

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

---

From: Nalini Elkins <[email-masked]>
Date: Sat, 1 Jun 2013 08:36:12 -0700 (PDT)

Guys,

It is as follows:

It is as follows:

 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

---

From: Bill Jouris <[email-masked]>
Date: Sat, 1 Jun 2013 08:47:44 -0700 (PDT)

> I would agree that the requirement to place it in a network layer header
 has not been 
> established; they could, for example, use the octet 
sequence number in the TCP header, 
> unless everything above the network 
layer is encrypted. However, I think it *is* fair to say 
> that putting it
 lower down the stack makes it readily accessible for more applications 
or 
> transports more quickly. You have experience with Happy Eyeballs, and
 the fact that the 
> horrendous design of the socket API forces us to 
change every application individually 
> when we could have changed the 
invisible underpinnings of an OS API once, and in so 
> doing ported all of
 the applications to IPv6 as well. She has a similar problem, but in a 

> packet.

The problem with using the  the octet sequence number in the TCP header is simply this: there is a lot of network traffic which is not TCP.  But the same need for end-to-end timings exists for packets using other protocols.  So avoiding using something in the IP header would require adding it instead to the headers of ALL of the other protocols.  Which seems like a far more complex approach.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

---

From: Simon Perreault <[email-masked]>
Date: Mon, 03 Jun 2013 10:41:55 +0200

Le 2013-06-01 17:35, Nalini Elkins a écrit :
> The second reason for not having a fragment header is that
> unfortunately, a number of firewalls, etc, drop packets which contain
> IPv6 fragment headers.

About that: I would guess that the number of firewalls that will drop a 
new option header will be greater than the number of firewalls that 
currently drop fragment headers. So the current situation with firewalls 
would argue in favour of using the fragment header...

Simon

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 21:17:24 +0900

On Sun, Jun 2, 2013 at 12:35 AM, Nalini Elkins <
[email-masked]> wrote:

> The second reason for not having a fragment header is that unfortunately,
> a number of firewalls, etc, drop packets which contain IPv6 fragment
> headers.  I find this to be unsuitable behavior which I hope will change .
>   But, it is the reality.
>

Those boxes will drop your proposed header as well.

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 05:28:06 -0700 (PDT)

Actually, I should not have used the point about header dropping as a reason.

If companies find that the new header we propose gives them capabilities that they want, then they will make sure their firewalls are configured to not drop the header.

I feel that the capabilities of packet sequence number AND end-to-end response time without agents will be quite attractive to many.  So, they will make sure they get the firewalls under their control get these headers so they do not lose the diagnostic capabilities.

Fragment header is not enough.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Lorenzo Colitti <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Fred Baker (fred) <[email-masked]>; Dan Wing (dwing) <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 5:17 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

On Sun, Jun 2, 2013 at 12:35 AM, Nalini Elkins <[email-masked]> wrote:

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jun 2013 15:44:16 +0200

On 06/01/2013 02:48 AM, Dan Wing wrote:
> draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the documents
> talk about how IPID is useful on IPv4 (if the sender is monotonically
> increasing the IPID, which is a necessity for the existing system to
> operate)

This is not correct. The IP ID is not required to be monotonically
increasing -- it just need to not be reused to quickly.

A simple (and poor implementation) could have an array of 65536 integers
in the range 0-65535 (without repeating any value), and then the stack
would select the IP ID as:

array[fragment]

 --  where "fragment" is the number of fragments that have been sent so far.

As a datapoint, look at OpenBSD's IP ID generation.

> and how routers sometimes send a packet twice (which is
> normal behavior of Ethernet) and that the monotonically increasing
> IPID helps distinguish Ethernet re-transmissions from host stack
> retransmissions.

Given the length of the IPv4 IP ID, badwidths available today, etc., I
don't think you can/should use the IP ID for much.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jun 2013 15:47:57 +0200

On 06/01/2013 05:35 PM, Nalini Elkins wrote:
> 2.  Forcing of IPv6 fragmentation header.  We did discuss this in
> section 3:
> http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-11
>
>  It is as follows:
> 
> "The current IPv6 specification does not provide a packet sequence
> number or similar field in the IPv6 main header.  One option might be
> to force all IPv6 packets to contain a Fragment Header.  In packets
> which are entire in and of themselves, the fragment ID would be zero
> - that is, an atomic fragment.

This is incorrect. Please reference any RFC section which requires a
special Identification value (i.e., zero) for atomic fragments (hint:
there's no such a recommendation).

> IPv6 fragment headers.  I find this to be unsuitable behavior which I
> hope will change .   But, it is the reality.

Firewalls will usually block all extension headers. My advice in this
area would be "think twice before specifying an IPv6 extension header.
Then don't". :-)

Cheers,

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 06:50:22 -0700 (PDT)

>> don't think you can/should use the IP ID for much.

When diagnosing problems at end locations, often, you finally get down to a series of packets which is the problem.   This may be 10 or 20 packets.  

It doesn't matter what the bandwidth is, it does matter whether you can say exactly what happened in those 10 or 20 packets.   

The case studies we have are from actual operators who actually use this field.  AND find it saves a great deal of time because it works.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Fernando Gont <[email-masked]>
To: Dan Wing <[email-masked]> 
Cc: [email-masked]; [email-masked] 
Sent: Monday, June 3, 2013 6:44 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

array[fragment]

Cheers,

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 06:59:22 -0700 (PDT)

>> area would be "think twice before specifying an IPv6 extension header.

If firewalls block all extension headers, why would time have been wasted at the IETF even specifying the protocols for extension headers?  Am I wrong that firewalls are configured by people and can be set to PASS extension headers rather than drop them?

Also, if the extension header provides value, I can guarantee you that people will set their firewalls to pass it.   We have thought "twice" and three times about proposing this.   The only reason we do is because it is important.

I have mentioned the possibility of  this new extension header to executives at two different companies and both felt that it provided great value and might even be THE impetus they need to migrate to IPv6.   Better diagnostics AND end-to-end response time are very practical and real needs for many companies.   As you know, we were very disturbed that one facility that we used frequently in IPv4, IPID, was not available to us in IPv6.     
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

Sent: Monday, June 3, 2013 6:47 AM

Cheers,

---

From: "cb.list6" <[email-masked]>
Date: Mon, 3 Jun 2013 07:04:57 -0700

On Jun 3, 2013 6:59 AM, "Nalini Elkins" <[email-masked]>
wrote:
> If firewalls block all extension headers, why would time have been wasted
at the IETF even specifying the protocols for extension headers?  Am I
wrong that firewalls are configured by people and can be set to PASS
extension headers rather than drop them?

Ipv6 came before ubiquitous firewalls

The extension header fw knob may or may not exist for your firewall

You will likey have better luck advancing your draft if you include a
statement that your extention header may not work on the internet but can
be engineerred to work within a single administrative domain

CB

> Also, if the extension header provides value, I can guarantee you that
people will set their firewalls to pass it.   We have thought "twice" and
three times about proposing this.   The only reason we do is because it is
important.
>
> I have mentioned the possibility of  this new extension header to
executives at two different companies and both felt that it provided great
value and might even be THE impetus they need to migrate to IPv6.   Better
diagnostics AND end-to-end response time are very practical and real needs
for many companies.   As you know, we were very disturbed that one facility
that we used frequently in IPv4, IPID, was not available to us in IPv6.
> Cc: Fred Baker (fred) <[email-masked]>; Dan Wing (dwing) <[email-masked]>;
"[email-masked]" <[email-masked]>; "
[email-masked]" <
[email-masked]>
> Subject: Re: [v6ops] new draft:
draft-elkins-v6ops-ipv6-end-to-end-rt-needed

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 07:11:41 -0700 (PDT)

>> You will likey have better luck advancing your draft if you include a statement that your extention header may not work on the internet but can be engineerred to work within a single administrative domain

Good suggestion.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: cb.list6 <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: IPv6 Ops WG <[email-masked]>; Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 7:04 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Ipv6 came before ubiquitous firewalls
The extension header fw knob may or may not exist for your firewall
You will likey have better luck advancing your draft if you include a statement that your extention header may not work on the internet but can be engineerred to work within a single administrative domain
CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Jun 2013 23:18:44 +0900

On Mon, Jun 3, 2013 at 10:59 PM, Nalini Elkins <
[email-masked]> wrote:

> value and might even be THE impetus they need to migrate to IPv6.
>

Nalini,

I'm afraid that that is known as the "killer app" fallacy. I say "fallacy"
instead of "argument" because such arguments have been tried many times but
have not been very successful to date. I don't think it will be very
convincing - especially since these companies already have what they need
from IPv4, right?

Also - supposing you do implement an extension header - how will the host
know whether to use it or not? If it uses it to talk to the Internet, then
the packet will get dropped. Does the host know which destinations
understand it and which do not? Or will you be forced to specify and
implement stripping this header in intermediate nodes?

Cheers,
Lorenzo

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jun 2013 16:24:55 +0200

On 06/03/2013 03:50 PM, Nalini Elkins wrote:
> When diagnosing problems at end locations, often, you finally get down
> to a series of packets which is the problem.   This may be 10 or 20
> packets.  
> 
> It doesn't matter what the bandwidth is, it does matter whether you can
> say exactly what happened in those 10 or 20 packets.   

The bandwidth matters in the sense that the IP ID gets reused.

If you want to uniqeuly identify a packet, why don't you employ a hash
over, say, some IP header fields and upper layer header fields?

-- that's something that you could do without bothering the network
about it.

Thanks,

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 07:30:44 -0700 (PDT)

>>I'm afraid that that is known as the "killer app" fallacy. I say "fallacy" instead of "argument" because such arguments have been tried many times but have not been very successful to date. I don't think it will be very convincing - especially since these
>>companies already have what they need from IPv4, right?

Possibly you are right but given that the execs in question asked me about budget for IPv6, I would suspect that you are wrong.  You underestimate how much companies spend on agents for gathering response time data which is required for Service Level Agreements.  AND how attractive it is to NOT have to do that.  This extension header provides them capabilities they do NOT have with IPv4.

>> Also - supposing you do implement an extension header - how will the host know whether to use it or not? If it uses it to talk to the Internet, then the packet will get dropped. Does the host know which destinations understand it and which do not? Or will
>>you be forced to specify and implement stripping this header in intermediate nodes?

Now this is a better point.  But, there is a bigger issue here.  The companies and agencies that I work with on implementing IPv6, already need to plan for how to differentiate between internal traffic or traffic to business partners vs. traffic to the Internet.   Some alternatives used are Internet proxies, a separate prefix for Internet traffic vs. trusted traffic etc.  This is just one more issue that needs to be dealt with.  That is, on such routes or to such destinations, we do not use this header.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Lorenzo Colitti <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 7:18 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

On Mon, Jun 3, 2013 at 10:59 PM, Nalini Elkins <[email-masked]> wrote:

I have mentioned the possibility of  this new extension header to executives at two different companies and both felt that it provided great value and might even be THE impetus they need to migrate to IPv6.

Nalini,

I'm afraid that that is known as the "killer app" fallacy. I say "fallacy" instead of "argument" because such arguments have been tried many times but have not been very successful to date. I don't think it will be very convincing - especially since these companies already have what they need from IPv4, right?

Also - supposing you do implement an extension header - how will the host know whether to use it or not? If it uses it to talk to the Internet, then the packet will get dropped. Does the host know which destinations understand it and which do not? Or will you be forced to specify and implement stripping this header in intermediate nodes?

Cheers,
Lorenzo

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 07:34:20 -0700 (PDT)

>>The bandwidth matters in the sense that the IP ID gets reused.

It may get reused but it is very easy to see that if you are looking at 10 - 20 packets at a time.

>>over, say, some IP header fields and upper layer header fields?

This will not work.   We have thought about this and I actually did a prototype implementation.  What happens is that on REAL networks there is false duplication of packets caused by packet trace facilities.   The hash will end up being the same.   Please see:

http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00#page-9

2.1.1 Limitations of Packet Capture
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Fernando Gont <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Dan Wing <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 7:24 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 09:40:00 -0500

> This will not work.   We have thought about this and I actually did a prototype implementation.  What happens is that on REAL networks there is false duplication of packets caused by packet trace f…

If it's a false duplication, wouldn't your sequence number also get duplicated and thus be the same, just like the hash?

Perhaps I am confused.

Owen

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 07:47:05 -0700 (PDT)

>> If it's a false duplication, wouldn't your sequence number also get duplicated and thus be the same, just like the hash?

Indeed it would.  Since we know that the combination of Packet Sequence Number and Timestamp together should never be duplicated, then we are safe to assume that such a packet is a false duplicate. 

If the packet seq number wraps, then the timestamp will be different.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Owen DeLong <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 7:40 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Perhaps I am confused.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jun 2013 16:54:51 +0200

On 06/03/2013 04:47 PM, Nalini Elkins wrote:
> Indeed it would.  Since we know that the combination of Packet Sequence
> Number and Timestamp together should never be duplicated, then we are
> safe to assume that such a packet is a false duplicate. 
> 

I guess this all depends on the granularity of the timestamps. That
said, I personally think that this looks like too much stress on the
network and implementations for something that is not meant for the
general Internet, and that can be performed, to a large extent, with
techniques such as a hash function on the headers.

P.S.: Before any attempt on this path, one should probably ask: are we
suppoed to have this ind of functionality at the Internet layer? Is this
worth the pain for most implementations? Is this going to work in the
general case, or is this going to be the subject of lots fo breakage?
(e.g., packet drops)

Cheers,

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 08:03:29 -0700 (PDT)

>> I guess this all depends on the granularity of the timestamps.

Picoseconds is the granularity of the timestamps.   The timestamp is NTP standard.  

>> hash function on the headers.

Again, I tell you, this will not work.  Not to mention, how do you intend to do a timestamp with hashes?

>> are we suppoed to have this ind of functionality at the Internet layer

I would say that real time performance metrix and managability are critical for networks.   As the speed of networks grows, and there are more and more critical applications, as well as numerous devices, without good performance metrix, IMHO growth will be slowed.  The Internet layer is the perfect place for this.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Fernando Gont <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: Owen DeLong <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 7:54 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Cheers,

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Jun 2013 11:19:45 -0500

> Picoseconds is the granularity of the timestamps.

i would be amazed if you had time measurements with a precision within
a factor of O(10^6) of that

A gentleman accosts a guard in the museum and asks, "How old is that mummy?"
The guard responds, "I believe it is 2005 years old."
The gentleman asks "Why that particular age, 2005?"
The guard responds "Well, I was told it was 2000 years old when I
started work here five years ago."

randy

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 09:23:01 -0700 (PDT)

HAHAHA

From RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification

The 64-bit timestamp format is used in packet headers and other
places with limited word size.  It includes a 32-bit unsigned seconds
field spanning 136 years and a 32-bit fraction field resolving 232
picoseconds.  The 32-bit short format is used in delay and dispersion
header fields where the full resolution and range of the other
formats are not justified.  It includes a 16-bit unsigned seconds
field and a 16-bit fraction field.

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Randy Bush <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: IPv6 Ops WG <[email-masked]> 
Sent: Monday, June 3, 2013 9:19 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

randy

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 12:56:46 -0500

You are mistaking precision for accuracy.

Let me attempt to explain the difference.

It is not uncommon for digital temperature sensors to provide 0.001 degrees C of precision.

Most of them are not accurate to less than 0.1ºC.

Just because you get three decimal places in the number doesn't mean that the contents of those decimal places are inherently correct.

Owen

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Jun 2013 11:20:05 -0700

Precision = repeatability.

Accuracy = matching a value deemed correct by an external measure.

The utility of the bits you measure depends on what you want to do with 
them:

- Precision without accuracy can be corrected to include accuracy if 
measured against a separate measure that is both accurate and precise.

- Precision without accuracy can be used to correctly measure relative 
shifts.

- Accuracy without precision is useless.

In the context of this discussion, reporting values down to the 
picosecond is probably meaningless in terms of accuracy, but not 
necessarily in terms of precision. And both are useful for NTP.

Joe

On 6/3/2013 10:56 AM, Owen DeLong wrote:
> Just because you get three decimal places in the number doesn't mean
> that the contents of those decimal places are inherently correct.
>
> Owen
>
> On Jun 3, 2013, at 11:23 AM, Nalini Elkins
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> HAHAHA
>>
>>  From RFC5905:Network Time Protocol Version 4: Protocol and Algorithms Specification
>>
>> www.insidethestack.com <http://www.insidethestack.com>
>>
>> ------------------------------------------------------------------------
>> *From:* Randy Bush <[email-masked]>
>> *To:* Nalini Elkins <[email-masked]>
>> *Cc:* IPv6 Ops WG <[email-masked]>
>> *Sent:* Monday, June 3, 2013 9:19 AM
>> *Subject:* Re: [v6ops] new draft:
>> [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Jun 2013 14:33:20 -0700 (PDT)

> From: Nalini Elkins <[email-masked]>
>To: Lorenzo Colitti <[email-masked]> 
>Sent: Tuesday, 4 June 2013 12:30 AM

Can you explain this further? Where are these agents located - on hosts, on routers or as separate probes? Where is the big cost in gathering this data, given that storage and processing power are cheap (and we're starting to be in an era of "big data", so tools to handle large amounts of data are becoming more available)? How does your proposed IPv6 extension header eliminate the need to perform measurement, collection and analysis of SLA data?

As a random idea, would agents in the hosts that trigger SNMP traps when there are TCP duplicate segments or out of order delivery solve the issue? It wouldn't work with UDP as UDP doesn't support detecting or recovering from these things, and they'd have to be detected at layers above UDP e.g. with RTP as Dan Wing mentioned.

In other words, better instrumenting hosts to detect and report these faults based on information they're already collecting for other reasons might be better than trying to develop and deploy a new IPv6 extension header. 

>Now this is a better point.  But, there is a bigger issue here.  The companies and agencies that I work with on implementing IPv6, already need to plan for how to differentiate between internal traf…

This sounds like multi-lever security, and Common Architecture Label IPv6 Security Option (CALIPSO) (RFC5570) might be the answer.

Regards,
Mark.

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 3 Jun 2013 18:45:33 -0700 (PDT)

>>Can you explain this further? Where are these agents located - on hosts, on routers or as separate probes? 

Often agents are located at the end  user device. 

>> Where is the big cost in gathering this data, given that storage and processing power are cheap (and we're starting to be in an era of "big data", so tools to handle large amounts of data are becoming more available)? 

This is a question better asked of the vendors of such agents.   Presumably, they feel that the coordination of agents to a gathering point at a central location as well as the time and effort spent in developing agent code is worth paying for.   Cost and price are two different things.  The price charged is what the market will bear.

>> How does your proposed IPv6 extension header eliminate the need to perform measurement, collection and analysis of SLA data?

Let me give you a simple scenario:

1.  Packet a is sent from source host a.  It is timestamped when it leaves host a.  The timestamp is in the proposed PDM extension header.

2.  A free packet trace tool such as WireShark sits at a host b server location.

3.  When packet a reaches the host b, we know how long the network time was to get from host a to host b because there is a timestamp.  Without a timestamp, there is no way of knowing.

4.  When host b finishes its processing.  It sends packet b back to host a.  The packet trace tool knows how long the server time was -- the delta between when the packet was received at host b to when the packet was sent back to host a.

5. These times can be used for Service Level Agreements of network time and server times.     

You can develop elaborate systems to collect this data,  but it simplifies many things.

>> As a random idea, would agents in the hosts that trigger SNMP traps when there are TCP duplicate segments or out of order delivery solve the issue? It wouldn't work with UDP as UDP doesn't support detecting or recovering >>from these things, and they'd have to be detected at layers above UDP e.g. with RTP as Dan Wing mentioned.

Several questions arise:

1.  Who is to code such agents?  This is hardly simple code.  You have to capture all packets and then find duplicates or out of order in real time and then send traps.  AND, you have to do all this in a way that you don't use up all the resources of the host in doing the trace capture and analysis.  Then, you have to send all the data to a central collection point - reliably.

2.  The other day, I worked with a device which was sending a duplicate acknowledgment once every millisecond.  If this host was to send SNMP traps  once every millisecond, this would be not a very nice situation.

>> In other words, better instrumenting hosts to detect and report these faults based on information they're already collecting for other reasons might be better than trying to develop and deploy a n…

I beg to differ.  I think that the new header is much the easiest way.   Agent architecture is tremendously difficult and costly to develop and maintain.  In particular as we go to a more and more mobile world.

>>This sounds like multi-lever security, and Common Architecture Label IPv6 Security Option (CALIPSO) (RFC5570) might be the answer.

How this fits into the discussion is something that you might want to explain more.  I am afraid that it is eluding me.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Mark Smith <[email-masked]>
To: Nalini Elkins <[email-masked]>; Lorenzo Colitti <[email-masked]> 
Cc: Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, June 3, 2013 2:33 PM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Jun 2013 20:47:35 -0700

> 3.  When packet a reaches the host b, we know how long the network time was to get from host a to host b because there is a timestamp.  Without a timestamp, there is no way of knowing.

But the accurate resolution of this knowledge is on the order of ± tens if not hundreds of milliseconds, not the picoseconds you stated earlier.

The relative difference in timestamps between packets sent from the same host may be microseconds or even sub-microseconds (very unlikely nano, let alone pico seconds), but the accuracy when comparing time on server b to timestamps created by host a is much much less, even with NTP synchronizing both hosts.

> 4.  When host b finishes its processing.  It sends packet b back to host a.  The packet trace tool knows how long the server time was -- the delta between when the packet was received at host b to…

But it cannot know how long it took the packet b to arrive back at host a, which I would expect must be part of any meaningful SLA as well.

Remember, the return route from b to a does not necessarily have anything in common with the pat from a to b. The traversal time could be radically different or the packet might never arrive at host a. Without an agent on host a, you cannot measure this.

> 5. These times can be used for Service Level Agreements of network time and server times.     

Not as a complete solution, they can't. You still need the agent on host a to measure the total time between when it sent packet a and when it received packet b.

> 1.  Who is to code such agents?  This is hardly simple code.  You have to capture all packets and then find duplicates or out of order in real time and then send traps.  AND, you have to do all thi…

You don't have to capture all packets... You only have to capture the packets in flows you are interested in analyzing.

> 2.  The other day, I worked with a device which was sending a duplicate acknowledgment once every millisecond.  If this host was to send SNMP traps  once every millisecond, this would be not a very…

I'm not sure I follow the relationship here. Why does the result from the host have to be different from the result that would be produced as a result of your extension header? If the extension header wouldn't cause the host to send an SNMP trap every ms, why would the agent have to do so?

Owen

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 12:09:09 +0000

I would like to agree with what I believe Fred is saying.   That is, that for those of us that do diagnostics at large DataCenters (EDCO),  the problem resolution needs addressed here span multiple protocols and are not limited to TCP.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Saturday, June 01, 2013 10:47 AM
To: Dan Wing (dwing)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 12:09:10 +0000

Possibly true.   But when the intended value is understood, perceived and experienced, then those implememtations that wish to derive the inherent benefits, will configure accordingly.   

Anything which is new may be relatively unknown and unused initially, but the intent is to have a valuable,useful diagnostic facility, once it is understood (and possible even optimized). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Monday, June 03, 2013 4:42 AM
To: [email-masked]
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

> unfortunately, a number of firewalls, etc, drop packets which contain

About that: I would guess that the number of firewalls that will drop a new option header will be greater than the number of firewalls that currently drop fragment headers. So the current situation with firewalls would argue in favour of using the fragment header...

Simon

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 12:09:12 +0000

If we are to assume that ALL Extension Headers are going to be dropped then IPV6 has MUCH BIGGER issues than being addressed in this draft.

________________________________
From: Fernando Gont <[email-masked]<mailto:[email-masked]>>
To: Nalini Elkins <[email-masked]<mailto:[email-masked]>>
Cc: Fred Baker (fred) <[email-masked]<mailto:[email-masked]>>; Dan Wing (dwing) <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 3, 2013 6:47 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: [email-masked]<mailto:[email-masked]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 12:09:11 +0000

The large IPID numbers and the rapid change due to high bandwidth connections (and ultimately whether 32 bits is large enough for IPID   in the Fragment header),  could conceivably be an issue in a situation with an extremely large number of fragments, when using the IPID for Fragment reassembly .
However, it would never be an issue using the Packet Sequence Number field for diagnostic purposes.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Monday, June 03, 2013 9:50 AM
To: Fernando Gont; Dan Wing
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

Thanks,
Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com<http://www.insidethestack.com>
________________________________
From: Fernando Gont <[email-masked]<mailto:[email-masked]>>
To: Dan Wing <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Sent: Monday, June 3, 2013 6:44 AM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

array[fragment]

Cheers,

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 12:09:10 +0000

As a diagnostic person, I would prefer this information to be in the Main IP Header, as in IPV4.   

However, understanding all the issues from the previous IETF meeting in Orlando, the best solution was an extension Header. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Monday, June 03, 2013 9:48 AM
To: Nalini Elkins
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

> - that is, an atomic fragment.

This is incorrect. Please reference any RFC section which requires a special Identification value (i.e., zero) for atomic fragments (hint:
there's no such a recommendation).

> hope will change .   But, it is the reality.

Firewalls will usually block all extension headers. My advice in this area would be "think twice before specifying an IPv6 extension header.
Then don't". :-)

Cheers,

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 04 Jun 2013 14:44:11 +0100

On 04/06/2013 13:09, Ackermann, Michael wrote:
> If we are to assume that ALL Extension Headers are going to be dropped then
> IPV6 has MUCH BIGGER issues than being addressed in this draft. 

That would be a reasonable assessment of v6 extension headers, yes.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Jun 2013 23:29:26 +0900

On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael <[email-masked]>wrote:

>     If we are to assume that ALL Extension Headers are going to be
> dropped then IPV6 has MUCH BIGGER issues than being addressed in this
> draft.
>

I'm afraid that on the Internet, a lot of the time, they are:

http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 4 Jun 2013 23:29:58 +0900

> As a diagnostic person, I would prefer this information to be in the Main

Changing the IP header is not realistic. That ship sailed about 15 years
ago.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 4 Jun 2013 18:01:05 +0000

Understood.      But that should change or at least the message should be loud and clear, that this is not acceptable.

In certain situations dropping EH's will be necessary and/or appropriate.   But as a general practice or default, it suggests that the IPV6 architecture is flawed.      I don't want to believe that.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, June 04, 2013 10:29 AM
To: Ackermann, Michael
Cc: Nalini Elkins; Fernando Gont; [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

On Tue, Jun 4, 2013 at 9:09 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:
If we are to assume that ALL Extension Headers are going to be dropped then IPV6 has MUCH BIGGER issues than being addressed in this draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Jun 2013 13:10:23 +0900

On Wed, Jun 5, 2013 at 3:01 AM, Ackermann, Michael <[email-masked]>wrote:

>  But as a general practice or default, it suggests that the IPV6
> architecture is flawed.      I don’t want to believe that.
>

You're free to believe what you want, but that data came from real-world
measurements. Unfortunately, there are good operational reasons (like lack
of hardware support) for this state of affairs, so it will not be
sufficient to tell network operators that they are misguided and wait until
the problem is fixed.

As for the architecture being flawed: remember that the IPv6 protocol was
finalized 1998. The Internet was a different place back then. IPv4 is no
better of course - there are plenty of features that haven't worked on the
Internet for a very long time. Record route? Source routing? Source quench?
Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago.

---

From: Nalini Elkins <[email-masked]>
Date: Wed, 5 Jun 2013 07:45:22 -0700 (PDT)

>> IPv4 is no better of course - there are plenty of features that haven't worked on the Internet for a very long time. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago.

There is a difference between basic functionality and relatively peripheral functionality.  I would put extension headers in the basic category.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Lorenzo Colitti <[email-masked]>
To: "Ackermann, Michael" <[email-masked]> 
Cc: Nalini Elkins <[email-masked]>; Fernando Gont <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, June 4, 2013 9:10 PM
Subject: Re: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

On Wed, Jun 5, 2013 at 3:01 AM, Ackermann, Michael <[email-masked]> wrote:

But as a general practice or default, it suggests that the IPV6 architecture is flawed.      I don’t want to believe that. 

You're free to believe what you want, but that data came from real-world measurements. Unfortunately, there are good operational reasons (like lack of hardware support) for this state of affairs, so it will not be sufficient to tell network operators that they are misguided and wait until the problem is fixed.

As for the architecture being flawed: remember that the IPv6 protocol was finalized 1998. The Internet was a different place back then. IPv4 is no better of course - there are plenty of features that haven't worked on the Internet for a very long time. Record route? Source routing? Source quench? Non-TCP/UDP protocols? In IPv4, that all stopped working a while ago.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Jun 2013 17:25:12 +0200

On 06/05/2013 04:45 PM, Nalini Elkins wrote:
> There is a difference between basic functionality and relatively
> peripheral functionality.  I would put extension headers in the basic
> category.

In practice, it is not.

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Jun 2013 11:52:56 -0700

That's not "practice". That's a bug. We really ought to be more careful 
about the difference.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Jun 2013 21:06:42 +0200

> That's not "practice". That's a bug. We really ought to be more careful

"In practce" == nothing depends nowadays on the use of IPv6 extension
headers. And since they are unreliable, I doubt anyone will want to make
their [whatever] depend on them.

Not that I like it... but the cat seems to be out of the bag, already
(earlier than expected, one might argue).

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Jun 2013 12:16:13 -0700

On 6/5/2013 12:06 PM, Fernando Gont wrote:
> headers.

Including fragmentation? Since - in practice - ICMPs are blocked, how 
would that ever work?

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jun 2013 08:14:28 +1200

> "In practce" == nothing depends nowadays on the use of IPv6 extension

That isn't true. But please take this up on 6man.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Jun 2013 03:47:10 +0200

> That isn't true. But please take this up on 6man.

Yep, I was sloppy: Certainly IPsec depends on extension headers. And
fragmentation relies on the fragment header. .. I was actually thinking
about Ext Headers carrying options (HBH, Gest Opt, etc.).

Cheers,