Re: [TICTOC] UDP checksum

Marshall Eubanks <tme@americafree.tv> Fri, 21 January 2011 20:36 UTC

Return-Path: <tme@americafree.tv>
X-Original-To: tictoc@core3.amsl.com
Delivered-To: tictoc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9233A67F6 for <tictoc@core3.amsl.com>; Fri, 21 Jan 2011 12:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.277
X-Spam-Level:
X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-Wo80ZlOxBr for <tictoc@core3.amsl.com>; Fri, 21 Jan 2011 12:36:26 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C687F3A67F5 for <tictoc@ietf.org>; Fri, 21 Jan 2011 12:36:25 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 6B8BE9B5366D; Fri, 21 Jan 2011 15:39:12 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Marshall Eubanks <tme@americafree.tv>
In-Reply-To: <4D39EC31.10602@cisco.com>
Date: Fri, 21 Jan 2011 15:39:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <01E54480-7D98-46F8-B82A-21A178044512@americafree.tv>
References: <7C362EEF9C7896468B36C9B79200D8350CFB0DFDA7@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6941B04CC39@SJEXCHCCR02.corp.ad.broadcom.com> <7C362EEF9C7896468B36C9B79200D8350CFB0DFDAA@INBANSXCHMBSA1.in.alcatel-lucent.com> <2C2F1EBA8050E74EA81502D5740B4BD6941B04CC6D@SJEXCHCCR02.corp.ad.broadcom.com> <4D39EC31.10602@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1081)
Cc: tictoc@ietf.org
Subject: Re: [TICTOC] UDP checksum
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2011 20:36:27 -0000

On Jan 21, 2011, at 3:27 PM, Stewart Bryant wrote:

> Presumably this is a v6 discussion. I can't see any point in using the c/s in v4.
> 
> WRT v6 there is a movement to make this optional (the debate is happening in 6lowlan, and I think that we should be pushing to turn it off for PTP.
> 
> The worst that can happen is that we receive a corrupt pkt and either junk it, or put it in the timing servo whereupon it gets rejected as an outlier.
> 

I think you are referring to this 

which is (will be shortly) in 6man

http://tools.ietf.org/html/draft-eubanks-chimento-6man-01

This is for the case where there is an "inner" packet with a header and checksum, so that the "outer" packet doesn't need protection.

Regards
Marshall

> - Stewart
> 
> 
> 
> On 20/01/2011 23:52, Shahram Davari wrote:
>> Hi Manav,
>> 
>> The minimum requirement is to do UDP checksum incremental update on transmission. If full update is done then UDP checksum must be verified on reception as well.
>> 
>> Thx
>> Shahram
>> 
>> -----Original Message-----
>> From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
>> Sent: Thursday, January 20, 2011 3:33 PM
>> To: Shahram Davari; tictoc@ietf.org
>> Subject: RE: UDP checksum
>> 
>> Hi Shahram,
>> 
>> It may be ok as long as the HWs are incrementally recalculating it. However, if its being done afresh then we have an issue. I don't see how the HW behavior can be mandated in a spec.
>> 
>> Cheers, Manav
>> 
>>> -----Original Message-----
>>> From: Shahram Davari [mailto:davari@broadcom.com]
>>> Sent: Friday, January 21, 2011 4.59 AM
>>> To: Bhatia, Manav (Manav); tictoc@ietf.org
>>> Subject: RE: UDP checksum
>>> 
>>> Hi Manav,
>>> 
>>> UDP checksum is usually not verified before updating the CF.
>>> After CF update it is incrementally recalculated. The end
>>> host will then verify the checksum for correctness.
>>> 
>>> Regards,
>>> Shahram
>>> 
>>> -----Original Message-----
>>> From: tictoc-bounces@ietf.org
>>> [mailto:tictoc-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav)
>>> Sent: Thursday, January 20, 2011 3:16 PM
>>> To: tictoc@ietf.org
>>> Subject: [TICTOC] UDP checksum
>>> 
>>> Hi,
>>> 
>>> Are the LSRs acting as TCs expected to verify the checksum
>>> before they update the correction field? If no, then there is
>>> no point in these LSRs in updating the UDP checksum as they
>>> will "correct" the checksum when its recomputed after
>>> modifying the CF field. In this case wouldn't it make more
>>> sense to just update the checksum at the MPLS terminating point?
>>> 
>>> I also think that updating the UDP checksum may be redundant
>>> as the LSRs are anyways verifying the outer ethernet checksum
>>> before accepting any packets. Any thoughts here?
>>> 
>>> Cheers, Manav
>>> 
>>> --
>>> Manav Bhatia,
>>> IP Division, Alcatel-Lucent,
>>> Bangalore - India
>>> 
>>> 
>>> _______________________________________________
>>> TICTOC mailing list
>>> TICTOC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tictoc
>>> 
>>> 
>>> 
>> _______________________________________________
>> TICTOC mailing list
>> TICTOC@ietf.org
>> https://www.ietf.org/mailman/listinfo/tictoc
>> 
> 
> 
> -- 
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>