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

[joel jaeggli <[e-mail]>]

On Oct 24, 2013, at 9:50 AM, Ackermann, Michael <[e-mail]> wrote:

> Hi Ray.
> And thanks again for all your insightful comments/questions. 
> 
> I am a little late in responding, so let me just tack on a little to what Nalini and others have already said. 
> 
> Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock.   This has not been my experience.   As long as the required Stratum level is realized, for the level of accuracy required by the situation or application, the proper level of time synchronization is achieved.   Example would be that if one node in the NTP domain is referencing a GPS Stratum 0 and another node is referencing a separate Stratum 0 source, the two nodes should be Stratum 1 and within that level of accuracy.  

stratum is not an indication of either precision or accuracy it’s an inidication of a position within the NTP heirachary.

> This is something we have implemented across several disparate enterprises and it has worked well for us.  I am wondering if your experience has yielded different results?
> 
> You also had two other points/questions, that I believe Nalini already responded to, but..............
> 
> 1. The possibility that "Middleboxes" could utilize PDM, is very intriguing to me.  I believe this would be more difficult to add/implement, but worth the effort if the Middlebox vendors would perceive value and actually use PDM.  Not sure how to determine if this would be the case or not? 
> 
> 2. It would be ideal to have only 1 PDM format that handles both time sycnronized and non synchronized situations.   I do not readily see how to achieve this.   Would love to talk to you some more if you have some ideas!  
> 
> Again, thanks for your great input, thoughts and questions!!!  (and hopefully more to come).  
> 
> Mike
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ray Hunter
> Sent: Tuesday, October 22, 2013 2:10 AM
> To: Nalini Elkins
> Cc: v6ops WG; 6man WG; [e-mail]
> Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt
> 
>> Nalini Elkins <mailto:[e-mail]>
>> 22 October 2013 00:58
>>> 1) encoding has to be fast, but decoding does not
>> 
>> True
>> 
>>> 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?   
> IMHO Not a relevant question. As a standards body we should be looking to the future. There are many operations that are delegated to microcode.
> 
> If you specified the packet with one single way of encapsulating timestamps, then hardware or interface microcode could add the timestamp at the last possible moment before the packet reached the wire, without having to examine the original packet contents, or knowing the context of the communicating nodes. I think that's very desirable.
>> 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.
> So what? Why add to the problem?
> 
> Why does the timestamp require synchronisation with that other TCP state?
> 
> Isn't it better to define a solution that is independent of the upper layer header transport protocol?
> 
> <heresy>  Why not allow middleboxes (or node hardware) to insert the timestamp header on the fly?</heresy>
>> 
>>> 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.
> 
> No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose which packet encoding to use in advance is problematic IMHO.
> 
> 
> 
>>> 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.
> 
> I understand the aim, but let me ask my question a different way.
> 
> Imagine there are nodes A&B that with clocks synched to DCF77.
> Imagine there are nodes C&D that with clocks  synched to GPS.
> Node E has free running clock (possibly because the GPS receiver is down).
> 
> Which packet format PDM type 1 or PDM type 2 do you use between each pair of nodes, and how does the sending node know that?
> 
> Scale this solution to 100K hosts.
>> 
>> ----------------------------------------------------------------------
>> --
> 
> 
> --
> Regards,
> RayH
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
> 
> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>