Cullen, thx for the reply, will respond to you shortly. alice
> -----Original Message----- > From: Cullen Jennings (fluffy) > Sent: Monday, 21 August, 2006 17:17 > To: Maria A. Dos Santos (mariados) > Cc: [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; Jari Arkko; Mark Townsley > (townsley); Romascanu, Dan (Dan) > Subject: Re: Latest updates : draft-ietf-l2tpext-pwe3-ethernet-08.txt > > > My apologies - I did not realize there was text for me in > this email till I got the ping today :-) More inline ... > > On Aug 4, 2006, at 12:03 PM, Maria A. Dos Santos ((mariados)) wrote: > > > > > ############################################################## > ############# > *Cullen Jennings:* > *Discuss:* > *[2006-07-05]* I may not understand the congestion > control technique but > it looks like it says, "in case of congestion, pull > the plug". I don't > believe anyone will implement this congestion > control suggestions - and > if they do, I don't believe the resulting systems > will be usable - they > will be impossible to manage not to mention the > incredible DOS > opportunities. No advice on the threshold is > provided. I think this > needs to be updated to either be clear no congestion > control is provided. > > From what I understand, the draft is inline with the > current state of congestion > control for emulation technologies, and PWE3 WG is > currently conducting > further study on the topic. Once we get the result of > that, this draft > and all other pwe drafts (both l2tp and mpls) will > leverage from that > mechanism. So at this point, the goal of the > "Congestion Control" section > in this draft is only to emphasize the possibility of > congestion and provide > some general best-effort recovery mechanisms. Would it > be better if I emphasize > the goal? > > > I'd have no problem with something along the lines of: > > This specification offers no congestion control and is not > TCP friendly <add ref to where TCP Friendly is define>. > Future works, such as <insert non normative reference that > will not block your document>, may extend this to provide > congestion control. > > > > > I am not sure what general default threshold is > appropriate given that the threshold will > vary according to network size and average traffic load > of individual network. That's why > it is left undefined and left to administrator to experiment. > > > Hmm - I know something about networks and I have no idea how > I would set up the parameters such that they would work and > not mess up other protocols on the same network. I understand > that how you might want the parameters on a satellite link, > vs a corporate switched LAN, to be somewhat different. I view > the problem with selecting numbers here is that no matter > what you pick, it is clear many people will disagree with it > and there will be cases where it does not work. That is > typically a sign that algorithm might be less than ideal > regardless of the parameters. However, if we are agreed that > for practical deployments and implementation, we expect that > PWE will not have automated congestion control, then I have > no real problem with the text you have here and we can just > ignore trying to figure out if this provides enough advice > that anyone will be able to get something that works. > > > > > The section titled "Applicability Statement" gives > me no idea where this > is applicable and where it is not. > > Would you mind elaborating what information are you > expecting here? > > > > I might have this wrong but talking to people I get the idea > that the expectation is that this protocol will be used > across the public internet as well as private networks and > will be used for many things including forming virtual > network connection between remote offices for enterprises. > > > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
