Subject: [ANCP] Splitting GSMP messages to different TCP packets

From: "Busser, M" <[email-masked]>
Date: Thu, 15 Nov 2007 14:35:38 +0100

Hi all.
 
When the adjacency comes up, a bunch of PORT-STATUS messages will be sent 
by the DSLAM to the BRAS. 
 
If the amount of data (all the GSMP messages) exceeds the limit of one TCP-Packet, 
the next portion of data have to be sent with the next TCP packets.
 
The question now is:
Do we have any requirements to make sure, that only complete GSMP messages
are sent in one TCP message?
 
>From my understanding, the stream of GSMP messages is a byte stream, 
which is transported to the far end by TCP. 
The application layer (e.g. the layer above TCP) do not have to take care 
about such details of transportation.
So the answer is no.
 
Am i wrong?

Best Regards; Freundliche Grüße 
Michael Busser

T-Systems Enterprise Services GmbH 
Production Line Network Centric Systems
ICT-Systems Integration
Network Integration Services
 
Brückes 2 -8, 55545 Bad Kreuznach
Postfach 9100, 55541 Bad Kreuznach
+49 671 8333 8911 (Phone)
+49 521 9210 3859 (Fax)
+49 151 1211 9689 (Mobile)
E-Mail: [email-masked]
Internet:  <http://www.t-systems.com/> http://www.t-systems.com 

T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Wilfried Peters*, 
Dr. Herbert Schaaff*, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG 

Notice: This transmittal and/or attachments may be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. 
T-Systems - Business flexibility 

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 15 Nov 2007 15:49:56 +0100

Hi Michael,
 
your interpretation is correct with respect to ANCP over TCP.
 
-Woj.

________________________________

	From: Busser, M [mailto:[email-masked]] 
	Sent: 15 November 2007 14:36
	To: [email-masked]
	Cc: Troester, Stephan; Haag,T; Witschurke,Birgit
	Subject: [ANCP] Splitting GSMP messages to different TCP packets

	Hi all.

	 
	The question now is:

	Am i wrong?

	 
	
	Internet: http://www.t-systems.com <http://www.t-systems.com/>

---

From: "Haag, T" <[email-masked]>
Date: Thu, 15 Nov 2007 16:36:55 +0100

Hi Wojciech,

Assuming that GSMP und layer above don't care about Does ANCP provide a kind of handshake mechanism to enforce the near end sending only port specific messages again if the application layer at the far end receives inconclusive messages?

Regards

Thomas

Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Donnerstag, 15. November 2007 15:50
An: Busser, Michael; [email-masked]
Cc: Tröster, Stephan; Haag, Thomas; Witschurke, Birgit
Betreff: RE: [ANCP] Splitting GSMP messages to different TCP packets

Hi Michael,

-Woj.

	Hi all.

	The question now is:

	Am i wrong?

	Michael Busser

	ICT-Systems Integration

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 15 Nov 2007 09:54:27 -0800

Yes, there is such a handshake mechanism. If received data is
dropped or corrupted or in the wrong order, the sender will
retransmit and the receiver will maintain proper order.

This is the function of TCP.

Haag, T wrote:
> Hi Wojciech,
> 
>  
> 
> Assuming that GSMP und layer above don’t care about Does ANCP provide a 
> kind of handshake mechanism to enforce the near end sending only port 
> specific messages again if the application layer at the far end receives 
> inconclusive messages?
> 
>  
> 
> Regards
> 
> Thomas
> 
> ------------------------------------------------------------------------
> 
> *Von:* Wojciech Dec (wdec) [mailto:[email-masked]]
> *Gesendet:* Donnerstag, 15. November 2007 15:50
> *An:* Busser, Michael; [email-masked]
> *Cc:* Tröster, Stephan; Haag, Thomas; Witschurke, Birgit
> *Betreff:* RE: [ANCP] Splitting GSMP messages to different TCP packets
> 
>  
> 
> Hi Michael,
> 
>  
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Busser, M [mailto:[email-masked]]
>     *Sent:* 15 November 2007 14:36
>     *To:* [email-masked]
>     *Cc:* Troester, Stephan; Haag,T; Witschurke,Birgit
>     *Subject:* [ANCP] Splitting GSMP messages to different TCP packets
> 
>     Hi all.
> 
>      
> 
>     *Michael Busser*
>     <mailto:[email-masked]>
> 
>     Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*,
>     Katrin Horstmann, Ulrich Kemp, Wilfried Peters*,
>     Notice: This transmittal and/or attachments may be privileged or
>     confidential. If you are not the intended recipient, you are hereby
>     notified that you have received this transmittal in error; any
>     review, dissemination, or copying is strictly prohibited. If you
>     received this transmittal in error, please notify us immediately by
>     reply and immediately delete this message and all its attachments.
>     Thank you.
>     T-Systems – Business flexibility
> 
>      
> 
>      
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Haag, T" <[email-masked]>
Date: Fri, 16 Nov 2007 09:05:23 +0100

I think it is a misunderstanding. That TCP has such a mechanism is quite clear. 

But the question was if GSMP on top of TCP has a handshake mechanism?

There is need for a mechanism which provides a retransmission of dedicated DSL port information, if the BRAS could not interpret a single message.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Jakob Heitz [mailto:[email-masked]] 
Gesendet: Donnerstag, 15. November 2007 18:54
An: Haag, Thomas
Cc: Tröster, Stephan; Busser, Michael; [email-masked]; Witschurke, Birgit
Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets

Haag, T wrote:
> Hi Wojciech,
> 
>  
> 
> Assuming that GSMP und layer above don't care about Does ANCP provide a

---

From: "PESCHI Robert" <[email-masked]>
Date: Fri, 16 Nov 2007 10:01:24 +0100

Thomas,

The genuine "General Switch Management Protocol (GSMP) V3" (RFC 3292) foresees some 
optional rudimentary mechanism to acknowledge GSMP messages:

>From RFC3292:

	"3.  Common Definitions and Procedures

	GSMP is a master-slave protocol.  The controller issues request
	messages to the switch.  Each request message indicates whether a
	response is required from the switch and contains a transaction
	identifier to enable the response to be associated with the request.
	The switch replies with a response message indicating either a
	successful result or a failure.  There are six classes of GSMP
	request-response message: Connection Management, Reservation
	Management, Port Management, State and Statistics, Configuration, and
	Quality of Service.  The switch may also generate asynchronous Event
	messages to inform the controller of asynchronous events.  The
	controller can be required to acknowledge event messages, but by
	default does not do so.  There is also an adjacency protocol message
	used to establish synchronisation across the link and maintain a
	handshake."

 and further: 

	"3.1 GSMP Packet Format 

	ReturnReceipt is a result field used in Events to indicate that 
      an acknowledgement is required for the message. The default for 
      Events Messages is that the controller will not acknowledge Events. 
      In the case where a switch requires acknowledgement, it will set 
      the Result Field to ReturnReceipt in the header of the Event Message." 

This (optional) mechanism has been kept by default in http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt.
Of course, as long as TCP is used, this mechanism has no added value I would say.

Kind regards,
Robert

Robert Peschi
DSL Product Architect,
Access Network Division
Tel.: +32 3 240 8926
GSM: +32 477 29 78 07

Alcatel-Lucent Bell NV
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law.  If you are not the intended recipient, you should delete this message.  Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author.

-----Original Message-----
From: Haag, T [mailto:[email-masked]] 
Sent: Friday, November 16, 2007 9:05 AM
To: [email-masked]
Cc: Troester, Stephan; Busser,M; [email-masked]; Witschurke,Birgit
Subject: AW: AW: [ANCP] Splitting GSMP messages to different TCP packets

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Jakob Heitz [mailto:[email-masked]]
Gesendet: Donnerstag, 15. November 2007 18:54
An: Haag, Thomas
Cc: Tröster, Stephan; Busser, Michael; [email-masked]; Witschurke, Birgit
Betreff: Re: AW: [ANCP] Splitting GSMP messages to different TCP packets

Yes, there is such a handshake mechanism. If received data is dropped or corrupted or in the wrong order, the sender will retransmit and the receiver will maintain proper order.

Haag, T wrote:
> Hi Wojciech,
> 
>  
> 
> Assuming that GSMP und layer above don't care about Does ANCP provide 
> a kind of handshake mechanism to enforce the near end sending only 
> port specific messages again if the application layer at the far end 
> receives inconclusive messages?
> 
>  
> 
> Regards
> 
> Thomas
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 16 Nov 2007 10:18:24 +0100

Hi Thomas,

the handshake you're looking for is a combination of ANCP version and ANCP capability exchange. The latter is currently has a few shortcomings that we'll hopefully get to address soon.

In essence, TCP (currently) guarantees reliable and ordered delivery.
If the BRAS, or DSLAM do not understand a message, then retransmitting it won't help. This is a basic protocol issue that is addressed by the two sides agreeing to use a commonly understood message set.

This actually opens up another point: We have previously discussed (and included in our charter) the possibility of using an alternative transport protocol. The WG however has however not seen much follow-up on this, especially in terms of laying out the reasons why, for example, the rate-change information needs to be transmitted reliably and/or acknowledged. This seems like a good time to have this discussion.

Regards,
Woj.

> Sent: 16 November 2007 09:05
> To: [email-masked]
> There is need for a mechanism which provides a retransmission 
> of dedicated DSL port information, if the BRAS could not 
> interpret a single message.
> 
> Regards
> Thomas
> 
> >     When the adjacency comes up, a bunch of PORT-STATUS 
> messages will be
> >     sent
> >     If the amount of data (all the GSMP messages) exceeds 
> the limit of
> >     one TCP-Packet,
> >     Do we have any requirements to make sure, that only 
> complete GSMP
> >     messages
> >     The application layer (e.g. the layer above TCP) do not 
> have to take
> >     care

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Mon, 19 Nov 2007 09:02:13 -0800

Hi Woj

Yes, TCP is cheap for the DSLAM who only has to handle a few of them overall (only one to the BRAS) while the BRAS needs to support one for all the DSLAM connected to it, meaning 5,000 or possibly more.
In our case, we lose a lot of cpu and memory to handle all the luxury of TCP which we might not require all of it.

If we moved out of TCP and build some form of reliable protocol say over UDP, it might be possible as long as the built-in functionality of TCP are either implemented or arrange not to be required.

1) Reliability
   Can be done by having sequencing/acknowledgment of any messages sent by each

2) stream oriented
   Instead of stream oriented, we make it message based (no messages are split over 2 packets at that layer (IP frag could still be there))
   (although still more than one message can be encapsulated in a single packet)

3) congestion control et al
   more tricky
   The DSLAM isn't forwarding any huge file of information to the BRAS. My assumption (I could be wrong) is there won't be more than a few CPEs connected to any DSLAM (up to 10, 20?). If so, the traffic between a given DSLAM and the BRAS are made of the "keepalive" and whatever Port up/down and other events that might occur. If the DSLAM builts a self throttle of bulk packets, (say limiting to 5 ANCP packets per seconds).

What's your input Woj?

> From: Wojciech Dec (wdec) 
> Sent: Friday, November 16, 2007 4:18 AM
> To: Haag, T; [email-masked]
> Subject: RE: AW: [ANCP] Splitting GSMP messages to different 
> TCP packets
> 
> Hi Thomas,
> 
> the handshake you're looking for is a combination of ANCP 
> version and ANCP capability exchange. The latter is currently 
> has a few shortcomings that we'll hopefully get to address soon.
> 
> If the BRAS, or DSLAM do not understand a message, then 
> retransmitting it won't help. This is a basic protocol issue 
> that is addressed by the two sides agreeing to use a commonly 
> understood message set.
> 
> This actually opens up another point: We have previously 
> discussed (and included in our charter) the possibility of 
> using an alternative transport protocol. The WG however has 
> however not seen much follow-up on this, especially in terms 
> of laying out the reasons why, for example, the rate-change 
> information needs to be transmitted reliably and/or 
> acknowledged. This seems like a good time to have this discussion.
> 
> Regards,
> Woj.
> 
> 
> > There is need for a mechanism which provides a retransmission of 
> > dedicated DSL port information, if the BRAS could not interpret a 
> > single message.
> > 
> > Regards
> > Thomas
> > 
> > Yes, there is such a handshake mechanism. If received data 
> is dropped 
> > or corrupted or in the wrong order, the sender will 
> retransmit and the

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 19 Nov 2007 10:37:12 -0800

Congestion control is indeed tricky.
At node startup, you want to get all the Port_Up
messages as quickly as possible and every
port will send one. Exactly like a huge file.
Node startup is the busiest and most important time.

Also, it is incorrect to assume DSLAMS are small.
One scenario might have 5000 DSLAMs with 10 ports
each, but another might have 5 DSLAMs with 10000
ports each. The standardized solution needs to work
well for all possible scenarios.

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Mon, 19 Nov 2007 11:32:11 -0800

Thanks Jakob.  Wasn't sure about that.
In this case, it has the potential to become chatty over that TCP connection.
In light of this, perhaps another solution might be to use an hybrid version (configurable by the admin - either TCP or the light weight, depending on the network topology)

> From: Jakob Heitz [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 1:37 PM
> To: Philippe Champagne (pchamp)
> Cc: Wojciech Dec (wdec); Haag, T; Troester, Stephan; 
> Busser,M; [email-masked]; Witschurke,Birgit
> Subject: Re: AW: [ANCP] Splitting GSMP messages to different 
> TCP packets
> 
> At node startup, you want to get all the Port_Up messages as 
> quickly as possible and every port will send one. Exactly 
> like a huge file.
> One scenario might have 5000 DSLAMs with 10 ports each, but 
> another might have 5 DSLAMs with 10000 ports each. The 
> standardized solution needs to work well for all possible scenarios.
> 
> > Yes, TCP is cheap for the DSLAM who only has to handle a 
> few of them overall (only one to the BRAS) while the BRAS 
> needs to support one for all the DSLAM connected to it, 
> meaning 5,000 or possibly more.
> > In our case, we lose a lot of cpu and memory to handle all 
> the luxury of TCP which we might not require all of it.
> > 
> > If we moved out of TCP and build some form of reliable 
> protocol say over UDP, it might be possible as long as the 
> built-in functionality of TCP are either implemented or 
> arrange not to be required.
> > 
> > 1) Reliability
> >    Instead of stream oriented, we make it message based (no 
> messages are split over 2 packets at that layer (IP frag 
> could still be there))
> >    The DSLAM isn't forwarding any huge file of information 
> to the BRAS. My assumption (I could be wrong) is there won't 
> be more than a few CPEs connected to any DSLAM (up to 10, 
> 20?). If so, the traffic between a given DSLAM and the BRAS 
> are made of the "keepalive" and whatever Port up/down and 
> other events that might occur. If the DSLAM builts a self 
> throttle of bulk packets, (say limiting to 5 ANCP packets per 
> seconds).
> > 
> > 
> > What's your input Woj?
> > 
> > 
> >> Subject: RE: AW: [ANCP] Splitting GSMP messages to different TCP 
> >> packets
> >>
> >> Hi Thomas,
> >>
> version and 
> >> ANCP capability exchange. The latter is currently has a few 
> >> shortcomings that we'll hopefully get to address soon.
> >>
> >> retransmitting it won't help. This is a basic protocol 
> issue that is 
> >> addressed by the two sides agreeing to use a commonly understood 
> >> message set.
> >>
> >> This actually opens up another point: We have previously discussed 
> >> (and included in our charter) the possibility of using an 
> alternative 
> >> transport protocol. The WG however has however not seen much 
> >> follow-up on this, especially in terms of laying out the 
> reasons why, 
> >> for example, the rate-change information needs to be transmitted 
> >> reliably and/or acknowledged. This seems like a good time to have 
> >> this discussion.
> >>
> >> Regards,
> >> Woj.
> >>
> >>
> >>> I think it is a misunderstanding. That TCP has such a 
> mechanism is 
> >>> quite clear.
> >>>
> ---------------------------------------------------------------------
> >> -
> >>>> --
> >>>>
> ---------------------------------------------------------------------
> >> -
> >>>> --
> >>>>

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 19 Nov 2007 11:45:16 -0800

Just one request:
If you add TCP-like functionality, such as
1. congestion control
2. in-order delivery
3. checksum
4. duplicate packet detection
5. retransmission of errored or lost packets,
please make sure to add this in a separate layer.
Do not run this layer when using TCP.

If you run a congestion control algorithm in a time
scale of the same order of magnitude as the one in TCP,
together with TCP, they will interfere with each other.

Multiple retransmission algorithms also interfere
with each other.

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Mon, 19 Nov 2007 11:54:15 -0800

Sorry, perhaps my use of the term "hybrid" was wrong.
What I meant is either one or the other but certainly not overlapping each other, (having them both together).

> Sent: Monday, November 19, 2007 2:45 PM
> Cc: [email-masked]; Troester, Stephan; Busser, M; Haag, T; 
> Witschurke, Birgit
> If you add TCP-like functionality, such as 1. congestion 
> control 2. in-order delivery 3. checksum 4. duplicate packet 
> detection 5. retransmission of errored or lost packets, 
> If you run a congestion control algorithm in a time scale of 
> the same order of magnitude as the one in TCP, together with 
> TCP, they will interfere with each other.
> 
> Multiple retransmission algorithms also interfere with each other.
> 
> > In light of this, perhaps another solution might be to use 
> an hybrid 
> > version (configurable by the admin - either TCP or the 
> light weight, 
> > depending on the network topology)
> > 
> > 
> > 
> >> Cc: Wojciech Dec (wdec); Haag, T; Troester, Stephan; Busser,M; 
> >> [email-masked]; Witschurke,Birgit
> >> Subject: Re: AW: [ANCP] Splitting GSMP messages to different TCP 
> >> packets
> >>
> >> At node startup, you want to get all the Port_Up messages 
> as quickly 
> >> as possible and every port will send one. Exactly like a huge file.
> >> One scenario might have 5000 DSLAMs with 10 ports each, 
> but another 
> >> might have 5 DSLAMs with 10000 ports each. The 
> standardized solution 
> >> needs to work well for all possible scenarios.
> >>
> >> few of them overall (only one to the BRAS) while the BRAS needs to 
> >> support one for all the DSLAM connected to it, meaning 5,000 or 
> >> possibly more.
> built-in 
> >> functionality of TCP are either implemented or arrange not to be 
> >> required.
> >>> 1) Reliability
> >>>    Can be done by having sequencing/acknowledgment of any 
> messages 
> >>> sent by each
> >>>
> >>> 2) stream oriented
> could still 
> >> be there))
> >> to the BRAS. My assumption (I could be wrong) is there 
> won't be more 
> >> than a few CPEs connected to any DSLAM (up to 10, 20?). If so, the 
> >> traffic between a given DSLAM and the BRAS are made of the 
> >> "keepalive" and whatever Port up/down and other events that might 
> >> occur. If the DSLAM builts a self throttle of bulk packets, (say 
> >> limiting to 5 ANCP packets per seconds).
> >>>
> >>> What's your input Woj?
> >>>
> >>>
> discussed 
> >>>>> Subject: AW: AW: [ANCP] Splitting GSMP messages to 
> different TCP 
> >>>>> packets
> >>>>>
> >>>>> Cc: Tröster, Stephan; Busser, Michael; [email-masked]; 
> Witschurke, 
> >>>>> Birgit
> >>>>> Betreff: Re: AW: [ANCP] Splitting GSMP messages to 
> different TCP 
> >>>>> packets
> >>>>>

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Mon, 19 Nov 2007 15:02:33 -0500

It seems what you are asking for is the capability for the reciever to selectively request retransmission of a specific message from the sender. I don't think this helps.  It is possible that TCP is happy (and has ack'd) as it has receved everything in sequence and with right checksum, but ANCP receives bad data from the TCP layer (due to internal software issues such as memory corruption). In this case it is possible that the receiver doesn't know what to request from the sender. In certain cases the agreed upon behaviour should be for then receiver to send out an error notification (a standalone ANCP message indicating error that can not be recovered from), and restart the ANCP connection with the peer. 
As as aside, ANCP has the optional capability where a sender can request the receiver to acknowledge a given message (we can build retransmission logic on top).  However, this doesn't guarantee recovery from all scenarios (one outlined above is an example), and therefore doesn't buy us much beyond reliability provided at TCP layer.

-Sanjay

>Sent: Friday, November 16, 2007 3:05 AM
>To: [email-masked]
>mechanism is quite clear. 
>