Subject: [Iccrg] FW: [dccp] Sending packets out of schedule?
From: [email-masked] (Christian Hoene)
Date: Thu Oct 28 10:41:23 2010

Hi,

I ask the following questions today at the DCCP mailing list but maybe ICCRG is a good place to ask those questions, too?

With best regards,

 Christian

> Christian Hoene wrote on 2010-10-28:
>> Hello,
>> 
>> may I ask a simply question? Is it possible to send DCCP packets at
>> other times than those calculated by the rate control? I mean, is it
>> possible to call a send socket call with an option saying, send this
>> packet immediately no matter that the rate control is saying to you?
>> 
>> The role of DCCP would be to calculate the proposed sending rate and to
>> measure the network round trip time. This data is then used by an
>> application specific rate control.
>> 
>> The background of my questions is based on the experience, that real-
>> time packets shall be send immediately, especially if a scenario of
>> very interactivity is given, and that some codecs cannot change their
>> sending rate immediately but need some extra time (e.g. one or two
>> additional frame periods). Thus, a less strict sending schedule would
>> help.
>> 
> I forgot one question. DCCP only allows sending rates of 10ms but we
> need 2ms to support distribute ensemble performances over the
> Internet, which require an acoustic end-to-end of about 25 ms. Is this
> a problem?

>> Thanks for any help and comments.
>> 
>> With best regards,
>>  Christian
>> 

-----Original Message-----
From: Ingemar Johansson S [mailto:[email-masked]]
Sent: Thursday, October 28, 2010 11:34 AM
To: Christian Hoene; [email-masked]
Subject: RE: [dccp] Sending packets out of schedule?

Hi Christian

I you may want to look at the iccrg archive for a discussion on the issues with too high packet rate. I posted some very similar questions ~a month ago http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2010-September/000847.html

Regards
/Ingemar

From: [email-masked] (Lachlan Andrew)
Date: Tue Oct 26 17:59:59 2010
Subject: [Iccrg] A Wireless Channel Model Based Rate Control (WMRC) Scheme (WAS Re: present a draft)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <AANLkTik_C660fk1uUNZMVXGDbM0Z=D_Ee5=[email-masked]>

Greetings all,

Although I'm a theorist at heart, on a cursory glance I also feel that
this may be too theoretical for an IETF standard.  There are many
possible channel models (for many possible channels), and
standardizing transmission based on one should be done with caution.

IETF documents are mainly useful for issues that need agreement to be
implemented.  The main reason congestion control algorithms (as
distinct from protocols) need agreement is for "fairness".  Fairness
in systems with different channels is a very complicated issue, which
doesn't seem to be addressed in this draft.

$0.02,
Lachlan

2010/10/27 Ingemar Johansson S <[email-masked]>:
> Hi
>
> I have briefly read through this draft. To me it seems to be quite teorethical and rely on the assumption that wireless access generally suffers from packet loss.
> My opinion is that with 3GPP access, at least for OTT (over the top) transmission, non-congestion related loss is relatively rare. One can for instance refer to 3GPP TS 23.203 http://www.3gpp.org/ftp/Specs/archive/23_series/23.203/23203-a10.zip table 6.1.7 (page 32).
> Best effort traffic is typically meant to be transported over a QCI=9 bearer. The packet loss rate is targeted at 10^-6. These bearers can drop packet as a result of congestion but as said before non-congestion related losses are expected to be rare.
>
> I have no opinion regarding other wireless access types however.
>
> Have you been able to test this algorithm in a real system ?, one possible problem I see is that one build a model of a system based on past data, as users move around this model may only be fairly correct as long as the user stays in one cell. As soon as the user makes a handover to another cell the model may change completely.
>
> /Ingemar
>
>
>> Message: 1
>> Date: Mon, 25 Oct 2010 21:05:47 +0200
>> From: Michael Welzl <[email-masked]>
>> Subject: Re: [Iccrg] present a draft
>> To: "[email-masked] list" <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
>>
>> ...so what's the group's opinion on this proposal?

-- 
Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Ingemar Johansson S)
Date: Tue Oct 26 14:11:54 2010
Subject: [Iccrg] A Wireless Channel Model Based Rate Control (WMRC) Scheme (WAS Re: present a draft)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

From: [email-masked] (Ingemar Johansson S)
Date: Tue Oct 12 08:35:58 2010
Subject: [Iccrg] RE: TFRC-SP and maximum packet rate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

Sorry about the delay. I have read the report below and it answers a lot of questions. My take is that even though TFRC may sometimes fail to be 100% fair against TCP it is anyway a lot better than nothing. I am very interested in your work so if you can send me a draft copy of your work I'd be more than happy.
>From my (wireless) perspective I still have some concerns as regards to how fast TFRC can react to the higher dynamics of for instance 3GPP access like LTE or HSDPA/EUL. I can imagine that one may need an additional emergency break to cope with this but I have no real work done to prove my point.

Some additional info:
My interest in TFRC is given by the initiative from Google et al to bring real time communication to the web platform (see http://www.alvestrand.no/mailman/listinfo/rtc-web )
My main interest in this area is congetsion control, a feature that I believe is very important as the real time media will in this case share the same bottlenecks as TCP. 

/Ingemar 

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:[email-masked]] 
> Sent: den 21 september 2010 13:59
> To: Ingemar Johansson S
> Cc: iccrg; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: TFRC-SP and maximum packet rate
> 
> Hi,
> 
> > 
> > An issue with modern video codecs is that they produce frames with 
> > larger differences in frame size. For instance I-frames may 
> be so big 
> > that they need to be split up in several packets (for PMTU reasons) 
> > while B- and P-frames are considerably smaller. The effect 
> of this is 
> > that even though the framerate of the video is 30Hz, the 
> packet rate 
> > may be considerably higher when I-frames are transmitted. 
> But I guess 
> > the only way to determine how TFRC-SP works in these cases 
> is to try 
> > it out.
> 
> You are right - the packet size will significantly vary 
> depending on the types of the frame (I, B, or, P) and video 
> content as well. As I said earlier, using TFRC-SP for video 
> streams without a modification may break the (proportional) 
> flow-level fairness when competing with the standard TCP flows.
> 
> There is another similar work that studied TFRC performance 
> with the variable packet sizes - 
> <http://www.icsi.berkeley.edu/ftp/pub/techreports/2000/tr-00-008.pdf>
> This work also mentioned the fairness issues and solve the 
> problem by estimating the mean packet size (assuming PMTU is 
> known a priori).
> 
> However, it is unclear to me as to how much the approximated 
> packet size is meaningful to the calculated send rate 
> (because, the frame sizes are so varying as we know).
> 
> I have an on-going work to solve these problems by 
> re-introducing the TCP-like Ack-clocking mechanism while 
> retaining the smoothness property in the send rate (of 
> course, for the interactive video streaming applications). I 
> should be able to publish the results somewhere in the next 
> month or so. If you are interested, I can send you the draft 
> copy sometimes early next month.
> 
> 
> Cheers,
> Soo-Hyun
> 
> 
> 
> 
> 
>From [email-masked]  Wed Oct 20 10:24:47 2010
From: [email-masked] (=?GB2312?B?1dS6o8zO?=)
Date: Wed Oct 20 11:59:29 2010
Subject: [Iccrg] present a draft
Message-ID: <[email-masked]>

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-dong-wmrc-rtpcontrol-00.pdf
Type: application/pdf
Size: 81963 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20101020/8f2e019b/draft-dong-wmrc-rtpcontrol-00-0001.pdf
>From [email-masked]  Mon Oct 25 20:05:47 2010
From: [email-masked] (Michael Welzl)
Date: Mon Oct 25 19:57:56 2010
Subject: [Iccrg] present a draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

...so what's the group's opinion on this proposal?

Cheers,
Michael

On Oct 20, 2010, at 11:24 AM, ??? wrote:

> Dear chair:
>
> We  have written this draft in the attachment.
> We would like to standardize it and would be thankful for comments.
> We hope that you can send the email to the ICCRG list. Thank you  
> very much!
>
>
>  Sincerely Yours,
>  Yu-ning Dong, Hai-tao Zhao
>  Best regards!
> <draft-dong-wmrc- 
> rtpcontrol-00.pdf>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Aaron Falk)
Date: Fri Oct  1 14:24:54 2010
Subject: [Iccrg] Request to publish  draft-irtf-iccrg-welzl-congestion-control-open-research-08
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

 RFC Editor-

Please publish draft-irtf-iccrg-welzl-congestion-control-open-research-08 as an Informational IRTF RFC. The document has been approved for publication by the IRSG and also reviewed for IETF conflict by the IESG. See http://trac.tools.ietf.org/group/irtf/trac/ticket/29 for details on the IESG and prior reviews. Please copy all correspondence to the document shepherd, Wesley Eddy,  [email-masked].

The authors would like to have a few edits made as described by the message below.

--aaron

---
Aaron Falk
Chair
Internet Research Task Force
http://www.irtf.org

On 9/29/10 5:43 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> Hi Aaron, the ICCRG document on open research issues in
> Internet congestion control has been through the IESG's
> review and is now ready for submission to the RFC Editor.
>
> The authors and IESG agreed on the following request to
> the RFC Editor for modification of the draft prior to
> publication as an RFC (which they would like the RFC
> Editor to handle, rather than submit another revision):
>
> RFC Editor Note
>
> (1) Replace beginning of Section 3.5.3 with:
>
>   3.5.3 Inelastic Multi-domain Pseudowires
>
>   Extending pseudo-wires across multiple domains poses specific issues.
>   Pseudowires (PW) [RFC3985] may carry non-TCP data flows (e.g. TDM
>   traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain 
>   IP network. Structure Agnostic TDM over Packet (SATOP) [RFC4553], 
>   Circuit Emulation over Packet Switched Networks (CESoPSN), TDM over 
>   IP, are not responsive to congestion control as discussed by
>   [RFC2914] (see also [RFC5033]). The same observation applies to ATM 
>   circuit emulating services (CES) interconnecting CBR equipment (e.g. 
>   PBX) across a Packet Switched Network (PSN).
>
>   Moreover, it is not possible to simply reduce the flow rate of a TDM
>   PW or an ATM PW when facing packet loss. Providers can rate control 
>   corresponding incoming traffic but they may not be able to detect 
>   that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing 
>   the traffic temporal properties may not necessarily be supported). 
>
>   This can be illustrated with the following example. 
>
>
> (2) Add at the end of Section 3.8.4 Congestion Control in Multi-layered Networks
>
>   Section 3.5.3 deals with Inelastic Multi-domain Pseudowires (PW), 
>   where the characteristics of the Pseudowire itself determines the 
>   characteristics of the traffic crossing the multi-domain PSN 
>   (and this independently of the characteristics of the traffic 
>   carried in the PW). A more complex situation arises when inelastic 
>   traffic is carried as part of a Pseudowire (e.g. inelastic traffic 
>   over Ethernet PW over PSN) whose edges do not have the means to 
>   characterize the properties of the traffic encapsulated into the
>   Ethernet frames. In this case, the problem explained in 
>   Section 3.5.3 is not limited to multi-domain Pseudowires but more 
>   generally induced by "Pseudowire carrying inelastic traffic" (over 
>   a single- or multi-domain PSN). The problem becomes even more
>   intricate when the Ethernet PW carries both inelastic and 
>   elastic traffic. Addressing this issue further comforts our 
>   observation that a general framework to efficiently deal with 
>   congestion control problems in multi-layer networks is absolutely
>   necessary but without harming its evolvability.
>
> --
> Wes Eddy
> MTI Systems
>
>
>