Subject: RE: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt

From: <[email-masked]>
Date: Mon, 12 Jun 2006 09:25:30 +0100

Ronen Soloman agreed with this remark from David Black:

> I would also observe that a retransmission protocol designed for a
> fixed- bandwidth mostly-reliable virtual circuit (where 
> losses are indication of link quality issues, not network 
> congestion) may not be appropriate for a variable-bandwidth 
> pseudo-wire on which losses need to be viewed as indicators 
> of possible network congestion.

There are some key architectural reasons why the above observation is
both correct and important.  These stem from the fact that in a
correctly architected co-cs or co-ps mode layer network technology we
have this object called a 'connection' (see G.805 func arch for
definition).  A connection MUST have these properties:
-	single source
-	connectivity = 1

This means ONLY p2p and p2mp connections are allowed in a properly
architected co-cs or co-ps mode layer network.  Further, because of the
nature of labelling in the co-cs mode it is NOT POSSIBLE to violate the
above connection properties.  However, one can violate these properties
in the co-ps mode...indeed both LDP mp2p LSPs and the action of PHP in
MPLS cause a merging behaviour which violates the required connection
property of a single source.  This requires a higher layer entity to
effect the demerging....and in the case of MPLS (and when the client is
NOT IP) this requires the running of a p2p PW entity (see Note) ABOVE
MPLS.

Note - If the PW is precisely 1 hop then the PW entity is simply an
adaptation function, ie it is NOT a networked entity per se.  If however
the PW is > 1 hop then a new PW layer network is created, and the PW
entity is a new PW connection in this new co-ps PW layer network, ie it
is now a networked entity.  This is a major step-change in behaviour
please note.  Moreover, also carefully note that because of the merging
behaviour in LDP/PHP then MPLS labels do NOT have consistent semantics
at all levels.  This can have some 'interesting implications' if defects
cause labelled MPLS PDUs at different levels to become misconnected.

Note also that in a properly architected co-cs or co-ps mode layer
network then once a connection has been established then all routing
choice is removed from that connection.  A key corollary of this is that
any new nodes or links that are added to a properly architected co-cs or
co-ps mode layer network DO NOT affect ALREADY ESTABLISHED connections.
This is a critical requirement in co-cs and co-ps mode layer networks to
ensure deterministic traffic behaviour.  This requirement is not
satisfied however in cl-ps mode layer networks (eg IP and native
ethernet) nor MPLS LDP since this also tracks the SPF behaviour of the
IGP.

All these factors mean that the deterministic traffic/fault/performance
behaviour one gets from a properly architected co-cs or co-ps mode layer
network is NOT possible in MPLS as-is.

So I would say we can state far stronger architectural reasons why what
David Black originally observed is correct.

regards, Neil

> -----Original Message-----
> From: Ronen Solomon [mailto:[email-masked]] 
> Sent: 11 June 2006 15:33
> To: [email-masked]; [email-masked]; Moran Roth
> Cc: Leon Bruckman; Luis Aguirre-Torres; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [PWE3] RE: draft-ietf-pwe3-fc-encap-00.txt
> 
> 
> David, 
> 
> I agree with your inputs. Additionally I would add to the 
> IETF FCoMPLS draft the modification required for the 
> transmitter throughout equation ( to be used in controlled 
> and non-controlled environment i.e. CIR/EIR as described in 
> the draft), and 'reciverNotReady' feedback. With respect to 
> the feedback , LAPB uses the SR_SREJ (selective reject) 
> indication to signal the transmitter on the lost frames. This 
> is used similarly as a receiver-transmitter indication to 
> allow the transmitter to adjust its throughout.  The SR_REJ 
> indication is an input to the transmitter throughout equation. 
> 
> We shall have the FCoATM LABP indications (SR_SREJ , SR-RR 
> and SR_RNR) documented in the FCoMPLS draft clearly with 
> respect to throughput adjustment and TFRC for review. 
> 
> Awaiting your inputs 
> 
> Regards, 
> 
> Ronen
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 07, 2006 5:22 PM
> To: Ronen Solomon; [email-masked]; Moran Roth
> Cc: [email-masked]; Luis Aguirre-Torres; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: draft-ietf-pwe3-fc-encap-00.txt
> 
> Ronen,
> 
> > David/Mark , please have in your inputs whether we could proceed  in
> > this direction. Your inputs are much appreciated.
> 
> While I'll have to look at other aspects in more detail, 
> based on slide 3, my immediate reaction is that the order of 
> the SR (selective retransmission
> - proposed for T11 standardization) and RS (Rate Shaping - 
> proposed for IETF standardization) components is backwards 
> because the rate shaping is shown upstream of the 
> retransmission.  The result cannot be TFRC-compliant because 
> TFRC controls the entire sending rate, including 
> retransmissions. A mechanism that retransmits in response to 
> loss without regard to the congestion consequences of doing 
> so has the effect of increasing the rate of traffic in 
> response to indications of congestion, which is not the 
> proverbial "right thing" to do.  Among the important 
> consequences of this is that under TFRC, the fact that a 
> packet has been transmitted does not grant an unfettered 
> right to retransmit it until its reception is acknowledged.
> 
> At a minimum, to reuse the T11 FCoATM SR mechanism, it will 
> be necessary to document the following in the IETF draft:
> - How the SR mechanism carries the receiver-to-sender 
> information required
> 	by TFRC.
> - How the combination of SR and RS mechanisms deals with loss 
> of feedback
> 	information (cf. Section 4.4 of RFC 3448).
> 
> I would also observe that a retransmission protocol designed for a
> fixed- bandwidth mostly-reliable virtual circuit (where 
> losses are indication of link quality issues, not network 
> congestion) may not be appropriate for a variable-bandwidth 
> pseudo-wire on which losses need to be viewed as indicators 
> of possible network congestion.  
> 
> I will look at the slides and current draft in more detail as 
> time permits over the next few weeks.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> > -----Original Message-----
> > From: Ronen Solomon [mailto:[email-masked]]
> > Sent: Wednesday, June 07, 2006 6:43 AM
> > To: Stewart Bryant; Moran Roth; Black, David
> > Cc: Danny McPherson; Luis Aguirre-Torres; Ronen Solomon;
> > [email-masked]; [email-masked]; 
> [email-masked]
> > Subject: RE: draft-ietf-pwe3-fc-encap-00.txt
> > 
> > Stewart
> > 
> > Following the last T.11 meeting where the NSP function of 
> the FCoMPLS
> > has been proposed it was suggested by David Black that the 
> bandwidth 
> > congestion management (i.e. Selective retransmission and 
> rate shaping)
> 
> > would be part of the IETF work. Currently the FCoMPLs draft includes
> > an applicability section that described the requirement of 
> the network
> 
> > in terms of delay and QoS , while the bandwidth congestion 
> management
> > is part of the NSP.
> > 
> > Moran and I however adopted the FCoATM-VC congestion control SR
> > mechanism already standardized by the T.11 which similarly 
> defines the
> 
> > efficient selective re-transmission (SR) and therefore 
> propose to have
> 
> > RT ( Rate shaping) adopted by the IETF ,while preserving the SR from
> > the
> > T.11 with a clear interworking.  Note that the SR as defined for 
> > FCoATM by T.11 has already been optimized to assure the need of the 
> > fiber channel transmission over virtual circuit such as 
> overhead and 
> > round trip effectiveness and therefore can be similarly 
> implemented by
> 
> > FCoMPLS. The Rate shaping, on the other hand, could be implemented
> > according to the IETF standard while defining the exact 
> interworking 
> > the SR and RS.
> > 
> > We would like to discuses this direction at the next IETF to have a
> > constant view and direction among all.
> > 
> > David/Mark , please have in your inputs whether we could proceed  in
> > this direction. Your inputs are much appreciated.
> > 
> > Regards,
> > 
> > Ronen
> > 
> > I have also CC'd the FC-BB chair and editor.
> > 
> > 
> > FYI
> > 
> > FC-BB-4 Ad Hoc Group Meeting Report
> > Santa Fe, NM; 6th April, 2006 (06-334v0)
> > 
> > "Moran Roth (Corrigent) presented contribution 06-022v1 which is a
> > follow up to the initial contribution into the previous meeting and 
> > attempts to address issues raised earlier. Discussions 
> centered on the
> 
> > previous assessment that a clear demarcation is needed between the
> > functionalities falling within the scope of T11 and IETF. 
> The IETF is 
> > responsible for specifying the PSN, PW label and CW. A number of 
> > issues were identified.
> > 
> > Regarding congestion control, it was agreed that SR (Selective
> > Retransmission) and RS (Rate Shaping) must interwork properly. There
> > is a need to understand the exact relationship between the 
> RS and SR 
> > mechanisms and also the scope of T11 and IETF (PWE3) 
> responsibilities.
> > Dave Black informed the meeting about two related RFCs 
> which need to 
> > be taken into account: RFC 2914 (Congestion Control Principles) and 
> > RFC
> > 3448 (TRCP - TCP-friendly rate control protocol). The 
> initial view of 
> > the meeting was that the two functions (SR and RS) fall 
> into the remit
> 
> > of IETF. Thus congestion control is being handled in IETF 
> and we need
> > to be consistent with the relevant RFCs. The intent is to be 
> > consistent or compliant with these RFCs. Given this, it was decided 
> > that SR and RS need to be removed from the scope (and text) of 
> > FC-BB-4. The editor was actioned to examine this and make a proposal
> for the next meeting."
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stewart Bryant [mailto:[email-masked]]
> > Sent: Thursday, June 01, 2006 1:56 PM
> > To: Moran Roth; Ronen Solomon
> > Cc: Danny McPherson
> > Subject: draft-ietf-pwe3-fc-encap-00.txt
> > 
> > Is draft-ietf-pwe3-fc-encap-00.txt ready for cross area review yet?
> > 
> > BTW you will need to provide an email for Munefumi Tsurusawa as when
> > this goes to RFC he will need to sign-off on the 48hr review.
> > 
> > Regards
> > 
> > Stewart
> > 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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