Re: [Spud] SPUD magic number

[Toerless Eckert <[e-mail]>]

On Fri, Apr 10, 2015 at 10:26:34AM -0700, Tom Herbert wrote:
> 32 bits seems a little light to me for this usage #2, especially if
> when some application packet inadvertently matches the magic number
> packet is dropped when it would have otherwise been accepted if magic
> numbers weren't being checked. 64 bits might be safer.

See my last email of how we ultimately would get 1/2^96 false
positive in middleboxes that are keeping today per-flow state
and with SPUD would do per-tube state.

> For UDP encapsulations (GUE, Geneve, VXLAN, etc), we probably would
> the magic number to be optional since we'll already have a port number
> to identify the protocol (at the client) and might not need middlebox
> support within a data center.

Even if just meant to be used for end-to-end signaling, i would not
remove the cookie. Its still very helpfull for end-to-end communication,
especially for any communication where it is not upfront clear whether
SPUD is used or not. And if there is prior signaling that makes
the endpoints know SPUD is used, then the cookie is easy to skip.
And hopefully the 32 bits are not going to be so valuable space
(SPUD tax..) that we need to make them optional.

I think the most important design goal should be to ensure that it
is easy for middleboxes to distinguish different type of "awareness"
int SPUD traffic, so that a middlebox would only need to inspect what
it is intersted in.

For example: A middlebox that ONLY wants to do a lightweight tracking
of flows would simply set up snoop punt entry in the forwarding plane
for cookie+cmd=01, cookie+cmd=02, cookie+cmd=03. And it would
never see data packets, but just connection setup/teardown.

With this in mind, i think it would be a lot better if SPUD had 8 bit
of CMD, and that would give us the ability to distinguish additional
levels of awareness through additional new CMDs, and only the middleboxes
interested in those commands would have to snoop those command packets
its interested in. And we could of course also simply say that the
high order bit = 0 or 1 is an indication whether middleboxes are
allowed to look at (and potentially modify) the packet. 

Cheers
    Toerless
> 
> Tom
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud

-- 
---
Toerless Eckert, [e-mail]