Subject: [Spud] Some initial comments on Requirements for the design of a Substrate Protocol for User Datagrams (SPUD)

From: [email-masked]
Date: Mon, 18 Jan 2016 16:37:16 -0000

Here are a few comments on a read of the requirements draft:

In section 4;

NiT; correct /flow which are/flow that are/

/refrain from sending heartbeat traffic/
- disagree with the hard state view,
to me this should I feel be regarded as soft state, in as much as a
middlebox can decide to keep the state once it sees the start of a SPUD
flow, but keeping that state indefinitely is I think unlikely and quite
undesirable. I would suggest that rather than eliminating heartbeat needs,
it relaxes this need, and can result in flows that do not need to generate
explicit heartbeats because their natural protocol interactions already
provide sufficient packet exchanges to refresh the state.

Tear-down messages bring their own DOS and reordering opportunities, but
could anyway be regarded as advisory, perhaps even good policy is not to
remove state until after a grace period.

NiT; /tube/
- term used, but not previously defined (definition should come earlier)
Similarly spud flow?
... I am not sure I understand this related to a 5-tuple and then saying
they receive similar treatment, will this not also imply the same DSCP?

/ICMP/
- presumably also ICMPv6?

what is 5-tuple ICMP?
- isn't recommended ICMP processing already based on a sort of 5-tuple
utilising the payload to extract the flow info that caused the error? Can
you explain more than current?

Sect 5.1
I'm unclear what is intended by "may or may not" be related to separate
semantic entities in the superstate. This seems like it should include the
same caveats as exposed when using multiple DSCPs with upper layer
protocols, as discussed in the DART WG, but of course without assumptions
that DSCPs are end to end.

Sect 5.4 See earlier note on End Signalling, tear down messages may be
delayed, reordered, etc. Hence I am really unsure it can be a good idea
for these to explicitly and immediately release state. (Perhaps in a hard
state model, but then this model seems wrong to me). They can however be
used to know that an association will end with a particular sequence
number (etc). being robust to reordering and delay is important.

Sect 5.7.
I agree endpoints need to verify that messages originate on-path. Equally
though I would suggest endpoints need to be robust to path changes and
cases where more than one path exists at a time, although I would say that
maybe these cases are not the norm, more that any system should not behave
stupidly when these occur.

Sect 6.1
Maybe you could think again about wording of this requirement! I do not
think you can require it to work through arbitrary middleboxes. You can
require the protocol to be designed to optimize the chances of success, or
something.

Sect 6.2
NiT: Again, probably "designed to have low overhead" is more correct?

Sect 6.3
- I understand the conclusion to use UDP, but TCP is widely implemented
also and often provides richer APIs all available from user space. it just
does not meet the requirements in terms of the transport services that are
needed by SPUD - which seems to need a datagram transport. So I am not
sure I agree with why the current reasoning, but agree with the outcome.

Sect 6.4
NiT: Again, probably "designed to operate in the present internet" is more
correct?

Sect 6.4
I do not agree that the information exposed by SPUD needs (must) be
useful, only that this is desirable to stimulate deployment. It doesn't
seem a prerequisite to me. Again, I'd argue that the information "should"
provide incentives, not has to.

Sect 6.4
I'd encourage the authors to bring out the implications of loss,
reordering etc as a separate point, since these are I suggest unrelated to
incremental Deployability.

Sect 6.4
I'm  about the actual requirements to operate in multiparty, multicast
etc. If the need is to support multicast, this is a CORE reason why SPUD
has to be over UDP, since it is the only IETF standards track transport
protocol that supports multicast over the network layer. In stating the
support for this, it's brings very specific requirements - I don't see
these discussed - Is the assumption SSM? ASM? Both? How will SPUD handling
scaling and multiple responses from different branches in the tree, etc?

Then Multipath. Multipath surely brings it own set of requirements - what
are these.

Sect 6.5
What is background in this context?
- The present text makes it sound like off path attack for UDP is somehow
a more problem than for TCP, whereas I think what may be intended is that
UDP receivers are not protected from these threats in the way that TCP and
other connection-Oriented transports protocols provide protection?
- The forgery of a source address is maybe less of an issue for multicast,
because of RPF rules,

This section could usefully refer to the UDP Guidelines, and probably
other sections, since some of what this document discusses are not
actually SPUD specific issues, but issues that result from the limited
in-built transport services offered by UDP. In these cases, reference to
the guidelines RFC(or newer ID) would seem the correct requirement.

Sect 6.5
/We note.../ This note is quite confusing to me. I am not sure what is
intended. In some ways this seems to contradict the multicast requirement,
and I am not sure what it really implies. Please clarify.

Sect 6.11
- duplication robustness was also noted as a need in 6.4. See note there.

Sect 6.11
- sending less that the output link MTU does not avoid downstream
fragmentation. I think this fragmentation requirement is a little
difficult to understand, but is important. For instance, how will SPUD
work with IPv6, where fragmentation -even at the endpoints, requires a UDP
checksum?

Sect 6.12
I see two requirements here, that the user of the transport service
(superstrate) is transparent to whether SPUD is used beneath. This I think
I understand.
The second is that the two formats are freely transcodable of the wire,
which leaves me very puzzled and worried.
Are these tow points perceived the same? I do not understand? And why the
latter?

Sect 6
There is no explicit requirement that the there is a return path from the
the receiving endpoint back to the sender, although I think this could
well be implied. I'd have expected this. I'd also hoped for some text that
said that data flow (whatever words) could be Uni or Bi directional, is
that the case?

Sect 6
In discussing robustness, it could be worth noting (aka UDP guidelines)
that per packets signals may need to be repeated over multiple packets and
appropriate interval to have sufficient confidence of delivery under link
loss or congestion.

Section 7.1
I think I didn't get my head around these two options.
I wonder though if this is related to a /bidirectional/ flow? - is it only
when the superstrate is bidirectional, I would have thought it was when
the SPUD layer was bidirectional, but maybe I am already confused here,
and will only be able to comment when the above comments are clarified.

section 7.3
I think there are two very distinct cases here:

1) avoiding corrupt data to the endpoint, and sent to other endpoints
I am not sure what the corruption protection model is that is being
proposed. How will SPUD use higher layer checksums to validate lower layer
information? Models vary widely, maybe this is implied use of DTLS or
something?

2) avoiding corrupt control data used by SPUD endpoints and middleboxes
- is it possible to separate these topics?

Section 7.6
I would personally prefer separation of the requirements for end to end
transport discovery support (and superstrates)  and the different case of
discovering middleboxes.

Hope this helps, and look forward to finding out more,

Gorry