References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]><[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <C895825F- [EMAIL PROTECTED]> X-Mailer: Apple Mail (2.924) Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC) FILETIME=[7BFF73E0:01C8CB45]
inline... On 10 Jun 2008, at 22:50, Carsten Bormann wrote: >> a. Use UDP-Lite, to avoid checksum coverage of its payload, and >> still get a pseudoheader check from UDP. > > How does that help with getting rid of the checksum? > With UDP-lite, you now have two, with different coverage. > >> b. Implement its own transport protocol, in parallel with UDP/TCP/ >> SCTP, with its own pseudoheader check, doing payload coverage >> however it likes. > > That's what they did. No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do. > They want to do this on top of UDP, which is a usual way to build > new transport protocols these days (cf. RTP). No, it's a way to really build more 'session-like' protocols. I wouldn't call RTP a full transport, as it doesn't care about describing length, or about reliability. > If UDPv6 were like UDPv4, this would be a better fit. > >>> The mechanism/policy conflation mentioned above >>> makes that impossible. >> >> Not impossible. It comes down to the pain of using UDP-Lite, or the >> pain of writing your own proper gets-a-protocol-number transport >> protocol with its own pseudoheader check. Either is better from >> layering/size/complexity viewpoints than layering over UDP and >> turning UDP checksums off. > > I don't agree with "better" here. > Being able to use UDP reduces complexity here; certainly from an > implementation point of view (if you consider that there will be > hosts with common operating systems on e.g. Ethernets that want to > talk to lowpans). ...which makes removing the UDP checksum more problematic. >>> Changing UDPv6 at this stage is a big step. If that is not what we >>> (the IETF/the IPv6 implementers community) want to do, there is no >>> way >>> for the end system to make that statement. This does not mean >>> that we >>> shouldn't honor it. >> >> Sorry, I'm unclear on the meaning of your last sentence here; the >> double negative (triple from the previous sentence) doesn't help. > > I'm just saying that, in the first-hop/last-hop case, HC could help > 2460 a little here, just (as you noted) NATs tend to "help" with > maintaining that checksum, They don't "help". Quite the opposite - by recomputing the checksum the value of the end-to-end guarantee offered by the checksum is reduced. HC may save bits on the wire, but it doesn't help overall reliability. HC can't make anything as reliable, or more reliable. > by proxying out the UDP checksum generation/check to the next hop, > as long as there is something else that provides e2e protection. Why fake up a checksum at a proxy unless something is going to use it? And if something does, there are e2e implications. (I doubt that we will ever agree here.) > In the first-hop case, it is easy for the host to make the > statement (by providing a mechanism for eliding the checksum); in > the last-hop case, there would need to be some agreement (implied or > signaled). > > Gruesse, Carsten > DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ <http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
