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

From: "Ronen Solomon" <[email-masked]>
Date: Sun, 11 Jun 2006 16:32:36 +0200

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

---

From: [email-masked]
Date: Thu, 15 Jun 2006 14:16:58 -0400

Ronen,

> Awaiting your inputs 

Here's the next round of input on this.  The T11.3 FC-BB-4 working
group is responsible for standardization of the Fibre Channel aspects
of the Fibre Channel pseudo-wire.  In my role as (what passes for)
liaison between T11 and IETF, I can report that the FC-BB-4 working
group just met this morning (in Anchorage, Alaska, where it's still
morning), and has essentially reiterated its conclusions on SR
(Selective Retransmit) and RS (Rate Shaping) from prior discussion
(in April) as reported below:

> > The initial view of the [April] meeting was that the two functions
> > (SR and RS) fall into the remit
> > FC-BB-4.

The current status is that FC-BB-4 believes that SR and RS should be
specified together, and specified by IETF since TCP-friendliness
(traffic
behavior in response to congestion) is considered to be important.  SR
has been removed from the FC-BB-4 working draft as the protocols that
use SR (e.g., FCoATM) are considered mature and will not be further
revised.  The existing FC-BB-3 SR text probably needs attention if
it is to be reused.  There should be no problem in importing that SR
text
into an IETF draft, but referencing it in its existing form in the
FC-BB-3 standard is not a recommended approach.

It is also important that Corrigent attend the next BB-4 meeting in
Calgary
in August in order to make progress on the FC aspects of the
pseudo-wire.

I will take a look at the current FC PW draft and comment on it in
a separate message.

Thanks,
--David

> Sent: Sunday, June 11, 2006 10:33 AM
> To: Black, David; [email-masked]; Moran Roth
> Cc: [email-masked]; Luis Aguirre-Torres; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Leon Bruckman

retransmission
required
feedback

the

RFC