Subject: RE: TCP Checksum Interoperability

From: Chris Trobridge <[email-masked]>
Date: Mon, 8 Apr 2002 15:30:18 +0100

FYI, The 'offending' stacks are PC/TCP (reception) and in Open VMS
(transmission).

This is an age-old issue; the following dates from 1985(!):

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8502.mm.www/0389.html

I think RFC 1624 is missing the UDP case, where +0 means "not calculated".
Indeed, RFC 768 asserts that the two values (+0 and -0) are equivalent.

Part of the problem is that there isn't an RFC standard that deals with the
issue of a zero checksum, apart from for UDP.

The protocol RFCs don't specify the details and the implementation RFCs
(1071, 1141, 1624) state explicitly that they are not standards, "It is not
a standard, but a set of useful implementation techniques".

They are a very good idea but not mandatory.

That's why I said I thought the receiver wasn't compliant: it rejects -0 as
invalid.

Chris

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: 05 April 2002 21:45
> To: Michael Smith
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]';
> [email-masked]'
> Subject: RE: TCP Checksum Interoperability
> 
> 
> On Fri, 5 Apr 2002, Michael Smith wrote:
> 
> > The last time this came up for a TCP implementation I used to
> > maintain, our interpretation of Robustness Principle applied to this
> > problem dictated that we shouldn't send segments with 
> checksum fields
> > set to all ones (that is, we shouldn't send ~(+0)), but 
> that we had to
> > accept either ~(+0) or ~(-0) in received segments.
> >
> > Strictly speaking, either zero state is completely legal
> 
> Not so. Please read RFC1624 sections 3-5.
> 
> L.
> 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> 
> 

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.
 
This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.

http://www.baltimore.com

---

From: Nguyen Thi Mai Trang <[email-masked]>
Date: Mon, 22 Apr 2002 19:06:46 +0200

Hi everybody,

I have a question about the notion of SLA (service level agreement) in Intserv/RSVP but I don't know where to post it
because the group Intserv is no longer active.

It seems that the notion SLA was born in Diffserv architecture. The SLA is necessary because network resources are
statically provisioned. It's very clear.

In Intserv/RSVP, I don't find the SLA/SLS (service level specification) concept in all concerning draft/RFCs . I
wonder if there is no SLA/SLS concept in Intserv/RSVP, how we can make policy decision in Intserv/RSVP.

Some clarifications:
In Intserv/RSVP, client uses RSVP to request resource in the routers. The routers verify if it has sufficiently
resources (Admission control) and the user has the right to request this amount of resource (Policy control) or not.
If both are positives, it makes the resource reservation for this flow. My question is that if there is no SLA/SLS,
how the network can answer (using COPS-RSVP for example) to the question "Does this client has the right to request
such a reservation ?" ?

Thank you very much,
Mai Trang

---

From: Alex Audu <[email-masked]>
Date: Tue, 23 Apr 2002 10:55:04 -0500

Refer to this excellent tutorial on QoS to answer your questions:   "Internet QoS: A Big Picture" by Xipeng Xiao and
Lionel M. Ni.  IEEE Network. March/April 1999.

Alex.