Subject: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation

From: Bob Hinden <[email-masked]>
Date: Tue, 15 Dec 2015 10:57:27 +0200

This message restarts a two week 6MAN Working Group Last Call on advancing:

   Title           : Deprecation of the Generation of IPv6 Atomic Fragments
   Authors         : Fernando Gont
                     Will(Shucheng) Liu
                     Tore Anderson
   Filename        : draft-ietf-6man-deprecate-atomfrag-generation-04.txt
   Pages           : 9
   Date            : 2015-11-26

   https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-04

as an Informational Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 12 January 2016.  This is a four week last call to account for the holidays in December.

Best regards,
Ole & Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 18:00:47 +0000

Hi, this is a late comment. But, one way to include an Identification value with a packet
is to include a fragment header with (Offset=0; MF=0) and set the Identification value
to something that might provide useful information to the network and/or destination.
Will this work deprecate that capability?

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Tuesday, December 15, 2015 12:57 AM
> To: IPv6 List
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation
> 
> as an Informational Document.  Substantive comments and statements of support for publishing this document should be directed to
> the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 12 January 2016.  This is a four week last call to
> account for the holidays in December.
> 
> Best regards,
> Ole & Bob
>

---

From: <[email-masked]>
Date: Wed, 16 Dec 2015 18:20:30 +0000 (UTC)

From: "Templin, Fred L" <[email-masked]>

>Will this work deprecate that capability?

Fred,

Our PDM Destination Option which is in review an IPPM and 6Man will provide a sequence number which is what the IP Identification value provided for network diagnostics.

https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/

Our draft actually provides much more in terms of response times, sequence numbers last received etc.   We would love to have comments and review by you & anyone else!

We have implementations underway to test what we are doing.  We have a prototype on FreeBSD & are working on Windows.

Nalini Elkins
Inside Products, Inc.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 19:49:27 +0000

Hi Nalini,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 16, 2015 10:21 AM
> To: Templin, Fred L; Bob Hinden; IPv6 List
> Subject: Re: 6MAN WG Last Call - draft-ietf-6man-deprecate-atomfrag-generation
> 
> Our draft actually provides much more in terms of response times, sequence numbers last received etc.   We would love to have
> comments and review by you & anyone else!
> 

It looks like your document is specifying a 16-bit sequence number whereas
IPv6 frag header provides 32-bits.  RFC6864 explains why 16-bits is insufficient
for functions such as duplicate packet detection, which is one of the uses I
have in mind.

Thanks - Fred

---

From: <[email-masked]>
Date: Wed, 16 Dec 2015 19:55:53 +0000 (UTC)

Fred,

My comments below yours. 

>for functions such as duplicate packet detection, which is one of the uses I

Fred, duplicate packet detection is one of the uses we had in mind also. The 16-bit field is used in conjunction with the other fields:

PSNTP    : Packet Sequence Number This Packet 
PSNLR    : Packet Sequence Number Last Received 
DELTATLR : Delta Time Last Received 
DELTATLS : Delta Time Last Sent

to calculate duplicate packets.  I would be interested to know the other uses that you have in mind.  It will help our thinking also.

Both 16-bit and 32-bit counters will wrap quickly.

Thanks,
Nalini

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 21:13:00 +0000

Hi Nalini,

> Sent: Wednesday, December 16, 2015 11:56 AM
> > Our PDM Destination Option which is in review an IPPM and 6Man will provide a sequence number which is what the IP
> Identification
> > value provided for network diagnostics.
> >

I am not sure about 32bit counters wrapping quickly. On a 10Gbps path,
assuming 60B packets, a 32-bit counter would wrap in 206seconds. That
is still greater than the Maximum Segment Lifetime for IPv6. Are you
worried about end-to-end data rates greater than that?

Thanks - Fred

---

From: <[email-masked]>
Date: Wed, 16 Dec 2015 21:26:17 +0000 (UTC)

Hello Fred,  

>worried about end-to-end data rates greater than that?

It all depends on what your world is, I suppose.
Here is from an advertisement for high performance switches taken from a simple Google search:
"[company name omitted] provides the highest performing Open Ethernet switch systems atspeeds of 10/25/40/50/56/100Gb/s, enabling Data Centers, Cloud Computing,Storage, Web2.0 and High Performance Computing applications to operate atmaximum functionality at any scale."

My world tends to be at the data center & 100gb oriented.  
Having said that, I think we are getting off-topic.  IMHO, I believe that PDM with 16-bit counters along with the other fields will allow us to find duplicate packets quite easily.  In my experience, many, if not most of the cases of duplicate packets that I have most issues with at my customer sites are well in the range provided by 16-bits - esp. for a 5-tuple.
I only brought this up because IMHO, I do not know that IP Identification from the Fragmentation header is needed.  The lack of IP ID was, frankly, the issue that started us working on the PDM Destination Option to start with.  We use IP ID very often for network problem diagnostics in my world.
Nalini