Subject: Re: Offset Indicating option

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Nov 2011 22:06:52 -0500

Just a question about this idea in general, if one of the reasons to
do it is to save middleboxes from doing 'lots of work' ... wouldn't a
smart attacker just not put this header in? and then choke the
middleboxes?

what's the incentive for a source to add this header? (it's not in
their interest to make things 'easier' is it?)

-chris
(interesting discussion at the meeting, thanks!)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 16:15:42 +1300

Chris,

> smart attacker just not put this header in? and then choke the

I could use that argument against *any* optimisation, couldn't I?
DoS is hard to defeat.

> their interest to make things 'easier' is it?)

Well, you can argue that it's a small price to get a small improvement
in response time from busy servers, but I agree, this would be a matter
of persuading stack vendors to do it because it's good to do it.

   Brian

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Nov 2011 22:41:49 -0500

> I could use that argument against *any* optimisation, couldn't I?

yes... it's not super hard :) but I get your point. The addition of an
assumption that middleboxes need/want/will-use this is part of my
weird feeling about this idea.

> of persuading stack vendors to do it because it's good to do it.

ok. still seems odd to me :) but sure.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Nov 2011 15:51:55 -0500

> > smart attacker just not put this header in? and then choke the

Actually, I think the argument is not that middleboxes will do less
work if this option is present, it's that they won't do the work at
all in the case where the option is *not* present. I.e., they won't
parse all the extension headers to get to the TCP Port numbers in
order to do (say) ECMP. If they could parse them, i.e., they have the
code and can do so, then they don't need the option in the first
place. I thought the premise for this work was middleboxes that
couldn't be bothered with parsing extension headers properly.

Thus, if a source includes this option, perhaps it will get slightly
better performance because ECMP works better on one of the paths.

If the option is missing, ECMP won't work as well.

IMO, no source will bother to implement the option based on this
cost/benefit.

> I could use that argument against *any* optimisation, couldn't I?

I think this is backwards. You have previously made the case that
middle boxes can't/won't parse extension headers. So they won't be
doing the extra work if the option is not present. Right?

So this isn't an optimization. This is to get around middleboxes that
are unwilling/unable to implement the specs as specified.

> of persuading stack vendors to do it because it's good to do it.

Sorry, what has this got to do with "busy servers"? this option is
only for middle boxes. Servers will ignore it.

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Tue, 22 Nov 2011 08:12:01 -0500

Thomas,

On 11/21/11 3:51 PM, Thomas Narten wrote:
> Brian E Carpenter<[email-masked]>  writes:
>
>> Chris,
>

I am hoping that the use of the flow label for ECMP will mitigate this 
type of failure scenario.

> only for middle boxes. Servers will ignore it.

They will ignore it because they need to process all the options 
included in the packet.

Regards,
Brian H.