Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

Nalini Elkins <> Mon, 21 October 2013 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F5AD11E87D9 for <>; Mon, 21 Oct 2013 15:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.181
X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NPTqbTBxHC7z for <>; Mon, 21 Oct 2013 15:58:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4F0811E87C0 for <>; Mon, 21 Oct 2013 15:58:22 -0700 (PDT)
Received: from [] by with NNFMP; 21 Oct 2013 22:58:22 -0000
Received: from [] by with NNFMP; 21 Oct 2013 22:58:22 -0000
Received: from [] by with NNFMP; 21 Oct 2013 22:58:22 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 23180 invoked by uid 60001); 21 Oct 2013 22:58:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1382396301; bh=gz7bsWA3BKYe3p8KchJBGACAUiJhFU+zTjXy2NOwom0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qdS7Q3Cy6lMzupXUJmmljNB/YrBNx/+yUBc9iKsGxxBNs+QEs/TRb6JXap2xfY/PkeeysCwQHmkjaMwChshIp6i3ToV3ebMokr17E2MESN6uvj8MCPhtQfUaNmCMWSfJQ6rK6WeNIstMipirz3dNoU36Sp54UDZtl8xIFXOlPhM=
X-YMail-OSG: 3qSutDkVM1m_rKOwD95QcNtpkvhcHeb9fl8kjbNU_zTepCz HpYBLoU8elofJ3oS18.BqVNg3h0TwGU5CANcnT30cosgpoOj1TSWC2l6vJX9 QFFrri7PMeDKffpZuH7mWWphetrFM6HF_vtVjXdEoRTmgmsGsnf00eGO2FAN l_a3a5fvrZZhH2b3DQPd06lhJIHNz.YKEjgpzggYc6jP7eJrxGnsJONWudMI tcqOh4R0NbruuSL9Q77wuqbxplQBmXM2dVQvLeKAhpGEPbkX16cR70wEf3aD WeoDj_HhOyKW.JLB6lKl4vY8vWYjE01qKOTYTbebOFmeM3RA.7gGGNsIaadq WPbIiC9BI8yLhGpaqXmVwgegUX84grXgjG1jpeYaguRYMfohIwQeWE_Xm0Vx SJvQE4RQCF4u2wFTfwVcpCduWql6lWyhAOmgBJXEZEWlt0HivW7Y3R6UJEGE EiNcNcAskPO9ZAoR7PdyPPTT.62TL5QJ3yzspqcO0sEJTkGVlSCRejis3XT. jGnv6I6YKq3lRqgv4Fs8JcEc_nc6HGHXwevqBtG2UF5ky5khqh3MaEHDspoc oSWu003NfORL2l8w-
Received: from [] by via HTTP; Mon, 21 Oct 2013 15:58:20 PDT
X-Rocket-MIMEInfo: 002.001, Cj7CoDEpIGVuY29kaW5nIGhhcyB0byBiZSBmYXN0LCBidXQgZGVjb2RpbmcgZG9lcyBub3QKClRydWUKCj7CoDIpIGEgbm9kZSdzIGNsb2NrIGNvdWxkIGJlIGVpdGhlciBpbiBvdXIgb3V0IG9mIHN5bmNoIHdpdGggc29tZSBub3Rpb25hbAo.wqBtYXN0ZXIgY2xvY2sgKGUuZy4gdmlhIE5UUCkKPsKgMykgdHdvIGNsb2NrcyBjb3VsZCBiZSBpbiBzeW5jaCB0byBhIG1hc3RlciBzb3VyY2UsIGJ1dCB0aGUgbWFzdGVyCj7CoHNvdXJjZXMgbWF5IHRoZW1zZWx2ZXMgbm90IHNoYXJlIGEgY29tbW9uIHNvdXJjZSABMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <> <>
Message-ID: <>
Date: Mon, 21 Oct 2013 15:58:20 -0700 (PDT)
From: Nalini Elkins <>
To: Ray Hunter <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops WG <>, 6man WG <>, "" <>
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Nalini Elkins <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Oct 2013 22:58:39 -0000

> 1) encoding has to be fast, but decoding does not


> 2) a node's clock could be either in our out of synch with some notional
> master clock (e.g. via NTP)
> 3) two clocks could be in synch to a master source, but the master
> sources may themselves not share a common source (one sourced from GPS,
>one from DCF77)
>4) the key to being able to perform the end to end calculations is
>whether two communicating nodes are synchronised to the same master
>clock (within some level of error/jitter)
>5) the absolute time is not particularly important

This is true for PDM 1 only.  PDM 2 does not require time synchronization.

> Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock?
> Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node.

1. I think that it is going to be interesting to see how hardware is going to handle TCP offload with IPv6 extension headers.   I do not see why PDM 2 would be so much harder than PDM 1 for an OS.
Can you tell me which end host operating systems are doing TCP offload in hardware?   

I know some OS's which process TCP segmentation in hardware.    But at this point, the packet is already crafted.  Also some do IP checksum offload in hardware but that does not apply to IPv6 as there is no IP header checksum.

2.  End hosts already maintain quite a bit of state.  Every OS has control blocks to handle events such as TCP duplicate packets, round trip time, congestion window, etc.   We are NOT suggesting
that the PDM headers be used in middle boxes.  That is, we are NOT asking routers to maintain state.

> Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding?

If clocks are out of synch, you could end up having it look like you received the packet before you sent it.

> Q2. Why do you need two separate packet formats at all?

> Why not have a common format for all cases, containing a timestamp based
>on the local clock, plus an optional field containing a flag that states
>if the local timestamp is coordinated to some master clock, plus an
>identifier for the master clock.

>You could then encode whether a node had a free-running clock (case 2),
>a synchronised clock (case 1), and whether it was synched via NTP to
>some stratum 0 source e.g. GPS, and also some identification of the
>stratum 1 source (IPv6 address).

>Two communicating nodes could then use e.g. NTP trace to see if they
>shared a common clock source or not, before performing their calculations.

We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired.