Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)

[[e-mail]]

--- On Mon, 8/15/11, Carlos Pignataro <[e-mail]> wrote:

> From: Carlos Pignataro <[e-mail]>
> Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)
> To: [e-mail]
> Date: Monday, August 15, 2011, 2:54 AM
> 
> 
> On 8/15/2011 2:21 AM, Joel Jaeggli wrote:
> > 
> > On Aug 14, 2011, at 1:31 PM, [e-mail]
> wrote:
> > 
> >> 
> >> I am working on contacting a number of our large
> corporate
> >> customers to weigh in on this topic.  I think
> that the biggest
> >> issue here is that when a large commercial network
> is having
> >> problems, anything that can help speed diagnostics
> is worth doing.
> >> Outages and poor performance can cost a great deal
> of money.
> >> 
> >> Situations such as comparing packets at various
> points on the
> >> network to determine packet loss is a necessary
> part of network
> >> problem determination.
> 
> I agree with this. To compare packets, we could potentially
> have the
> network protocol analyzer (e.g., Wireshark) compute a hash
> on invariant
> fields of the packet (i.e., exclude Hop Limit, etc), and
> present that as
> packet metadata that is not actually carried on the wire.
> This would
> work for packet traces not being instrumented. Would that
> help?
> 

Well, that is a really good idea that we had explored also.  Now, we ourselves make an intelligent packet analyzer and work with the WireShark folks.  If I look at this selfishly for having an extra selling point for my products, then I can say, 'Yes, we allow you to do this!  Buy my product!'  But, I was trying to be a good citizen and allow all to do this without our products.  Now, if our proposal is not adopted, then we will do the checksum or hash on the packets in our products as I think it is needed for diagnostics. 

This idea also helps technicians who have taken a trace at one point using multiple facilities - that is, WireShark and IBM mainframe CTrace.  Then, it is useful to have the IPID shown in sequence.

But, the idea of the hash or checksum leaves aside the case where you have only one trace at one point along the path.  Being able to view the sequence of packet transmission is useful even then.  

Also, I really feel that down the road here, the 32-bit IPID is going to run into scalability issues.  We are proposing a 64-bit IPID.   The IPID is also not standardized.  Some implementations use the same IPID for all connections, others use a different IPID for each connection. Some increment by 1, some by two.

Our other future thoughts, and agenda, if you will, is that as networks and traffic grow, more and more diagnostics and troubleshooting will have do be done by computer systems rather than humans.  So, we are looking at what metrics need to be saved for that.  I feel that the IPID is one such.  There are others such as TCP Window Scaling - but that belongs on another email list, so I did not want to bring that up.


> >> I am working to get the technicians from
> >> the corporations themselves to get onto this email
> list and tell
> >> their opinions themselves.
> >> 
> >> I wish that the IPID was in the main IPv6
> header.  That would be
> >> the best place for it.  That is not possible,
> so what we are
> >> looking at is doing our best under the
> circumstances.  One problem
> >> with having a Fragmentation Header generated is
> that it skews
> >> statistics on fragmentation.
> > 
> > I presume that if one is parsing that far into the
> optional headers,
> > that you can distinguish between a fragment header
> that has an offset
> > of zero and a more fragments flag of 0 which would
> indicate the
> > existence of a fragmentation header but that no other
> fragments exist
> > and the other possible combinations.
> 
> This would also be less disruptive as it's a known header
> instead of a
> new header (potentially for existing nodes.)
>

Now, actually, I am setting up a meeting with the IBM TCP/IP architects, as they are the host implementation that we work most closely with, to ask them what exactly would their stack do if they got a fragmentation header with 0 in the fragmentation header.  I wonder if that would cause any problems.

And, yes, the fragmentation header is known.  But, you know, we feel that diagnostics is very important and as we all grow in our sophistication and hopefully ability to do network diagnostics and recovery automatically, we may have other uses for a 'Diagnostic Header'.  We see the IPID as potentially the first use of this.
 
> Thanks,
> 
> -- Carlos.
> 
> > 
> >> Many corporate networks keep track of how much
> fragmentation is on
> >> their networks and if we generate a spurious
> indication, then this
> >> invalidates the real fragmentation.
> > 
> > should be straight forward to distinguish between the
> two use-cases.
> > 
> >> Nalini
> >> 
> >> 
> >> --- On Sun, 8/14/11, Carlos Pignataro <[e-mail]>
> wrote:
> >> 
> >>> From: Carlos Pignataro <[e-mail]>
> Subject: [v6ops]
> >>> draft-elkins-6man-ipv6-diagnostic-header (Was:
> draft minutes ietf
> >>> 81, 3 meetings...) To: [e-mail]
> Date: Sunday, August 14,
> >>> 2011, 10:03 AM Hi,
> >>> 
> >>> I believe there was one further point raised
> in regards to 
> >>> draft-elkins-6man-ipv6-diagnostic-header
> (though I don't recall
> >>> if it was at the mike by Andrew Y., in a
> corridor, or only in my 
> >>> head): the Heisenbug principle -- if this is
> used in debugging
> >>> (and diagnostics), the issue being studied or
> attempted to
> >>> reproduce alters its behavior or goes away
> when modifying the
> >>> packet (like compiling with different -o). I
> think this is one of
> >>> the most important arguments against this
> proposal. The use of
> >>> fragment header is interesting, a new header
> could show much more
> >>> pronounced deviation of observed behaviour
> than without it.
> >>> 
> >>> For completeness, I did ask some services
> escalation engineers
> >>> about how they use the ip-id in IPv4 for
> troubleshooting, and 
> >>> basically got two main uses for very corner
> case situations in:
> >>> i. identify middleboxes and their
> characteristics (by check IP ID
> >>> increment patterns, find if packets generated
> by the same box),
> >>> and ii. track set of packets along different
> points in the
> >>> network (e.g., back-to-back packets and see
> rate, drops, out of
> >>> order). But it's built into the v4 header.
> >>> 
> >>> Thanks,
> >>> 
> >>> -- Carlos.
> >>> 
> >>> On 8/2/2011 1:24 PM, Joel Jaeggli wrote:
> >>>> * Presentation - RFC for IPv6 IP
> identification field
> >>> (header) - Mike Ackerman
> >>>> http://tools.ietf.org/agenda/81/slides/v6ops-7.ppt 
> >>>> http://tools.ietf.org/html/draft-elkins-6man-ipv6-diagnostic-header
> >>>>
> >>>>
> >>>> 
> Fred B - Question for the group, do you use the IPID
> >>> in ipv4? (no
> >>>> respondants other than presenters)
> >>>> 
> >>>> Weg G - We use it all the time? I've never
> heard of
> >>> it...
> >>>> 
> >>>> Francis D - it's potentially a covert
> channel, also
> >>> why not use the
> >>>> fregmentation header?
> >>>> 
> >>>> Bob H - We diefintently want to hear if
> this is
> >>> useful. I don't know
> >>>> who puts this header in the packet?
> >>>> 
> >>>> Nalini ? - The host clearly
> >>>> 
> >>>> Andrei Y - typical use case for this
> header would be
> >>> to see if a
> >>>> middle box is modifying the packet.
> >>>> 
> >>>> Fred B - What I'm out of this discussion
> is that the
> >>> application isn't
> >>>> a bad one, it could be simulated in a
> fregment.
> >>>> 
> >>>> Fred Baker - Meeting complete, go to
> Lunch
> >>>
> _______________________________________________ v6ops
> mailing
> >>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> >>> 
> >> _______________________________________________
> v6ops mailing list 
> >> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> >> 
> > 
> > _______________________________________________ v6ops
> mailing list 
> > [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> > 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>