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

[Carlos Pignataro <[e-mail]>]

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?

>> 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.)

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
>