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

[Mirja Kühlewind <[e-mail]>]

Hi Gorry,

thanks for your comments. We did not address your comments in the last 
revision as wanted to get our updates out in time. However, we are already 
working on the next revision and will incorporate your comment in the next 
update. Stay tuned!

Mirja


On 18.01.2016 17:37, [e-mail] wrote:
> 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
>