Re: New Version Notification for draft-herbert-6man-icmp-limits-00.txt

[[e-mail]]

> 
>>> would be to stop using
>>> extension headers if we saw that they were causing packet drops. The
>>> second level of action is to alert the administrator so that
>>> configuration can be changed appropriately. The third level action,
>>> would be to try to automatically scale back the extension headers to
>>> be more palatable to whatever node is having a problem with them.
>> 
>> This sounds like Happy Eyeballs on steroids. I do think that
>> diagnosis is the most important use of this idea.
> 
> Actually, I think we're trying to avoid having to do Happy Eyeballs
> for extension headers. The equivalent mechanism right now would be
> something like applications sending packets with different extensions
> headers, detecting loss, and so trying to reverse engineer based on
> packet loss (which requires transport layer input) which extension
> headers are allowed on the path to a destination and which aren't. I
> don't think any host implementation would ever actually implement
> that, it is far easier just to not use extension headers at all.

Since it would take some time before all routers on all paths implemented this, wouldn't applications have to deal with the smallest common denominator anyway?

If there is an application class that can chose based on received ICMP if an extension header should be included or not, why wouldn't it not send EH ever?

I do see the point for troubleshooting though.

Cheers,
Ole