Subject: Re: [ntpwg] Regarding draft-ietf-ntp-extension-field-02.txt

From: Danny Mayer <[email-masked]>
Date: Mon, 09 Mar 2015 12:49:09 -0400

On 3/9/2015 11:33 AM, Anil Kumar S N (VRP Network BL) wrote:
> Hi Talmi/David,

I assume you meant Tal/Danny (me).

> 
> We were going through the proposed draft and felt that we can
> reserve
the MSB bit of “Field Type" to indicate the availability of next
extension field in the packet.

That will break backward compatibility. There needs to be a very good
reason for doing this.

> 
> In case of multiple extensions their corresponding Field type MSB
> will
be set to 1 except the last one.
> 
>  
> 
>        0                   1                   2                   3
> 
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       |M|        Field Type           |            Length             |
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       .                                                               .
> 
>       .                            Value                              .
> 
>       .                                                               .
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       |                       Padding (as needed)                     |
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                      Figure 14: Extension Field Format
> 
>  
> 
>         Bit-M : 1 – More extensions to be followed, 0 – No more extensions. 
> 
>  
> 
> Pros:
> 
> ü Remove the size constraint for the last extension header. [Refer
section 7.5.1.4 of the proposed draft]

No, all extension fields should have size constraints. There are
practical limits as well as effective limits.

> 
> ü Make the processing easier by skipping decision making after each
extension (to know whether the followed type is MAC or Extension header)

This has been a major problem for processing since we couldn't easily
tell. Personally I'd like to make the MAC an extension field itself and
require that it cover all previous extensions and the regular part of
the packet. That way if someone wants to add an extension beyond the MAC
they can do it but it would not be covered by the MAC.

> ü Reduce packet size avoiding unwanted padding.>
>  

I'm not sure why that would help. Most newer CPU's are 64-bit anyway so
it is more efficient to make everything 64 bit aligned. Yes network
equipment may not be.

Danny

> 
> Request your views on this proposal.
> 
>  
> 
> Thanks
> 
> Anil/Vikram
> 
>  
> 

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Tue, 10 Mar 2015 16:15:54 -0400

Vikram,

Like I said, you cannot do this at all without breaking backward
compatibility. You are dealing with legacy implementations that would
need to interoperate with your proposed changes. You need to specify
exactly how you would do that since your feedback doesn't discuss it.
Your points are understood.

Thanks,
Danny
On 3/10/2015 4:13 AM, Vikram Choudhary wrote:
> Hi Danny,
> 
> Thanks for replying. Please find reply inline.
> 
> 1. That will break backward compatibility. There needs to be a very good reason for doing this.
> Vikram>> We feel that extra padding will eat up bandwidth for no reason and having 'More' bit option can save packet size. Think of the case where one have to encode several extensions together.
> Now coming to ensuring backward compatibility, since we have only one defined extension [RFC-5906, auto-key] and that can be ensured by encoding it as the first extension always.
> All the new upcoming extensions can follow the new approach of defining 'More' bit and help in reducing the padding overhead. Moreover, If only one extension is defined then it must be more than 6 words to avoid confusion between extension and MAC.
> 
> 2. No, all extension fields should have size constraints. There are practical limits as well as effective limits.
> Vikram>> Actually, I meant of removing padding constraints.
> 
> 3. This has been a major problem for processing since we couldn't easily tell. Personally I'd like to make the MAC an extension field itself and require that it cover all previous extensions and the regular part of the packet. That way if someone wants to add an extension beyond the MAC they can do it but it would not be covered by the MAC.
> Vikram>> I agree, I would also love to do that. How about defining a new version in which everything is defined as per TLV format including MAC.
> 
> 4. I'm not sure why that would help. Most newer CPU's are 64-bit anyway so it is more efficient to make everything 64 bit aligned. Yes network equipment may not be.
> Vikram>> It will save bandwidth over the network and avoid un-necessary congestion.
> 
> Thanks
> Vikram
> 
> 
> -----Original Message-----
> From: Danny Mayer [mailto:[email-masked]] 
> Sent: 09 March 2015 22:19
> To: Anil Kumar S N (VRP Network BL); [email-masked]
> Cc: [email-masked]; Vikram Choudhary; Dhruv Dhody; Kalyankumar Asangi
> Subject: Re: Regarding draft-ietf-ntp-extension-field-02.txt
> 
>> We were going through the proposed draft and felt that we can reserve
> the MSB bit of "Field Type" to indicate the availability of next extension field in the packet.
> 
> That will break backward compatibility. There needs to be a very good reason for doing this.
> Vikram>> We feel that extra padding will eat up bandwidth for no reason and having 'More' bit option can solve
> Currently, only auto-key extension is supported and we can handle this specially to ensure backward compatibility. Moreover, we propose 
> 
>>
>> In case of multiple extensions their corresponding Field type MSB will
>>         Bit-M : 1 - More extensions to be followed, 0 - No more extensions. 
>>
>>  
>>
>> Pros:
>>
> No, all extension fields should have size constraints. There are practical limits as well as effective limits.
> 
>>
> This has been a major problem for processing since we couldn't easily tell. Personally I'd like to make the MAC an extension field itself and require that it cover all previous extensions and the regular part of the packet. That way if someone wants to add an extension beyond the MAC they can do it but it would not be covered by the MAC.
> 
> I'm not sure why that would help. Most newer CPU's are 64-bit anyway so it is more efficient to make everything 64 bit aligned. Yes network equipment may not be.
> 
> Danny
> 
>>

---

From: Danny Mayer <[email-masked]>
Date: Wed, 25 Mar 2015 13:04:15 -0400

On 3/25/2015 1:44 AM, Vikram Choudhary wrote:
> A Gentle Reminder!!!!

A gentle reminder for what? I am not sure what you are asking here.

Danny

> From: Vikram Choudhary 
> Sent: 17 March 2015 21:32
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Dhruv Dhody; Kalyankumar Asangi; Anil Kumar S N (VRP Network BL)
> Subject: RE: Regarding draft-ietf-ntp-extension-field-02.txt
> 
> Hi Danny,
> 
> Please find the details below:
> 
> 1. New extension/s MUST comply with the below proposed TLV format.
>          0                   1                   2                   3
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          .                                                             .
>          .                           Value                             .
>          .                                                             .
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                      Padding (as needed)                    |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
>          M-Bit : 1 - More extensions to be followed, 0 - No more extensions.
>                  
> 2. Multiple NTP extension/s MUST follow below points for ensuring backward compatibility.
>         a. Autokey extension/s MUST be continuous and SHOULD start after NTP header (existing implementation, no change).
>         b. First extension following NTP header MUST be at least 7 words.
>         c. First extension following autokey extension MUST be at least 7 words.
>                 
> 3. Cases ensuring backward compatibility.
>         a.  NTP packet with no extension/s and MAC.
>                 This is simple as the packet size will be just equal to NTP header size. No special processing required.
>                 
>         b.  NTP packet with MAC only.
>                 NTP packet size as defined in RFC 5905 will be considered for MAC processing.
>                 
>         c.  NTP packet with autokey extension/s and with/without MAC.
>                 Autokey extension's are the only defined NTP extension's so current size limitation and processing will remain as defined in RFC 5905 and 5906.
>                 
>         d.  NTP packet with new extension/s with/without autokey extension/s and with/without MAC.
>                 Above proposed changes [2] MUST be followed.
>         
> 4. Pro's
>         a. No need to have size restriction for all extension fields.
>         b. Save's bandwidth and avoid un-necessary congestion over the network.
>         c. Backward compatibility is ensured.
>         
> 5. Con's
>         a. The proposed solution doesn't help in addressing legacy size constrains for NTP autokey extension/s.
> 
> Kindly, let us know if anything else needs to be clarified from our end.
> 
> Thanks
> Vikram
> 
> From: Anil Kumar S N (VRP Network BL)
> Sent: 16 March 2015 14:49
> To: [email-masked]; Vikram Choudhary
> Cc: [email-masked]; [email-masked]; Dhruv Dhody; Kalyankumar Asangi
> Subject: RE: Regarding draft-ietf-ntp-extension-field-02.txt
> 
> Hi Danny,
> 
> 	Thanks for the reply, Since we were busy we couldn't respond.	
> 	We will document our idea in detail were backward compatibly is addressed and will send you soon. 
> 
> With warm Regards,
> Anil S N
> 
> Sent: 11 March 2015 01:46
> To: Vikram Choudhary
> Cc: [email-masked]; Anil Kumar S N (VRP Network BL); [email-masked]; Dhruv Dhody; Kalyankumar Asangi
> Like I said, you cannot do this at all without breaking backward compatibility. You are dealing with legacy implementations that would need to interoperate with your proposed changes. You need to specify exactly how you would do that since your feedback doesn't discuss it.
>> Vikram>> We feel that extra padding will eat up bandwidth for no 
>> Vikram>> reason and having 'More' bit option can solve
>> Currently, only auto-key extension is supported and we can handle this 
>> specially to ensure backward compatibility. Moreover, we propose
>>
>>>