Re: [Last-Call] [v6ops] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Brian E Carpenter <[e-mail]>]

On 08-Apr-21 03:20, Tom Herbert wrote:
...
> So my fundamental concern with this draft is that it is an entirely
> qualitative description of a well known problem, however a qualitative
> analysis is insufficient input for moving extension headers forward.
> In the draft, there are several reasons suggested as to why routers
> might drop packets, however there is no indication of the relative
> occurrence frequency of these.

That seems to call for a fairly major measurement project by an
organisation like CAIDA or RIPE Labs, with collaborative ISPs.
While that is a perfectly good idea, it would presumably take
a couple of years to get data. I personally don't see it as a
valid reason to hold up this draft. Maybe the authors should
add a note about the need for data.

> Also, there are parameterizations
> mentioned such as in the state that routers might drop if the chain is
> "too long", there is no analysis on exactly what "too long" commonly
> is (a couple of sizes for parsing buffers are mentioned but without
> reference which is another frustration of mine with this draft). A
> quantified analysis of the problem would delve into implementations
> and deployment thereby providing actionable data. Note this is not the
> same as making recommendations, I am just asking for the operational
> data as part of the analysis from which we could derive guidance or
> new protocol requirements.

Again, I don't see how that can be done without a major and organised
effort. The issue of buffer sizes may also involve proprietary
information, which is another difficulty. Again, it is neither quick
nor easy to get data.

Regards
    Brian

> Tom
> 
> 
> Tom
> 
>>
>> Regards,
>> Rob
>>
>>
>>> -----Original Message-----
>>> From: v6ops <[e-mail]> On Behalf Of Tom Herbert
>>> Sent: 10 March 2021 02:03
>>> To: Fernando Gont <[e-mail]>
>>> Cc: Gorry Fairhurst <[e-mail]>; IPv6 Operations
>>> <[e-mail]>; [e-mail];
>>> [e-mail]; [e-mail]
>>> Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-
>>> v6ops-ipv6-ehs-packet-drops-05
>>>
>>> On Tue, Mar 9, 2021 at 4:03 PM Fernando Gont <[e-mail]>
>>> wrote:
>>>>
>>>> On 9/3/21 19:07, Tom Herbert wrote:
>>>> [...]
>>>>>
>>>>> Yes, ACLs on transport layer ports are common requirements, however
>>>>> the problem arises from related requirements that arise due to the
>>>>> limitations of routers to be able to locate the transport layer
>>>>> information in a packet. An example of such an implied requirement
>>>>> from this draft is "don't send packets with IPv6 header chains that
>>>>> are too long because some routers can't parse deep enough into packets
>>>>> to find the transport layer ports due to implementation constraints
>>>>> (like limited size parsing buffer)".
>>>>
>>>> You seem to be reading more from the document than what we actually said
>>>> in the document.
>>>>
>>>> There are no requirements in this document. We simply explain things
>>>> operators need to do, what are the associated limitations in real-world
>>>> devices, and what's the likely outcome.
>>>>
>>>> That's not an implied requirement, but simply a description of facts.
>>>>
>>> It's obvious that the implied or at least inferred requirement is that
>>> if a host wants to increase the probability of packets making it to
>>> the destination then they should not make header chains too long. This
>>> would also be an obvious interoperability requirement, i.e. if I make
>>> my header chains too long then packets will be dropped and my host
>>> stack is not interoperable with some elements in the network.
>>>
>>>>
>>>>
>>>>> While the rationale for the
>>>>> requirement may make sense, the problem, at least from the host stack
>>>>> perspective of trying to send packets with low probability they'll be
>>>>> dropped, is that a requirement that "don't IPv6 header chains that are
>>>>> too long" is is useless without any quantification as exactly to what
>>>>> "too long" might be.
>>>>
>>>> "too long" for the processing device(s). You don't know what devices
>>>> will process your packets, hence cannot even guess what "too long" might
>>>> mean.
>>>>
>>>> What you know for sure is that the longer the chain, the lower the
>>>> chances of your packets surviving -- as per RFC7872.
>>>>
>>> That seems to me more like an assumption than a proven fact. To prove
>>> it we'd need the data that correlates the length of the chain with
>>> probability of drop, or alternatively, one could survey common router
>>> implementations' capabilities and similarly extrapolate the
>>> correlation. If we had this data then we could derive a meaningful
>>> quantified requirement for both what routers are expected to process
>>> and what hosts can expect. RFC7872 doesn't really have sufficient data
>>> to make this correlation, and besides that it is not current.
>>>
>>> In any case, this draft qualitatively describes why routers are
>>> droppings. Which I suppose is good, but, given that information, I
>>> don't see much that helps host developers that are sending packets in
>>> the network and are trying to go beyond sending packets that conform
>>> to the least common denominator of plain TCP/IP.
>>>
>>> Tom
>>>
>>>> Thanks,
>>>> --
>>>> Fernando Gont
>>>> SI6 Networks
>>>> e-mail: [e-mail]
>>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>