I think that the ROLL ML can be removed from this thread. Thanks.
JP. On 6/11/08 12:01 AM, "Lloyd Wood" <[EMAIL PROTECTED]> wrote: > References: > <[EMAIL PROTECTED]> <[EMAIL PROTECTED] > 37.emea.cisco.com> <[EMAIL PROTECTED]> <208D4602-AE7F-457E-9377-96296 > [EMAIL PROTECTED]> <[EMAIL PROTECTED]> <86848218-AF7E-4E9C-9A6C-5B > [EMAIL PROTECTED]> <[EMAIL PROTECTED] > .emea.cisco.com> <[EMAIL PROTECTED]> <12114968 > [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]> > > > > > _______________________________________________ > Roll mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
