Hi, Brian, On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter < [email protected]> wrote:
> Spencer, > On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: > > <snip> The bits where we can simply do what you suggest </snip> > > > Grrr, but please see below. > > > >> > >>> > >>> I'm really confused by this text. > >>> > >>> Nevertheless, when running within a secure ACP on reliable > >>> infrastructure, UDP MAY be used for unicast messages not exceeding > >>> the minimum IPv6 path MTU; however, TCP MUST be used for longer > >>> messages. In other words, IPv6 fragmentation is avoided. If a node > >>> receives a UDP message but the reply is too long, it MUST open a TCP > >>> connection to the peer for the reply. Note that when the network is > >>> under heavy load or in a fault condition, UDP might become > >>> unreliable. Since this is when autonomic functions are most > >>> necessary, automatic fallback to TCP MUST be implemented. The > >>> simplest implementation is therefore to use only TCP. > > Editor hat off. > > I agree. I think it's very naive to think that for this application, > intended to be used internally within an enterprise network, in > a NAT-free and proxy-free addressing realm, UDP has any value. > In fact, it's just a nuisance, since the programmer has to do a lot > of the work that TCP does. The performance gain, even if it's real, > is unimportant - autonomic traffic will be a tiny fraction of total > traffic. There will be no gain in footprint, since autonomic nodes > will carry full TCP stacks anyway. [If we wanted to put GRASP in > constrained nodes, we'd probably be talking about GRASP-over-COAP > anyway.] So here's what I would do: > > OLD > All other GRASP messages are unicast and could in principle run over > any transport protocol. An implementation MUST support use of TCP. > It MAY support use of another transport protocol. However, GRASP > itself does not provide for error detection or retransmission. Use > of an unreliable transport protocol is therefore NOT RECOMMENDED. > > Nevertheless, when running within a secure ACP on reliable > infrastructure, UDP MAY be used for unicast messages not exceeding > the minimum IPv6 path MTU; however, TCP MUST be used for longer > messages. In other words, IPv6 fragmentation is avoided. If a node > receives a UDP message but the reply is too long, it MUST open a TCP > connection to the peer for the reply. Note that when the network is > under heavy load or in a fault condition, UDP might become > unreliable. Since this is when autonomic functions are most > necessary, automatic fallback to TCP MUST be implemented. The > simplest implementation is therefore to use only TCP. > > NEW > All other GRASP messages are unicast and could in principle run over > any transport protocol. An implementation MUST support use of TCP. > It MAY support use of another transport protocol, but the details > are out of scope for this specification. However, GRASP itself does > not provide for error detection or retransmission. Use of an > unreliable transport protocol is therefore NOT RECOMMENDED. > END NEW > > That doesn't slam the door, but it removes what I now feel is > a very misleading paragraph. Of course, anybody is at liberty to > draft a full description of GRASP-over-UDP as a separate > document. > > Again, that was personal opinion. I won't edit that part of > the draft without community input. > Thanks, and I agree with not making changes unless there's community agreement. I do suspect that if UDP is not at least NOT RECOMMENDED, some developers may not use TCP at all. A quick Google search turned up e-mail from 2015 asking "if we REALLY have to support TCP in our (micro-)DNS server", and TCP to accommodate response TrunCation has been a requirement for DNS since at least RFC 1035 in 1987. But I don't know the future, of course. :D Spencer > Brian >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
