Loading ...
Sorry, an error occurred while loading the content.

Reactivate 135-2008ad-8 Increase Segmentation Window Size for MS/TP

Expand Messages
  • cliffcopass
    After the first public review of 135-2008ad, part 8 was removed due to a single comment suggesting that an alternate mechanism could be used to accomplish the
    Message 1 of 3 , Jun 16, 2011
    • 0 Attachment
      After the first public review of 135-2008ad, part 8 was removed due to a single comment suggesting that an alternate mechanism could be used to accomplish the same result (send segments without expecting a reply).

      After some thought, I am not at all convinced that this alternate approach would be without backward compatibility and inter-operational issues when communicating with some devices (depending on the implementation). It also complicates sending aborts, etc. back to the message originator.

      The original approach is fully backward compatible, does not change the higher level protocol (i.e. how segments are sent) and clears up some of the protocol stack issues in the standard.

      I would like to consider reactivating this proposal given that no one has come forward with a better alternative that is unlikely to cause communication problems in some situations.

      Cliff Copass
    • Kerry Lynn
      Cliff, Is there a need in practice to send datagrams larger than 1497 octets over MS/TP? I ask because there *is* a proposal in the pipeline for sending large
      Message 2 of 3 , Jun 16, 2011
      • 0 Attachment
        Cliff,

        Is there a need in practice to send datagrams larger than 1497 octets over
        MS/TP?  I ask because there *is* a proposal in the pipeline for sending
        large frames over MS/TP.

        -K-

        On Thu, Jun 16, 2011 at 11:33 AM, cliffcopass <Clifford.H.Copass@...> wrote:
         

        After the first public review of 135-2008ad, part 8 was removed due to a single comment suggesting that an alternate mechanism could be used to accomplish the same result (send segments without expecting a reply).

        After some thought, I am not at all convinced that this alternate approach would be without backward compatibility and inter-operational issues when communicating with some devices (depending on the implementation). It also complicates sending aborts, etc. back to the message originator.

        The original approach is fully backward compatible, does not change the higher level protocol (i.e. how segments are sent) and clears up some of the protocol stack issues in the standard.

        I would like to consider reactivating this proposal given that no one has come forward with a better alternative that is unlikely to cause communication problems in some situations.

        Cliff Copass


      • Clifford.H.Copass@jci.com
        I think the main difference is the 135-2008ad, part 8 proposal would work with existing routers and has no known conflicts with existing devices that would not
        Message 3 of 3 , Jun 16, 2011
        • 0 Attachment

          I think the main difference is the 135-2008ad, part 8 proposal would work with existing routers and has no known conflicts with existing devices that would not understand the larger frame sizes.

          Cliff Copass
          Johnson Controls, Inc.



          From:Kerry Lynn <kerlyn2001@...>
          To:bacnet-mstpwg@yahoogroups.com
          Date:06/16/2011 11:05 AM
          Subject:Re: [bacnet-mstpwg] Reactivate 135-2008ad-8 Increase Segmentation Window Size for MS/TP







          Cliff,


          Is there a need in practice to send datagrams larger than 1497 octets over
          MS/TP?  I ask because there *is* a proposal in the pipeline for sending
          large frames over MS/TP.

          -K-

          On Thu, Jun 16, 2011 at 11:33 AM, cliffcopass <Clifford.H.Copass@...> wrote:
           
          After the first public review of 135-2008ad, part 8 was removed due to a single comment suggesting that an alternate mechanism could be used to accomplish the same result (send segments without expecting a reply).

          After some thought, I am not at all convinced that this alternate approach would be without backward compatibility and inter-operational issues when communicating with some devices (depending on the implementation). It also complicates sending aborts, etc. back to the message originator.

          The original approach is fully backward compatible, does not change the higher level protocol (i.e. how segments are sent) and clears up some of the protocol stack issues in the standard.

          I would like to consider reactivating this proposal given that no one has come forward with a better alternative that is unlikely to cause communication problems in some situations.

          Cliff Copass






        Your message has been successfully submitted and would be delivered to recipients shortly.