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

[Ray Hunter <[e-mail]>]

> 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